The Essential WCAG 2.1 AA Compliance Checklist for Web Developers
A comprehensive developer checklist covering contrast ratios, keyboard accessibility, semantic landmarks, and ARIA attributes to achieve WCAG 2.1 Level AA conformance.
The Web Content Accessibility Guidelines (WCAG) 2.1 Level AA is the benchmark standard recognized by courts, the U.S. Department of Justice (DOJ), and international regulations like the European Accessibility Act (EAA).
Ensuring full conformance requires attention to detail across design tokens, HTML semantics, and interactive states. Here is our checklist of the most critical requirements to evaluate across your web applications.
1. Perceivable: Information Must Be Accessible to All Senses
- 1.1.1 Non-text Content (Level A): Every informative
<img>, SVG graphic, and icon must have a descriptivealtattribute. Purely decorative elements must explicitly declarealt=""oraria-hidden="true". - 1.3.1 Info and Relationships (Level A): Semantic structure must mirror visual structure. Use genuine HTML headings (
<h1>through<h6>) in logical descending order. Ensure lists use<ul>,<ol>, and<li>. - 1.4.3 Contrast Minimum (Level AA):
- Standard text (under 18pt or under 14pt bold) requires a contrast ratio of at least 4.5:1 against its background.
- Large text requires a contrast ratio of at least 3:1.
- Interactive UI components and borders require a contrast ratio of at least 3:1.
- 1.4.10 Reflow (Level AA): Content must adapt and reflow down to 320 CSS pixels without requiring horizontal scrolling or loss of information.
2. Operable: All Functionality Must Be Keyboard Accessible
- 2.1.1 Keyboard Navigation (Level A): All interactive components (buttons, dropdowns, modal dialogs, tab panels) must be completely operable using keyboard keys alone (
Tab,Shift+Tab,Enter,Space, and Arrow keys). - 2.1.2 No Keyboard Trap (Level A): Focus must never become trapped inside a component without a standard escape mechanism (such as pressing
Escapeto dismiss a dialog). - 2.4.1 Bypass Blocks (Level A): Provide a visible "Skip to main content" link as the first focusable element on every page.
- 2.4.7 Focus Visible (Level AA): Never suppress focus outlines (
outline: nonewithout providing a high-contrast replacement). Always implement high-visibility:focus-visiblestyles.
3. Understandable: Intuitive Navigation & Predictable States
- 3.1.1 Language of Page (Level A): Always declare
<html lang="en">(or appropriate language code) on the root document. - 3.3.2 Labels or Instructions (Level A): Every form input must have an explicitly associated
<label for="...">oraria-label. Placeholder text is not a valid substitute for a persistent label.
4. Robust: Clean Markup & Assistive Technology Compatibility
- 4.1.2 Name, Role, Value (Level A): Interactive custom elements must declare appropriate ARIA roles (e.g.
role="dialog",role="tablist"), active states (aria-expanded,aria-selected), and accessible names. - 4.1.3 Status Messages (Level AA): Asynchronous notifications and toast alerts should use
aria-live="polite"to inform screen readers without interrupting user workflow.
Automated Audits in Your CI/CD Pipeline
Integrating automated accessibility scanners (such as @axe-core/playwright) into your pull request workflows catches over 50% of common accessibility regressions before code reaches production. Combine automated scans with keyboard testing to maintain high compliance scores.
Related Articles
Automated vs. Manual Accessibility Testing: What Every Team Needs to Know
Understand the strengths and limitations of automated scanners vs manual assistive audits, and learn how to build an efficient hybrid compliance testing strategy.
How to Protect Your Business from Predatory ADA Web Accessibility Lawsuits
Over 4,600 digital accessibility lawsuits were filed last year. Learn how plaintiffs' attorneys target small businesses and the 4 steps to shield your company.