How do you test whether a design is actually accessible vs technically compliant?

Published Read 3 min read

On this page

You test for real accessibility by putting the interface through a keyboard, a screen reader, and ideally people who actually rely on assistive technology, because an automated checker proves only that the machine-detectable rules pass, not that a human can complete the task. A green audit score is the floor of testing, not the finish line. The two questions are genuinely different: “does this meet the success criteria a tool can measure” and “can a person who cannot see the screen or use a mouse actually book the appointment.” The first is a checkbox. The second is the point.

The reason automated checks fall short is that most of what makes an interface usable lives outside what a scanner can evaluate. Tools are excellent at the mechanical, deterministic faults: a missing alt attribute, a contrast ratio below threshold, a form field with no programmatic label. But by most accounts they catch only a fraction of real accessibility problems, with figures commonly cited around a third of issues and the rest requiring human judgment. Treat any single number as a working guide rather than a guarantee, because it depends heavily on how you count. The reliable takeaway is the shape of the gap, not the exact percentage: a clean scan tells you what no longer fails automatically, and says almost nothing about whether the experience holds together.

Consider a checkout button that a scanner happily passes. It has a visible label, sufficient contrast, and a valid role, so every automated rule is green. Then you tab to it with the keyboard and discover the focus outline was styled away, so a sighted keyboard user cannot tell where they are. You turn on a screen reader and the button announces “button” with no name because the accessible name comes from an icon the tool counted as decorative. You try to reach it after an error and focus never moves to the message, so a blind user has no idea the form rejected them. None of that registers as a violation, yet the task is impossible. Technically compliant, actually broken.

The exception worth naming is that manual testing is not a license to skip the automated pass, and real-user testing is not a stamp you can claim from one session. The checker still does valuable, fast work catching the regressions humans miss, so run it as the first gate, not the only one. And testing with one person who uses a screen reader tells you about that person’s path on that day, not about every disability, input method, or assistive setup, so treat it as evidence rather than proof. The strongest signal comes from layering: automated scan, then a keyboard-only walkthrough, then a screen-reader pass, then observation of people with disabilities doing the actual job.

So before you call a design accessible because the audit came back clean, unplug the mouse and try to finish the core task with the keyboard alone, then do it again with a screen reader running. Where you get stuck or lost, real users will too, and that is the work the scanner never did. Book time with people who depend on assistive technology and watch them use it, because their lived experience surfaces what no checklist anticipates. Use the automated pass as your floor and let keyboard, screen reader, and real people decide whether you have actually built something usable.

Related posts:

  1. How do you redesign without breaking what users already know? You redesign without breaking what users know by protecting their existing mental models: preserve the patterns and locations they rely on, change the surface more than the structure wherever you......
  2. Tabs or an accordion, when does each suit the content? Tabs suit a few parallel sections that a user views one at a time, where switching is quick and the sections are peers; an accordion suits a longer list of......
  3. How do you pick a primary color that works for both small buttons and large fills? Pick a base color that holds up as a small saturated accent, then define lighter or desaturated variants for large areas, because one fixed value cannot serve both demands. A......
  4. When does versioning a component help vs create confusion? Versioning a component helps when a change is significant enough that consumers need time to migrate, and keeping the old version stable for a while protects them from a forced,......
  5. How do you audit an existing design before redesigning it? A useful audit assesses the current design against user needs, goals, and performance, cataloguing what works, what fails, and why, across usability, consistency, accessibility, and outcomes, so that the redesign......
  6. Should the logo always link home, and does anyone still expect that? Yes, link the logo home by default, and yes, people still expect it. This is one of the few web conventions that has held firm long enough to become a......
  7. When does color alone fail to communicate, and what has to back it up? Color alone fails the moment meaning rests on it, so the rule is simple: any state, link, category, or status signaled by color must be reinforced with a second cue,......
  8. Should you group nav items by what they are or by what the user wants to do? Group navigation by what users want to do, not by what your internal categories call things, because people navigate toward goals rather than around an org chart. Task-led grouping should......
  9. How do you make a custom component keyboard-navigable from scratch? A custom component becomes keyboard-navigable when it satisfies four conditions at once: it is reachable in the tab order, operable with the keys users expect, it exposes its role and......
  10. Why does a “clever” navigation pattern usually cost more than it gains? A clever navigation pattern usually costs more than it gains because navigation runs on learned conventions, so anything unconventional forces users to spend attention learning the mechanism before they can......
  11. Should a CTA repeat down the page, or does once do it? On a long page the CTA should repeat, and on a short page one well-placed CTA is enough; the answer follows page length and where conviction builds, not a fixed......
  12. At what point does a strong hero flatten everything below it? A hero flattens the page the moment the section directly below it stops earning attention on its own. That is the line, and it is a behavioral test, not a......
  13. Should navigation be sticky, or does that depend on page length? The call turns on page length and how often users need to re-navigate, and it resolves cleanly: make the nav sticky on long, multi-section pages and let it scroll away......

Leave a comment

Your email address will not be published. Required fields are marked *