WCAG 2.2 AA Audit Checklist: 15 Accessibility Fixes Every Team Can Ship This Month
Most accessibility backlogs fail the same way: the audit report is 47 pages long, lists 312 issues across 22 pages, maps each to an obscure WCAG identifier, and ends up shelved because nobody knows where to start. Legal risk goes untreated, screen reader users keep getting blocked, and a year later the next audit finds the same issues plus a few new ones.
This checklist takes the opposite approach. Fifteen specific fixes, ordered by impact, each with a named WCAG 2.2 success criterion, a concrete test you can run in a browser, and a remediation pattern you can apply today. Most teams can ship 10–12 of these in a single sprint and close 60–70% of the issues a typical audit surfaces.
Work through them in order. Each one compounds with the next.
How to Use This Checklist
Each item includes:
- WCAG criterion: The specific success criterion and level (A or AA)
- What to check: A plain-language description
- How to test: A browser-based test taking under five minutes
- How to fix: The remediation pattern
You do not need specialized tools. A browser with DevTools, a keyboard, and the free axe DevTools extension will cover every item on this list.
Group A: Visual Accessibility
1. Text color contrast — WCAG 1.4.3 (AA)
What to check: Body text needs a contrast ratio of at least 4.5:1 against its background. Large text (18pt+ regular or 14pt+ bold) needs 3:1.
How to test: Open axe DevTools and run a scan. Or use the Chrome DevTools color picker — click any text element and the tooltip shows the ratio and whether it passes.
How to fix: Darken the text or lighten the background. The usual offenders are placeholder text (#999 gray), inline links that do not distinguish from body color, disabled button states, and timestamp metadata. See our full guide to WCAG color contrast ratios.
2. Non-text contrast — WCAG 1.4.11 (AA)
What to check: UI components and graphical elements (form borders, icon buttons, focus indicators, chart bars) need 3:1 contrast against adjacent colors.
How to test: Look at form field borders, checkbox outlines, and icon-only buttons. Use the color picker to verify each against its background.
How to fix: Darken borders and icon strokes. The common failure is 1px light-gray form borders (#e5e5e5) on white — these fail 3:1 against white.
3. Focus indicator visible — WCAG 2.4.7 (AA) and 2.4.11 (AA, new in 2.2)
What to check: Every interactive element must show a visible focus indicator when tabbed to. The indicator must not be obscured by sticky headers, modals or tooltips.
How to test: Press Tab repeatedly from the top of the page. Watch each focused element. Can you see where focus is? Does a sticky header hide it when you scroll?
How to fix: Remove any outline: none or outline: 0 from your CSS. Replace with a visible focus style — a 2px solid outline with at least 3:1 contrast. Add scroll-padding-top equal to your sticky header height to prevent focus being obscured.
4. Text resizable to 200% — WCAG 1.4.4 (AA)
What to check: When the browser zooms to 200%, content must remain readable and functional with no loss of content or functionality.
How to test: Press Cmd/Ctrl + until the browser reports 200%. Does text get cut off? Do buttons overlap? Is horizontal scrolling required on desktop?
How to fix: Use relative units (rem, em) for font sizes, avoid fixed heights on text containers, ensure layouts use flexbox or grid with wrapping, and remove any max-width that prevents line wrapping.
Group B: Structural Accessibility
5. Semantic landmarks — WCAG 1.3.1 (A)
What to check: Every page should have a <header>, <nav>, <main> and <footer>. Exactly one <main> per page.
How to test: Install the Landmarks browser extension. It highlights every landmark on the page. Missing ones stand out immediately.
How to fix: Replace generic divs with semantic elements. If you must use ARIA (legacy code, third-party components), role="banner", role="navigation", role="main", role="contentinfo" map one-to-one.
6. Heading hierarchy — WCAG 1.3.1 (A) / 2.4.6 (AA)
What to check: One <h1> per page. Headings in logical order without skipping levels (no h2 → h4).
How to test: Use the HeadingsMap browser extension. It shows the heading outline at a glance.
How to fix: Demote decorative headings to paragraphs with visual styling. Use headings for structure, not appearance. Our guide on heading hierarchy for SEO and accessibility covers the full pattern.
7. Descriptive link text — WCAG 2.4.4 (A)
What to check: Link text should describe the destination. Avoid "click here," "read more," "learn more" without context.
How to test: A screen reader user can navigate by pulling up a list of all links on the page. Does that list make sense out of context?
How to fix: Change "Read more" to "Read more about the EAA compliance checklist." If visual space forces short text, use aria-label to extend it for assistive technology while keeping the short visual text.
8. Image alt text — WCAG 1.1.1 (A)
What to check: Every informative image has descriptive alt text. Decorative images have alt="". Functional images (icon buttons) describe the action, not the icon.
How to test: In DevTools, search the HTML for <img without an alt attribute. Every match is a violation.
How to fix: For informative images, describe what matters. For product photos, include the product name. For icon-only buttons, describe the action ("Close menu," not "X icon"). For purely decorative images, alt="" hides them from assistive technology.
Group C: Keyboard and Interaction
9. Keyboard accessibility — WCAG 2.1.1 (A)
What to check: Every interactive element must be reachable and operable with keyboard alone.
How to test: Unplug your mouse. Complete your primary user flow — search, filter, add to cart, checkout. Any step that requires a mouse is a WCAG failure.
How to fix: Replace click-only handlers with proper interactive elements. Use native <button> and <a> tags instead of clickable divs. Custom components need keyboard event handlers (Enter, Space, Arrow keys as appropriate).
10. No keyboard trap — WCAG 2.1.2 (A)
What to check: Keyboard focus must not get stuck anywhere. Users must be able to Tab out of every element.
How to test: Tab into every modal, dropdown, date picker and embedded widget. Then Tab out. If you cannot escape, focus is trapped.
How to fix: In modals, implement focus management: focus moves into the modal on open, cycles within it, returns to the trigger on close. Escape key must close the modal.
11. Target size — WCAG 2.5.8 (AA, new in 2.2)
What to check: Interactive targets must be at least 24×24 CSS pixels, with limited exceptions for inline links.
How to test: Inspect icon buttons, close buttons, radio buttons and small action icons. Measure the clickable area, not the visual icon.
How to fix: Increase padding on small interactive elements so the click target meets 24×24, even if the visual icon is smaller. See our mobile touch target size guide for the full rules and mobile-specific considerations.
12. Focus order matches visual order — WCAG 2.4.3 (A)
What to check: Tab order follows the logical reading order of the page.
How to test: Tab from the top. Does focus move in the order a sighted user reads? Does it jump across the page illogically?
How to fix: Fix the DOM order. Avoid positive tabindex values (they override natural order and create bugs). Use CSS for visual rearrangement, but keep the DOM in reading order.
Group D: Forms and Dynamic Content
13. Form labels programmatically associated — WCAG 1.3.1 (A) / 3.3.2 (A)
What to check: Every form field has a visible label programmatically connected to the input.
How to test: Click each input's label. The input should receive focus. If it does not, the label is not properly associated.
How to fix: Use <label for="fieldId"> with matching id="fieldId" on the input. Placeholder text is not a label — it disappears on input, has poor contrast, and is not reliably announced by assistive technology.
14. Clear error identification and messaging — WCAG 3.3.1 (A) / 3.3.3 (AA)
What to check: Form errors must identify the field in error, describe what is wrong in plain language, and suggest how to fix it.
How to test: Submit a form with intentional errors. Are errors linked to the specific fields? Does the message explain what went wrong? Is the message announced to screen readers?
How to fix: Use aria-invalid="true" on fields in error, associate error messages via aria-describedby, and place a summary at the top of the form with anchor links to each error. Error text must have 4.5:1 contrast — red alone is not enough.
15. Language attribute set — WCAG 3.1.1 (A)
What to check: The page's primary language is declared with <html lang="en"> (or the appropriate code).
How to test: View the page source. Check the opening <html> tag.
How to fix: Add the lang attribute. For multilingual pages, wrap foreign-language content in an element with its own lang attribute so screen readers switch pronunciation correctly.
What This Checklist Does Not Cover
These 15 fixes address the most common and highest-impact WCAG failures. They will not catch every issue a comprehensive audit finds. In particular, you still need human judgment and screen reader testing for:
- Meaningful alt text quality — automation can check presence, not meaningfulness
- Reading order with complex layouts — multi-column grids, absolute positioning, CSS order properties
- Custom component accessibility — comboboxes, date pickers, tree views, data grids built from scratch
- Dynamic content announcements — live regions, toast notifications, loading states
- Video captions and audio descriptions (WCAG 1.2 series)
- Cognitive accessibility — WCAG only partially addresses this; usability testing with diverse users is irreplaceable
This is where automated tools plateau at 30–40% coverage and a structured manual audit becomes necessary. Overlays cannot fill this gap either — see our breakdown of why accessibility overlays don't make sites ADA compliant.
Building This Into Your Process
A one-time cleanup is worth doing — but new accessibility issues will be introduced every sprint unless accessibility becomes part of how you build.
- Add axe-core to CI. Free, open source, catches regressions on every deploy. Fail the build on new serious or critical violations.
- Accessible defaults in your design system. Your Button component should handle focus states, your Modal should handle focus trapping, your Input should label correctly. Make accessibility the default, not an override.
- Accessibility acceptance criteria on every ticket. "Keyboard accessible" and "screen reader tested" become definition-of-done items, not a post-launch cleanup task.
- Quarterly manual pass. Keyboard-only and screen reader testing of top user flows every quarter. This catches the 60–70% automation misses.
- Annual formal audit. Either internal expert or external. Documented against WCAG 2.2 AA success criteria.
When You Are Ready for the Full Audit
This 15-item checklist gets you 60–70% of the way to WCAG 2.2 AA. The remaining 30–40% — meaningful alt text, custom component ARIA patterns, dynamic content handling, and the hundreds of edge cases a real audit surfaces — requires either in-house accessibility expertise or a structured external audit.
Heurilens is launching a dedicated Accessibility Audit that combines automated WCAG 2.2 AA scanning with expert manual review and screen reader testing, delivered as a PDF report mapped to specific success criteria — the documentation your legal team, procurement team and clients actually need. Built for agencies, e-commerce and SaaS teams preparing for the European Accessibility Act and ADA requirements. Join the waitlist to get early access and a launch-day discount.
In the meantime, the checklist above is free and actionable. Ship the fixes this month — your users and your legal team will both thank you.
Was this article helpful?
