The short answer
Accessibility UX research is UX research with people with disabilities, using their own assistive technology, to find out if they can complete your product's key tasks. For a UX research leader, it's your existing practice extended to more of your users. Your job is to make it a default part of how your team plans, recruits, runs and reports research, so accessibility decisions get made with evidence from real users.
Accessibility compliance tells you if your product follows the accessibility rules. It can't tell you if a person with a disability can actually sign up, check out or finish any other task in your product. Accessibility UX research answers that second question, and it's the part of accessibility a UX research team owns.
The audience is large. One in six people worldwide lives with a significant disability, according to the World Health Organization. Yet most enterprise product teams check their product for those users with automated scans and an audit against the Web Content Accessibility Guidelines (WCAG), and nothing else.
This post explains what accessibility UX research is, what it finds that compliance checks can't, and what a UX research leader needs to put in place so the team can answer accessibility questions with evidence.
Accessibility compliance vs. accessibility UX research at a glance
| Accessibility compliance | Accessibility UX research | |
|---|---|---|
| The question it answers | Does the product follow a standard like WCAG? | Can people with disabilities complete your product's key tasks? |
| How it's done | Automated scans, audits and expert reviews against a checklist | Studies with participants who use their own assistive technology |
| What it catches | Missing labels, low color contrast, missing image descriptions and other rule violations | Dead ends, exhausting navigation and tasks people can't finish with their own assistive technology |
| Who owns it | Accessibility specialists and engineering | UX research, working with accessibility specialists |
| What leadership gets | A conformance score or audit report | Task success by user group, prioritized issues and fixes engineering can act on |
Watch the 1-minute version
What accessibility UX research is, and why compliance isn't enough
Below, we cover what accessibility UX research is, the gaps compliance leaves and what your research function needs to own.
Accessibility UX research is UX research with participants who have disabilities. You may also hear it called accessibility user testing or accessibility usability testing. Participants use the product with the assistive technology they rely on every day, such as a screen reader, screen magnification, voice control, switch access or captions, and researchers observe where the product works for them and where it stops them.
For your team, this is familiar work. You use the same methods you already run: interviews, prototype tests, task-based usability studies and longitudinal studies. Only three things change: who you recruit, how you set up the sessions and how you write up what you find.
The benefit also reaches beyond people with permanent disabilities. Microsoft's inclusive design guidance points out that people can be limited permanently, temporarily or by their situation. A person with one arm, a person with a broken arm and a parent holding a baby all struggle with a task that needs two hands. Fix it for the first person, and it works for the other two as well.
Even the W3C, the organization that writes the WCAG rules, says passing those rules isn't enough on its own:
“Evaluating with users with disabilities and with older users identifies usability issues that are not discovered by conformance evaluation alone…”
W3C Web Accessibility Initiative, Involving Users in Evaluating Web Accessibility
In plain terms: following the rules doesn't guarantee people can use your product. The only way to find out is to watch them try, and that's the job of your research team.
Here's the core problem. A compliance check reviews your product one screen or one button at a time. People use your product to finish tasks, like signing up, checking out or sharing a file. A product can pass the check on every single screen and still stop a person halfway through a task.
Automated checks also miss a large share of issues. Deque, a company that sells automated accessibility testing tools, analyzed more than 13,000 audited pages and found that automated tests caught about 57% of the issues. The other 43% needed a person to find them.
Here are two examples our researchers see often. In both, every screen passed its checks, and the participant still couldn't finish the task.
A dead end a scan can't see
A blind participant using a screen reader hid a contact's name while sharing content in a mobile app. Once the name was hidden, the app gave no way to undo it. Every screen passed its checks, but the participant had to delete the contact and start the whole task over.
A keyboard path that passes but wears people out
The keyboard rule only checks that every control can be reached. It doesn't check how many key presses that takes. When an important button sits dozens of presses away, the product passes and the person gives up.
No scan or audit flags either problem, because each screen follows the rules on its own. Your research team finds them by watching people try the task, which is why accessibility research belongs to UX research.
White paper
Green Dashboard, Blocked User: Where Accessibility Checks Fall Short
See more sessions where products passed their accessibility checks and still blocked people with disabilities, and what product teams did after watching them.
Read the white paperWhen accessibility research is a normal part of your team's work, your research function gets four things it can't get from compliance reports.
Product, engineering and legal all ask your team accessibility questions. Research gives them answers backed by what real users did: which tasks work, which ones fail, for which user groups and what to fix first.
If your team tests prototypes with people with disabilities, problems get fixed while the design is still easy to change, and product starts bringing research into planning. If accessibility only gets checked right before launch, the same problems turn into rebuilt components and delayed releases. We cover that cost in why accessibility can’t be a final-stage checkbox.
Enterprise customers expect the products they buy to be accessible, and many write it into their buying requirements. Since 28 June 2025, the European Accessibility Act applies to any organization offering services to EU consumers. Those customers and regulators want proof that people with disabilities can use the product. Research gives you that proof, because it shows real people completing the tasks.
Each study produces numbers leaders can follow over time: task success by user group, a healthy, at risk or unhealthy rating for every key task, and how quickly accessibility bugs get fixed. In our experience, once accessibility shows up as a leadership metric, product teams start asking research for it earlier.
Your researchers run the studies. Your job is the system around them, so every study is set up, run and reported in a way stakeholders trust. You don't need to be an assistive technology expert to own that. It comes down to six defaults.
01
Accessibility in every research brief
Each brief names the user groups affected, the tasks in scope and the assistive technology the study covers. If a brief leaves accessibility out, that's a decision someone made on purpose.
02
Recruiting by need and technology
Screeners ask about the tasks people do, the assistive technology they use and the devices they use it on. Medical diagnoses don't predict how someone uses your product, so they stay out of the screener. Broad labels get split into real groups: "users with vision disabilities" includes people who are colorblind, people with low vision who zoom in and people who are blind and use a screen reader.
03
Sessions that are accessible themselves
Participants use their own devices, settings and assistive technology. Consent forms and instructions are accessible, sessions get extra time for setup, and the budget covers needs like sign language interpreters. An inaccessible session excludes the people you're trying to learn from.
04
Findings written for decisions
Every finding names the task, the barrier, the impact on the user, how many participants hit it, the recommended fix and an owner. That format keeps accessibility findings from being dismissed as one person's anecdote.
05
One study is never a certificate
A single pre-launch study doesn't prove a product is accessible. Research runs across the product cycle, and fixes get re-tested with the same tasks after they ship.
06
Progress reported as impact
Report task success, issues fixed and re-test results to leadership, alongside the number of studies run. Leaders fund what they can see moving.
What a decision-ready finding looks like
Task: Creating an account on desktop with a screen reader.
Barrier: The error message for an invalid email isn't connected to the email field, so the screen reader never announces it.
Impact: Participants couldn't tell which field to fix and abandoned sign-up.
Evidence: 3 of 4 screen reader participants hit the same issue.
Fix and owner: Connect the error to its field and announce it when it appears. Priority 1, owned by design and engineering, re-tested in the next round.
The example above is made up, but the format is the one that gets fixes prioritized. A product manager can read it once and know what broke, who it hurt and what to do next.
Accessibility research belongs at every stage of the product cycle, and each stage answers a different question. The table below shows which question and which methods fit. For what it costs when research only happens at the end, read why accessibility can’t be a final-stage checkbox.
| Stage | The question your team answers | Typical methods |
|---|---|---|
| Discovery | Who does the product exclude today, and what workarounds do they use? | Interviews, contextual inquiry, support ticket review |
| Concept and prototype | Can people understand and operate the concept before anything is built? | Prototype tests with participants using their own assistive technology |
| Build and pre-launch | Can people complete the critical tasks with their own setup? | Task-based usability studies, one or two user groups per platform |
| After launch | Where do people still get stuck, and did the fixes work? | Re-tests, longitudinal studies, support and abandonment data |
Compliance is still the baseline, and most products don't meet it yet. The WebAIM Million 2026 report found WCAG failures on 95.9% of the top one million home pages. That's why accessibility research works alongside the checks your accessibility and engineering teams already run. Each of the three methods below has its own job, and a strong accessibility program uses all of them.
Automated scans
Use them: on every release.
They catch: rule violations like missing labels and low contrast, quickly and cheaply.
They miss: anything that only shows up when a person works through a whole task.
Expert reviews
Use them: for a fast check before a release, or while you build the budget for a study.
They catch: obvious barriers, because a specialist walks through your key tasks with assistive technology.
They miss: how people who rely on that technology every day actually experience your product.
Accessibility UX research
Use it: on your most important tasks, before the design is locked and after major changes.
It catches: the dead ends and exhausting paths that block real people from finishing a task.
Works best with: automated scans on every release, so rule violations get fixed fast and your study time goes to the problems only people can show you.
If your budget only covers one step beyond automated scans, spend it on a focused study of your single most important task with one user group. That study tells you if people can complete the task your business depends on, which neither a scan nor an expert review can.
When accessibility research isn't changing the product, our researchers usually see one of these four mistakes behind it.
Testing only with employees
Internal testers know the product too well and rarely use assistive technology the way your customers do. Their sessions miss the problems a new user hits.
One participant speaking for everyone
A blind screen reader user, a low vision user who zooms in and a person who is colorblind experience the same screen in very different ways. One session can't stand in for all of them.
Recruiting only expert assistive technology users
Expert users work around design flaws that stop newer users cold. Recruit a mix of experience levels so your findings reflect your real customers.
Findings that never reach the backlog
If a study doesn't change requirements, designs or release criteria, it hasn't done its job. Tie every finding to an owner and re-test it.
Your team can design and analyze accessibility studies. The part that slows teams down is recruiting and running the sessions. The user groups are specific, each participant needs the right assistive technology set up before the session, some need interpreters, and recruiting from scratch for every study takes weeks. That's why many teams keep strategy and analysis in-house and use a partner with an established panel for recruiting and sessions.
Akraya has run accessibility research panels for five years and supported more than 200 accessibility studies. Our panels recruit across 14 disability categories, from blind and low vision participants to people with dyslexia, people who are non-speaking and people with temporary injuries. Sessions support 27 kinds of assistive technology and support, including screen readers, braille displays, switch access, eye tracking, speech-generating devices and sign language interpreters.
We run studies in person in the US and remotely in the UK and Canada, typically have a study in field within one to two weeks of a request and can run up to 50 sessions a week. Our PhD-level researchers are vetted against a big tech hiring bar, and every study is scoped to the product decisions your team needs to make.
We work with Fortune 500 teams building software, AI products and wearables. You can start with a rapid UX research study that delivers findings in 2 to 3 weeks, or add an embedded researcher who tracks accessibility release after release. Both run under our UX research as a service model.
Go deeper
Making the case to move accessibility research earlier? Read why accessibility can’t be a final-stage checkbox, and what it costs when it is.
Find out where your product stops people with disabilities
Tell us which tasks and user groups matter most to your roadmap. We'll help you scope a study that shows if people with disabilities can complete them, with findings your stakeholders can act on.
Talk to our UX research teamAccessibility UX research is UX research with participants who have disabilities, using the assistive technology they rely on every day, such as screen readers, screen magnification, switch access or captions. It shows if those participants can complete your product's key tasks, and where the product stops them.
WCAG compliance is the baseline every product should meet, and it catches real problems like missing labels and low contrast. It checks your product against a set of rules, so it can't show you if people with disabilities can finish a task. The W3C, which publishes WCAG, recommends evaluating with users with disabilities because it finds usability issues that conformance checks alone miss.
A UX research leader owns the system around the studies: accessibility in every research brief, a reliable way to recruit participants with disabilities, accessible sessions, findings written so product and engineering can act on them, and metrics that show leadership progress over time. Individual researchers run the studies inside that system.
Screen participants by the tasks they do and the assistive technology they use, such as a screen reader, magnification or switch access, along with the devices and browsers they use it on. Medical diagnoses don't predict how someone uses your product, so they don't belong in the screener. Test with one or two user groups at a time so each group gets enough sessions to give you reliable findings.
Most UX research teams can design and synthesize accessibility studies in-house. Recruiting is the hard part: the user groups are specific, sessions need the right assistive technology and sometimes interpreters, and one-off recruiting is slow. Many teams keep strategy and synthesis in-house and bring in a partner with an established panel for recruiting and fieldwork.