Web Accessibility Checklist (WCAG 2.2 AA)

Structure & semantics

0/5

Use real heading elements (h1-h6) in a logical order, never skipping levels for styleScreen reader users navigate by heading level — a skipped or decorative heading breaks that map of the page.
Use semantic HTML elements (button, nav, main, list) instead of styled divsNative elements come with keyboard behavior and screen reader roles built in that a div only fakes with extra ARIA work.
Add a 'skip to main content' link as the first focusable element on the pageWithout it, keyboard and screen reader users must tab through the entire navigation on every single page.
Set the page's lang attribute correctly, including on any section in a different languageIt's what tells a screen reader which pronunciation rules to use — wrong or missing lang mispronounces everything.
Only reach for ARIA roles when no native HTML element provides the same semanticsPer WAI-ARIA guidance, redundant or incorrect ARIA is worse than none — it can override correct native semantics with wrong ones.

0/5

Tab through the entire page and confirm every interactive element is reachableWCAG 2.1.1 requires all functionality to be operable from a keyboard alone, with no exceptions for convenience.
Confirm focus never gets trapped in a widget with no way out via keyboardWCAG 2.1.2 exists because modals and custom widgets are the most common place a keyboard user gets stuck.
Check that a visible focus indicator appears on every focused elementWCAG 2.4.7 requires this because without it, a sighted keyboard user has no way to tell where they are on the page.
Verify tab order follows the visual and logical reading orderA tab order that jumps around disorients anyone not scanning the page visually to keep track.
Confirm focus isn't obscured by a sticky header, cookie banner, or other overlay when it lands on an elementWCAG 2.4.11, new in 2.2, targets exactly this — a focused element hidden behind fixed UI is unusable even with focus.

0/5

Check text contrast meets 4.5:1 for normal text and 3:1 for large text (18pt, or 14pt bold)This is WCAG 1.4.3's exact threshold — below it, low-vision users lose legibility first.
Check UI component and icon contrast meets at least 3:1 against its backgroundWCAG 1.4.11 covers this separately from text, since a low-contrast button border or icon is just as unusable.
Confirm interactive touch targets are at least 24x24 CSS pixels, or spaced enough to avoid mis-tapsWCAG 2.5.8, new in 2.2, sets this minimum because small, cramped targets are hard to hit for anyone with limited fine motor control.
Test the page at 200% browser zoom and confirm content reflows without horizontal scrollingWCAG 1.4.10 requires this so low-vision users who zoom in don't lose content off the edge of the viewport.
Verify color is never the only way information is conveyed (status, required fields, errors)WCAG 1.4.1 exists because colorblind users, or anyone on a poor screen, lose that signal entirely without it.

0/5

Associate every input with a visible label using a real label element or aria-labelledbyA placeholder is not a label — it disappears the moment the user starts typing and isn't announced consistently by screen readers.
Tie error messages to their field programmatically with aria-describedbyWithout the association, a screen reader user hears 'invalid entry' with no idea which field or what to fix.
Avoid asking for the same information twice within one process where it can be reused insteadWCAG 3.3.7, new in 2.2, targets re-entry specifically, since retyping already-given information is a disproportionate burden for many users.
Don't rely on a memory-only or puzzle-based step as the only way to authenticateWCAG 3.3.8, new in 2.2, requires an alternative such as password managers, copy-paste, or a cognitive-function-free method.
Make sure form validation on submit moves focus to the first error, not just a visual bannerA banner alone at the top of the page can go completely unnoticed by someone navigating linearly with a screen reader.

0/4

Provide meaningful alt text for informative images, and empty alt="" for purely decorative onesWCAG 1.1.1 requires text alternatives for non-text content — an empty alt on decoration prevents screen readers from announcing noise.
Add captions to prerecorded video and a transcript for audio-only contentThis is the baseline for deaf and hard-of-hearing users to get the same information as anyone hearing it.
Ensure video doesn't autoplay with sound, or provide an immediate, easy way to pause itUnexpected audio is disorienting for screen reader users, whose own audio output it competes with.
Avoid content that flashes more than three times per secondThis threshold, from WCAG 2.3.1, exists to prevent triggering seizures in people with photosensitive epilepsy.