The short answer
Treating accessibility as a final-stage checkbox means your team only checks it right before launch, after the design is set and the code is built. At that point, every problem you find means rebuilding work that's already done, fighting the launch date and shipping with known issues. For a UX research leader, the fix is to own accessibility across the product cycle: requirements set at planning, prototypes tested with people with disabilities and progress reported to leadership before launch pressure takes over.
In most product teams we work with, accessibility has a set place in the schedule: the last few weeks before launch. The design is approved, the code is written, and someone runs the scans and the audit to make sure the product passes.
But by then, the decisions that decide if people with disabilities can use the product have already been made. Every problem the check finds has to be fixed in work that's already finished, and the launch date doesn't move to make room for it.
For UX research leaders, that's usually the moment accessibility reaches your team: when there's no time left to change what matters. This post covers what that late check costs, why accessibility keeps landing at the end of the schedule, and what your research function can change at each stage.
What fixing the same accessibility problem involves at each stage
| When you find it | What fixing it involves | How much work it takes |
|---|---|---|
| Planning and design | Change the design file, then show the new version to a few people again | Low. Nothing has been built yet |
| Early build | Adjust a component before other teams reuse it | Medium. The fix stays in one place |
| Right before launch | Rebuild components, reproduce and record each bug, log it, fix it and verify it again | High. The work competes with the launch date |
| After launch | Everything above, plus users who are already blocked and exceptions nobody follows up on | Highest. Customers and legal risk are now involved |
From the outside, nothing looks wrong. The team designs and builds the product, and accessibility shows up as one item on the pre-launch list, next to security review and performance testing. Someone runs an automated scan, an auditor checks the product against the Web Content Accessibility Guidelines (WCAG), and the item gets marked as done.
The problem is everything that happened before that check. Accessibility wasn't in the requirements, so designers didn't plan for it. Nobody with a disability saw the prototype, so no one flagged problems while the design could still change. Engineers built the components without accessibility criteria, so other teams reused them as they were.
By the time the audit runs, all of those decisions are locked in. The findings arrive as a list of bugs against a launch date that's already set, and the team has to choose between fixing finished work and shipping on time.
A late accessibility bug is almost never a one-line fix. When our researchers see accessibility problems found right before or after launch, the cost shows up in five places.
A missing keyboard shortcut or a focus trap (a spot where keyboard users get stuck and can't move on) sounds small. But when it lives inside a component the whole product uses, engineers often have to rebuild that component from scratch. And every late bug comes with its own process: someone reproduces it by hand, records it on video with audio, logs it in a tracker and checks the fix again once it ships.
Once accessibility runs into a deadline, the conversation changes. In our experience, teams push back on how severe a bug is, or try to show a workaround exists so the bug can be downgraded to minor. Other teams file exceptions so they can ship on time. However, exceptions tend to get pushed from one release to the next, because nothing holds anyone to them.
Whatever ships with known issues lands on real users. A blind person who hits a dead end in a checkout or a sharing flow doesn't file a bug. They leave, call support or ask someone else for help, and your team may never hear about it.
Our own team has lived this. A tool we were told was accessible failed in its very first study with our panel, and participants with disabilities couldn't complete basic steps. Checking everything properly took about eight months, and moving over fully took close to a year. One early session with real users would have caught it before anyone committed to the switch.
Digital accessibility lawsuits under the Americans with Disabilities Act are common in the US, as this American Bar Association overview explains. And since 28 June 2025, the European Accessibility Act applies to any organization offering services to EU consumers. On top of that, enterprise customers often write accessibility into their buying requirements. Every known issue you ship makes each of those conversations harder.
Yes. The savings come from the rework your team no longer has to do. A problem caught in a prototype gets fixed with a quick change to the design file. The same problem caught after launch means rebuilding the component, reproducing and logging the bug, verifying the fix, and handling exceptions and support tickets while it stays open. Every stage you move the check earlier takes a layer of that work off your team's plate.
Industry research points the same way. Forrester research commissioned by Microsoft, which the W3C cites in its business case for digital accessibility, found that accessibility contributes to cost savings when it's built into ongoing development cycles. The same page reports lower maintenance and service costs for redesigns that include accessibility from the start.
In our experience, accessibility drifts to the end of the schedule for a few predictable reasons.
Teams assume the design system covers it
When a design system is labeled accessible, teams often leave accessibility out of design and sprint planning. But accessible building blocks can still add up to an inaccessible product: contrast, labels and focus order can break depending on how each team puts the pieces together, and nobody finds out until the final check.
Products get built for most users first
Teams build for most users first and plan to handle accessibility later. By then, research can only find the symptoms after launch, when the root cause could have been fixed in the design.
AI-generated code moves faster than review
More teams now ship code written with AI tools. That code can look finished and pass a quick review while still breaking for keyboard and screen reader users, and those problems only surface when someone uses the product that way.
Research needs aren't in the budget
Studies with people with disabilities have costs teams don't plan for, such as sign language interpreters for some Deaf participants. When those costs aren't in the budget from the start, research gets pushed back until there's no time left for it.
Moving accessibility earlier, sometimes called shift left accessibility, needs an owner across the whole product cycle. UX research is well placed to be that owner, because your team already works with product at planning, with design on prototypes and with engineering before launch. Here's what to change at each stage.
01
Plan: get accessibility into the requirements
Work with product to put accessibility requirements in the product requirements document, with the user groups and key tasks named. Budget for research with people with disabilities, including needs like interpreters, at the same time as the rest of the research plan.
02
Design: put prototypes in front of people with disabilities
Add participants with disabilities to the prototype tests your team already runs. Our researchers often give this kind of lightweight feedback before anything is built, which is when changes cost the least.
03
Build: agree on who checks what
Engineering runs automated scans on every release and checks components once they're combined into full tasks. Your team flags the flows that need a closer look, such as new components or code generated with AI tools.
04
Before launch: run a focused study on critical tasks
Test the key tasks with one or two user groups on one platform at a time. Rate each task as healthy, at risk or unhealthy, and turn every issue into a bug with steps to reproduce it, a recommended fix and an owner.
05
After launch: re-test and report progress
Re-test fixes with the same tasks, make sure every exception has an owner and a date, and report task health to leadership over time. Leaders fund what they can see moving.
This pays off quickly. In our experience, once a product team has run a few early studies, it starts asking research for feedback earlier on every new feature, and fewer problems make it to launch.
Automated scans are the cheapest part of accessibility to move earlier, yet many teams still run them only once, right before launch. Agree with engineering that scans run from the first build and on every release, as part of the checks code already goes through before it ships.
That way, rule violations like missing labels or low contrast get fixed by the engineer who just wrote the code, and your team's study time goes to the problems only people with disabilities can show you.
Moving accessibility earlier needs budget and a seat at planning, and both come from leadership. Three moves make that case easier to win.
01
Show what the last late fix cost
Pick a recent launch and count what late accessibility issues created: components rebuilt, bugs downgraded, exceptions filed, launch dates moved. Put it next to the table at the top of this post, and the cost of waiting stops being abstract.
02
Propose one early study on a high-risk task
Choose one task the business depends on, such as sign-up, checkout or account recovery, and test the prototype with one user group. A small, early win is easier to fund than a program.
03
Report accessibility as a metric
Give leadership task health by user group and how quickly accessibility bugs get fixed, release after release. In our experience, once accessibility shows up as a leadership metric, product teams start asking research for it earlier.
Most research teams can design and synthesize these studies themselves. Recruiting people with disabilities quickly enough to test early is the hard part, which is where a partner with an established panel helps.
Akraya has run accessibility research panels for five years and supported more than 200 accessibility studies. Our panels recruit across 14 disability categories, and sessions support 27 kinds of assistive technology and support, from screen readers and braille displays to switch access and sign language interpreters.
Because speed matters when you're testing early, 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. And if you want accessibility tracked release after release, an embedded researcher can work inside your team under our UX research as a service model.
We run these studies for Fortune 500 teams building software, AI products and wearables, with PhD-level researchers vetted against a big tech hiring bar.
Go deeper
New to testing with people with disabilities? Start with what accessibility UX research is and how it fits next to your accessibility audits.
Find accessibility problems while they're still easy to fix
Tell us what you're building and where it is in your schedule. We'll help you scope an early study with people with disabilities, with findings you can take to product leadership before the launch date.
Talk to our UX research teamBy the end of development, the design is set and the code is built. Any accessibility problem you find then means rebuilding components, reproducing and logging each bug and checking the fix again, all while the launch date gets closer. Teams under that pressure often downgrade bugs or ship with exceptions, and people with disabilities run into the problems after launch.
The biggest cost is the work itself: engineers rebuild components that are already in use, and every bug has to be reproduced by hand, recorded, logged and verified again after the fix. On top of that, launches slip or ship with known problems, users with disabilities get blocked, and the product carries more legal and customer risk. The earlier your team finds the problem, the less of that work it has to do.
Shift left accessibility means moving accessibility work earlier in the product cycle. Instead of one check before launch, the team sets accessibility requirements during planning, tests prototypes with people with disabilities, checks components as they're built and runs automated scans on every release.
Start as soon as you have something people can react to, even a clickable prototype or a design concept. Early feedback from people with disabilities is quick to act on because nothing has been built yet. After that, keep testing at each stage: components during the build, full tasks before launch and fixes after they ship.
Accessibility remediation is the work of fixing accessibility problems after they've been found in a design or a product that's already built. The later it happens, the more it involves: rebuilding components, reproducing and logging each bug, and checking every fix again. Building accessibility into each stage keeps most of that work from piling up at the end.