An accessibility audit is a structured evaluation of a website, web application or digital document against a defined accessibility standard, most often the Web Content Accessibility Guidelines (WCAG) at conformance level AA, that identifies barriers for people with disabilities and documents how to remove them. In web accessibility it is the main method for establishing the current conformance level of a product and for producing a prioritized remediation plan.
A credible audit combines automated testing, expert manual review and testing with assistive technologies such as screen readers, screen magnifiers and keyboard-only navigation. Automated tools alone detect only a minority of WCAG issues, because many criteria require human judgment about meaning, context and usability.
How an accessibility audit is conducted
An audit follows a repeatable sequence of phases, from defining what is tested to verifying the fixes. A widely used reference for this process is the WCAG Evaluation Methodology (WCAG-EM), which describes how to define the scope, select a representative sample of pages and record results so that the evaluation can be reproduced.
| Phase | Main activities | Output |
|---|---|---|
| Scoping | Set the standard, level, platforms and assistive technologies | Audit plan |
| Sampling | Choose templates, key user journeys and random pages | Page and flow sample |
| Automated scanning | Run rule-based tools across the sample | List of machine-detectable issues |
| Manual review | Check each WCAG success criterion by hand | Confirmed issues with locations |
| Assistive technology testing | Complete tasks with screen readers and keyboard | Barriers in real use |
| Reporting | Rate severity, map to criteria, propose fixes | Audit report and remediation plan |
| Retesting | Verify fixes after remediation | Updated conformance status |
Sampling is critical for large sites. Auditors usually test every distinct page template and every critical user journey, such as registration, search, checkout or form submission, and then add a random selection of pages to catch content-level problems such as missing alternative text or poor heading structure.
Standards and conformance levels used in audits
Most audits measure against WCAG 2.1 or WCAG 2.2, which organize requirements under four principles: perceivable, operable, understandable and robust. Each success criterion has a conformance level of A, AA or AAA, and legal frameworks and procurement rules typically require level AA.
| Level | Character | Typical examples | Usual audit target |
|---|---|---|---|
| A | Minimum barriers that block access | Text alternatives, keyboard operability | Always included |
| AA | Common barriers for many users | Color contrast of 4.5 to 1, visible focus, resize to 200 percent | Standard target |
| AAA | Enhanced accessibility | Contrast of 7 to 1, sign language for video | Rarely required as a whole |
Regional rules reference these levels. The European standard EN 301 549 incorporates WCAG for public sector websites and, through the European Accessibility Act, many private services. In the United States, Section 508 applies to federal agencies. An audit report usually states the exact standard version so that results remain comparable over time.
Automated testing compared with manual evaluation
Automated and manual methods find different kinds of problems. Rule-based scanners reliably detect missing form labels, insufficient contrast for plain text or invalid ARIA attributes. They cannot judge whether alternative text is meaningful, whether the focus order is logical or whether an error message actually helps the user correct a mistake.
| Method | Detects well | Misses | Cost and speed |
|---|---|---|---|
| Automated scan | Missing labels, contrast, invalid markup | Meaning, logic, usability | Fast, cheap, repeatable |
| Manual expert review | Focus order, headings, alt text quality | Some real-use friction | Slower, needs expertise |
| Screen reader testing | Announcements, accessibility tree problems | Visual issues | Slow, needs trained testers |
| Testing with disabled users | Real barriers and workarounds | Systematic criterion coverage | Slowest, most realistic |
An audit differs from continuous accessibility testing built into development pipelines. Continuous checks prevent regressions on every build, while an audit gives a point-in-time, criterion-by-criterion verdict. Mature teams use both, with periodic audits confirming what automated checks cannot.
Severity ratings and the audit report
A useful report does more than list failures. Each finding should name the WCAG success criterion, the location, the affected user groups, a severity rating and a concrete recommendation. Severity reflects impact on task completion, not only the formal level of the criterion.
| Severity | Meaning | Example |
|---|---|---|
| Critical | Blocks a key task for some users | Checkout button not reachable by keyboard |
| High | Causes major difficulty | Form errors not announced to screen readers |
| Medium | Causes friction or confusion | Skipped heading levels in long articles |
| Low | Minor or cosmetic impact | Redundant title attribute on a link |
Many organizations convert audit results into an accessibility conformance report based on the VPAT template, or into the accessibility statement required for public sector websites in the European Union. Both documents must reflect the actual tested state, not an intended one.
Common mistakes in accessibility audits
- Relying only on automated scores gives a false sense of conformance, because a perfect tool score can coexist with serious barriers.
- Testing only the home page misses forms, dynamic widgets and authenticated areas where most barriers live.
- Ignoring third-party components such as chat widgets, payment frames and cookie banners, which are part of the user experience.
- Treating an accessibility overlay as a fix does not remove underlying code problems and can interfere with assistive technologies.
- Skipping retesting leaves the organization unsure whether fixes work.
Audits are most valuable when they feed design systems and development practice. Fixing a focus indicator or an accessible form pattern in a shared component removes the same defect from hundreds of pages at once.
A non-technical view
An accessibility audit is a careful inspection of a website. Specialists check whether people with disabilities can use it. They test whether someone who cannot see the screen can still fill in a form. They check whether someone who uses only a keyboard can reach every button.
It works like a building inspection for ramps, doors and signs. Some checks can be done by machines, but many need a trained person. The result is a list of problems, ranked by how badly they hurt users, with clear advice on how to fix them.
A concrete example
A regional public transport operator must publish an accessibility statement for its ticketing website. It commissions an audit against WCAG 2.2 level AA, covering the journey planner, account registration, ticket purchase and the help center, tested with NVDA, VoiceOver and keyboard-only navigation.
Automated scanning finds about 120 issues, mostly contrast and missing labels. Manual and screen reader testing finds fewer but more serious problems: the date picker in the journey planner traps keyboard focus, and payment errors are shown only in red text. Both are rated critical because they block ticket purchase.
The development team fixes the shared date picker component and the error pattern first. A retest six weeks later confirms that all critical and high findings are resolved, and the operator publishes an accurate statement listing the remaining minor issues and their planned fix dates.