There is a pattern I have seen repeat itself more times than I can count. A product is nearly ready to ship. The design looks clean, the functionality works, the team has gone through rounds of testing. Then, right at the end, sometimes just days before release, someone asks: “Did we test for accessibility?”
What follows is usually a scramble. A quick pass with an automated tool. A few boxes checked. Some items flagged as “known issues to be addressed in a future release.” And then the product ships anyway.
I understand how it happens. Deadlines are real. Competing priorities are real. Accessibility often feels abstract compared to a login button that doesn’t work or a report that generates incorrect numbers. Those problems are visible, immediate, and easy to explain to a stakeholder. An accessibility gap can feel like something only a small number of users would ever notice.
But that thinking has a cost, and it falls almost entirely on the people who had no say in how the product was built.
Who Actually Gets Left Out
When a digital product isn’t built with accessibility in mind, the impact isn’t evenly distributed. People who rely on screen readers to navigate because they can’t see a screen. People who use keyboard navigation only because a mouse is physically difficult. People who need high color contrast to distinguish elements on a page. People who use voice control software to interact with a device.
These aren’t edge cases. According to the CDC, roughly one in four adults in the United States lives with some form of disability. In the context of a banking application, a healthcare portal, or a government service platform, that translates to millions of people trying to do something completely ordinary: check an account balance, book an appointment, access a benefit. And hitting a wall that most other users never see.
The wall isn’t always dramatic. Sometimes it’s a form field that a screen reader can’t identify properly. Sometimes it’s a button that only works with a mouse click and ignores keyboard input. Sometimes it’s a color scheme that looks fine to most users but makes critical information invisible to someone with a color vision difference. Small, quiet failures, but for the person experiencing them, the effect is the same: this service was not built with me in mind.
Why Treating It as a Checklist Makes Things Worse
The instinct to run accessibility testing at the end of a project, rather than throughout it, creates a particular kind of problem: by the time the issues surface, fixing them is expensive and slow.
Accessibility isn’t just about how something looks. It touches the structure of the code, the way interactive elements are labeled, the order in which content is presented to someone using assistive technology, and the logic behind how a page responds to different types of input. These things are much easier to get right during design and development than to retrofit after the fact.
When accessibility is treated as a late-stage checklist, the team ends up doing two things instead of one: building the product, and then partially rebuilding it. And even then, the fixes are often incomplete, because the underlying decisions that caused the problem were made too early and too many layers deep to fully unwind under a tight timeline.
I have seen this firsthand. Accessibility issues that would have taken a developer an hour to address during build took weeks to remediate after release because they were woven into the foundation of how a feature worked. The late discovery didn’t save time. It created more work, more risk, and a worse experience for the people who needed it most.
What Baking It In Actually Looks Like
Testing for accessibility throughout a project doesn’t require a separate team or a specialized toolkit. It requires a shift in when the questions get asked.
During requirements: does this feature need to work for users who navigate without a mouse? Does it need to be usable on a screen reader? If a form produces an error, how will that error be communicated to someone who can’t see the screen?
During design: does the color contrast between text and background meet basic readability standards? Are interactive elements clearly distinguishable from static ones? Is the visual hierarchy logical to someone who can’t rely on color alone to understand it?
During development: are form fields labeled in a way that a screen reader can interpret? Does keyboard navigation move through the page in a logical order? Are error messages tied to the specific fields they describe?
During testing: beyond automated scanning tools, has someone actually navigated the product using only a keyboard? Has it been tested with a screen reader running? Does the experience hold together from start to finish for a user relying on assistive technology, not just for individual components in isolation?
None of these questions are technically complex. They are mostly about remembering to ask them at the right point in the process, rather than leaving them for the end when the answers are hardest to act on.
Why This Feels Personal to Me
Part of what draws me to accessibility testing is that it sits at the intersection of technical work and something that matters beyond the code. Getting an API response formatted correctly is important. Making sure a banking application actually works for a person using a screen reader is important in a different way, because that person is trying to access their own money, and the barrier between them and it is something a team built, usually without meaning to.
That’s what I keep coming back to. Accessibility failures are rarely deliberate. They happen because the question of who else might use this product got crowded out by other, louder questions. Testing for accessibility is one way of keeping that question in the room, of making sure the people who need the product most aren’t only considered after everyone else has already been taken care of.
Onyinyechi Isima is an ISTQB-certified Quality Engineer with experience in enterprise software quality, API testing, and digital accessibility within regulated financial systems.