Release field note

Website accessibility testing: a practical, evidence-led workflow

A practical guide to website accessibility testing across automated checks, keyboard use, assistive technology, critical journeys, evidence capture and remediation verification.

13 August 20267 minute readRelease Council
Abstract editorial illustration of people navigating clear and obstructed digital pathways using different modes of interaction.

What website accessibility testing should establish

Website accessibility testing asks whether people with different disabilities can perceive, understand and operate a website, including the journeys that matter most. It is not simply a hunt for missing alternative text or low-contrast colors. Navigation, forms, authentication, validation, dynamic updates, media, time limits and third-party components can all determine whether someone completes a task.

Start by naming the standard and scope. WCAG 2.2 Level AA is a common organizational target, but the appropriate standard may depend on contracts, policies, jurisdiction and sector. Testing against WCAG is not, by itself, legal advice or a guarantee of compliance. Record the precise target rather than using an ambiguous label such as “accessible.”

Testing also needs a defined release. Record the URL, build or commit, date, browser, viewport, operating system and assistive technology. A result without this provenance may be difficult to reproduce after the application changes.

Define journeys before choosing tools

Begin with an inventory of page types, reusable components and complete processes. Include public pages and authenticated states where permitted. Prioritize journeys such as registration, sign-in, search, checkout, booking, account recovery, document submission and cancellation according to the product being reviewed.

WCAG conformance applies to full pages, and a complete process must conform when a page is part of that process. Sampling can reveal recurring defects and provide useful risk evidence, but a small sample cannot establish whole-site conformance. Record what was excluded, including inaccessible environments, unsupported devices, third-party content and states that could not safely be reached.

  • Identify representative templates and components.
  • Map each critical journey from entry to completion.
  • Include empty, loading, success, error and expired-session states.
  • Define supported browser and assistive-technology combinations.
  • Use disposable accounts and data where actions could affect real people or records.

Use a layered testing workflow

No single technique is sufficient. Automated rules are fast and repeatable, but they only evaluate conditions the tool can detect. A clean scan means that implemented rules did not find a failure; it does not mean the page is accessible. Manual and assistive-technology testing are necessary for context, interaction and usability.

Run the layers against the same identified build so that findings can be compared and deduplicated.

  • Automated checks: Run a maintained rules engine across representative pages and reachable states. Review color contrast, document language, names and labels, parsing-related issues, landmarks and other machine-testable conditions. Treat tool severity and suggested fixes as inputs requiring human review.
  • Keyboard testing: Complete each journey without a pointer. Check logical focus order, visible focus, keyboard access to every control, escape from composite widgets, absence of traps, skip mechanisms and sensible focus movement after dialogs, errors and route changes.
  • Visual and responsive testing: Resize text to 200%, inspect reflow at narrow widths, zoom, and test high-contrast or forced-color settings where relevant. Look for clipped content, overlapping controls, hidden instructions and meaning conveyed by color alone.
  • Screen-reader testing: Use combinations appropriate to the product’s supported platforms and audience, such as NVDA with a Windows browser, VoiceOver with Safari, or TalkBack with Chrome. Verify headings, landmarks, control names, roles, states, descriptions, reading order, errors and dynamic announcements.
  • Source and semantic review: Inspect native HTML, accessible names, label relationships, heading structure and ARIA use. Prefer native elements where they provide the required behavior. The browser accessibility tree is useful evidence, but it is not a substitute for operating the page with assistive technology.
  • Content and media review: Check meaningful alternative text, captions, transcripts and audio description where applicable. Confirm that link text, instructions, headings and validation messages remain understandable outside their visual context.

Test behavior, not just individual pages

Many serious barriers appear only after interaction. A correctly labeled submit button does not make a form accessible if errors are not associated with fields, focus is lost after submission or a status message is never announced. Similarly, an accessible-looking dialog can fail if background content remains operable or keyboard focus does not return when it closes.

For each critical journey, write a short protocol with starting conditions, actions and expected results. Test successful completion as well as invalid input, interruption and recovery. Avoid consequential actions against production data unless authority and safeguards are explicit.

  • Can a keyboard user identify and reach the next action?
  • Does a screen-reader user receive the same status and error information?
  • Are required fields and input formats explained before failure?
  • Can users review, correct or cancel important submissions?
  • Do session timeouts provide warning and an appropriate extension mechanism?
  • Does the journey still work at increased text size and narrow viewport width?

Record findings as reproducible evidence

An actionable accessibility finding should distinguish observation from interpretation. State what happened, what was expected, who may be affected and which requirement may apply. Avoid claiming that a criterion is violated solely because a scanner assigned that label.

Attach evidence suited to the issue: screenshots, a short recording, relevant DOM or source excerpts, accessibility-tree output and exact reproduction steps. Preserve the original evidence even if teams later edit titles, severity or remediation notes. This creates a reviewable history rather than a mutable list of assertions.

Prioritize by user impact, journey importance, frequency and reach. A keyboard trap in account creation may warrant faster action than a minor semantic defect on an isolated page, even if a tool labels them similarly. Be explicit when impact is uncertain or a finding needs confirmation with another configuration.

  • Build, commit or release identifier
  • Exact URL and application state
  • Browser, operating system, viewport and zoom
  • Assistive technology and version, when used
  • Steps, actual result and expected result
  • Relevant WCAG success criterion and confidence level
  • Raw evidence and reviewer interpretation
  • Owner, remediation status and retest result

Verify remediation rather than closing on code changes

A proposed code change is not proof that the barrier has been removed. Re-run the original steps in the same configuration, then check adjacent components and journeys for regressions. A fix for an accessible name, for example, may alter visible labeling or create duplicate announcements elsewhere.

Record the new build and retain both the original and retest evidence. Close the finding only when the observed behavior meets the stated expectation. If a partial fix reduces impact without resolving the issue, document that distinction instead of treating it as a pass.

Concise pre-release accessibility checklist

Use this as a release prompt, not as a substitute for WCAG evaluation or testing by people with disabilities.

  • Scope, standard, build and supported platforms are recorded.
  • Critical journeys and complete processes are represented.
  • Automated results have been reviewed rather than accepted blindly.
  • All journeys can be completed with a keyboard alone.
  • Focus remains visible, logical and recoverable.
  • Forms expose labels, instructions, errors and status updates.
  • Text resize, zoom and narrow-width reflow have been checked.
  • Selected journeys have been tested with relevant assistive technology alongside manual keyboard testing and automation; user research remains a separate source of evidence where appropriate participants are available and ethically engaged or compensated under the organization’s research practice, rather than being treated as a prerequisite for every test run or as something a simulator can replace or claim to predict for an individual user or disability community. Automated rules and scripted checks are treated only as indicators for conditions they can actually inspect. Keyboard traversal covers focus order, visibility, traps, custom controls, dialogs and recovery after errors. Screen reader checks cover names, roles, states, reading order, landmarks, headings, dynamic announcements and form feedback, while recognizing that results vary by browser, operating system, assistive technology version and user settings. Zoom, text spacing, reflow, orientation where applicable, contrast, non-color cues, reduced motion behavior where relevant, captions, transcripts and alternative text are evaluated against the stated scope. Authentication, checkout, booking, consent, upload, account recovery, cancellation and other consequential flows use disposable data and stop before unauthorized or irreversible effects. Third-party widgets, embedded media, payment surfaces, cookie controls and identity-provider handoffs are included when they form part of the user journey, with ownership and testing limitations recorded. Every issue contains reproducible steps, expected and observed behavior, location, environment, user impact, relevant requirement or criterion, confidence, raw evidence and remediation guidance that does not prescribe an unverified fix. Duplicate reports are consolidated without deleting the underlying observations. Severity is based on practical impact, reach, frequency, availability of a workaround and importance of the blocked task rather than on scanner labels alone. Unavailable states, excluded pages, unsupported combinations and assumptions are explicit. Remediation is retested on an identified build, adjacent patterns are checked for regression and the report distinguishes resolved, partially resolved, not reproduced, accepted risk and out-of-scope findings. The final conclusion states exactly what was tested and avoids claiming universal accessibility, legal compliance, certification or future performance.

Primary references and provenance

Use primary standards when interpreting results. WCAG success criteria are normative; W3C Understanding documents, Techniques and ARIA Authoring Practices provide supporting guidance but do not replace the normative requirements. Tool rules should identify the standard and rule version they implement.

  • W3C Web Content Accessibility Guidelines 2.2: https://www.w3.org/TR/WCAG22/
  • W3C Understanding WCAG 2.2: https://www.w3.org/WAI/WCAG22/Understanding/
  • W3C Website Accessibility Conformance Evaluation Methodology: https://www.w3.org/TR/WCAG-EM/
  • W3C ARIA Authoring Practices Guide: https://www.w3.org/WAI/ARIA/apg/
  • W3C guidance on evaluating web accessibility: https://www.w3.org/WAI/test-evaluate/