Web Accessibility Checklist for Developers (WCAG 2.2)

Most accessibility failures aren’t exotic. They’re a missing label on a search box, a gray-on-white button nobody can read, a modal that traps the keyboard or an icon button a screen reader announces as just “button.” These are quick to fix in code, and expensive to fix after a demand letter or a lost government contract.

This checklist is built for developers. Each item maps to a WCAG 2.2 success criterion, says how to test it and, where it helps, shows the code fix.

What WCAG 2.2 is and what level to aim for

The Web Content Accessibility Guidelines (WCAG) are the W3C’s standard for accessible web content. WCAG 2.2 became a W3C Recommendation on October 5, 2023. Success criteria come in 3 levels: A (minimum), AA (the usual target) and AAA (enhanced).

Most organizations, contracts and laws aim for Level AA, which means meeting every A and AA criterion. WCAG 2.2 is backward compatible: if you meet 2.2 AA, you also meet 2.1 AA and 2.0 AA. According to the W3C’s What’s New in WCAG 2.2, the update added 9 success criteria and removed 4.1.1 Parsing as obsolete.

Where the law stands in the US

• State and local governments: The Department of Justice’s 2024 ADA Title II rule requires web content and mobile apps to meet WCAG 2.1 Level AA. An interim final rule published April 20, 2026 pushed the compliance dates back 1 year: April 26, 2027 for entities serving 50,000 or more people, and April 26, 2028 for smaller entities and special districts. DOJ notes that existing Title II accessibility duties apply regardless of those dates.
• Businesses: The ADA applies to many private businesses, and website accessibility lawsuits are common, but there’s no DOJ technical rule for private websites. WCAG AA is the standard most settlements and policies reference.
• Selling in Europe: The European Accessibility Act has applied to many consumer digital products and services since June 28, 2025.

This is not legal advice. Check with counsel about your own obligations.

Key takeaway: Target WCAG 2.2 Level AA. It covers the 2.1 AA requirement in the US government rule, and most of it can be built into your components once and reused everywhere.

The checklist at a glance

Area	Key criteria	Level	Quick test
Images and media	1.1.1 Non-text Content, 1.2.2 Captions	A	Inspect alt text, play video with captions
Structure	1.3.1 Info and Relationships, 2.4.6 Headings and Labels	A, AA	Heading outline, landmarks
Color	1.4.3 Contrast (Minimum), 1.4.11 Non-text Contrast, 1.4.1 Use of Color	AA, AA, A	Contrast checker
Keyboard	2.1.1 Keyboard, 2.1.2 No Keyboard Trap, 2.4.7 Focus Visible	A, A, AA	Unplug the mouse
Focus (new in 2.2)	2.4.11 Focus Not Obscured (Minimum)	AA	Tab under sticky headers
Pointer (new in 2.2)	2.5.7 Dragging Movements, 2.5.8 Target Size (Minimum)	AA	Measure targets, try without drag
Forms	3.3.1 Error Identification, 3.3.2 Labels or Instructions	A	Submit empty form
Forms (new in 2.2)	3.3.7 Redundant Entry, 3.3.8 Accessible Authentication (Minimum)	A, AA	Walk through checkout and login
Help (new in 2.2)	3.2.6 Consistent Help	A	Compare help location across pages
Code	4.1.2 Name, Role, Value	A	Screen reader, accessibility tree

Images, media and structure

Give every meaningful image a text alternative (1.1.1). Decorative images get an empty alt so screen readers skip them.

html <img src="chart-q3.png" alt="Q3 sales rose 12% over Q2, led by online orders"> <img src="divider.svg" alt="">

Name icon-only buttons. An icon with no text is announced as just “button.”

```html

```

Caption videos (1.2.2) and provide transcripts for audio-only content.

Use real headings and landmarks (1.3.1). One logical heading outline per page, with no skipped levels for styling. Use header, nav, main and footer elements so screen reader users can jump around.

Set the page language and titles. Add lang=”en” on the html element (3.1.1) and a unique, descriptive title on every page (2.4.2).

Color and contrast

Normal text needs a contrast ratio of at least 4.5:1, and large text at least 3:1 (1.4.3). Large text means roughly 18 point, or 14 point bold. Light gray placeholder text and text on photos are the usual failures.

UI parts need 3:1 too (1.4.11). Input borders, focus rings, icons and chart lines must have at least 3:1 contrast against their background.

Don’t use color alone (1.4.1). A red border on an invalid field needs an error message or icon as well. Links inside paragraphs should be underlined or otherwise distinguishable without color.

Support zoom and reflow (1.4.4, 1.4.10). Text should resize to 200% without loss of content, and pages should reflow at a 320 CSS pixel width without horizontal scrolling. Never disable pinch zoom in the viewport meta tag.

Keyboard and focus

Everything must work with a keyboard (2.1.1). The most common failure is a clickable div.

```html

Save ```

No keyboard traps (2.1.2). Modals should move focus inside when opened, keep Tab within the dialog while open, close on Escape and return focus to the trigger. The native dialog element opened with showModal() handles much of this.

Show focus clearly (2.4.7). Never remove outlines without a replacement.

css /* Fails */ :focus { outline: none; } /* Passes */ :focus-visible { outline: 3px solid #1a5fb4; outline-offset: 2px; }

Don’t hide focus under sticky elements (2.4.11, new in 2.2). A focused item must not be entirely covered by a sticky header, cookie banner or chat widget. Adding scroll-padding-top equal to your header height is a simple fix.

Keep a logical order (2.4.3) and add a “Skip to main content” link as the first focusable element (2.4.1).

Pointer and touch targets (new in 2.2)

Targets at least 24 by 24 CSS pixels (2.5.8). Small icon buttons, pagination links and close buttons are common failures. The criterion has exceptions, including when targets have enough spacing around them, and inline links in a sentence.

css .icon-button { min-width: 24px; min-height: 24px; }

Many design systems go larger, around 44 pixels, for comfortable touch use.

Offer an alternative to dragging (2.5.7). Sliders, sortable lists and map pins need a single-pointer option, such as buttons or arrow keys, unless dragging is essential.

Forms, errors and authentication

Every field needs a visible, programmatic label (3.3.2, 1.3.1). Placeholder text is not a label.

html <label for="email">Email address</label> <input id="email" type="email" autocomplete="email" required>

Explain errors in text (3.3.1) and suggest fixes (3.3.3). Link the message to the field so screen readers announce it.

```html

Enter a 5-digit ZIP code, for example 30301.

```

Use autocomplete attributes (1.3.5) for personal data fields such as name, email and address.

Don’t make people re-enter information (3.3.7, new in 2.2). If a user typed a shipping address, auto-fill it or let them select “same as shipping” for billing.

Accessible login (3.3.8, new in 2.2). Don’t require a cognitive test, such as solving a puzzle or remembering a code, unless there’s an alternative. Allowing paste and password managers, offering passkeys or email links all help. Blocking paste in password fields is a classic failure.

Consistent help (3.2.6, new in 2.2). If you offer help, such as a contact link or chat, put it in the same relative place on every page.

ARIA and custom components

Use native HTML first. Buttons, links, inputs, select and dialog come with roles, keyboard behavior and states built in. ARIA can’t add keyboard support; it only changes what assistive technology announces.

Custom widgets need name, role and value (4.1.2). A custom toggle must expose its state:

html <button aria-pressed="false">Dark mode</button>

Announce dynamic updates (4.1.3). Use a polite live region for messages like “Added to cart” or “3 results found.”

```html

```

If you use a framework, build these patterns into shared components once. Our guide to React vs Angular vs Vue covers how each structures components.

Where to start: testing in 5 steps

1. Run an automated scan with a browser extension or a CI tool such as axe-core, Lighthouse or WAVE. Automated tools catch only part of WCAG issues, so treat a clean scan as a starting point.
2. Do a keyboard pass. Tab through every page and flow. Can you reach, see and operate everything? Can you get out of every modal?
3. Check contrast and zoom. Use a contrast checker on text and controls, then zoom to 200% and test a 320-pixel-wide window.
4. Test with a screen reader. NVDA on Windows and VoiceOver on Mac and iPhone are free. Check headings, form labels, buttons and error messages.
5. Add accessibility to your definition of done. Include automated checks in your pipeline and in your pre-launch QA checklist, and add component-level tests alongside your unit and integration tests.

For high-traffic sites, also check performance and layout basics in our technical SEO checklist, since many fixes overlap.

Conclusion

WCAG 2.2 AA looks long on paper, but most failures come from a short list: missing labels and alt text, low contrast, broken keyboard access, invisible focus, small targets and inaccessible login. Fix those in your shared components, test with a keyboard and a screen reader, and accessibility becomes part of how you build rather than a late scramble. For definitions of terms like ARIA and WCAG, see our glossary.

Sources

• Web Content Accessibility Guidelines (WCAG) 2.2, W3C — success criteria text, levels and contrast requirements
• What’s New in WCAG 2.2, W3C WAI — 9 new criteria, removal of 4.1.1 Parsing, 24 by 24 pixel target size, October 5, 2023 publication
• Extension of Compliance Dates, Federal Register (April 20, 2026) — new ADA Title II compliance dates
• Fact Sheet: New Rule on Web Content and Mobile Apps, ADA.gov — Title II rule requiring WCAG 2.1 Level AA