WCAG 2.1 AA Compliance Checklist for Website Owners

DEFINITION

POUR Principles

The four organizing principles of WCAG: Perceivable (can users perceive the content?), Operable (can users interact with controls?), Understandable (can users comprehend the content?), and Robust (does the content work across assistive technologies?). Every WCAG success criterion falls under one of these four.

DEFINITION

Success Criteria

Individual, testable requirements within WCAG. Each criterion has a level (A, AA, or AAA). Most legal and regulatory frameworks require conformance to Level AA, which includes all Level A criteria plus additional requirements.

DEFINITION

Conformance Levels

WCAG defines three conformance levels. Level A is the minimum baseline. Level AA adds requirements like contrast ratios and consistent navigation — this is what courts and regulators expect. Level AAA is aspirational and not typically required for legal compliance.

What WCAG 2.1 AA Actually Requires

WCAG 2.1 has 78 success criteria total across three conformance levels. Level AA — the level courts and regulators care about — includes 50 criteria (all 30 Level A criteria plus 20 Level AA criteria). That sounds like a lot, but most real-world failures cluster around the same 10-12 issues.

This checklist covers the criteria that actually matter for compliance, grouped by the four POUR principles.

Perceivable: Can Users See, Hear, or Otherwise Access Your Content?

This principle covers how content is presented. If a user cannot perceive your content through at least one sense, the content does not exist for them.

1.1.1 Non-Text Content (Level A) — Every image, icon, and non-text element needs a text alternative. Decorative images need empty alt attributes (alt=""). Functional images (buttons, links) need alt text that describes the function, not the image.

1.2.1-1.2.5 Time-Based Media (Level A/AA) — Videos need captions. Pre-recorded audio needs transcripts. Live video needs real-time captions at AA.

1.3.1 Info and Relationships (Level A) — Information conveyed through visual formatting (headings, lists, tables, form labels) must also be conveyed programmatically. If it looks like a heading, it must be an <h2> or <h3>, not a bold <div>.

1.4.3 Contrast (Level AA) — Text must have a contrast ratio of at least 4.5:1 against its background. Large text (18pt or 14pt bold) requires 3:1. Test with a contrast checker or use A11yProof’s automated contrast scanning.

1.4.10 Reflow (Level AA) — Content must reflow at 320px width (equivalent to 400% zoom on a 1280px viewport) without horizontal scrolling. No content should be cut off or overlap.

1.4.11 Non-Text Contrast (Level AA) — UI components (form borders, icons, focus indicators) need 3:1 contrast against their background. Subtle gray form borders on white backgrounds often fail this.

Operable: Can Users Navigate and Interact?

This principle covers keyboard access, navigation, and input methods.

2.1.1 Keyboard (Level A) — All functionality must be operable via keyboard. No mouse-only interactions.

2.1.2 No Keyboard Trap (Level A) — Users must be able to navigate away from every component using the keyboard. Modals, dropdown menus, and date pickers are common trap sources.

2.4.1 Bypass Blocks (Level A) — Provide a “skip to content” link so keyboard users can bypass repeated navigation. This is one of the easiest fixes and one of the most commonly missing.

2.4.2 Page Titled (Level A) — Every page needs a descriptive <title> element. “Home” or “Page 1” is not descriptive. “WCAG Compliance Checklist | A11yProof” is.

2.4.3 Focus Order (Level A) — Tab order must follow the visual layout. If a user tabs through your page and focus jumps from the header to the footer and back to the sidebar, the focus order is broken.

2.4.7 Focus Visible (Level AA) — When an element receives keyboard focus, it must have a visible indicator. Removing the default browser focus outline with outline: none without providing an alternative is a WCAG violation.

2.5.5 Target Size (Level AAA, but practically important) — While AAA, making touch targets at least 44x44 CSS pixels prevents usability issues for users with motor impairments. Many mobile accessibility complaints stem from tiny tap targets.

Understandable: Can Users Comprehend Your Content and Interface?

This principle covers language, predictability, and input assistance.

3.1.1 Language of Page (Level A) — Declare the page language in the <html lang="en"> attribute. Screen readers use this to select the correct pronunciation engine.

3.1.2 Language of Parts (Level AA) — If a section of content is in a different language, mark it with a lang attribute on that element.

3.2.3 Consistent Navigation (Level AA) — Navigation menus must appear in the same order across pages. Moving the nav items around from page to page confuses users who rely on predictable layouts.

3.3.1 Error Identification (Level A) — When a form validation error occurs, identify the field in error and describe the error in text. Do not rely on color alone (a red border without a text message fails).

3.3.2 Labels or Instructions (Level A) — Every form input needs a visible label. Placeholder text alone does not count — it disappears when the user starts typing.

Robust: Does Your Code Work with Assistive Technologies?

This principle covers HTML quality and ARIA usage.

4.1.1 Parsing (Level A, deprecated in WCAG 2.2 but still good practice) — HTML should not have duplicate IDs, unclosed tags, or malformed attributes. These cause unpredictable behavior in assistive technologies.

4.1.2 Name, Role, Value (Level A) — Custom UI components must expose their name, role, and state to assistive technologies. A custom dropdown must announce itself as a “combobox” or “listbox,” not just a <div>.

4.1.3 Status Messages (Level AA) — Status messages (like “item added to cart” or “form submitted successfully”) must be announced by screen readers without moving focus. Use ARIA live regions.

How to Use This Checklist

Start with an automated scan using A11yProof or axe to catch the programmatically testable criteria. Then work through the manual checks: keyboard navigation, screen reader testing, form validation, and zoom testing.

Track your progress against this checklist over time. Accessibility is not a one-time project — every code change, content update, or design revision can introduce new issues. Scheduled scans catch regressions before they become legal problems.