9 April 2026 · mandatiq Team

WCAG 2.1 AA Checklist: A Practical Audit Guide

If you're auditing a website for WCAG 2.1 Level AA you don't need a 78-page document. You need a working list of what to check, in what order, and with what tools.

WCAG 2.1 has 50 success criteria at Level A and AA (25 at A, 25 at AA). Roughly 30 of them can be tested automatically with axe-core or equivalent. Below is the order we recommend, organised by the four POUR principles: Perceivable, Operable, Understandable, Robust.

Perceivable - can users sense your content?

These are the ones that matter most for users with visual or auditory impairments, and they're also where automated scanners catch the most issues.

Run automated first

Any axe-core-based scanner catches these in seconds:

1.1.1 Non-text Content - every <img> needs alt. Decorative images get alt="". Icons inside buttons need an accessible name on the button itself.
1.4.3 Contrast (Minimum) - text needs at least 4.5:1 against its background (3:1 for large text, 18pt+ or 14pt bold). Watch out for muted gray-on-white placeholders and faint disabled states.
1.4.10 Reflow - at 320 CSS pixels wide, content must not require horizontal scrolling. Most responsive sites pass this; sites with fixed-width tables or data grids fail.
1.4.11 Non-text Contrast - UI components and graphical objects need 3:1 contrast against adjacent colours. Form input borders are the usual culprit.
1.4.12 Text Spacing - content must remain functional when users override line height, paragraph spacing, letter spacing, and word spacing. Test by applying the WCAG Text Spacing bookmarklet.

Then check manually

1.2.x Time-based Media - captions for prerecorded video, audio descriptions for video. No scanner can tell whether a caption track is accurate.
1.3.1 Info and Relationships - semantic HTML. Headings in order, lists as <ul>/<ol>, form labels associated with inputs. Most issues here come from custom components built with <div> soup.
1.4.4 Resize Text - zoom to 200% in the browser; nothing should be cut off or overlap.

Operable - can users interact with everything?

This is where keyboard users and screen-reader users live. Pull your mouse out and tab through the entire flow. If you can't reach a control with the keyboard, it fails 2.1.1.

The high-value manual checks:

2.1.1 Keyboard - every interactive element reachable and operable via Tab and Enter/Space. Pay special attention to custom dropdowns, modals, and date pickers.
2.1.2 No Keyboard Trap - once you tab into a widget, you must be able to tab out. Modals are the classic offender: a modal that traps focus correctly while open and releases focus when closed.
2.4.3 Focus Order - the tab order should match the visual reading order. CSS can break this (e.g. flex-direction: row-reverse).
2.4.7 Focus Visible - every focusable element must have a visible focus indicator. Removing the default outline without replacing it is a Level AA failure on its own.
2.5.5 Target Size (Enhanced) - Level AAA, but worth aiming for. Touch targets at least 44×44 CSS pixels.

The automated wins:

2.4.1 Bypass Blocks - needs a "Skip to main content" link or proper landmark structure.
2.4.2 Page Titled - every page needs a unique, descriptive <title>.
2.4.4 Link Purpose (In Context) - avoid "click here" / "read more" links with no surrounding context.

Understandable - can users comprehend the content and the interface?

Mostly manual review, but two automated wins:

3.1.1 Language of Page - the <html> element needs a lang attribute.
3.3.2 Labels or Instructions - every form field needs a programmatic label (not just placeholder text).

The manual checks worth your time:

3.2.1 On Focus - focusing an element must not change the context (no auto-submitting forms when an input gets focus, no opening modals on focus).
3.2.2 On Input - same rule for changes triggered by user input. A select that auto-navigates when you change its value fails this.
3.3.1 Error Identification - when validation fails, the error must be announced to screen readers. aria-invalid="true" and an associated error message do the job.
3.3.3 Error Suggestion - where possible, suggest a fix ("did you mean user@example.com?").

Robust - does it work with assistive tech?

Almost entirely automated, and almost entirely about valid markup and ARIA.

4.1.1 Parsing - was deprecated in WCAG 2.2 but still scanned by axe-core for 2.1. It checks for well-formed HTML and ARIA. If your page has a lot of parsing errors, expect to fail this.
4.1.2 Name, Role, Value - the most-violated criterion in WCAG 2.1. Any custom widget (toggle, accordion, tab panel) needs the right ARIA role and a programmatic name and value that screen readers can announce. If you're using a component library, check whether it has built-in accessibility or if you need to add ARIA yourself.
4.1.3 Status Messages - toast notifications and live updates need role="status" or role="alert" so screen readers announce them without stealing focus.

What automated scanners cannot catch

This is the part most teams underestimate. axe-core (and every tool built on it) catches roughly the 30 criteria that have a deterministic, parseable signal. The remaining 20 require human judgement:

Whether alt text is meaningful, not just present
Whether headings describe the section, not just exist in order
Whether captions match the spoken audio
Whether keyboard focus order is logical, not just technically valid
Whether error messages are understandable
Whether ARIA labels actually describe what the control does

A reasonable rule: automated scanning gets you to 70%. The last 30% is half a day with NVDA or VoiceOver and a real keyboard user.

Where to start tomorrow

If you do nothing else this week, do these four things:

Run an automated scan on your top 10 pages.
Fix the missing alt attributes and the contrast violations. That's usually 60% of your reported issues.
Open the site without a mouse. Tab through the homepage, the signup flow, and the checkout and note everything you can't reach.
Add a visible focus indicator if your reset CSS removed the default outline.

That alone moves most sites from "obviously failing" to "credibly working on it" - which is, in 2026, the difference between a regulator's complaint and a regulator's email acknowledging your statement.

You can run the first scan above on any page in 30 seconds with our free scanner - it shows you which WCAG criteria each violation maps to.