Accessibility heuristics are a set of broad principles that evaluators use to review an interface for accessibility problems. Instead of checking every rule in a formal WCAG checklist (which has 78+ success criteria across three conformance levels), a heuristic evaluation applies general principles to identify the most common and impactful barriers. It's faster, cheaper, and catches a lot of issues that automated scanners miss.
The concept comes from Jakob Nielsen's 10 usability heuristics, which have been a standard UX evaluation method since the 1990s. Accessibility researchers adapted and extended that framework specifically for evaluating how well an interface works for people with disabilities, including visual, motor, cognitive, and auditory impairments. The result is a set of 10 accessibility heuristics that cover everything from screen reader compatibility to cognitive load.
How accessibility heuristics differ from WCAG compliance
WCAG (Web Content Accessibility Guidelines) is a formal specification. It tells you exactly what to do: "Color is not used as the only visual means of conveying information" (1.4.1), "All non-text content has a text alternative" (1.1.1). Each criterion has a pass/fail test. A WCAG audit checks your interface against every applicable criterion and documents what passes and what doesn't.
A heuristic evaluation is different. It's an expert review where 3-5 evaluators walk through the interface and flag problems based on broad principles. There's no pass/fail score. The output is a list of issues ranked by severity. It's faster than a WCAG audit (hours vs days), and it catches design-level problems that WCAG criteria don't directly address, like confusing navigation patterns or inconsistent interaction models that work technically but confuse users in practice.
Most teams use both. Heuristic evaluations early in the design process to catch structural problems. WCAG audits later to verify formal compliance. And automated scans (with tools like axe or Lighthouse) on every deploy to catch regressions.
The 10 accessibility heuristics
1. Equitable use
The interface should be usable by people with diverse abilities without requiring a separate "accessible version." One design, one experience. If sighted users can browse a product catalog with images and filters, screen reader users should be able to do the same thing using the same interface, not a stripped-down text-only page.
A common failure: an image carousel that's navigable by swipe but has no keyboard or screen reader controls. Sighted users scroll through products. Screen reader users hit a dead end.
2. Flexibility in use
The interface should accommodate different interaction methods. Some users navigate with a mouse. Some use a keyboard only. Some use voice control, switch devices, or eye-tracking systems. The interface should work with all of them without requiring a specific input method.
A common failure: a drag-and-drop interface for reordering items that has no keyboard alternative. A user who can't use a mouse has no way to complete the task.
3. Simple and intuitive design
The interface should be understandable regardless of the user's experience, knowledge, language skills, or current concentration level. Labels should be clear. Icons should have text labels. Navigation should be predictable. The user shouldn't need to remember information from a previous screen to complete a task on the current one.
A common failure: a multi-step form that uses icons without text labels for navigation (a checkmark for "save," a circle-arrow for "undo," a gear for "settings"). A user with a cognitive disability, or simply an unfamiliar user, doesn't know what each icon does.
4. Perceptible information
The interface should communicate information effectively regardless of the user's sensory abilities. This means every piece of information should be available through at least two sensory channels. Visual information should have a text equivalent. Audio cues should have a visual indicator. Color-coded status (red for error, green for success) should also use text labels or icons.
A common failure: a form validation error indicated only by a red border around the input field. A colorblind user doesn't see the red. A screen reader user doesn't know the field has an error because there's no text message or ARIA attribute to announce it.
5. Tolerance for error
The interface should minimize the impact of accidental or unintended actions. This means undo functionality, confirmation prompts for destructive actions, clear error messages that explain what went wrong and how to fix it, and input validation that catches mistakes before submission.
A common failure: a "Delete Account" button with no confirmation dialog. A user with a motor impairment who accidentally taps the wrong button loses their account with no recovery path.
6. Low physical effort
The interface should be usable with minimal physical exertion. Touch targets should be large enough to tap accurately (at least 44x44 CSS pixels per WCAG). Interactions shouldn't require precise gestures, sustained physical effort, or rapid repeated actions. Scrolling should be the primary navigation method, not multi-finger gestures or long-press actions.
A common failure: a mobile app where the primary action button is 24x24 pixels. A user with limited fine motor control can't reliably tap it. They hit the wrong element, trigger unintended actions, and get frustrated.
7. Low cognitive effort
The interface should minimize the amount of thinking required. Don't make users memorize codes, decode abbreviations, or calculate values in their head. Use plain language. Break complex tasks into steps. Show progress indicators. Avoid time limits that create pressure (or provide a way to extend them).
A common failure: a checkout flow that shows a 60-second timer during payment processing with no explanation. A user with an anxiety disorder panics. A user with a cognitive disability doesn't understand what the timer means and abandons the purchase.
8. Navigation and wayfinding
The interface should make it easy to find content, understand where you are, and get back to where you were. This means consistent navigation across pages, clear heading hierarchy, breadcrumbs for deep page structures, visible focus indicators for keyboard users, and skip-navigation links that let screen reader users jump past repeated content.
A common failure: a mobile app with a hamburger menu, a bottom tab bar, and a floating action button that all lead to different navigation trees. The user can't build a mental model of the app's structure. Screen reader users have to navigate through all three to find what they need.
9. Compatibility with assistive technology
The interface should work correctly with screen readers (VoiceOver, TalkBack, NVDA), switch controls, voice recognition software, and screen magnifiers. This means proper semantic HTML (or native UI elements on mobile), correct ARIA roles and labels, logical focus order, and announced state changes.
A common failure: a custom dropdown component built with <div> elements instead of a native <select>. It looks like a dropdown to sighted users, but a screen reader announces it as "group" or "clickable" with no indication that it's a selection control. The user doesn't know they can expand it, navigate options, or make a selection.
10. Clear documentation and help
When the interface can't be fully self-explanatory (complex forms, technical tools, multi-step workflows), accessible help should be available. Help content should be findable, written in plain language, and compatible with assistive technology. Error messages should explain the problem and suggest a fix, not just say "invalid input."
A common failure: a help section that's only available as a PDF. The PDF isn't tagged for screen readers. A user who needs help the most (someone unfamiliar with the interface or using assistive technology) can't access the help content.
How to run an accessibility heuristic evaluation
A heuristic evaluation works best with 3-5 independent evaluators. Each one reviews the interface against the 10 heuristics, documents every issue they find, and rates each issue's severity on a 0-4 scale:
- 0 = not an accessibility problem
- 1 = cosmetic only, fix if there's time
- 2 = minor problem, low priority
- 3 = major problem, should be fixed before launch
- 4 = catastrophic, blocks users from completing a task
After all evaluators finish independently, they combine their findings. Duplicates get merged. Each issue gets a final severity rating based on consensus. The output is a prioritized list of accessibility problems with severity scores, which your team can feed directly into a sprint backlog.
The independent part matters. If evaluators discuss findings during the review, they anchor to each other's observations and miss issues they would have caught alone. Nielsen's research showed that 5 independent evaluators catch roughly 75% of usability problems. The same principle applies to accessibility heuristics.
One evaluation session typically takes 1-2 hours per evaluator for a moderately complex interface. Compare that to a full WCAG 2.2 audit, which can take days. Heuristic evaluations don't replace WCAG audits, but they catch the high-impact issues early and cheaply.
Heuristics catch design issues. Real devices catch platform issues.
Heuristic evaluations are expert reviews done on a screen. They'll catch problems like missing alt text, poor color contrast, confusing navigation, and small touch targets. What they won't catch is how the interface actually behaves on a specific device, OS version, and screen reader combination.
VoiceOver on iOS 17 handles custom components differently than TalkBack on Android 14. A focus trap that works fine on Chrome desktop can break the entire flow on Safari mobile. A touch target that passes the 44px rule in your design tool might render smaller on a device with unusual display scaling.
These are platform-specific accessibility failures, and they only surface when you test on real devices. Tools like Drizz let you run automated tests on real Android and iOS devices using plain English test steps and Vision AI. You can verify that your app's accessibility fixes actually work on the devices your users have, not just on the laptop your evaluator used. The heuristic evaluation tells you what to fix. Testing on real devices tells you if you fixed it correctly.
FAQ
What are accessibility heuristics?
Accessibility heuristics are a set of broad principles used to evaluate an interface for accessibility barriers. They're adapted from Nielsen's 10 usability heuristics and extended to cover disabilities including visual, motor, cognitive, and auditory impairments. Evaluators walk through the interface and flag issues based on these principles, then rate each issue by severity.
What's the difference between a heuristic evaluation and a WCAG audit?
A heuristic evaluation is a quick expert review against broad principles. It takes hours, catches design-level problems, and produces a severity-ranked list of issues. A WCAG audit is a formal compliance check against specific success criteria (78+ in WCAG 2.2). It takes days, produces a detailed conformance report, and is required for legal compliance in many jurisdictions.
How many evaluators do you need for a heuristic evaluation?
Nielsen's research recommends 3-5 independent evaluators. Each evaluator reviews the interface alone, then findings are merged. Five evaluators catch roughly 75% of accessibility problems. Using fewer than 3 risks missing too many issues. Using more than 5 has diminishing returns.
Can heuristic evaluations replace automated accessibility scans?
No. They serve different purposes. Automated scans (axe, Lighthouse) catch programmatic issues like missing alt text, incorrect ARIA roles, and insufficient color contrast. Heuristic evaluations catch design-level issues like confusing navigation patterns, cognitive overload, and interaction models that work technically but confuse users. Use both.
Are accessibility heuristics the same as usability heuristics?
They're related but not the same. Usability heuristics (Nielsen's original 10) evaluate general ease of use. Accessibility heuristics extend those principles to specifically address barriers faced by people with disabilities. For example, "perceptible information" in an accessibility context means ensuring information is available through multiple sensory channels (visual + text + audio), not just that it's easy to see.
When should I run a heuristic evaluation?
Early in the design process, ideally during prototyping or before development starts. Heuristic evaluations are cheap and fast enough to run on wireframes or high-fidelity mockups. Catching a confusing navigation structure in a prototype costs 10 minutes of design time. Catching it after development costs a sprint.
