"We'll Get to Accessibility in the Next Sprint"
We have heard this sentence, or some version of it, from more teams than we can count. It is always sincere. Nobody says it and means "we will never do this." They mean it. They fully intend to circle back. Accessibility is on the roadmap. It is in the backlog. There is a Jira epic for it. Someone even created labels.
And then the next sprint has a deadline. And the sprint after that has a feature the CEO saw at a conference and wants shipped immediately. And the sprint after that is bug fixes from the feature the CEO wanted, because it shipped fast and it shows. And suddenly it has been 18 months and the accessibility epic has been reprioritized so many times it is basically a historical document. It is still in the backlog. It will always be in the backlog. The backlog is where good intentions go to live forever without anyone ever looking at them again.
This post is about what happens next. Not the aspirational version where the team finally gets around to it and everything works out. The real version, where "later" arrives uninvited, usually in the form of a demand letter, a failed audit, or a client asking "is your product WCAG 2.2 AA compliant?" and someone on the team Googling what WCAG stands for while on mute.
The Math Nobody Does Upfront
Here are two numbers that every product team should see before they start building, and almost none of them do.
Building accessible from day one: approximately 10-15% additional effort over the baseline development cost. That is it. Not 50%. Not double. Ten to fifteen percent. It is using a <button> instead of a <div>. It is adding aria-label where it is needed and not where it is not. It is managing focus when a modal opens. It is testing with a keyboard once per feature. These are not heroic engineering efforts. They are habits. Small, boring, extremely effective habits that take a few extra minutes per component and save you from everything that follows in this post.
Retrofitting 18 months later: 3 to 5 times the original component cost. Not the original project cost. The original component cost. Per component. Across every component in your application.
Let that math settle for a moment. If a component took two days to build, the accessibility remediation for that single component will take six to ten days. Not because accessibility is inherently complicated, but because you are now doing archaeology. You are excavating assumptions that were baked into the component 18 months ago by someone who may not even work at the company anymore. You are unraveling state management that was never designed to track focus. You are replacing a custom dropdown that was built from scratch with <div>s because someone thought <select> was ugly, and that dropdown is now used on 23 pages, and it cannot be made accessible without rewriting it from the ground up. That rewrite touches every page it appears on. Every page needs retesting. The QA team just added three weeks to their estimate and they are not happy about it.
Ten to fifteen percent upfront. Three to five times the cost later. That is the math. It has never once been wrong.
Why Retrofitting Costs So Much More
"Just add accessibility" is a sentence that reveals a fundamental misunderstanding of what accessibility work actually involves. You are not adding accessibility the way you add a feature. You are not bolting something on. You are redesigning components that were built on assumptions that are now wrong.
You built the house and then someone asked for a basement. That is what retrofitting accessibility feels like. The foundation is already poured. The framing is already up. Every decision was made assuming this was a one-story house, and now you need to get underneath it. The house is not bad. The builder is not incompetent. The house was just not built with a basement in mind, and adding one now involves jacking up the entire structure and hoping nothing cracks.
Here is what that looks like in code:
Custom dropdowns. Someone built a custom dropdown component because the native <select> did not match the design system. They used <div>s with click handlers. It works beautifully with a mouse. It is completely invisible to a keyboard. It has no ARIA roles, no arrow key navigation, no screen reader announcements, and it is used in every form in the application. Making it accessible is not "add some ARIA attributes." It is "rewrite the entire component from scratch using a pattern like Listbox, then replace every instance across the app, then regression test every form." That is not a one-sprint fix. That is a project.
Modals that never managed focus. The modal opens. Focus stays on the trigger button behind the overlay. A screen reader user has no idea the modal is open. A keyboard user can tab behind the modal and interact with things they cannot see. Fixing this requires focus trapping, focus restoration on close, and an aria-modal role with proper labeling. All of which needed to be part of the original architecture. Adding it after the fact means touching the modal component, every place it is called, and the state management that controls it. We have seen modal fixes that took longer than the modal's original build. By a significant margin.
State management that does not know where focus is. React re-renders destroy focus. We wrote about this in detail. When the DOM updates, the element that had focus might disappear and re-render, dumping the user to <body>. Fixing this retroactively means adding focus management to every component that re-renders dynamically. If your app was not designed with this in mind, "every component that re-renders dynamically" is most of them.
The pattern is always the same: the original build made reasonable decisions that did not account for accessibility, and now those decisions are load-bearing. You cannot change them without affecting everything built on top of them. That is why it costs 3-5x. You are not fixing a bug. You are undoing architecture.
The Demand Letter Scenario
This is the section where the humor pulls back, because this is where it gets real for a lot of companies.
Here is what actually happens. An attorney, usually representing a plaintiff with a disability who encountered barriers on your website, sends a demand letter. The letter cites specific ADA violations. Your website is inaccessible, they have documented how, and they are seeking damages and injunctive relief.
Your general counsel forwards the letter to your VP of Engineering with a note that says something like "please advise on our accessibility compliance status." The VP of Engineering forwards it to the product team. The product team looks at the backlog, finds the accessibility epic that has been sitting untouched for 14 months, and begins to understand the meaning of the phrase "deferred technical debt."
What happens next costs money. Here is how much, based on publicly available ADA settlement data and what we have seen across the remediation projects we have worked on:
| Cost Category | Typical Range |
|---|---|
| Legal fees (defense) | $10,000 - $50,000+ |
| Settlement or damages | $5,000 - $100,000+ |
| Emergency accessibility audit | $5,000 - $25,000 |
| Remediation (the actual fix) | $25,000 - $150,000+ |
| Ongoing monitoring | $5,000 - $15,000/year |
| Total first-year cost | $50,000 - $340,000+ |
Those ranges are wide because the cost depends on the size and complexity of your application. A marketing website with 20 pages is on the low end. A SaaS product with a complex UI, user dashboard, and interactive features is on the high end. The high end is not unusual. We have seen it. Multiple times.
Compare that to the 10-15% upfront cost of building it right the first time. On a $200,000 development project, that is $20,000-$30,000 in additional effort, spread across the entire build, requiring no emergency response and zero conversations with attorneys. The math is not subtle.
The Overlay Tax
We need to talk about overlays, because they are responsible for more false confidence than any other product in the accessibility space.
Here is the pitch: install a single JavaScript widget on your site, and it will automatically fix your accessibility issues using AI. Some of them cost $500 a year. Some cost $50,000. All of them make the same core promise: compliance without code changes.
Here is what actually happens. The overlay detects some issues. It fixes a few surface-level ones (it might increase contrast or enlarge text). It cannot fix the structural issues that cause most accessibility failures: missing keyboard navigation, broken focus management, inaccessible custom components, missing ARIA patterns, incorrect heading hierarchy. These are not problems you can solve by layering JavaScript on top. They are problems in the HTML, the component architecture, and the interaction design. An overlay cannot restructure your DOM. It cannot rewrite your modal to trap focus. It is putting a fresh coat of paint on a house with no foundation.
The result: companies pay for the overlay, believe they are compliant, and then get sued anyway. The lawsuit costs everything we listed in the table above. Plus they are still paying for the overlay. Plus the overlay's automated "fixes" sometimes create new accessibility issues that did not exist before, because injecting JavaScript into someone else's DOM at runtime is exactly as predictable as it sounds.
We have been called in to do emergency remediation for companies that had active overlay subscriptions at the time they received their demand letter. The overlay vendor's marketing page said "WCAG 2.2 AA compliance guaranteed." The demand letter said otherwise. The demand letter was correct. The overlay vendor did not offer to help with the legal situation. They rarely do.
If you currently have an overlay and you think you are covered, please get an actual audit. We mean this genuinely. We would rather tell you "your site is fine, the overlay is handling it" than watch you find out the hard way that it is not. For the record, we have never once audited a site with an overlay and said "your site is fine." Not once. But we remain theoretically open to the possibility.
What "Accessible from Day One" Actually Looks Like
After all of that, you might be thinking that building accessibly is a massive undertaking that requires a dedicated accessibility team, a six-figure budget, and a complete overhaul of your development process. It does not.
It looks like this:
Use semantic HTML. A <button> instead of a <div> with an onClick. A <nav> instead of a <div className="navigation">. An <input> with a <label> instead of a placeholder that disappears when you start typing. This is not extra work. This is less work. Semantic HTML gives you keyboard support, screen reader support, and accessibility tree integration for free. The <div> approach requires you to manually rebuild all of that. Using semantic HTML is faster, more reliable, and more accessible. It is the rare situation where the right choice is also the easy choice.
Manage focus on dynamic updates. When a modal opens, focus goes to the modal. When it closes, focus goes back to the trigger. When a list filters, focus does not get dumped to <body>. These are decisions, not implementations. Each one takes a few lines of code and a useRef. The hard part is remembering to make the decision. Once you are in the habit, it takes seconds.
Test with a keyboard. Tab through your feature. Can you reach everything? Can you activate everything? Can you leave every component you enter? This takes two minutes per feature. If something does not work, you will find it immediately. If everything works, you just did a basic accessibility test and it cost you 120 seconds. That is the best ROI in software development. Nothing else comes close.
Add ARIA only where HTML falls short. Custom components that have no native equivalent need ARIA roles and properties. A tabs component needs role="tablist", role="tab", and aria-selected. A live search results area needs aria-live="polite". But if you are reaching for ARIA on a component that has a native HTML equivalent, stop. You are making it harder, not more accessible. The first rule of ARIA is do not use ARIA. The W3C wrote that. It is official guidance.
That is it. Semantic HTML, focus management, keyboard testing, and ARIA where needed. This is the 10-15% effort that saves you the 3-5x remediation cost, the legal fees, the emergency audit, and the overlay subscription that was never going to work anyway.
The Business Case, in Case You Need to Convince Someone
Sometimes the person reading this already knows all of this. They need to convince someone else. A CTO, a product director, a budget holder who sees accessibility as a cost rather than a requirement. Here is the version for that conversation:
Government contracts require it. Section 508 compliance is not optional for federal work. If your product is not accessible, you are not eligible. That is not a risk factor. That is a disqualification. The federal market is large, growing, and increasingly particular about accessibility compliance. Being locked out of it because your product team kept pushing the accessibility epic to the next sprint is an expensive mistake.
Enterprise clients ask about it. We are seeing VPATs and accessibility statements requested in procurement questionnaires with increasing frequency. Enterprise buyers are treating accessibility compliance the same way they treat SOC 2: as a checkbox that determines whether your product makes the shortlist. If you do not have a VPAT, you are not in the conversation. The sales team will eventually figure this out, and when they do, the request will come to engineering as urgent.
Users benefit from it. Approximately 1 in 4 adults in the United States has a disability. That is the CDC's number, not ours. Your product has users with disabilities right now. They are either using it successfully because it was built accessibly, or they are struggling with it and you do not know because your analytics do not track the people who gave up before completing the task. Accessibility is not a niche concern. It is a quarter of your addressable market.
And you avoid everything in this post. The 3-5x remediation cost. The demand letter. The legal fees. The emergency audit. The overlay that did not work. The conversation with the CEO where you explain why a six-figure accessibility remediation was not in the original estimate. It was not in the estimate because nobody brought it up. Now everyone is bringing it up. That is usually how it goes.
Build it right the first time. The math works out. It always does.