By Aurélien Lair, Co-organiser at CTM
I remember the first time I tried to navigate one of my own applications using just a screen reader. It was a humbling and frankly, frustrating experience.
As testers, we spend our days obsessing over performance, security and UI consistency. Yet, far too often, we treat accessibility (a11y) as a mysterious, specialised discipline that requires "expert" status to even begin.
I remember this coming up at our meetup. This topic sparked a deep discussion (resources, time, costs, you name it) as it is an industry-wide challenge. But the consensus was clear: accessibility shouldn't be treated as a separate job for a specialized team. It’s a core piece of quality engineering. If we are serious about building software that serves everyone, we can’t ignore the barriers that many users face simply because they don't fit our "standard" testing scenarios (1.3 billion people or 16% of the global population experience significant disability according to the World Health Organisation).
The problem with "checklist" accessibility
When we talk about accessibility, the human element of the story often gets lost in fear-mongering about "compliance" and "risk management" but the element that gets overlooked is people! Without these tests, we are effectively locking millions of people out of the digital services we build.
Accessibility comes up often in our meetup discussions. Many feel that they need to move the conversation towards practical application - sharing the tools and techniques that can be used in daily workflows.
Three pillars of actionable accessibility
If you’re a tester looking to expand your toolkit, here is the mindset to prioritize:
- Building awareness over assumptions: We don’t need to "understand" every lived experience but we must be aware of the barriers we overlook daily. The goal is to move beyond "one size fits all" and learn to identify the navigation obstacles we often ignore.
- A practical toolkit: You don’t need deep complexity to start. Effective testing relies on a practical, everyday toolkit like screen readers or basic diagnostic software that allows you to view your application from a new perspective (see W3C).
- Risk management as quality: Testing for accessibility should be treated like a high-priority product risk. When you do so, you're protecting a subset of users/potential users. As we know, protecting the user is synonymous with protecting the overall quality of the software.
See it in action
We are hosting a live, hands-on session with Ady Stoke, a tester with over 20 years of experience, titled: "Accessibility testing live: simple tests everyone should know"
📆 Join us on March 18th at 7 PM CET.
This isn't a theoretical lecture. Ady is going to walk through the simple, actionable tests that any of us can add to our daily workflow. You don’t need to be an accessibility specialist to make a difference, you just need the right approach.
If you’re tired of abstract advice and want to see how to actually start testing, we’d love to have you join the conversation.