Define the change and the prior evidence
The fictional Fieldnotes header changes a link from “About” to “Our story.” Its href="#about", surrounding links and embedded CSS stay the same. The new words appear on home, pricing and help at both captured widths.
The prior evidence scenario is a reviewer checking that people can identify the link's purpose, reach it by keyboard and follow it to the intended section. That historical review is illustrative: no named person or completed customer audit is claimed. Actual browser captures and DOM observations are supplied by the navigation experiment.
Scope matters. This fixture uses one wrapping navigation, not a collapsed menu. It does not test a mobile menu button, a dialog, logged-in account links, a screen reader or translated labels. A real site's separate menu implementation would need its own evidence.
Make an evidence-level decision
Scroll horizontally to see all columns.
| Earlier evidence | Decision for this change | Reason | Next check |
|---|---|---|---|
| Link name and purpose | Affected | The tested words changed | Read the new name with its destination and context |
| Keyboard path through this navigation | Retest | The component changed; captures do not exercise the task | Tab through, activate the link and inspect focus |
| Distinct collapsed mobile menu | Not tested | This fixture has no such state | Test the actual site's separate menu if it exists |
| Unrelated form validation | Cannot determine from this example | No form target, state or baseline chain is supplied | Check its own preserved evidence and dependencies |
| Unchanged paragraph target with a proven baseline | Eligible for comparison, not automatic approval here | A screenshot alone does not prove target, context and styles match | Inspect the exact binding and lineage |
“Affected” identifies evidence that no longer describes the same target. It does not mean a WCAG failure has already been established. “Uncertain” describes an inability to establish continuity. It must remain visible until a reviewer has enough evidence to resolve it.
Run the retest as a task
- Open the after version and locate “Our story.” Decide whether the wording identifies the destination in this context. W3C's Link Purpose (In Context) explains the requirement.
- Use Tab and Shift+Tab to reach the link. Confirm its focus is visible and its position in the sequence makes sense. Activate it with the keyboard and confirm the expected section is reached.
- Inspect the accessible link name with the browser accessibility tools and the assistive technology in your evaluation scope. Compare the announced name and role with the visible control. See Name, Role, Value.
- Repeat at the actual responsive states used by the site. If a menu collapses, check opening, closing, focus movement and return. Do not check a box for a state that does not exist in the evidence.
- Save the browser, assistive-technology version, viewport, task, result and artifacts. Use “not tested” for work you did not perform and “cannot determine” when the available evidence cannot support a decision.
These are proposed manual retest steps. The editorial harness extracted text and metadata and ran an automated scan; it did not conduct a human screen-reader evaluation. W3C explains why knowledgeable human evaluation remains necessary.
How OnChange treats continuity
OnChange's evidence impact comparison is conservative. A target can be marked unaffected only when its preserved baseline belongs to the exact previous artifact and its target, accessibility context and stylesheet evidence remain equivalent. All bound targets must meet the requirement. Changed or removed targets are affected; missing lineage, missing style evidence or changed style archives can make the result uncertain.
In this example, the link's name changed. A screenshot, a passing automated scan or a shared navigation group does not supply a reason to carry its prior approval forward. Keep the original evidence attached, add the new observation and reopen the necessary retest. A reviewer override needs a reason tied to evidence.
Reuse the worksheet
Download the editable CSV worksheet or plain-text worksheet. Record one task or evidence item per row. Include the exact target, previous artifact, new artifact, dependencies, status, owner and rationale. Leave the reviewer blank until someone actually performs the review.
For this case, start with nav a[href="#about"], the before and after navigation fixtures, and the purpose/keyboard task. Add real application URLs and preserved artifact identifiers when using the worksheet in your own process. Do not convert an illustrative example into a completed audit record.
Sources and review status
Published by OnChange on 13 October 2026. This is an editorial worked decision based on controlled fixtures, product behavior and the linked W3C guidance. It is not an independent accessibility audit or a claim of conformance. No human specialist sign-off is represented. Initial edition; no prior revisions.
The recorded environment is Chrome 155.0.8059.40 on macOS, 1440 × 900 and 390 × 844, scale 1, captured 13 October 2026 at 17:14 UTC. Exact observations and timestamps are in the evidence JSON. Read the related W3C explanations for Keyboard and Focus Visible when defining your own test scope.