One of the sessions I attended recently left a lasting impression—not because it showcased some groundbreaking new tool or shiny framework, but because it touched on something we often overlook: accessibility. It wasn’t about tools. It was about responsibility.
And it made me stop and reflect on how I think about the role of an engineer—not just as a builder of software, but as a builder of experiences.
Venkat Subramaniam took us through a session on “Testing for Accessibility”, and as always, he made it practical, relatable, and a little eye-opening.
Accessibility: It’s Not Optional
Venkat opened by reminding us that accessibility is part of usability. It's not a feature you slap on at the end or a checkbox on a compliance list. It’s foundational to good software design.
Let’s be honest—accessibility doesn’t always make the sprint. In fast-paced environments, it’s easy to see it as “extra.” Something we’ll get to later. But that thinking is part of the problem.
He illustrated this with a story that really stuck with me: A group of NASA scientists once struggled with a website simply because it required constant mouse clicks. With each click, they had to physically push down hard enough that it caused them to slowly slide backward in their chairs—something so simple, yet so disruptive to their workflow. No visual glitches. No broken UI. Just poor interaction design with real-world consequences.
That story hit me because it wasn’t about disability in the traditional sense. It was about friction. About what happens when we design for idealized users instead of real ones. In many cases, developers assume accessibility only matters for people with visible impairments, but that’s a narrow view. Accessibility is about making digital experiences usable for everyone, including those facing temporary, situational, or cognitive challenges. That’s what accessibility is about—designing software that works for everyone, in every context.
What Does Accessibility Really Mean?
At its core, accessibility means making your application usable by as many people as possible, no matter their physical abilities, environment, or circumstances. It’s about inclusivity—taking into account those who are more comfortable using screen readers, navigating with a keyboard, dealing with temporary impairments like a broken arm or screen glare, or processing information differently due to neurodiversity.
Accessibility is not limited to permanent disabilities. It also covers everyday situations like using a device in poor lighting, recovering from an injury, or feeling sensory overload due to excessive motion or noise. It includes users with different interaction preferences, reading speeds, and attention spans. When we design with these real situations in mind, we’re not just ticking a box, we’re making the experience better for everyone.
Why should we care?
Because not every impairment is visible. And even if it were, the goal isn’t just empathy—it’s effectiveness. As Venkat put it:
- It’s the right thing to do
- In some places, it's actually a legal requirement
- It makes your product more inclusive and widely usable
- It reflects on your company’s reputation
- It helps create apps that are actually usable—not just technically functional
- It improves usability for everyone, not just for those with impairments
Accessibility, in short, makes things work better—for more people, more of the time.
Build With People, Not Just For Them
It sounds simple, but it’s a profound shift.
We often rely on simulations, assumptions, or best practices when designing for accessibility. But those are not a substitute for real lived experience.
Imagine designing a mobile app without ever speaking to someone who uses a screen reader. Or launching a public service without understanding how it works for someone with low vision, anxiety, or cognitive overload.
One of the most impactful takeaways was the emphasis on involving people with impairments in your testing process whenever possible.
We can’t design inclusive products without including people in the process. It’s not just about checking boxes. It’s about building something that genuinely works for everyone.
Where Do You Start?
Venkat recommended using WCAG (Web Content Accessibility Guidelines) as a baseline. If you're unfamiliar, this is a great starting point.
He also laid out a straightforward three-pronged approach to accessibility testing:
- Measure – Use tools to identify accessibility issues (e.g., sa11y, Playwright with accessibility checks, etc.)
- Improve – Don’t just detect, fix
- Measure again – Accessibility isn’t a one-time task. It’s continuous
And here’s what I’d add from my own experience:
- Shift left: Bring accessibility into the earliest design and development conversations.
- Use semantic HTML: It’s not just cleaner—it’s more understandable to assistive tech.
- Design for contrast, clarity, and keyboard navigation: These three cover more users than you’d expect.
- Be mindful of motion and animation: Not all users respond well to movement-heavy interfaces.
None of this is difficult. It just needs to be intentional.
Final Thoughts
There’s a tendency in tech to chase the next big thing. But sometimes, the most important work is right in front of us—and it’s not flashy.
We don’t need to wait for laws to force us to care. We can start by listening better. Testing smarter. Building with more awareness.
Accessibility might not win hackathons or make headlines, but it will make your software better. More inclusive. More usable. More human.
And isn’t that the whole point?
