How to Run a Website Accessibility Audit: A Step-by-Step WCAG-EM Guide
Your automated scanner just gave your site a clean bill of health. Congratulations - you've now found roughly half the problem.
That's not a knock on automated tooling. It's a structural reality of how WCAG works: many success criteria require human judgement to evaluate. Is that alt text accurate, or just present? Does the focus order make sense to a keyboard user navigating a modal? Does the error message actually explain what went wrong? No rules engine can answer those questions for you.
This guide walks through how to run a real accessibility audit - one that will hold up to scrutiny from regulators, procurement teams, and your own users. The methodology is anchored in W3C's WCAG-EM, the standard framework for conformance evaluation, and it applies whether you're auditing for the European Accessibility Act (EAA), EN 301 549, or simply trying to build something genuinely usable.
Why automated-only audits fall short
Automated tools are fast, consistent, and excellent at catching structural issues at scale. But they have a hard ceiling.
Deque's analysis of over 2,000 audits covering nearly 300,000 issues found that automated testing using axe-core identified, on average, 57% of accessibility issues by volume. That figure is better than the older "30% of criteria" framing - because some high-frequency issue types (contrast failures, missing labels, missing language attributes) occur many times per page and are reliably machine-detectable. But it also means that roughly four in ten real barriers will not appear in your automated report.
Deque's study found automated tools could test for issues across only 16 of the 50 WCAG 2.1 Level AA success criteria. The remaining criteria - focus order, reading order, meaningful alt text, error identification, cognitive load, motion, and more - require a human to evaluate them in context.
The practical implication: a Lighthouse score of 100 does not mean your site is accessible. It means you passed the subset of checks that can be automated. A credible audit requires automated tooling plus manual expert review plus assistive-technology testing. All three.
Accessibility overlays (accessiBe, UserWay, EqualWeb, etc.) do not change this equation. They run the same automated detection layer on top of your existing site. They cannot fix issues that require human judgement to identify, and they do not produce EN 301 549 conformance. See our post Do accessibility overlays make you compliant? for the full reasoning.
The legal context: EAA enforcement is live
If you're serving EU consumers, the clock has already run. The European Accessibility Act became enforceable across all 27 EU member states on 28 June 2025. Enforcement is not theoretical: the first EAA-related lawsuits were filed in French Commercial Court in November 2025, and in June 2026 a French court ordered Carrefour to make both its e-commerce site and mobile application fully accessible. Regulators in Sweden, the Netherlands, and Germany have all confirmed active enforcement programmes ramping through 2026.
The technical standard underpinning the EAA is EN 301 549 v3.2.1, which incorporates WCAG 2.1 Level AA. Conforming to EN 301 549 creates a "presumption of conformity" with the EAA. For a deeper look at what EN 301 549 covers beyond WCAG, see our EN 301 549 explainer.
A structured audit is the recommended starting point - and the audit output (findings, remediation log, retest evidence) is also the paper trail that demonstrates good-faith effort to regulators.
The WCAG-EM methodology: five steps
W3C's Website Accessibility Conformance Evaluation Methodology (WCAG-EM) provides a structured, technology-agnostic process for evaluating conformance. It covers self-assessment and third-party evaluation alike. A WCAG-EM 2.0 draft extending the methodology to apps and other digital products was published in early 2026 - the core five-step structure remains the same.
Specify exactly what is being evaluated: the website or app, its URL scope, any included subdomains or third-party components, and the WCAG conformance level (for EAA: WCAG 2.1 AA, or WCAG 2.2 AA if you're future-proofing). Also define the accessibility support baseline — which browsers and assistive technologies must be supported. Document any explicit exclusions and the reason for each. Excluding parts of a product from scope can distort results and conflict with WCAG's requirement for full-page and complete-process conformance.
Before sampling, map the site: identify all distinct page types (homepage, category pages, product/service pages, forms, checkout, account management, error states, PDFs, media players, etc.), key user journeys, and the technologies in use (JavaScript frameworks, third-party widgets, iframes, dynamic content). This exploration phase prevents you from missing whole categories of content in your sample. Note any areas that require authentication or specific data states to reach — these need to be included.
For large sites it is not feasible to test every page. WCAG-EM recommends a structured sample: include at least one instance of every distinct page type and template, every distinct type of functionality (search, forms, media, data tables, modals, carousels), and a random selection of additional pages. For EAA compliance, prioritise the pages that form complete user journeys — a checkout flow must be tested end-to-end, not just the landing page. Document your sampling rationale.
For each page and page state in your sample, test against every applicable WCAG success criterion at the target level. Record pass, fail, or not applicable for each. This is where automated tooling, manual techniques, and assistive-technology testing all run in parallel — not sequentially. Log the specific element, the SC reference, and the failure description for every issue found. The W3C's WCAG-EM Report Tool can structure this output.
Aggregate results across the sample. Report which success criteria pass, fail, or were not applicable across the evaluated pages. Assign severity and priority to each failure. Produce an evaluation statement that accurately describes the scope, methodology, assistive technologies used, and overall conformance status. This report feeds directly into your EAA accessibility statement — which must be published and kept up to date.
Manual testing techniques
This is where most teams underinvest. Manual testing is not optional - it is the only way to evaluate the majority of WCAG criteria. Here are the core techniques every audit should include.
Keyboard-only navigation
Unplug (or disable) your mouse and navigate the entire page using Tab, Shift+Tab, Enter, Space, and arrow keys. You are checking:
- All interactive elements are reachable - no functionality is mouse-only
- No keyboard traps - you can always Tab away from a component (modals and custom widgets are common offenders)
- Focus order is logical - the Tab sequence follows the visual and semantic reading order
- Visible focus indicator - you can always see which element has focus; a suppressed
outline: nonewith no replacement is a failure
Screen reader testing
According to WebAIM's 2024 Screen Reader User Survey, JAWS (40.5%) and NVDA (37.7%) are the two most-used primary desktop screen readers, with VoiceOver dominant on mobile at 70.6%. A credible audit tests with at least two screen readers - typically NVDA + Chrome and JAWS + Chrome on Windows, VoiceOver + Safari on macOS/iOS, and TalkBack on Android for mobile coverage.
What to check:
- Headings and landmarks - does the page structure make sense when navigating by heading (H key in NVDA/JAWS)?
- Images - are alt texts meaningful, not just file names or "image"?
- Forms - are all inputs labelled, are error messages announced, are required fields identified?
- Dynamic content - are live regions and ARIA alerts announced when content updates?
- Links and buttons - is the purpose clear from the accessible name alone?
Zoom and reflow
Zoom the browser to 200% and then 400%. At 400%, WCAG 2.1 SC 1.4.10 (Reflow) requires that content reflows to a single column without horizontal scrolling (except for content that inherently requires two dimensions, like data tables or maps). Check that no text is clipped, no controls overlap, and no functionality is lost.
Colour contrast
Use a contrast analyser (the Colour Contrast Analyser from TPGi is free) to verify:
- Normal text: minimum 4.5:1 ratio against its background
- Large text (18pt / 14pt bold): minimum 3:1
- UI components and graphical objects: minimum 3:1
Automated tools catch many contrast failures, but they miss text rendered in images, text over gradients, and text whose colour changes on interaction.
Forms and error handling
Forms are one of the highest-risk areas. Test:
- Every input has a visible, programmatically associated label (not just placeholder text)
- Required fields are identified before submission, not only after
- Error messages identify the specific field and describe what is wrong - "Invalid input" fails; "Enter a date in DD/MM/YYYY format" passes
- Autocomplete attributes are present for personal data fields (SC 1.3.5)
Motion and animation
Check for content that moves, blinks, or auto-updates. SC 2.2.2 requires that anything moving for more than five seconds can be paused, stopped, or hidden. SC 2.3.1 prohibits content that flashes more than three times per second. For sites with parallax effects or animation-heavy UIs, also check that prefers-reduced-motion media queries are respected.
Tooling: what to use and when
No single tool covers everything. Use these in combination:
| Tool | Type | Best for | Cost |
|---|---|---|---|
| axe DevTools (browser extension) | Automated | Developer in-browser testing; zero false positives; maps to WCAG SC | Free (core) |
| WAVE (WebAIM) | Automated + visual | Visual overlay of issues on the page; good for communicating findings to non-technical stakeholders | Free |
| Lighthouse (Chrome DevTools) | Automated | CI integration; performance + accessibility in one run; powered by axe-core | Free |
| W3C WCAG-EM Report Tool | Reporting | Structuring and documenting a full WCAG-EM evaluation; generates a conformance report | Free |
| NVDA + Chrome | Screen reader (manual) | Windows screen reader testing; free; most common SR in Europe | Free |
| JAWS + Chrome/Edge | Screen reader (manual) | Enterprise Windows screen reader; most common in North America | Paid |
| VoiceOver + Safari | Screen reader (manual) | macOS and iOS testing; essential for mobile coverage | Built-in |
| TalkBack + Chrome | Screen reader (manual) | Android mobile testing | Built-in |
| Colour Contrast Analyser (TPGi) | Manual | Precise contrast checking including images and gradients | Free |
For CI/CD pipelines, integrate axe-core (or a wrapper like @axe-core/playwright or cypress-axe) into your automated test suite. This catches regressions on every pull request - but remember it only covers the automatable subset. It is a safety net, not a substitute for a full audit.
Turning findings into action
A list of failures is not a remediation plan. Here's how to make audit output actionable.
Severity and priority. Assign each finding a severity (critical / serious / moderate / minor) based on impact on users and frequency of occurrence. A missing form label on a checkout field is critical; a slightly suboptimal heading hierarchy on a blog post is moderate. Prioritise by severity × frequency × user journey importance.
Map to WCAG SC and POUR principle. Every finding should reference the specific success criterion it fails (e.g., SC 1.3.1 Info and Relationships) and the POUR principle it falls under (Perceivable, Operable, Understandable, Robust). This framing helps engineers understand why something matters, not just what is broken.
Write developer-ready tickets. Each ticket should include: the failing element (with a code snippet or screenshot), the SC reference, the failure description, a suggested fix, and the acceptance criteria for the retest. Vague tickets ("fix accessibility") get deprioritised; specific tickets get fixed.
Retest and document. After remediation, retest the specific elements that were fixed. Update your audit log with the retest date and outcome. This documented cycle - audit -> remediation -> retest - is the evidence trail that supports your EAA accessibility statement.
Publish your accessibility statement. The EAA requires service providers to publish an accessibility statement covering conformance status, known non-conformities, the assessment method used, and a feedback/escalation mechanism. Your audit report is the source of truth for this statement. See our EAA accessibility statement guide for what it must contain.
Audit cadence and ongoing monitoring
A one-time audit is a snapshot. Accessibility regresses as code changes - new components, third-party script updates, CMS content changes can all introduce new barriers.
Recommended cadence:
- Full WCAG-EM audit at launch of a new product or major redesign, and annually for stable products
- Targeted audit after any release that changes user-facing flows (checkout, forms, navigation, authentication)
- Automated checks in CI on every pull request - catches regressions before they reach production
- Accessibility statement review at least annually, or after any significant change to conformance status
Common audit mistakes to avoid
- Testing only the homepage. The homepage is rarely where real barriers live. Test the full user journey - search, filter, product detail, form, confirmation.
- Using only one screen reader. JAWS and NVDA behave differently with ARIA patterns. VoiceOver on iOS has its own quirks. Test with at least two.
- Treating automated results as the final word. A zero-issue automated report is a starting point, not a finish line.
- Ignoring dynamic states. Test modals when open, accordions when expanded, error states after failed form submission, loading states. Many issues only appear in specific states.
- Skipping third-party content. Embedded chat widgets, payment iframes, video players, and social media embeds are in scope if they are part of a user journey. "We don't control it" is not a defence under the EAA.
- No retest. Fixes that aren't verified often aren't actually fixed. Always retest the specific element, not just re-run the automated scanner.
Quick-reference: what automation catches vs. what needs human review
| Issue type | Automated? | Manual technique |
|---|---|---|
| Missing or empty alt text | ✅ Yes | - |
| Alt text quality / accuracy | ❌ No | Expert review |
| Colour contrast (static text) | ✅ Mostly | Contrast analyser for edge cases |
| Colour contrast (interactive states) | ⚠️ Partial | Manual check on hover/focus/active |
| Missing form labels | ✅ Yes | - |
| Error message quality | ❌ No | Expert review + screen reader |
| Keyboard operability | ⚠️ Partial | Keyboard-only navigation session |
| Focus order / logical sequence | ❌ No | Keyboard-only navigation session |
| Visible focus indicator | ⚠️ Partial | Visual inspection |
| Reading order (DOM vs. visual) | ❌ No | Screen reader + code review |
| Reflow at 400% zoom | ❌ No | Browser zoom test |
| Screen reader announcements | ❌ No | Screen reader testing |
| Motion / animation controls | ❌ No | Manual + prefers-reduced-motion check |
| Accessible authentication (SC 3.3.8) | ❌ No | Expert review |
The bottom line
A credible accessibility audit is not a scanner run. It is a structured process - scoped, sampled, manually tested with real assistive technologies, documented, and retested after remediation. The WCAG-EM framework gives you the methodology. The tools give you efficiency on the automatable slice. Human expertise covers everything else.
The EAA has made this a legal requirement for most digital products sold in the EU. But beyond compliance, a properly audited and remediated product is simply a better product - one that works for the estimated 87 million people with disabilities in the EU, and for the many more who benefit from accessible design without identifying as disabled.
Start with an automated baseline, scope your manual audit using WCAG-EM, and build retesting into your release process. That's the audit that holds up.
Related reading
Accessibility Conformance Reports (ACR/VPAT): The EU Procurement Guide for Vendors and Buyers
What a VPAT is, how it becomes an ACR, which edition to use for EU procurement under EN 301 549, and how to write one that survives scrutiny - plus a buyer-side checklist.
Web Accessibility Directive vs European Accessibility Act: Two EU Laws, One Compliance Programme
The EU has two distinct digital-accessibility regimes: the WAD for public sector bodies and the EAA for private-sector products and services. Many organisations are subject to both. Here's how to tell them apart - and how to satisfy both at once.
Cognitive Accessibility and the EAA: Why WCAG Compliance Isn't Enough
WCAG 2.1 AA is the EAA's legal floor - but it only partially covers people with cognitive and learning disabilities. Here's what teams must do beyond the standard.