The short answer
The most common accessibility issues, like low contrast text and missing alt text, are easy for automated scans to find. The issues that stop people with disabilities from finishing a task are a different group: dead ends between screens, screen readers that behave differently than the code expects, barriers for cognitive users, and AI answers a screen reader can't follow. Those issues only show up when people with disabilities use the product, which makes accessibility research the only way for your team to find them before your customers do.
Most product teams track accessibility with automated scans, audit reports, and compliance scores. When those all come back clean, it's reasonable for leadership to believe the product works for people with disabilities.
In our researchers' experience, that belief is where the risk sits. The teams most confident that accessibility is handled are often the ones shipping barriers they can't see, because the checks they trust were never built to find them. Your dashboard stays green while a blind user, a person with a motor disability, or a user with dyslexia can't finish the task your business depends on.
This post is for UX research leaders who need to know what those hidden issues are and how to find them. We'll start with the common issues scans already catch, explain why a whole group of issues stays invisible to them, then walk through eight blind spots our researchers find in sessions with people with disabilities, along with what each one costs your company.
Automated scans are good at finding issues where the code breaks a clear rule. Every year, WebAIM scans the home pages of the top one million websites, and its 2026 WebAIM Million report found detectable failures of the Web Content Accessibility Guidelines (WCAG) on 95.9% of them. These were the most common:
The most common accessibility issues on the top one million home pages (WebAIM Million, 2026)
| Issue | Share of home pages | What it means for users |
|---|---|---|
| Low contrast text | 83.9% | Text is too faint for people with low vision to read |
| Images without alternative text | 53.1% | Screen reader users don't know what the image shows |
| Form fields without labels | 51% | Screen reader users don't know what to type into a field |
| Empty links | 46.3% | A link is announced with no name, so users can't tell where it goes |
| Empty buttons | 30.6% | A button is announced with no name, so users can't tell what it does |
| Missing page language | 13.5% | Screen readers may read the page with the wrong pronunciation |
These issues are worth fixing, and they're the cheapest ones to catch: a scan finds them in seconds, and the engineer who wrote the code can fix them the same day. If your team doesn't run scans on every release yet, that's the first thing to put in place.
The limit is what a scan can't see. WebAIM's own report warns that a page with no detected errors isn't necessarily accessible, and Deque, a company that sells automated accessibility testing tools, found that automated tests caught about 57% of the issues across more than 13,000 pages it audited. The issues in the rest of this post sit in the part a scan never reaches.
A scan or an audit looks at the product one piece at a time: one screen, one button, or one form field, checked against a list of rules. People with disabilities use the product as a sequence of steps, with their own assistive technology, on their own device, and with their own body and mind.
Many accessibility problems only appear in that sequence, so a check that looks at the pieces one by one can pass every piece while the task still fails.
One of our researchers calls this confusing component compliance with a usable journey. Every button, menu, and form field in a sign-up flow can pass on its own, and the team still has no evidence that a blind user can get from the first screen to the last.
What a check looks at, compared with what a person goes through
| What a scan or audit checks | What a person with a disability goes through | |
|---|---|---|
| Scope | One screen or one element at a time | A full task, from start to finish |
| Timing | A finished page, frozen in one state | A product that changes as they use it, including AI answers that stream in |
| Tools | The code, read against a set of rules | Their own screen reader, magnifier, switch device, or voice control, set up their own way |
| Mistakes | Doesn't make any | Taps the wrong thing, needs to undo it, and keeps going |
| Context | No device, no body, no fatigue | A specific phone, watch, or laptop, a specific disability, and a limited amount of energy |
Our researchers see what this means all the time. In one study, an experience had already passed its earlier accessibility checks. When screen reader users tested it, every one of them hit errors that stopped the task: they got stuck inside a dropdown, moved behind a pop-up window they couldn't see, and sat through long, unnecessary announcements on every button.
None of those problems had shown up in the checks, because each one only happens while a person is moving through the flow.
Our researchers run into these eight blind spots again and again, on mobile apps, websites, AI products, wearables, and enterprise software. Each one shows up in products where the team was already doing accessibility work and believed the product was in good shape. For each one, you'll see what the issue is, why scanners and audits don't catch it, what watching people with disabilities use the product reveals, and what it costs the company building it.
A dead end is a point in a task where a user takes an action and then has no way to undo it or move forward. Dead ends usually hide in the moment between two states of a screen, when something gets hidden, removed, collapsed, or replaced.
Automated scanners and audits check each state on its own: the screen before the action passes, and the screen after it passes too. What they don't check is whether a person using a screen reader or a keyboard can get from one state to the other and back again.
That's why dead ends only show up when you watch people with disabilities work through a full task, including the ordinary mistakes everyone makes, like tapping the wrong option and needing to reverse it.
For a blind user, a hidden control with no way to bring it back can mean deleting their work and starting over. For your company, it means a core task fails while every report says it passes, and you rarely hear about it, because users who hit a dead end leave instead of filing a bug.
Screen readers do much more than read the code out loud. They have modes, shortcuts, audio cues, and settings each user configures their own way, and the same page can behave very differently depending on the screen reader, the browser, and the device.
A common example is a screen reader that switches from reading mode into typing mode as the user moves past a text field, which traps their keyboard inside the field and turns off the shortcuts they use to move around the page. Others include audio that cuts off mid-sentence, focus that jumps somewhere unexpected, and buttons that announce so much extra detail that users are worn out halfway through a task.
Scanners read the code against a set of rules, and the code behind each of these problems passes. The problem only exists when a real screen reader runs on a real device, so the only way to see it is to watch a screen reader user complete the task with their own setup.
For your company, these issues show up as drop-off your usage data can't explain.
Barriers for people with dyslexia, ADHD, and other cognitive and neurodivergent conditions usually don't break any rule a scanner checks. A page can be technically perfect while the most important button doesn't stand out to a reader with dyslexia, or a form asks a user with ADHD to keep too much in mind at once.
Screen reader and magnification problems are tangible, because you can point to the element that failed. Cognitive barriers are harder to pin down, which is why no scan or AI tool flags them.
We find them by watching participants work through a task and asking what made each step hard, because their experience is the only evidence these barriers leave behind.
For your company, the cost hides in plain sight: many of these users never mention a disability, so their struggle shows up as abandoned forms, support calls, and lower conversion that the team blames on the design without knowing who it's failing.
More and more of what users see changes while they're using it: AI answers that stream in word by word, live updates, notifications, and menus that reorder their options from one visit to the next. Scanners analyze a page at one moment, usually once it has finished loading, so they never see what happens while the content is changing.
A screen reader user does. With a streaming AI answer, every new word counts as an update, so the screen reader keeps interrupting itself and reading the answer again from the top, and if the user mutes the updates, they can't tell when the AI has finished.
We see these issues by watching people use the feature in real time with their own assistive technology.
For your company, the risk is highest in AI features, where many teams are placing their biggest bets. If screen reader users can't follow the answers, the feature fails a whole group of customers on day one, and as we cover in the six factors that decide if people keep using your AI product, users burned by one AI feature are slower to try the next one.
Most accessibility checks are built around a screen that sits still in front of the user. Real products run on phones, watches, headsets, and other hardware, where the device, the platform, and the user's body all change what's accessible.
A watch interaction might assume the user can hold one wrist steady and reach across with the other hand, which turns a simple tap into a barrier for someone with cerebral palsy or someone who drives a motorized wheelchair with one hand.
On phones, patterns that work on desktop break down: navigation bars fill most of the screen at 800% magnification, text scrolls one character at a time under the iPhone's Zoom feature, and the numbered labels Voice Control places on buttons stack on top of each other.
None of this shows up in a scan of the code, because the problem sits in how a person and a device fit together. We see it by testing on each device and platform with the people who'll use it.
For your company, every new platform brings its own barriers, and on hardware they cost far more to fix after launch, which is why we scope studies by platform for wearables and other physical products.
“The moment it changes to something wearable, like a headset or a watch, the user's body becomes part of the interface too.”
One of Akraya's accessibility researchers, on why screen-based testing can't stand in for testing on the device
Teams often leave accessibility out of design and sprint planning because their design system is labeled accessible. A design system tests its components one at a time, and each product team then combines and configures those components its own way.
Contrast, labels, and the order keyboard focus moves through a screen can all break in that step, especially with prebuilt pieces like dashboard widgets that teams assume stay accessible however they're set up. Older design systems add another layer, because every feature built on them inherits their gaps.
Scanners check whether each component meets the rules, and they don't check whether the finished screen works for someone using a keyboard or a screen reader to finish a task. Watching people with disabilities use the configured product is what shows where the pieces stopped fitting together.
For your company, one wrong assumption repeats in every product built on that system, and it pushes accessibility to the end of the schedule, which is the most expensive place to find it, as we explain in why accessibility can’t be a final-stage checkbox.
More engineers now ask AI tools how to make a feature accessible and ship the code they suggest. The AI solves the specific problem it was asked about, and it has no way to test the result with the people who'll use the product, so its fixes often work for one group and fail another.
A common pattern is a fix that works for screen reader users and still blocks people with motor or cognitive disabilities. Another is new code that adds a problem of its own, like a second main section on the page that confuses screen readers trying to navigate it.
This code usually looks correct and passes a scan, because it follows the rules it was written to follow. Only people using assistive technology show whether the fix improved their experience or created a new barrier, and our researchers have seen this pattern grow over the past year.
For your company, AI helps your team ship faster, and without checks by people with disabilities, it also helps barriers ship faster, while your reports show more accessibility fixes than ever.
Accessibility risk also comes in through the tools, platforms, and third-party components your company buys. Vendors describe their products as accessible based on their own checks, and those claims often stand in for testing the real workflow with the people who'll use it.
We've seen how costly that gets firsthand. When our own panel team moved participants onto a research platform described as accessible, participants across the panel couldn't complete basic steps in the first study, and fixing it took an eight-month audit.
We see the same pattern with third-party widgets and components inside the products we test. A vendor's documentation can help you decide what to buy, and only people with disabilities using the real workflow can show whether it works.
For your company, one session before the contract is signed or the migration starts costs far less than an audit after it.
These eight patterns look different, but they have one thing in common: the checks said the product was fine, and real people still couldn't finish the task. A research function can be set up to find them on purpose, and the next sections cover how.
Every issue above appeared because the right person was in the session, with the right assistive technology, on the right device. That makes recruiting the decision that matters most in accessibility research, and it's where most studies go wrong. Four decisions shape what a study can find.
Cover all five main disability groups
Plan for blind, low vision, motor and dexterity, Deaf and hard of hearing, and cognitive and neurodivergent users. The blind spots above spread across all five, and a study that only includes screen reader users will miss most of them.
Break each group down further
Asking to test with users who have vision disabilities covers blind, low vision, and colorblind users, and each of those needs different assistive technology. Our researchers dedicate time to each subgroup instead of letting one participant stand in for all of them.
Test each platform on its own
Mobile and desktop assistive technology work differently, from touch targets and swipe navigation to focus order. In our researchers' experience, one study rarely represents both well, so scope by platform.
Plan the session setup with the participant
Participants need their assistive technology configured their way, and some Deaf participants need a sign language interpreter, who also needs to be scheduled and paid. Sessions that skip this preparation lose time to setup and can fail before the first task.
Your researchers run the studies. Your job is to set up a research function that finds these blind spots before launch, release after release, and reports them in a way leadership acts on. In our experience, that comes down to six defaults.
01
Treat scan results as the minimum
Keep automated scans running on every release so rule violations get fixed by the engineer who wrote the code. Report them to leadership as the baseline they are, so a clean scan never stands in for evidence that people with disabilities can use the product.
02
Test complete tasks, including mistakes
Build studies around the tasks your business depends on, such as sign-up, checkout, sharing, or account recovery. Include the moments where users make a mistake and need to undo it, since that's where dead ends hide.
03
Recruit by disability, assistive technology, and platform
Write recruiting criteria at the level of detail above, and include newer assistive technology users alongside experienced ones. Experienced users work around problems that stop newer users completely.
04
Add a check for AI features and AI-generated code
Flag AI features with streaming or changing content, and code written or fixed with AI tools, for testing with assistive technology before release.
05
Re-test every fix with assistive technology
A bug marked as fixed isn't fixed until someone confirms it with a screen reader or other assistive technology. Ask the team to show the fix working the same way the participant used it.
06
Prioritize and report in business terms
Rate each issue by how severe it is, how many users it affects, and how much effort it takes to fix. Treat anything that stops a user from finishing a task as a blocker that has to be fixed, and report task health by user group to leadership over time.
The fastest way to start finding these blind spots uses research your team already runs. Every quarter, your team runs usability studies, concept tests, and prototype reviews. If you recruit people with a range of disabilities into those same studies, alongside your other participants, the issues in this post start showing up in research you've already planned and paid for.
To make that work, ask for three things in every recruit: participants across the five main disability groups, the specific assistive technology your product needs to support, and a mix of experienced and newer assistive technology users. Plan for their setup too, like screen readers configured their own way and sign language interpreters for some Deaf participants.
Finding those participants quickly is the part most teams can't do on their own, and it's where Akraya helps. Our accessibility panels cover 14 disability categories, our sessions support 27 kinds of assistive technology and support, and we can typically have participants in your study within one to two weeks. Your team keeps running the research it already has planned, and we make sure the right people with disabilities are in it.
Most research teams can design and synthesize an accessibility study. The hard part is everything around it: recruiting the right people with disabilities quickly, running sessions with their own assistive technology on the right devices, and turning what happens into fixes engineering can act on. That's the work Akraya takes off your team's plate.
Akraya has run accessibility research panels for five years and supported more than 200 accessibility studies. Our panels recruit across 14 disability categories, covering all five main groups, and our sessions support 27 kinds of assistive technology and support, from screen readers, magnifiers, and braille displays to switch access, voice control, and sign language interpreters.
We screen participants by the tools they use every day, so the person in the session matches the user you're building for.
We typically have a study in field within one to two weeks of a request. A rapid UX research study delivers findings in 2 to 3 weeks, which fits between design and build, when fixes cost the least. If you want accessibility tracked release after release, an embedded researcher works inside your team under our UX research as a service model, re-testing products and adding new user groups over time.
Every issue we find comes with an annotated screen and audio recording of the session, exact steps to reproduce it, a plain-language explanation of the impact written for engineers with no accessibility training and a concrete recommendation for the design or the code.
We prioritize each issue by severity, how many users it affects, and the effort to fix it, so your team knows what blocks a launch and what can wait. When the fix is in, we re-test it with assistive technology.
Our PhD-level researchers are vetted against a big tech hiring bar and run usability studies, user evaluations, and expert walkthroughs across all five disability groups. We work with Fortune 500 teams building software, AI products, and wearables, which is why we know where accessibility breaks on screens, in AI conversations, and on the body.
Go deeper
Our white paper, Green dashboard, blocked user: where accessibility checks fall short, covers more of these examples in full, why passing checks create false confidence, and the questions to ask before your next launch review.
New to testing with people with disabilities? Start with what accessibility UX research is and how it fits next to your accessibility audits.
Find the accessibility issues your dashboard can't show you
Tell us what you're building and which tasks matter most. We'll scope a study with the right people with disabilities, on the right devices, and have it in field within one to two weeks.
Request accessibility researchThe most common issues on websites are low contrast text, images without alternative text, form fields without labels, empty links, empty buttons, and pages that don't declare their language. The 2026 WebAIM Million found low contrast text on 83.9% of the top one million home pages. Automated scans catch these well. The issues that block people from finishing tasks, such as dead ends between screens or screen reader behavior, need testing with people with disabilities.
Automated testing checks one screen or one element at a time against a set of rules. It can't catch problems that only appear while a person completes a task: dead ends between screens, screen readers switching modes on their own, content that changes while someone reads it, barriers for cognitive and neurodivergent users, and problems tied to a specific device, platform, or body. Those need research with people with disabilities.
No. Overlays and widgets help with technical compliance, but they can't show you how a person with a disability experiences the product. In our researchers' experience, a scan or widget sets the minimum. It doesn't tell you if people can complete the tasks your business depends on.
Plan for five main groups: blind, low vision, motor and dexterity, Deaf and hard of hearing, and cognitive and neurodivergent users. Each group breaks down further. Vision alone covers blind, low vision, and colorblind users, and each of those uses different assistive technology. Recruit by the specific disability and assistive technology your product needs to support, and test mobile and desktop separately.
Start with an automated scan on every release and a walkthrough of your key tasks by one accessibility expert. Together they catch rule violations and obvious journey problems. They can't show you how people with disabilities experience the product, so use what they find to justify one study on the task your business depends on most.