A release can invalidate accessibility evidence even when the page looks almost unchanged. A button can lose its accessible name, focus can move to the wrong place, or an error message can stop being associated with its field. The opposite is also possible: a visible copy change may leave an earlier interaction result relevant.
Retesting works best when release changes are connected to the behavior that was evaluated. Use that relationship to choose the next checks, and keep uncertainty visible when the connection cannot be established confidently.
Start with the changed behavior and its reach
Collect the release description, affected components, page examples, and any preserved before-and-after evidence. Ask what a person can now see, hear, focus, activate, or complete differently. This helps turn a technical change list into a testable set of questions.
Distinguish local changes from shared ones. Updating one article may affect a single content example. Updating a form control used across the application can affect many journeys. A stylesheet change can have a broad reach even if only one file changed.
Do not assume that a missing change record means nothing relevant changed. If the release information is incomplete, record that limitation and widen the review around the affected area. A focused retest depends on trustworthy information about the change.
Map changes to earlier evidence
Use a simple matrix to connect each change with the observations that might depend on it. This illustrative table is a planning aid, not an automatic rule engine or a substitute for evaluator judgment.
| Release change | Evidence to reconsider | Useful retest |
|---|---|---|
| Dialog implementation replaced | Keyboard sequence, focus entry and return, naming | Open, operate, close, and resume the surrounding task |
| Form validation rewritten | Error identification and field associations | Submit invalid data, discover errors, correct them, and continue |
| Shared typography or colors changed | Contrast, text resizing, wrapping, focus visibility | Inspect representative contexts and relevant display conditions |
| Navigation reordered | Focus order and route discovery | Traverse links and controls through the intended sequence |
| Content-only edit | Heading structure, link purpose, alternative text where changed | Review the edited content in context |
For example, the WCAG understanding document for focus order explains the relationship between sequential navigation and meaningful operation. A screenshot cannot establish that sequence; test it through interaction when the relevant structure changes.
Define a retest unit people can reproduce
“Check the checkout” is too broad for a focused retest and too vague for a completed record. Describe the starting state, task, relevant conditions, and expected outcome. Reference the original evidence where one exists.
A better unit might be: “From the delivery step, submit without a postcode, find the error using the agreed keyboard and screen reader setup, correct the value, and continue to payment.” The unit describes the behavior, not just the page.
Keep the complete process in view even when the initial defect is local. Fixing the error announcement is not enough if the repair prevents progression to the next step. Include nearby interactions when they share the changed code or could plausibly be affected by the fix.
Distinguish automated signals from evaluation results
An automated scan can identify some regressions quickly and provide repeatable evidence. A clean result does not cover every manual interaction, and a visual difference does not by itself establish an accessibility failure.
Use each signal to choose a question. A new contrast finding needs examination in its actual context. A changed accessible name may require checking whether the new name remains appropriate. An unchanged screenshot says little about programmatic relationships, which are discussed in Understanding Name, Role, Value.
OnChange's accessibility assurance workflow can help connect captured changes with recorded evidence. Treat its impact information as review support. Where the relationship is uncertain, investigate it; do not convert uncertainty into an automatic approval.
Record outcomes without erasing history
Keep the earlier evaluation and add a new result against the released version. Include the reviewer, date, test conditions, and evidence. The history should show what was true before the release and what was verified afterward.
Use distinct outcomes for confirmed current, needs remediation, partially resolved, and unable to verify. If an earlier test no longer applies because the interface was removed, explain that decision. If a replacement interface exists, create the appropriate new test rather than inheriting the old approval by default.
The evidence handoff guide provides a structure for these records. Stable identifiers make it possible to follow the same issue through investigation, implementation, and retesting without relying on a changing report filename.
Decide when the sample needs to expand
A narrow retest is appropriate only while its assumptions hold. Expand the review when a shared component changes, a new workflow appears, the page structure differs substantially, or the original sample no longer represents the product.
Revisit the sample rationale, not just the old URL list. A page can keep its address while becoming a different interface. Conversely, a moved page can preserve much of its behavior but still need checks around navigation and context.
Before closing the release review, confirm that each material change has either a completed check or an owned follow-up. Record outstanding limitations alongside the decision. This gives the next reviewer a usable starting point and keeps accessibility evidence connected to the website people actually use.