Accessibility Heuristics: Auditing Beyond the Checklist

WebAIM scans the home pages of the top million websites once a year. Every year since it started, it has found detectable WCAG failures on roughly nineteen out of twenty of them. The word doing the work in that sentence is detectable. An automated scanner reads the markup and the computed styles. It cannot tab through a date picker, and it cannot tell you that a modal announced itself correctly and then dropped the user back at the top of the page on close.

That is the gap a checklist leaves. Success criteria are written to be testable, which means they are written around the things a test can see. Whether an interface is actually operable by someone who never touches a mouse, or readable by someone getting it one line at a time through speech, needs a reviewer asking open questions. An accessibility heuristic is one of those questions: broad enough to catch a barrier the criteria never anticipated.

Why conformance and usability come apart

Take a form field labelled by placeholder text. The placeholder is programmatically associated, the contrast passes, the input has a name. A scanner sees nothing wrong. A user sees the label vanish the moment they start typing, and a screen reader user reaching that field after an error has no idea which of the six inputs they are standing in.

Or take alt text. alt="image" satisfies 1.1.1 Non-text Content in the sense that the attribute exists and is not empty. It satisfies nothing else.

This is why accessibility work that lives entirely inside a compliance ticket stalls. The team fixes the eighty contrast violations the scanner found, the score goes green, and the checkout is still impossible to complete with a keyboard.

Seven accessibility heuristics

These are evaluation prompts. Each maps onto success criteria you can cite in a ticket, but the heuristic is the wider question.

1. Keyboard reach, and a way back out

Tab through the whole flow without touching the pointer. Can you reach every control, activate it, and get out again?

The failures cluster in a predictable set of components: custom dropdowns, date pickers, carousels, drag-and-drop reorderers, and anything built on a div with a click handler and no tabindex. These are almost always the pieces a team wrote itself or pulled from a library that stopped being maintained, which is also why they survive redesigns — nobody wants to reopen them.

Getting out matters as much as getting in. A modal that traps focus deliberately is correct; a modal that traps it permanently because Escape was never wired up leaves the user closing the tab.

Related criteria: 2.1.1 Keyboard, 2.1.2 No Keyboard Trap.

2. Focus you can follow

Two separate failures hide here. The first is a focus ring removed in CSS and never replaced — outline: none deserves its own lint rule. The second is focus that stays behind: open a dialog and focus remains on the page beneath it, close it and focus resets to body, so the next Tab starts the user over from the skip link.

Related criteria: 2.4.7 Focus Visible, 2.4.11 Focus Not Obscured, 1.4.11 Non-text Contrast for the indicator itself.

3. Names that match what is on screen

A button that looks like a toggle should report as a toggle, with a pressed state that changes when it does. A link styled as a button should still announce as a link if it navigates. The mismatch cases are the interesting ones: an icon-only button whose accessible name is "button", a tab list built from list items with no role="tab", a custom select whose expanded state never updates.

Read the accessibility tree in dev tools next to the rendered component and check that a stranger could match one to the other. Where the mismatch is in the name itself, our guide to ARIA labels covers the ordering rules that decide which text wins.

Related criteria: 4.1.2 Name, Role, Value; 2.5.3 Label in Name.

4. Nothing means only red

Around one in twelve men has a colour vision deficiency. That is enough to break required fields marked in red alone, a status column where green means shipped and amber means delayed, or a six-series line chart separated by hue. None of them survive a greyscale screenshot either.

Contrast is the floor underneath this: 4.5:1 for body text, 3:1 for large text and for the non-text parts of a control. Check specific pairs with the contrast checker.

Related criteria: 1.4.1 Use of Color, 1.4.3 Contrast (Minimum), 1.4.11 Non-text Contrast.

5. Structure that matches the outline

1.3.1 Info and Relationships is the criterion. The review question underneath it is whether the markup tells the same story the layout does.

Read the page as a heading list. Does it work as a table of contents, or does it jump from H1 to H4 because someone wanted smaller text? Are the things that look like lists marked up as lists, and the thing that looks like the main column actually main?

Screen reader users move through a page by these structures the way sighted users scan it, so one H1 and thirty unlabelled divs offers no way in. That is the same argument behind skip navigation links: a long repeated block needs a way past it that does not cost forty keystrokes.

Related criteria: 1.3.1 Info and Relationships, 2.4.1 Bypass Blocks, 2.4.6 Headings and Labels.

6. Pace under the user's control

Carousels that advance themselves. Toasts that vanish in three seconds. Then the session expires with no warning and the form someone spent nine minutes on is gone.

Large background motion triggers nausea and vertigo in people with vestibular disorders, which is why parallax that keeps running while you read is a health question and not a taste one. The test is whether the user can stop it, extend it, or opt out before it starts, including via prefers-reduced-motion.

Related criteria: 2.2.1 Timing Adjustable, 2.2.2 Pause, Stop, Hide, 2.3.3 Animation from Interactions.

7. Errors in words, next to the field

"Something went wrong" fails on every count. So does a red border with no message, a message that only appears as a tooltip on hover, and a summary at the top of a long form that names the field without taking you to it.

An error should say what was wrong with the value entered, in words, somewhere the user will land next. The common real-world version of this failure is a validation message rendered visually but never announced — the screen reader user submits, hears silence, and assumes the button is broken.

Related criteria: 3.3.1 Error Identification, 3.3.3 Error Suggestion, 4.1.3 Status Messages.

Running the pass

The mechanics are the same as any expert review, and the heuristic evaluation walkthrough covers them in depth. Three things change when the heuristics are accessibility heuristics.

Pick real flows, not pages. Signup, checkout, the thing your product is actually for. Barriers cluster at transitions: a modal opening, a step advancing, a validation firing. A page-by-page sweep walks straight past them.

Use the assistive tech, at least a little. You do not need expertise to find the blocking issues. Tab through the flow. Turn on VoiceOver or NVDA and try to complete one task. Zoom to 400% and see whether the layout reflows into one column or starts scrolling sideways. Most of what a checklist misses shows up in the first ten minutes.

Rate severity by what the barrier costs. A missing alt attribute on a decorative icon is an A-level failure that costs nothing. A keyboard trap in the payment step stops the purchase.

What the automated tools are for

None of this argues against scanners. They are fast and they never get bored, which suits failure classes that are mechanical and repetitive. Low-contrast text and missing form labels are most of what the WebAIM Million finds every year. They are genuinely harmful, and no reviewer should be spending attention on them.

Automated testing catches about a third of real issues, and it is the cheapest third. Run the scanner first so the manual pass starts on a page that has already had the obvious removed. Then spend the review on the questions above, which is where the barriers that stop someone completing a task actually live.

Where the standards fit

WCAG 2.2 became a W3C Recommendation in October 2023 and added nine success criteria, several of which read like heuristics that got promoted: focus not obscured by sticky headers, a 24×24 minimum target size, not making people re-enter information they already gave you, not gating authentication behind a cognitive puzzle. Section 508 in the US and the European Accessibility Act, enforceable since June 2025, both point back at WCAG.

Cite them in tickets. They make a finding legible to legal, procurement, and whoever decides what gets scheduled. But you fix the keyboard trap because it stops people buying things. 2.1.2 is the reference number you attach to that.

Frequently asked questions

What is an accessibility heuristic?

An open evaluation question about whether an interface is usable by people with disabilities, used the way Nielsen's usability heuristics are used — as a prompt for expert review, not a pass/fail test. Each accessibility heuristic usually maps onto several WCAG success criteria while staying deliberately broader than any of them, so it catches barriers the criteria did not anticipate.

How is this different from a WCAG accessibility checklist?

A checklist asks whether specific, testable conditions are met. A heuristic asks whether the underlying goal is achieved. "Is there a visible focus indicator" is a checklist item. "Can a keyboard user always tell where they are" is the heuristic, and it catches the dialog that resets focus to the top of the document while every individual indicator passes.

Do accessibility heuristics replace conformance testing?

No, and they should not be sold that way. Conformance is the legal floor, and most of it automates. Heuristics find the rest. Most teams need a scanner in CI, a manual keyboard and screen reader pass on the main flows, and testing with disabled users on anything high-stakes.

What contrast ratio does WCAG require?

4.5:1 for normal text and 3:1 for large text (roughly 18pt, or 14pt bold) under 1.4.3 Contrast (Minimum) at level AA; 7:1 and 4.5:1 at AAA. Separately, 1.4.11 Non-text Contrast requires 3:1 for user interface components and meaningful graphics — the part people forget, since it covers focus rings, input borders, and icon buttons.

Is APCA replacing the WCAG contrast formula?

Not yet. APCA models perceived lightness contrast more accurately than the current ratio, particularly for dark themes and thin type, and it appears in WCAG 3 draft work. WCAG 3 is an early draft. Use APCA as a second opinion; 1.4.3 is still the normative requirement.

How many accessibility heuristics should a review use?

Few enough to hold in your head. Seven to ten is the working range, for the same reason Nielsen stopped at ten: past that, reviewers stop carrying the list and start skimming it. If you need finer detail, add it underneath a heuristic as a checklist item.

Can one person run an accessibility heuristic review?

Yes, and a single reviewer will still find most of the blocking barriers. The same evaluator effect applies here as in usability review: different people notice different things. Two or three independent passes, reconciled afterwards, return more for not much more time.

What should we fix first?

Anything that makes a task impossible: keyboard traps, unreachable controls, unlabelled inputs in a flow someone has to complete, errors that are never announced. Contrast and alt text matter, but they rarely stop a purchase, and ordering by severity keeps a remediation backlog from becoming busywork.

Where this fits

More on this cluster in the accessibility topic hub. These heuristics all ask one question: can a user tell what a control does, what state it is in, what just happened. That question is the UX Clarity framework, which is what a Full UX Audit scores against.

Sources: WebAIM Million · W3C — How to Meet WCAG 2.2 (Quick Reference) · W3C — Understanding Non-text Contrast · NN/g — 10 Usability Heuristics.

Want a second pass over the flows your scanner reports as clean? Apply for a Full UX Audit →