Accessibility evidence starts where the screenshot stops

Test a named journey

Choose one complete user task, such as finding an item, opening its details, submitting a form, and recovering from an error. A screenshot can support visual comparison, but it cannot show focus order, accessible names, announcements, keyboard traps, or whether content survives zoom. WCAG 2.2 requires keyboard operability for functionality and programmatically determinable names, roles, values, and state changes. Turn those requirements into observations along the journey.

Record viewport, browser, zoom, input method, assistive technology and version where relevant, test data, and expected outcome. Keep evidence tied to the changed flow. A site-wide conformance claim requires a much broader evaluation than one engineering pass.

WCAG 2.2 ↗

Follow focus, semantics, and feedback

Complete the journey with keyboard input alone. Verify that focus is visible, moves in a meaningful order, enters and leaves composite widgets predictably, and returns sensibly after a dialog closes. Inspect the accessibility tree or equivalent platform view for each control's name, role, state, and relationship. Trigger validation and asynchronous updates, then confirm that the information is available without relying only on color or visual position.

Native elements usually carry behavior that a styled generic element does not. The WAI-ARIA Authoring Practices Guide explains that authors must implement keyboard support for custom ARIA widgets. Its examples are instructional rather than a guarantee of production interoperability, so match a known pattern and test the combinations relevant to the audience.

ARIA keyboard interface guidance ↗

Use automation as a fast filter

Run automated rules against the actual rendered states, including opened menus, errors, loading states, and completed forms. Add DOM-level assertions for important accessible names and states so regressions are visible in CI. Automation is good at repeatable syntactic checks, but it cannot determine whether heading text is useful, focus movement is understandable, alternative text communicates the right purpose, or the journey makes sense with speech output.

An agent may propose many ARIA attributes to satisfy a scanner. Review whether those attributes override correct native semantics or advertise behavior the component does not implement. More accessibility markup can make a control worse when code and semantics disagree.

Publish bounded evidence

A useful handoff includes the tested journey, standards criteria, automated findings, keyboard notes, assistive-technology observations, screenshots as supporting context, and unresolved combinations. For a hypothetical account form, that might include label association, error-summary focus, field-level descriptions, keyboard submission, and status announcement after save. It should not say accessible because a scanner returned zero findings.

Limitations belong beside the result. Browser and assistive-technology support varies, the APG cautions developers to perform their own testing, and disabled users' experience cannot be reduced to a checklist. Prioritize direct user research for critical services and unusual interactions. Retest after component-library, routing, or focus-management changes because visually unchanged screens can acquire interaction regressions. Preserve defect steps and expected announcements so later reviewers can repeat the same journey. No accessibility evaluation was run for this article.

APG assistive-technology support and testing ↗