How to Run a WCAG Website Accessibility Audit

A WCAG website accessibility audit evaluates whether people with different disabilities can perceive, operate, understand, and reliably use a digital experience. Conformance criteria provide a shared technical standard, but a useful audit also follows complete user journeys and explains the practical effect of each barrier.

Automated scanners are valuable for repeatable detection, yet they cannot determine whether alternative text communicates purpose, focus order makes sense, instructions are understandable, or a task works with assistive technology. A credible audit combines tools, human judgement, and transparent limits.

Define scope, standard, and representative journeys

State the WCAG version and conformance level being evaluated, the domains and environments included, supported browsers and assistive technologies, and any authenticated or third-party areas. Record exclusions explicitly. An audit cannot claim coverage for pages, states, documents, or embedded services that were not tested.

Build a sample across templates, components, content types, and risk. Include the homepage, navigation, search, forms, account flows, errors, dialogs, media, documents, consent, and important transaction paths. Sample dynamically generated and edge-case states, not only polished static pages.

Include mobile and high-zoom behavior in the test plan.
Prioritize journeys people must complete to access a service.
Record versions and settings for test tools and assistive technology.

Run automated checks as broad evidence

Use automated tools across the representative sample to find detectable issues such as missing labels, invalid relationships, contrast failures, duplicate identifiers, and some structural errors. Combine browser checks with repeatable crawling or test automation where the site size justifies it.

Review each result rather than copying tool output directly into a report. Tools can produce false positives, miss context, and report many instances of one component defect. Group shared causes while preserving affected locations so teams can fix the component and verify every instance.

Test keyboard, focus, structure, and reflow manually

Navigate every interactive element using the keyboard. Check logical order, visible focus, skip links, menus, dialogs, tabs, accordions, carousels, forms, and escape behavior. Focus must move intentionally when content opens or closes and should not become trapped or lost behind overlays.

Inspect headings, landmarks, lists, tables, names, roles, states, instructions, and error associations. Test zoom and narrow reflow without assuming a responsive layout is automatically accessible. Content should remain readable and operable without two-dimensional scrolling except where the information genuinely requires it.

Confirm hover or pointer-only information is available through other input methods.
Check that status and error updates are conveyed without relying only on color.
Verify touch targets and controls remain usable when text spacing changes.

Use assistive technology on complete tasks

Test representative journeys with screen readers and browser combinations appropriate to the audience and support policy. Evaluate navigation efficiency, control announcements, form guidance, errors, live updates, dialogs, tables, and dynamic content. Avoid reducing the exercise to reading the page from top to bottom.

Where possible, include people with disabilities in usability research. Standards testing and user research answer different questions: one evaluates criteria, while the other reveals how design, language, timing, and workflow combine in real use. Neither should be presented as a substitute for the other.

Write findings that developers can reproduce

Each finding should identify the barrier, affected users, relevant criterion, location, prerequisites, reproduction steps, actual behavior, expected behavior, evidence, severity, and remediation guidance. Include code only when it clarifies the solution; avoid prescribing a brittle patch without understanding the component architecture.

Prioritize by user impact, task importance, reach, frequency, and remediation dependency. A blocker in an essential form deserves urgent attention even if it appears once. Widespread component defects may be efficient to fix centrally. Separate conformance findings from usability recommendations while keeping both visible.

Use stable identifiers so findings can be tracked through retesting.
Describe the accessible outcome rather than only the invalid code.
Attach concise evidence without exposing personal or sensitive information.

Remediate, retest, and prevent regression

Fix root causes in shared components and content rules, then retest the original scenario and related states. Automated regression tests can protect names, roles, labels, and keyboard behavior, but manual checks remain necessary for meaning and end-to-end usability. Keep unresolved exceptions documented with owners and target decisions.

Accessibility becomes sustainable when design reviews, component documentation, content guidance, quality checks, procurement, and release criteria include it. Publish an accessible contact route and respond to reported barriers. An audit is a snapshot; the operating practice determines whether the site remains usable as it changes.