Skip to main content :::
:::

Weekly Accessibility Review for Website Maintainers

A weekly accessibility review should not repeat a full audit. It should use reports, interaction events, latest scan state, and recent changes to identify the pages worth reviewing first.

Last updated:

Summary

  • A weekly review is not meant to prove conformance. It helps maintainers know which pages to review first this week.
  • Start with this week’s reports and interaction events, then combine them with current latest scan state, recent changes, and important flows.
  • Latest scan state is not a newly found issue this week. It is the most recent stored scan summary for that page and should be read separately from recent events.

The weekly report should answer: where should we look first?

A weekly accessibility review should not become a score-watching exercise. A more practical goal is to find which pages or flows are most likely to stop users from getting something done, then spend limited maintenance time there.

A useful weekly report should separate “new maintenance clues this week” from “current page scan state.” The first tells you where something happened recently. The second tells you what machine-detectable risks are currently stored for those pages.

Six signals worth reviewing each week

The following signals are not a full audit, and none of them proves a page is broken by itself. Their value is helping maintainers narrow the review area and decide where to look first this week.

  • User reports: someone describes where they could not understand, activate, submit, or complete something.
  • Priority pages: Pulse orders these by interaction events and scan summaries, not directly by Signal reports. Review reports separately and adjust your review order to the task involved.
  • Repeated interaction clues: repeated clicks, possible keyboard dead interactions, focus reversals, Escape close difficulties, or repeated keyboard loops may indicate that a flow needs review.
  • Latest scan state: start with findings the tool labels critical or serious and those related to WCAG A/AA, then review best-practice suggestions. Critical and serious are the scanner’s impact labels, not WCAG conformance levels. Stored results are not necessarily new this week.
  • Recently changed pages: pages with updated copy, components, forms, third-party embeds, campaign content, or authenticated states.
  • Important flows: even without many signals, periodically review login, checkout, search, forms, and support contact paths.

Do not treat every signal as equally severe

When signals pile up, maintainers can easily lose track of where to start. A better ordering method is to ask how likely the issue is to affect task completion and whether several signals point to the same place.

For example, a checkout page with a user report this week, keyboard events, and serious scan state should usually come before a low-traffic content page with only a minor scan suggestion. A single signal does not always mean something is wrong; it may simply tell you what to verify.

When should human review happen?

If a signal involves a flow, semantics, focus, error states, image alt text, or whether users can complete a task, numbers alone are not enough. Someone should open the page and try the flow.

DevCheck can support this browser-based preliminary review through visual simulations, manual review aids, axe-core scans, image alt text suggestions, or PDF structure signals. But maintainers still need to judge whether the flow actually works for people.

A simple weekly review rhythm

If the team has limited time, start with 30 minutes. The goal is not to finish everything. The goal is to prevent accessibility risks from accumulating until the next large redesign or formal audit.

  • Start with new user reports and check whether any issue blocks task completion.
  • Review Pulse’s priority page list alongside Signal reports and recent changes. A concrete report of a blocked task need not wait for its page to appear in the list.
  • Compare against pages changed or added this week and decide whether they need review.
  • Choose 1 to 3 pages for human review, starting with keyboard use, focus, error messages, and main interactions.
  • Route confirmed issues to the closest source: content, design, engineering, third-party service settings, or component systems.
  • Record an owner, the next review date and why any item is deferred; after a fix, repeat the original task steps.

Example: a filter page with events but no scan findings

The weekly report example uses a fictional /products/filter page: 11 events across 4 page views, with no findings in its latest scan. Pulse groups events by a random identifier that exists only in that page's memory; a page view is not a person or a completed or failed task. The example therefore does not establish four failed users or diagnose a broken control.

Check whether the event period and scan date cover the release being reviewed. Then use a keyboard to reach the filter, choose a condition, update results and move to the next control. Record focus, result updates, and error or loading feedback. Use a real screen reader when checking announcements.

If you reproduce lost focus, send those steps to the component owner. If you cannot reproduce it, record the environment and unknown conditions; neither label the clue resolved nor turn it into a confirmed failure.

Next week: verify the fix, not just a lower count

In your existing issue tracker, record the page and state, clue date, reproduction steps, expected and actual results, owner, fix, re-test environment, and status: needs review, reproduced, fixed awaiting re-test, or re-test passed. This is your maintenance record, not a ticket Pulse creates automatically.

Use the fixed version to repeat the original task and check related flows using the same component. Re-scan machine-checkable items directly; do not wait for a new Pulse summary before verifying the fix.

Pulse caches scans rather than scanning on every visit. No new events may mean nobody reached the same state, while an old saved scan does not establish that a fix failed. Use dates, page versions and actual re-test results; a weekly count decrease is not proof of a better experience.

Related pages