Guides

WCAG 2.1 AA Checklist for Website Owners

A practical, plain-language walkthrough of the main WCAG 2.1 AA requirements website owners actually need to check, organized by the four core principles.

Published September 2, 2026

WCAG 2.1 AA requires meeting all Level A and Level AA success criteria, which total 50 checkpoints organized under four principles: perceivable, operable, understandable, and robust. This checklist walks through the practical areas that matter most for a typical business website, grouped by those four principles, so you can check your own site systematically rather than guessing at what “AA compliant” actually covers.

Two things worth knowing before going through this list. First, this is a practical walkthrough of the areas that matter most for a typical business site, not a word-for-word restatement of all 50 success criteria; the official W3C documentation is the authoritative source if you need exact legal language. Second, “AA” is a level, not a separate standard: Level AA includes everything required at Level A plus the additional Level AA criteria, so a site claiming AA conformance needs to satisfy both tiers together, not AA criteria in isolation.

Perceivable: can users perceive the content at all

Color contrast. Text needs a contrast ratio of at least 4.5:1 against its background (3:1 for large text). This is worth checking first: the 2026 WebAIM Million report found 83.9% of home pages had low-contrast text, making it the single most common failure across the entire dataset. Light gray text on a white background, a design choice still common in a lot of modern site templates, is a frequent culprit worth checking specifically.

Alt text for images. Every meaningful image needs a text alternative describing its purpose or content; purely decorative images should have empty alt attributes so screen readers skip them rather than announcing something meaningless. Product photos, informational graphics, and icons that convey meaning (like a checkmark indicating success) are the categories most often missed.

Captions and transcripts. Prerecorded video needs captions, and audio-only content needs a transcript. This applies to any embedded video content, not just content you’ve produced yourself.

Resizable text. Text needs to be resizable up to 200% without loss of content or functionality, and content shouldn’t rely on a fixed pixel layout that breaks when zoomed.

Don’t rely on color alone. Any information conveyed by color (a red border indicating a form error, for example) needs a second indicator too, like an icon or text label, for users who can’t perceive the color difference.

Operable: can users navigate and interact with everything

Full keyboard access. Every interactive element, links, buttons, form fields, custom widgets like dropdowns or modals, needs to be operable using only a keyboard, with no keyboard traps that prevent a user from tabbing back out.

Visible focus indicator. When a user tabs to an element, there needs to be a visible indicator showing where focus currently is. This is an area WCAG 2.2 later expanded further, but it’s already a Level AA requirement under 2.1.

No unexpected content shifts. Elements shouldn’t automatically trigger a major change of context (like a new page loading) just from receiving focus, and content shouldn’t move around unpredictably during interaction.

Descriptive link text and headings. Link text should make sense out of context (avoid generic “click here” links), and pages need a logical heading structure so screen reader users can navigate by heading level.

Multiple ways to find content. A site generally needs more than one way to locate a given page, such as a search function plus a navigation menu plus a sitemap, rather than requiring users to know an exact path.

Understandable: is the content and behavior predictable

Clear language and instructions. Form fields need clear labels, and instructions should be understandable, particularly around required fields and expected input formats.

Consistent navigation. Navigation menus and repeated components should appear in the same relative order across pages, so users build an accurate mental model of the site.

Error identification and suggestions. When a form submission fails, the specific error needs to be identified in text (not color alone) and, where possible, a suggestion for fixing it should be provided.

Predictable behavior on input. Changing a form field’s value or setting shouldn’t automatically trigger an unexpected change of context, like submitting the form or navigating away, without the user taking an explicit action.

Robust: does the content work with assistive technology

Valid, well-structured markup. While the old 4.1.1 Parsing criterion was retired in WCAG 2.2, having clean, standards-compliant HTML still matters in practice for reliable assistive technology support.

Proper name, role, and value for custom components. Any custom interactive component (a custom dropdown, tab panel, or modal built from scratch rather than native HTML elements) needs the correct ARIA roles, states, and properties so assistive technology can identify and interact with it correctly.

Status messages. Dynamic status updates, like a “item added to cart” confirmation or a form validation result, need to be announced to screen reader users without requiring them to shift focus manually.

A simple order to work through it in

Trying to fix all 50 criteria at once tends to stall a project before it starts, so a rough prioritization helps. Start with the issues that are both high-impact and easy to verify: color contrast and missing alt text, since both are common (contrast failures alone showed up on 83.9% of home pages in the 2026 WebAIM Million study) and straightforward to check with a scanner. Move next to keyboard access on your core conversion flows, since a user who can’t complete checkout or signup with a keyboard alone is blocked entirely, not just inconvenienced. Then work through form labeling and error messaging, which tends to be where a lot of custom-built components quietly fall short even on sites that otherwise look reasonably accessible. Save the more judgment-heavy criteria, like whether heading structure is genuinely logical or whether a status message announces correctly to a screen reader, for a dedicated manual testing pass once the more mechanical issues are cleared.

How to actually run through this checklist

Automated scanning tools, including those built on Deque’s widely used axe-core engine, are a genuinely useful first pass and will catch a real share of these issues quickly, particularly contrast and missing alt-text problems. But automated tools can’t evaluate everything on this list: whether a heading structure is logical, whether an ARIA label is actually accurate, or whether a screen reader user can complete your checkout flow in a sensible order all require a human tester, ideally one using real assistive technology on your key user flows. Some vendors, like Wawsome, pair automated widget-based checks with a human-reviewed checker specifically to cover that gap, while others like UserWay offer an automated scan with an optional professional manual audit add-on for a deeper pass.

If you’re not sure whether to build this checklist into an in-house process or bring in outside help, our guide on choosing between a widget and a manual audit walks through how to make that call based on your team’s resources.

Frequently asked questions

How many success criteria does WCAG 2.1 AA actually have?

WCAG 2.1 has 50 success criteria total across all three conformance levels (A, AA, AAA). Meeting Level AA means satisfying all Level A and Level AA criteria combined, which comes to 50 criteria at those two levels.

Can I check WCAG 2.1 AA compliance with an automated tool alone?

Only partially. Automated tools reliably catch issues like missing alt attributes or insufficient color contrast, but many criteria, like whether a page's reading order actually makes sense or whether an error message is genuinely understandable, require a human to evaluate properly.

What's the single most common WCAG failure to check first?

Low-contrast text. The 2026 WebAIM Million report found 83.9% of home pages had a low-contrast text failure, making it the single most common issue found, and it's also one of the easier ones to check and fix.

Do I need to test with an actual screen reader, or is automated testing enough?

For genuine confidence, yes. Automated testing is a fast first pass, but testing key user flows, like checkout or account signup, with an actual screen reader is the only reliable way to catch issues in reading order, focus management and dynamic content announcements.