// Accessibility
Website Accessibility Audit: The Complete WCAG 2.2 Guide
How to run a website accessibility audit against WCAG 2.2 Level AA. Covers color contrast, keyboard navigation, screen readers, ARIA, forms, and automated vs manual testing.
Why accessibility audits matter in 2026
Web accessibility is no longer optional. The European Accessibility Act (EAA) takes effect June 2025, the DOJ has clarified that the ADA applies to websites, and accessibility lawsuits in the US crossed 4,600 in 2024 — up 300% from 2018. Even without legal pressure, 15-20% of your visitors have some form of disability affecting how they use the web.
Beyond compliance, accessibility improvements directly boost SEO and conversion. Proper heading structure helps crawlers understand page hierarchy. Alt text improves image search visibility. Keyboard navigation fixes benefit power users and mobile visitors. Accessible forms reduce abandonment. Every accessibility fix has a business upside.
This guide walks through a complete WCAG 2.2 Level AA audit — the standard most regulations reference. We cover what to check, how to test it, and which issues to prioritize based on user impact.
The 20-point WCAG 2.2 audit checklist
WCAG 2.2 has 86 success criteria across 4 principles (Perceivable, Operable, Understandable, Robust). These 20 checks cover the failures we see most often and the ones with the highest user impact.
- 1. Color contrast — text must have a 4.5:1 contrast ratio against its background (3:1 for large text). Use WebAIM's contrast checker or let WebEnture's Accessibility Agent scan every page automatically
- 2. Alt text on images — every meaningful image needs descriptive alt text. Decorative images need empty alt attributes (alt=""). Missing alt text is the #1 accessibility failure globally
- 3. Heading hierarchy — use H1-H6 in logical order without skipping levels. One H1 per page. Screen readers use headings for navigation — skipped levels create a confusing experience
- 4. Keyboard navigation — every interactive element (links, buttons, forms, menus) must be reachable and operable with Tab, Enter, Space, and Arrow keys. Test by unplugging your mouse
- 5. Focus indicators — focused elements must have a visible outline. Never use outline: none without providing an alternative focus style. Users who navigate by keyboard rely on focus indicators to know where they are
- 6. Form labels — every form input needs a programmatically associated label (<label for=""> or aria-label). Placeholder text alone is not sufficient — it disappears when the user starts typing
- 7. Error identification — form validation errors must identify the specific field and describe the error in text. Color alone is not sufficient (red border without text fails WCAG)
- 8. Link purpose — link text must describe the destination. Avoid 'click here' and 'read more' — screen reader users often navigate by link list, so each link must make sense out of context
- 9. Skip navigation — provide a 'Skip to main content' link as the first focusable element. This lets keyboard users bypass the navigation menu on every page
- 10. ARIA landmarks — use semantic HTML5 elements (main, nav, header, footer, aside) or ARIA roles to define page regions. Screen readers use landmarks for quick navigation
- 11. Page language — set the lang attribute on the <html> element. Screen readers use this to select the correct pronunciation engine. Missing lang is a common oversight
- 12. Resize support — content must be readable and functional when zoomed to 200%. No horizontal scrolling required at 320px viewport width (WCAG 1.4.10 Reflow)
- 13. Motion and animation — provide a way to pause, stop, or hide any auto-playing content. Respect prefers-reduced-motion media query. Flashing content must not flash more than 3 times per second
- 14. Touch targets — interactive elements need a minimum 44×44px touch target (WCAG 2.5.8, new in 2.2). Small links and tiny checkboxes fail this requirement on mobile
- 15. Drag alternatives — any action that requires dragging (sliders, sortable lists) must have a non-drag alternative like buttons or keyboard controls (WCAG 2.5.7, new in 2.2)
- 16. Consistent navigation — navigation menus must appear in the same order across pages. Moving nav items between pages confuses users who rely on spatial memory
- 17. Text spacing — content must remain readable when users override letter spacing (0.12em), word spacing (0.16em), line height (1.5), and paragraph spacing (2em). Test with a browser extension
- 18. Status messages — use ARIA live regions (aria-live="polite") for dynamic updates like form success messages, loading indicators, and error counts. Screen readers must announce these without focus change
- 19. Authentication — WCAG 2.2 adds 3.3.8 Accessible Authentication: login flows must not require cognitive function tests (CAPTCHA, password memorization) without an alternative like passkeys or email magic links
- 20. Redundant entry — WCAG 2.2 adds 3.3.7: don't ask users to re-enter information they've already provided in the same session. Auto-fill shipping from billing, remember form state on back navigation
Automated vs manual testing
Automated tools (axe-core, Lighthouse, WebEnture's Accessibility Agent) catch 30-40% of WCAG failures — primarily color contrast, missing alt text, empty headings, missing form labels, and ARIA misuse. They're essential for coverage across large sites but cannot catch everything.
Manual testing is required for keyboard navigation flow, focus order logic, screen reader announcement quality, cognitive clarity of error messages, and whether ARIA is used correctly in context. The best approach combines automated scanning for breadth with manual testing on your 5-10 most important pages.
Screen reader testing should cover at least NVDA (Windows, free), VoiceOver (macOS/iOS, built-in), and optionally JAWS (Windows, paid). Each has slightly different behavior — what works in VoiceOver may not work in NVDA.
Prioritizing accessibility fixes
Not all accessibility failures have equal impact. Prioritize by user harm: a completely inaccessible form blocks conversions, while a missing skip link is an annoyance. Here's a practical priority framework:
P0 (fix immediately): keyboard traps, missing form labels on critical forms, zero contrast text, auto-playing audio/video without controls. These block entire user groups from completing core tasks.
P1 (fix this sprint): missing alt text on content images, broken heading hierarchy, no focus indicators, missing ARIA live regions for dynamic content. These significantly degrade the experience for assistive technology users.
P2 (fix this quarter): color contrast ratios between 3:1 and 4.5:1, missing skip navigation, inconsistent navigation order, touch target sizes under 44px. These cause friction but don't completely block access.
P3 (continuous improvement): text spacing override support, redundant entry elimination, decorative images with non-empty alt, ARIA landmark completeness. These polish the experience for power users of assistive technology.
Audit your site with WebEnture
WebEnture's Accessibility Agent (/accessibility-agent) runs axe-core across every crawled page and reports WCAG violations grouped by severity with per-page detail. It catches contrast failures, missing alt text, heading hierarchy issues, missing form labels, and ARIA problems — the same automated checks that Lighthouse runs, but across your entire site instead of one page at a time.
For the manual testing portion, use the Heading Structure Agent (/heading-structure-agent) to visualize your heading tree across all pages, and the Mobile UX Agent (/mobile-ux-agent) to catch touch target sizing issues. Together, these three agents cover the automated portion of a WCAG 2.2 Level AA audit in under 60 seconds.