A client came to us after their site failed an accessibility review conducted by one of their larger customers, and fixing the issues after the fact was far more expensive than building them in from the start would have been. That project became the reason we now check a short list of accessibility basics on every project by default, not just when a client specifically asks.
What that first failed review actually found
The review that started this was not exotic in its findings — nothing about the failures involved obscure edge cases. Keyboard navigation broke entirely on the site's main navigation dropdown, several product images had no alt text at all, and a handful of interactive elements were built as styled `div`s with click handlers rather than actual buttons, meaning a screen reader had no way to know they were interactive at all. None of this was surprising once we looked, and none of it would have been meaningfully more expensive to get right the first time than it was to build the way it had been built.
Why retrofitting cost so much more than building it in
Retrofitting accessibility onto an already-built site meant going back through components that had shipped months or years earlier, understanding decisions made by developers who had since moved on to other projects, and testing changes against a design that had not been built with keyboard or screen-reader navigation in mind at any point in its original design process. Building the same requirements in from the start would have meant a handful of decisions made once, at design and component-build time, by people who already had full context on what they were building.
The basics we now check on every project
- Every interactive element reachable and operable by keyboard alone, tested by literally unplugging the mouse and navigating the whole flow with tab and enter
- Meaningful `alt` text on images, and empty `alt` on purely decorative ones, decided deliberately rather than left as a default the CMS happened to fill in
- Color contrast checked against WCAG AA, not just eyeballed, using an actual contrast-checking tool during design review rather than trusting that a color pairing "looks readable enough"
- Form fields with properly associated labels, not just placeholder text, since placeholder text disappears the moment a user starts typing and was never a real substitute for a label in the first place
- Headings used in actual hierarchical order, not chosen for their default font size, since a screen reader user often navigates a page by jumping between headings and a broken hierarchy makes that navigation actively misleading
Where we check for these things in our process
We moved these checks earlier than most teams tend to put them — into design review, not just a pre-launch QA pass. A design comp gets checked for color contrast before a single line of code is written against it, and a component library gets checked for keyboard operability as each component is built, not in a batch pass at the end of the project when fixing a fundamental interaction pattern would mean reworking several already-built pages that used it.
Tooling we added to make this practical
Automated tools catch a meaningful subset of these issues without any manual effort — missing alt text, insufficient color contrast, and missing form labels are all things a linter can flag automatically, and we run one as part of every project's CI pipeline now, failing a build outright on the most clear-cut violations. Automated tools cannot catch everything, though — whether a screen reader's announced content actually makes sense in context, or whether a custom interactive widget behaves the way a user actually expects it to, still needs a human going through the flow directly, which we now schedule as a standard QA step rather than something done only when time allows.
What this has changed for client conversations
Bringing this up during initial project scoping, rather than waiting for a client to ask, has changed some of those conversations in a good way. A few clients had genuinely never considered accessibility as something with real business consequences — a discrimination complaint, a large customer's own compliance requirement, simply excluding a portion of potential users — until we walked through it concretely, and treating it as a default rather than an upsell has made it a much easier thing to include in a project's scope from day one.
The actual cost, in practice
None of this is exotic or expensive to build in from the start. It only becomes expensive when it is retrofitted onto a site that was never built with it in mind, which is exactly the trap that client fell into, and which we now build every new project specifically to avoid falling into ourselves.
Training the design team, not just development
Accessibility problems are often decided, unintentionally, at the design stage — a color pairing chosen for brand consistency without checking contrast, an interaction pattern that assumes a mouse without considering keyboard equivalents. We ran a half-day internal training session for the design team specifically, walking through common accessibility pitfalls in visual design decisions, since catching these issues in design review is considerably cheaper than catching them once a developer has already built the corresponding component.
A specific example that changed our review process
On one project after this training, a designer proactively flagged a proposed color scheme during an internal review, noting that the planned accent color against the site's background would likely fail contrast requirements at the sizes it was intended to be used, before any development work had started on it. That kind of catch, happening because a non-developer team member now has the vocabulary and awareness to flag it early, is exactly the outcome we were hoping this training would produce, and it has happened often enough since that we consider the training time well spent.
Working with actual assistive technology, not just automated checks
Automated accessibility checkers are a useful first pass, but they cannot tell you whether a screen reader user can actually complete a task the way a sighted user can. We now do a manual pass with a real screen reader — VoiceOver on projects where that is the more relevant target platform, NVDA on others — for any project with meaningfully complex interactive components, like a multi-step checkout flow or a filterable product listing, since this is exactly the kind of experience where an automated tool might report zero errors while the actual experience is still confusing or broken for someone genuinely relying on that assistive technology.
Bringing this into contract language, not just process
Beyond our internal checklist, we started including a short accessibility clause directly in new project contracts, specifying which WCAG level we are building to and what "done" looks like for that requirement, the same way we would specify a browser support matrix. This has occasionally sparked a useful conversation at the scoping stage about a client's own compliance obligations that they had not previously connected to their choice of web agency. We have also started sharing a short version of this checklist directly with clients during project kickoff, framed as a standard part of how we build rather than an optional add-on, which has made it a much easier conversation than treating it as a special request only some clients happen to make.
Measuring whether this is actually working
We track a simple internal metric now: the number of accessibility-related bugs found after launch versus before, across projects that went through the full checklist compared to older projects that predated it. Post-launch accessibility issues have dropped substantially on every project built under the new process, which is the kind of evidence that has made this an easy internal standard to defend when a tight deadline tempts a project team to treat it as optional, rather than something we have to keep re-justifying from first principles on every single project. That metric has also proven useful in a different way we did not originally anticipate: it gives account managers a concrete, evidence-backed answer whenever a client asks why a seemingly small accessibility fix is being prioritized alongside more visible feature work, rather than leaving that prioritization decision to feel arbitrary or negotiable on a tight timeline. It is, in the end, the same argument we make for testing generally: cheaper early than late.