WCAG Accessibility Checklist for Developers: 22 Checks to Run Before You Ship

Most WCAG resources are written for auditors and compliance officers. They list 50+ success criteria, explain intent, and leave you guessing about what to actually click. This WCAG accessibility checklist is the opposite: 22 concrete, pass/fail checks a developer can run on a single page or template in under an hour, each mapped to the exact WCAG 2.2 Level A/AA criterion it satisfies, with the browser and screen reader tool to use for it.

As of August 2026, WCAG 2.2 is the current W3C Recommendation (WCAG 3.0 is still an early working draft, so do not plan releases around it). WCAG 2.2 adds nine success criteria to 2.1 and removes 4.1.1 Parsing, which is now obsolete. Everything below reflects 2.2.

How to use this checklist

Scope it to one page or template at a time. A homepage, a checkout step, a data table view, a modal-heavy dashboard screen. Auditing “the whole site” in one pass never works.
Target Level AA. That is the level referenced by the European Accessibility Act / EN 301 549, the ADA Title II web rule, Section 508 and most enterprise procurement contracts.
Record a verdict, not a feeling. Each check is Pass, Fail or N/A. Every Fail gets a ticket with the criterion number in the title, for example “[a11y][2.4.11] Focus hidden behind sticky header on /pricing”.
Do not stop at the automated scan. Automated tooling reliably detects roughly a third of WCAG issues. Checks 1 to 7 and 18 to 22 below are mostly manual for a reason.

Tools to install before you start

Tool	What you use it for
axe DevTools or WAVE (browser extension)	First automated pass, contrast and ARIA errors
Accessibility Insights for Web	Tab stop visualisation, guided manual tests
Chrome/Edge DevTools	Accessibility tree pane, contrast picker, emulation (reduced motion, forced colors)
TPGi Colour Contrast Analyser	Contrast of gradients, images, canvas, video overlays
NVDA + Firefox (Windows) or VoiceOver + Safari (macOS)	Names, roles, states, live region announcements
axe-core in CI (Playwright, Cypress or jest-axe)	Preventing regressions after the audit

Your 55 minute budget

Block	Checks	Time
Automated scan + triage	Sets up 8, 9, 13, 16, 18	5 min
Keyboard only pass	1 to 7	15 min
Visual and zoom pass	8 to 12	10 min
Structure and forms	13 to 20	15 min
Screen reader spot check	21, 22 + confirm 16	10 min

The 22 checks at a glance

#	Check	WCAG 2.2 criterion	Level
1	Everything operable by keyboard	2.1.1 Keyboard	A
2	No keyboard traps	2.1.2 No Keyboard Trap	A
3	Focus order matches visual order	2.4.3 Focus Order	A
4	Visible focus indicator everywhere	2.4.7 Focus Visible	AA
5	Focus never hidden by sticky UI	2.4.11 Focus Not Obscured (Minimum)	AA (new in 2.2)
6	Working skip link / bypass mechanism	2.4.1 Bypass Blocks	A
7	Target size and pointer alternatives	2.5.8, 2.5.7, 2.5.1	AA / A
8	Text contrast 4.5:1 (3:1 large text)	1.4.3 Contrast (Minimum)	AA
9	UI component and graphic contrast 3:1	1.4.11 Non-text Contrast	AA
10	Colour is never the only cue	1.4.1 Use of Color	A
11	Reflow at 400% zoom / 320 CSS px	1.4.10 Reflow	AA
12	Text resize and text spacing overrides	1.4.4, 1.4.12	AA
13	Meaningful alt text, empty alt for decoration	1.1.1 Non-text Content	A
14	Heading hierarchy and landmarks	1.3.1 Info and Relationships, 2.4.6	A / AA
15	Unique page title and correct lang	2.4.2, 3.1.1	A
16	Accessible name, role and state on every control	4.1.2 Name, Role, Value, 2.5.3	A
17	Link purpose clear from the link text	2.4.4 Link Purpose (In Context)	A
18	Every field labelled and autocompleted	3.3.2 Labels or Instructions, 1.3.5	A / AA
19	Errors described in text with a fix suggestion	3.3.1, 3.3.3	A / AA
20	No redundant entry, no cognitive test to log in	3.3.7, 3.3.8	A / AA (new in 2.2)
21	Status messages announced without focus change	4.1.3 Status Messages	AA
22	Motion, autoplay and time limits controllable	2.2.1, 2.2.2, 2.3.1, 1.4.2	A

Part 1: Keyboard navigation and focus management (checks 1 to 7)

Unplug the mouse. Seriously. Put it out of reach for fifteen minutes and drive the page with Tab, Shift+Tab, Enter, Space, arrow keys and Esc. There is a practical rundown of it online.

1. Every interactive element is reachable and operable by keyboard

Maps to: 2.1.1 Keyboard (Level A)

Test: Tab through the entire page. Activate every control you reach. Then look for anything you never reached: card overlays, custom dropdowns, carousel arrows, star ratings, drag handles, map controls, “x” close buttons.
Tool: Accessibility Insights for Web, “Tab stops” visualisation, which draws numbered dots on the page as you tab.
Fail if: a <div> or <span> with a click handler has no tabindex="0", no role and no key handler, or a control opens only on hover.
Fix: use native <button>, <a href>, <input> first. Custom widgets need role, tabindex and Enter/Space/arrow handling as described in the ARIA Authoring Practices Guide.

2. No keyboard traps

Maps to: 2.1.2 No Keyboard Trap (Level A)

Test: open every modal, date picker, cookie banner, video player and embedded iframe. Tab forward and backward out of each one. Press Esc.
Fail if: focus loops forever inside a widget with no keyboard way out, or Esc closes the dialog but focus lands on <body> instead of returning to the trigger element.
Note: a modal should trap focus while open, but it must be dismissible with Esc and must restore focus to the element that opened it.

3. Focus order matches the visual order

Maps to: 2.4.3 Focus Order (Level A)

Test: watch the tab stop numbers. They should read left to right, top to bottom (or the reverse in RTL locales).
Fail if: CSS order, flex-direction: row-reverse, grid-area or absolute positioning has reordered the visual layout without changing the DOM, or if a positive tabindex value (2, 3, 10…) exists anywhere in the page.
Fix: reorder the DOM. Only tabindex="0" and tabindex="-1" belong in production code.

4. The focus indicator is always visible

Maps to: 2.4.7 Focus Visible (Level AA), with 1.4.11 for its contrast

Test: tab across dark sections, light sections, images, buttons with custom backgrounds, and inputs inside modals.
Fail if: you find outline: none or outline: 0 without a replacement, or the indicator is a 1px light grey line on a white background.
Fix: use :focus-visible with a minimum 2px indicator at 3:1 contrast against the adjacent colour. A double outline (one dark, one light) survives both light and dark themes.

5. Focus is never obscured by sticky headers, chat widgets or cookie bars

Maps to: 2.4.11 Focus Not Obscured (Minimum), Level AA, new in WCAG 2.2

Test: tab down a long page. Watch what happens when the focused element scrolls under a sticky header or behind a floating chat bubble.
Fail if: the focused element is entirely hidden by other content.
Fix: add scroll-margin-top equal to the sticky header height on focusable elements, and make sure floating widgets are dismissible.

6. A skip link (or other bypass mechanism) actually works

Maps to: 2.4.1 Bypass Blocks (Level A)

Test: load the page, press Tab once. The skip link should appear. Press Enter, then Tab again: the next stop must be inside the main content.
Fail if: the link is visually hidden even on focus, or the target has no tabindex="-1" so focus stays in the header (a classic Chrome and Safari failure).
Alternative: proper landmarks (check 14) also satisfy this criterion for screen reader users, but a skip link is still the only help for sighted keyboard users.

7. Targets are at least 24 by 24 CSS pixels and gestures have alternatives

Maps to: 2.5.8 Target Size (Minimum) AA and 2.5.7 Dragging Movements AA, both new in WCAG 2.2, plus 2.5.1 Pointer Gestures (A)

Test: inspect small controls (close icons, pagination numbers, table row actions, toggle switches, star ratings) in DevTools and read the box model. Spacing counts: a 20px icon with 24px of clear space around its centre still passes.
Fail if: a reorderable list, slider or map can only be operated by dragging, or a carousel only responds to swipe.
Fix: add click-based or button-based alternatives (“move up”, “move down”, +/- buttons on sliders).

Part 2: Colour, contrast and visual presentation (checks 8 to 12)

8. Text contrast is at least 4.5:1 (3:1 for large text)

Maps to: 1.4.3 Contrast (Minimum), Level AA

Large text means 18.66px bold or 24px regular and above.
Tool: axe DevTools for flat backgrounds, then the TPGi Colour Contrast Analyser eyedropper for text over gradients, photos, video posters and <canvas>, which automated scanners skip.
Usual suspects: placeholder text, disabled-looking-but-enabled buttons, grey helper text under inputs, footer links, chart legends, “ghost” secondary buttons.
Exempt: genuinely disabled controls, logos, and purely decorative text.

9. UI components and meaningful graphics reach 3:1

Maps to: 1.4.11 Non-text Contrast, Level AA

Test: measure input borders against the page background, checkbox and radio outlines, toggle track versus knob, focus rings, icon-only buttons, chart lines and data point colours against each other.
Fail if: a text input is defined only by a #e5e5e5 border on white (about 1.3:1). This is one of the most common failures in modern design systems.

10. Colour is never the only way information is conveyed

Maps to: 1.4.1 Use of Color, Level A

Test: apply a greyscale filter (DevTools Rendering panel, “Emulate vision deficiencies” or a CSS filter: grayscale(1) in the console) and ask whether every state is still distinguishable.
Fail if: required fields are marked by red labels only, chart series rely on colour alone, links inside paragraphs are distinguished from body text only by colour with less than 3:1 between them and no underline, or status badges differ only by hue.
Fix: add an icon, a text label, a pattern, or an underline.

11. The page reflows at 400% zoom without horizontal scrolling

Maps to: 1.4.10 Reflow, Level AA

Test: set the browser window to 1280px wide and zoom to 400% (Ctrl/Cmd + +). That is equivalent to a 320 CSS pixel viewport.
Fail if: content is cut off, overlaps, or requires two dimensional scrolling. Data tables and complex diagrams are the recognised exception.
Watch for: fixed widths in px, white-space: nowrap on long labels, sticky sidebars that eat the whole viewport, modals taller than the screen with no internal scroll.

12. Text resizes to 200% and survives user text spacing

Maps to: 1.4.4 Resize Text and 1.4.12 Text Spacing, Level AA

Test: paste the well known text spacing bookmarklet or run this in the console: line height 1.5x font size, paragraph spacing 2x, letter spacing 0.12em, word spacing 0.16em.
Fail if: text is clipped inside buttons or cards with fixed heights, or content overlaps.
Fix: use min-height instead of height, avoid overflow: hidden on text containers, and size in rem rather than px.

Part 3: Structure, semantics and accessible names (checks 13 to 17)

13. Images have appropriate alternative text

Maps to: 1.1.1 Non-text Content, Level A

Test: WAVE shows alt text inline on every image. Then judge each one by hand, because an automated tool cannot tell you that alt="image1.png" is useless.
Rules of thumb: decorative images get alt=""; functional images (an icon inside a link) get the destination or action as their alt; informative images describe the information, not the picture; charts need a short alt plus a longer text or table equivalent nearby.
Also check: CSS background images carrying real information (they are invisible to assistive tech), and inline SVG, which needs role="img" plus a <title> or aria-label, or aria-hidden="true" when decorative.

14. Headings and landmarks describe the page structure

Maps to: 1.3.1 Info and Relationships (A) and 2.4.6 Headings and Labels (AA)

Test: in NVDA press Insert+F7 for the elements list, or use the headings map in WAVE. Read only the headings: they should work as an outline of the page.
Fail if: there is no <h1>, levels are skipped (h2 straight to h4), text is styled to look like a heading with a bold <div>, or a heading is used purely for visual size.
Landmarks: one <main>, a <header>, <nav> (labelled with aria-label if there are several), <footer>. Everything on the page should sit inside a landmark.
Also here: real <table> markup with <th scope> and a <caption>, real <ul>/<ol> for lists, and <fieldset>/<legend> for radio groups.

15. The page has a unique, descriptive title and the correct language

Maps to: 2.4.2 Page Titled and 3.1.1 Language of Page, Level A

Test: check <title> and <html lang> in the DOM. In a single page app, confirm the title updates on route change.
Fail if: every route shares the same title, or lang="en" is set on a French page, which makes screen readers pronounce it as gibberish. Mark inline foreign phrases with lang too (3.1.2, AA).

16. Every control exposes a correct name, role and state

Maps to: 4.1.2 Name, Role, Value (A) and 2.5.3 Label in Name (A)

Test: select a control in DevTools, open the Accessibility pane and read the computed name and role. Then confirm with a screen reader.
Fail if: an icon-only button announces as “button” with no name, a toggle never exposes aria-expanded, a custom select does not report the selected option, or a tab does not report aria-selected.
Label in Name: if a button visibly says “Send message”, its accessible name must contain that string. aria-label="Submit" on a button labelled “Send message” is a failure and breaks voice control users.
ARIA rule: no ARIA is better than bad ARIA. Check for role="button" on real buttons, aria-hidden="true" on focusable elements, and invalid attribute combinations. axe flags most of these automatically.

17. Link text makes sense out of context

Maps to: 2.4.4 Link Purpose (In Context), Level A

Test: in NVDA press Insert+F7 and switch to links, or use VoiceOver rotor (VO+U). Read the list on its own.
Fail if: you see six identical “Read more” or “Click here” entries, or a raw URL as link text.
Fix: rewrite the visible text, or extend it with visually hidden text: Read more<span class="visually-hidden"> about our WCAG audits</span>. Also warn when a link opens a new tab or downloads a file.

Part 4: Forms and error handling (checks 18 to 20)

Forms are where accessibility failures cost real money, because they sit on signup, checkout and contact flows.

18. Every field has a persistent, programmatically associated label

Maps to: 3.3.2 Labels or Instructions (A) and 1.3.5 Identify Input Purpose (AA)

Test: click each visible label. The matching input should receive focus. That single click proves the for/id pairing.
Fail if: the label is a placeholder only (it disappears on typing and usually fails contrast), the label is a floating <div>, or required and format rules are only shown after a failed submit.
Also check: autocomplete tokens on personal data fields (name, email, tel, street-address, cc-number), which is what 1.3.5 requires.

19. Errors are identified in text, near the field, with a suggestion

Maps to: 3.3.1 Error Identification (A) and 3.3.3 Error Suggestion (AA)

Test: submit the form empty. Then submit it with a badly formatted email and a wrong date.
Pass criteria:
1. The error text names the field and the problem, not just “Invalid input”.
2. The message is tied to the input with aria-describedby, and the input has aria-invalid="true".
3. Focus moves to the first invalid field, or to an error summary at the top of the form with links to each field.
4. The error is not communicated by a red border alone (see check 10).
5. When a fix is known, it is suggested: “Enter a date in DD/MM/YYYY format”.
Tool: run the submit with NVDA or VoiceOver open and confirm you hear the error without hunting for it.

20. No redundant entry and no cognitive test to authenticate

Maps to: 3.3.7 Redundant Entry (A) and 3.3.8 Accessible Authentication (Minimum) (AA), both new in WCAG 2.2

Test: walk a multi step flow (checkout, onboarding wizard). Information already given must be auto populated or selectable, not retyped.
Fail if: login blocks paste into the password field, requires transcribing a code by memory, or relies on a puzzle or object recognition with no alternative.
Fix: allow password managers and paste, offer email link or passkey alternatives, and keep the “confirm email” field out of your forms unless you have a very good reason.

Part 5: Dynamic content, media and motion (checks 21 and 22)

21. Status messages are announced without moving focus

Maps to: 4.1.3 Status Messages, Level AA

Test: with a screen reader running, trigger each asynchronous update: “3 results found”, “Added to cart”, “Saved”, loading spinners, toast notifications, inline validation.
Fail if: nothing is announced, or the app steals focus to force the announcement.
Fix: use role="status" (polite) or role="alert" (assertive, for errors only). The live region must exist in the DOM before the text is injected, otherwise most screen readers stay silent.

22. Motion, autoplay and time limits are under the user’s control

Maps to: 2.2.2 Pause, Stop, Hide (A), 2.2.1 Timing Adjustable (A), 2.3.1 Three Flashes (A), 1.4.2 Audio Control (A) There is more on it in Web Accessibility Checklist.

Test: look for carousels that rotate automatically, marquees, animated backgrounds, video that autoplays with sound, and session timeouts.
Fail if: anything moves for more than 5 seconds without a pause control, audio plays automatically for more than 3 seconds with no way to stop it, or a session expires with no warning and no way to extend.
Also: honour @media (prefers-reduced-motion: reduce) for parallax, large transitions and animated illustrations. Emulate it in DevTools Rendering panel.

What this page-level checklist does not cover

Twenty two checks get you through a page. A full WCAG 2.2 AA conformance claim also needs these, which are better handled at site or content level:

1.2.x Media: captions for prerecorded and live video, audio description, transcripts.
3.2.3 / 3.2.4 Consistent Navigation and Identification: reviewed across templates, not on one page.
3.2.6 Consistent Help (new in 2.2): if help exists (contact link, chat, FAQ), it appears in the same relative place on every page.
2.4.5 Multiple Ways: search plus sitemap plus navigation.
1.3.4 Orientation and 1.3.6 Identify Purpose on mobile and native apps.
An accessibility statement, which is a legal requirement under the European Accessibility Act and EN 301 549 rather than a WCAG criterion.

Turn the checklist into a pull request gate

An audit that is not automated decays in about two sprints. After the manual pass, lock in the results:

Add eslint-plugin-jsx-a11y (React) or the equivalent template linter so obvious issues fail at commit time.
Add @axe-core/playwright or cypress-axe to your end to end suite and assert zero violations on key routes, including the modal-open and error states, not just the initial render.
Add a short a11y section to your PR template: keyboard reachable, visible focus, accessible name, contrast checked, error state announced.
Re-run the full 22 point manual pass once per quarter and after any design system change.

FAQ

What is a WCAG checklist?

A WCAG checklist restates the Web Content Accessibility Guidelines success criteria as verifiable items you can tick off. Reference checklists (W3C, WebAIM, the A11Y Project) list criteria by number and level. A developer checklist like this one flips the order: it starts from the actions you perform in the browser and tells you which criterion each action verifies, which is far faster when you are auditing a page rather than writing a conformance report. There is more on it in WCAG Cheat Sheets and Checklists.

What are the WCAG accessibility requirements?

WCAG is built on four principles, known as POUR: content must be Perceivable, Operable, Understandable and Robust. Under those sit 13 guidelines and, in WCAG 2.2, 87 success criteria split across three conformance levels: A (minimum), AA (the legal and contractual target almost everywhere) and AAA (enhanced, rarely required for a whole site).

Is WCAG legally required?

WCAG itself is a technical standard, not a law, but it is referenced by laws. In the European Union, the European Accessibility Act has applied to new consumer products and services since 28 June 2025, using the harmonised standard EN 301 549, which incorporates WCAG 2.1 AA and is aligned toward 2.2. In the United States, Section 508 covers federal agencies, the ADA is regularly applied to private websites by the courts, and the Department of Justice rule for state and local government sets WCAG 2.1 AA, with the compliance date for larger public entities already passed in April 2026 and smaller entities due in April 2027. Canada, the UK and Australia have equivalent regimes. Building to WCAG 2.2 AA satisfies all of them today.

What is the difference between WCAG 2.1 and WCAG 2.2?

WCAG 2.2 adds nine success criteria (2.4.11 and 2.4.12 Focus Not Obscured, 2.4.13 Focus Appearance, 2.5.7 Dragging Movements, 2.5.8 Target Size Minimum, 3.2.6 Consistent Help, 3.3.7 Redundant Entry, 3.3.8 and 3.3.9 Accessible Authentication) and removes 4.1.1 Parsing, which modern browsers made obsolete. Everything else carries over, so a 2.1 AA site needs six new AA-level checks to reach 2.2 AA.

Can automated tools replace this checklist?

No. axe, Lighthouse and WAVE are excellent at what they cover (missing alt, missing labels, flat colour contrast, invalid ARIA, duplicate IDs), and they should run in CI. But they cannot judge whether alt text is meaningful, whether focus order is logical, whether an error message is helpful, or whether a custom widget behaves correctly on the keyboard. Plan for automation plus a manual pass.

How long does a WCAG audit actually take?

This 22 point page audit takes 45 to 60 minutes once you know the tooling, and around 90 minutes the first time. A full multi template audit with a formal conformance report (VPAT or an EU accessibility statement) takes days, because it covers every criterion, every template, several browsers and at least two screen readers.

Need a second pair of eyes?

At coding4.net we run this checklist as part of every front end delivery and we audit existing applications against WCAG 2.2 AA, including remediation plans your developers can act on ticket by ticket. If you want your product reviewed before an EAA deadline or a client procurement review, get in touch and we will start with your three highest traffic templates.