Debunking Accessibility Testing Myths

I saw @marie.drake share a really interesting blog post last week that I wanted to chat about some more on here.

I was wondering if anyone has any other accessibility testing myths to share? Or have you tried/plan to try some of Maries suggestions in your own workplace?

1 Like

Thank you for sharing this. I am going to try some of her ideas, as I have heard from testers on my team that it is has been very stressful to learn DA testing, as it is unlike anything else they have done, and the expectation was added after the project was underway. It previously hadn’t been an expectation… While no one questions the need, and value to end users, they are absolutely stressed by it. It has been a steep learning curve, with PMs, and programmers who also knew nothing having some unrealistic expectations. I am curious if BAs play any role in determining the user scenarios in other organizations? It has all fallen on the QA team, as no one else on the project team has any idea at all.


I’ve honestly never had a BA on my team during my testing career so I worked with the developers and product owner to create and refine user stories.

One more myth - most companies genuinely care about having accessible products! From my experience, they only care if they are legally obligated to implement accessibility features, either that or if it explicitly required by their clients/customers.

My experience is somewhat similar; management will pay lip-service to accessibility and that feeds down into the development teams in terms of prioritisation so all too often, accessibility is either dealt with as an afterthought or pushed into the backlog to be dealt with at some unspecified time in the future.

However, when management get threatened with legal action as if by magic, accessibility becomes a priority! I recall at a previous place twice seeing what I used to refer to as “the great accessibility panic” when exactly this happened, they came running to me after someone remembered I’d had accessibility training, then I’d smile sweetly and point out there were no quick/cheap fixes thanks to the decisions about how to get stuff properly accessible had been kicked down the road again and again. When the threatened legal action failed to materialise, accessibility once again got forgotten about…

1 Like

We have a quite small client base, so the line I took with our product owner was to highlight the risk that if one of our users acquired an accessibility requirement through illness or accident, our product might no longer be able to meet the “reasonable adjustment” requirement. If Brand X met that requirement better than our product did, that client might switch to Brand X even if it was inferior to our product in other ways.

It got the business to take accessibility seriously.


After keeping tabs on the hints Marie has dropped, I have discovered a few pointers. WCAG is just a standard, and not a replacement for the real questions. Can a disabled person use my product? To start at the “will I be able to sell to a govt owned or govt funded customer?” question, is not the only question you should be asking. Do you go directly to certify, or use a consultant, which route is cheaper, which is quicker? And that a new WCAG spec is in the wings, so be ready to do it all again if you already have.

But mostly, that being unable to even get a salesperson talking to some big customers is probably the biggest gotcha that you want to prepare for; by doing small steps right now; and to keep on talking about it in requirements meetings all of the time.

Nice article by @marie.drake ! Thanks for sharing it @heather_reid :+1: