Accessibility Audit Workflow

Combine automated checks with keyboard and screen-reader testing, fix findings by severity, and add regression checks for critical journeys.

intermediate~90 minaccessibilitytestingquality

Objective

Verify that key user journeys meet WCAG 2.2 AA requirements and prevent regressions through automated and manual checks.

Environment

A representative set of pages and user journeys
axe-core or an equivalent automated scanner
Keyboard-only testing and at least one screen reader
CI integration for automated checks

Steps

1. Select representative journeys

Choose the highest-value flows, including navigation, forms, search, authentication, and error states. Include mobile and desktop layouts.

Expected state: The audit covers real tasks, not only the homepage.

2. Run automated scans

Scan each page with axe or an equivalent tool and record violations by rule and severity.

Expected state: A baseline report exists with reproducible findings.

3. Test keyboard operation

Navigate every journey using only the keyboard. Verify focus order, visible focus, skip links, dialogs, and escape behavior.

Expected state: Every interactive element is reachable and operable without a mouse.

4. Test with a screen reader

Use NVDA, JAWS, or VoiceOver to verify names, roles, states, live-region announcements, and form errors.

Expected state: The journey is understandable and operable with speech output.

5. Fix and regress

Fix findings by severity, rerun automated and manual checks, and add the most important checks to CI.

Expected state: Critical issues are closed and covered by repeatable checks.

Decision points

Which issues block release?

Keyboard traps, missing names, and unusable forms
Any automated warning

Block on issues that prevent task completion or comprehension; triage lower-severity findings with owners and dates.

Should automated scans be a hard CI gate?

Yes, with a curated rule set and baseline
No, manual review only

Gate on high-signal rules and keep manual testing for semantics and screen-reader experience.

Expected outcome

Documented evidence that critical journeys meet WCAG 2.2 AA, with remaining issues prioritized, owned, and regression-tested.

Verification

Confirm automated scans pass their configured threshold, every critical journey works with keyboard only, screen-reader output is coherent, and CI runs the agreed checks on future changes.

Cleanup

Archive reports with tool versions and page URLs, and update the accessibility checklist for future releases.

Automated checks are the start

Automated scanners catch missing labels, contrast issues, and invalid ARIA, but they cannot judge whether a journey makes sense with a screen reader. Combine tools with real keyboard and assistive-technology testing.

npx @axe-core/cli https://staging.example.com/checkout \
  --exit

Manual checks that matter

Tab through the entire journey and confirm focus order and visibility.
Open and close dialogs with the keyboard; confirm focus returns to the trigger.
Submit a form with errors and verify the messages are announced.
Test at 200% zoom and a narrow viewport.
Use a screen reader to confirm names, roles, states, and live updates.

Verification

Automated scans meet the configured threshold.
Every critical journey is operable with keyboard only.
Screen-reader output is coherent for names, errors, and dynamic updates.
CI runs the agreed automated checks.
Remaining issues have severity, owner, and date.

Common failures

Testing only the homepage, relying solely on a browser extension, and treating a passing automated scan as full WCAG compliance. Accessibility is a property of user tasks, not a single score.