Web Accessibility Testing – Are We There Yet?

In the tech world right now, web accessibility is being talked about a lot. Webinars. Blog posts. Conference talks. Panels. How to do web accessibility testing, the tools and the law etc. There’s no shortage of conversation, and awareness is definitely higher than it’s ever been.

That’s progress worth celebrating. But : when it comes to actually doing accessibility testing well, I feel like we’re still falling short. Hence it’s time we asked ourselves honestly—are we there yet?

The Awareness vs. Action Gap

Accessibility is no longer an unknown. Most people in tech have at least heard of WCAG, know that “keyboard navigation” is a thing, or can tell you that screen readers exist. Organizations are starting to acknowledge that accessibility isn’t optional—it’s a legal, ethical, and business necessity.

But awareness without proper execution is like knowing the rules of the road and never drive properly.

I’ve seen accessibility testing treated as a checkbox at the end of a release cycle, run only with a tool, or tested a page or a section in isolation or assigned to one person while the rest of the team assumes they’re covered while some teams in the same organisation is not thinking / developing / testing accessibility at all. I think we only scratching the surface.

What more testers need to do?

Why We’re Not There Yet

Despite the noise, here’s what I keep seeing in practice:

• Overreliance on automation

Automated tools are great for spotting obvious issues—but they only catch 20–40% of accessibility problems. The more complex, experience-driven barriers (like confusing navigation flows or poor screen reader announcements) go completely unnoticed unless someone manually tests them.

• Inconsistent approaches across teams

Within the same company, different teams can have completely different interpretations of accessibility testing. Without standardization, we create gaps big enough for serious accessibility issues to slip through.

• Accessibility left until the end

This is a big one. Accessibility testing is still often done as a “final check.” or after we go live with feature implementation. By then, fixing issues is harder, slower, and more expensive. Worse, some issues get deferred or ignored because the issues are not getting prioritised due to time or budget.

• Unclear ownership

Who owns accessibility testing? Developers? Testers? Designers? Product owners? The truth is—all of them. But unless teams define shared responsibility, it often becomes “someone else’s job.”

• Lack of user involvement

Perhaps the most critical gap: very few projects actually involve users with disabilities in their testing. Without this, we’re missing the lived experience perspective that no tool, checklist, or guideline can replicate.

What Needs to Change

If we want to genuinely “get there,” here’s are some things to think about.

• Shift left. Accessibility shouldn’t wait until the testing phase—it needs to be part of design decisions, coding practices, and ongoing QA.

• Standardise and align. Companies with multiple products or teams need clear guidelines and consistent approaches.

• Accessibility can’t be random. Balance automation with manual checks. Tools should be our helpers, not our only line of defense.

• Make accessibility a shared responsibility. Designers consider it in layouts, developers in code, testers in validation, product owners in definition of done.

• Engage real users. This is where true learning happens—when people with disabilities interact with our products and highlight barriers we didn’t even think about.

So… Are We There Yet?

Not really. At least for majority of the companies. We’re having the conversations, and that’s important. But too much of accessibility testing today is surface-level. It’s often an afterthought, a compliance checkbox, or a presentation topic rather than a lived practice.

To say we’re “there,” accessibility has to be embedded into how we define quality. It needs to be as natural to us as writing unit tests, running regression suites, or checking performance.

The good news is—we already know what needs to change.

The question is, will we move from talking about accessibility to consistently delivering accessible experiences?