How One Screen Reader Test Changed My Approach

The First Time I Used a Screen Reader, I Nearly Gave Up

I'll never forget it. The first time I turned on a screen reader, I was in a hurry to test a fix, and within seconds, I was completely stuck. I didn't know how to move, pause, or exit. I thought it would just click, but it didn't. For a moment, I actually panicked.

My colleague in QA calmly laughed, knowing exactly what had happened. She walked me through how to get out of VoiceOver and what I had just experienced from the perspective of a real user. That five minute exchange changed how I thought about accessibility forever.

What That Moment Revealed

At the time, I was leading a small accessibility project, our first one. Until then, my work was all about hitting design specs, meeting deadlines, and keeping builds lean. Accessibility had always been a “nice to have” rather than an expectation.

But that screen reader experience exposed a gap, not just in my knowledge, but in how our entire process was built. We weren't designing or coding with all users in mind. We were optimizing for speed and visual polish, assuming usability followed automatically.

Why It Changed How I Build

That moment made me slow down and ask different questions: How does this component sound, not just look? Can someone navigate it without a mouse? Does focus move logically? Is the message clear when read aloud instead of seen?

Since then, accessibility hasn't been an afterthought. It's part of my process, as foundational as layout or performance. I've learned that accessibility isn't about meeting a checklist. It's about creating digital experiences that actually work for people, regardless of how they interact with the web.

Building Better From the Start

Over the years, I've seen the same pattern across teams: accessibility only surfaces when something breaks, when QA flags an issue, or when a legal letter arrives. But when it's considered early, during design and planning, everything gets better. The product is more robust, the experience more consistent, and development actually moves faster in the long run.

Accessibility isn't just a responsibility, it's a quality measure. And that realization started the day I couldn't figure out how to turn off VoiceOver.

Final Thought

If you've ever had your own “wake up moment” with accessibility, a point where something clicked, that's often the start of real change. Those moments shift habits, influence design decisions, and make the web better for everyone.