Published March 27, 2026 · 18 min read
Web Accessibility Checklist 2026: WCAG 2.2 Complete Guide
Web accessibility is not a nice-to-have. It is a legal requirement in most jurisdictions, a moral imperative, and increasingly a ranking factor for search engines. Over 1.3 billion people worldwide live with some form of disability. If your website is not accessible, you are excluding roughly 16% of the global population from using your product.
This checklist covers WCAG 2.2 Level AA requirements, which is the standard that most accessibility laws reference. Each item includes what to check, why it matters, and how to fix it. Use our Accessibility Checker tool to automate the technical checks.
1. Perceivable
Information and UI components must be presentable to users in ways they can perceive.
Text Alternatives
- All
<img> elements have meaningful alt attributes. Decorative images use alt="".
- Complex images (charts, infographics) have extended descriptions via
aria-describedby or a visible caption.
- Icon buttons have accessible labels:
<button aria-label="Close menu">
- SVG images include
<title> elements or aria-label attributes.
- Image-of-text is avoided. Use real HTML text styled with CSS instead.
/* Good: Meaningful alt text */
<img src="chart.png" alt="Bar chart showing 40% increase in
sign-ups from January to March 2026">
/* Good: Decorative image */
<img src="divider.png" alt="" role="presentation">
/* Good: Icon button */
<button aria-label="Search">
<svg>...</svg>
</button>
Color and Contrast
- Text has a minimum contrast ratio of 4.5:1 against its background (3:1 for large text).
- UI components (buttons, form fields, focus indicators) have at least 3:1 contrast.
- Color is never the only way to convey information. Links in text should have underlines or other visual indicators besides color.
- Error states use more than just red color (add icons, text, or borders).
Test contrast ratios with our Contrast Checker. Common fails: light gray text on white backgrounds, placeholder text in form fields, and disabled button states that are too faded to read.
Media
- Videos have captions (or a transcript link).
- Audio content has a text transcript.
- No content auto-plays audio. If it does, provide a visible pause/stop control within the first 3 seconds.
- Flashing content does not flash more than 3 times per second (seizure risk).
Responsive and Adaptable
- Content is readable and functional when zoomed to 200%.
- Text reflows at 400% zoom without horizontal scrolling (for pages up to 320px viewport width).
- Content does not require a specific orientation (landscape or portrait).
- Spacing between lines is at least 1.5x the font size. Paragraph spacing is at least 2x font size.
2. Operable
UI components and navigation must be operable by all users.
Keyboard Navigation
- Every interactive element is reachable by Tab key. This is the single most important accessibility requirement.
- Focus order follows a logical reading order (typically top-to-bottom, left-to-right).
- Focus is visible. A clear outline or highlight appears on the currently focused element.
- No keyboard traps. Users can always Tab away from any component.
- Custom widgets (dropdowns, modals, tabs) support expected keyboard patterns (Arrow keys, Escape, Enter).
- Skip navigation link is provided:
<a href="#main" class="skip-link">Skip to content</a>
/* Skip link CSS - visible on focus */
.skip-link {
position: absolute;
top: -100%;
left: 0;
background: #ff5f1f;
color: #0a0a0a;
padding: 8px 16px;
z-index: 9999;
font-weight: 700;
}
.skip-link:focus {
top: 0;
}
/* Visible focus indicators */
:focus-visible {
outline: 2px solid #ff5f1f;
outline-offset: 2px;
}
/* Never do this */
*:focus { outline: none; } /* REMOVES ALL FOCUS INDICATORS */
Timing and Motion
- Users can pause, stop, or hide any moving, blinking, or auto-updating content.
- Session timeouts provide a warning and allow users to extend their session.
- Animations respect
prefers-reduced-motion:
@media (prefers-reduced-motion: reduce) {
*, *::before, *::after {
animation-duration: 0.01ms !important;
animation-iteration-count: 1 !important;
transition-duration: 0.01ms !important;
scroll-behavior: auto !important;
}
}
Navigation
- Pages have descriptive
<title> elements.
- Headings follow a logical hierarchy (h1 > h2 > h3, no skipping levels).
- Links have descriptive text. Avoid "click here" or "read more" without context.
- Multiple navigation methods are available (menu, search, sitemap).
- The current page is indicated in navigation menus (use
aria-current="page").
Pointer and Touch
- Touch targets are at least 24x24 CSS pixels (WCAG 2.2 requirement).
- Functionality available via complex gestures (pinch, swipe) also works with simple clicks.
- Dragging operations have a non-dragging alternative.
3. Understandable
Information and operation of the UI must be understandable.
Language and Readability
- Page language is declared:
<html lang="en">
- Language changes within the page are marked:
<span lang="fr">Bonjour</span>
- Unusual words, abbreviations, and jargon are defined or explained.
Forms
- Every form input has a visible
<label> element linked via for/id.
- Required fields are clearly marked (not just with color).
- Error messages identify the specific field and describe how to fix the error.
- Errors are announced to screen readers (use
aria-live="polite" or role="alert").
- Form instructions appear before the form, not only after submission fails.
- Autocomplete attributes are used for common fields:
autocomplete="email", autocomplete="tel".
/* Accessible form field */
<div class="field">
<label for="email">
Email address <span aria-hidden="true">*</span>
<span class="sr-only">(required)</span>
</label>
<input type="email" id="email" name="email"
required autocomplete="email"
aria-describedby="email-error">
<div id="email-error" role="alert"
class="error" hidden>
Please enter a valid email address (e.g., name@example.com).
</div>
</div>
Consistency
- Navigation is consistent across pages.
- Similar components behave the same way throughout the site.
- Changes of context (new windows, form submissions) are user-initiated, not automatic.
4. Robust
Content must be robust enough to be interpreted by a wide variety of user agents, including assistive technologies.
HTML and ARIA
- HTML validates without errors (use our HTML Validator).
- ARIA roles, states, and properties are used correctly. First rule of ARIA: do not use ARIA if native HTML works.
- Custom widgets use appropriate ARIA patterns (dialog, tablist, menubar, etc.).
- Dynamic content updates are announced via
aria-live regions.
- IDs are unique within the page.
/* ARIA live region for dynamic updates */
<div aria-live="polite" aria-atomic="true" class="sr-only">
<!-- JavaScript updates this when content changes -->
</div>
/* Accessible modal dialog */
<div role="dialog" aria-modal="true"
aria-labelledby="dialog-title">
<h2 id="dialog-title">Confirm deletion</h2>
<p>This action cannot be undone.</p>
<button>Delete</button>
<button>Cancel</button>
</div>
New in WCAG 2.2
WCAG 2.2, published in 2023 and now the recommended standard, added several new success criteria:
- 2.4.11 Focus Not Obscured (Minimum): When an element receives keyboard focus, it is not entirely hidden by author-created content (sticky headers, cookie banners, chat widgets).
- 2.4.13 Focus Appearance: Focus indicators must have a minimum area of the element's perimeter and a 3:1 contrast ratio against the unfocused state.
- 2.5.7 Dragging Movements: Any functionality that uses dragging must have a non-dragging alternative (e.g., up/down buttons for reordering lists).
- 2.5.8 Target Size (Minimum): Interactive targets must be at least 24x24 CSS pixels, or have sufficient spacing from adjacent targets.
- 3.2.6 Consistent Help: If help mechanisms exist (chat, contact, FAQ links), they appear in the same relative location on every page.
- 3.3.7 Redundant Entry: Information previously entered by the user is auto-populated or available for selection. Do not make users re-enter data.
- 3.3.8 Accessible Authentication: Login processes do not require cognitive function tests (CAPTCHAs, puzzles) unless an alternative is provided.
Testing Tools and Process
Automated Testing
- SPUNK.CODES Accessibility Checker — Free, instant audit of any page
- axe DevTools — Browser extension for in-page accessibility testing
- Lighthouse — Built into Chrome DevTools, includes accessibility audit
- WAVE — Web accessibility evaluation tool by WebAIM
Manual Testing Checklist
- Navigate the entire site using only the keyboard (Tab, Enter, Escape, Arrow keys).
- Test with a screen reader (VoiceOver on Mac, NVDA on Windows, TalkBack on Android).
- Zoom to 200% and verify everything is still usable.
- Test with high contrast mode enabled.
- Disable CSS and verify content is still readable in a logical order.
- Test on mobile with screen reader enabled.
Automated tools catch roughly 30-40% of accessibility issues. Manual testing is required for the rest. No automated tool can verify that alt text is actually descriptive, that focus order makes sense, or that error messages are helpful.
Legal Requirements in 2026
- United States: ADA Title III covers websites of businesses open to the public. The DOJ references WCAG 2.1 AA. ADA lawsuits exceeded 4,000 in 2025.
- European Union: European Accessibility Act (EAA) enforcement began June 2025. Applies to private sector digital products and services. Requires WCAG 2.1 AA minimum.
- Canada: Accessible Canada Act requires federal organizations to meet WCAG 2.1 AA.
- United Kingdom: Equality Act 2010 plus public sector regulations require WCAG 2.1 AA for government sites.
The trend is clear: accessibility requirements are expanding from public sector to private sector globally. Building accessible websites now is not just ethical — it is risk management.
Audit Your Site's Accessibility
Run a free accessibility check on any URL. Instant results with specific recommendations.
Accessibility Checker
Contrast Checker
Related Tools and Resources
- Accessibility Checker — Automated WCAG audit
- Contrast Checker — Verify color contrast ratios
- HTML Validator — Check markup for errors
- Heading Structure Checker — Validate heading hierarchy
- Dark Mode CSS Guide — Accessible dark mode implementation
- Accessibility Books on Amazon