Accessibility has always been close to my heart. I was introduced to it early in my career, when a client required our product to be AAA-compliant. As a team of two, we audited our entire app.
We were barely AA.
If those letters don’t mean much, they refer to the Web Content Accessibility Guidelines (WCAG), the international standard for making digital products usable for people with disabilities. AAA is the highest level of conformance. AA is typically considered the acceptable baseline.
We weren’t even confidently there. That experience changed how I see design.
Most products today aren’t perfect. Many aren’t even close. But accessibility isn’t just about passing audits or checking contrast ratios.
Yes, color contrast matters. Alt text matters. Focus states matter. But those should be the floor, not the ceiling. Accessibility goes beyond a checklist. It’s a mindset. And that mindset deepened for me on the Firefox UX team.
At Mozilla, I’ve had the opportunity to collaborate closely with our accessibility specialists and conduct research using Fable: a platform that connects us directly with people who use assistive technologies like screen readers, magnification software, and voice access.
Instead of designing based on assumptions, we test with real users navigating Firefox in real ways. That difference is everything.
In two recent moderated sessions I facilitated, I was reminded how much nuance lives in the margins of our designs.
In one session, we worked with a participant who uses screen magnification software. We learned:
- Even the slightest pixelation can create ocular vibration and discomfort
- Swipe gestures, which often feel “modern” to designers, can be risky or disorienting for magnification users
- Thoughtful line height can meaningfully reduce cognitive load
These aren’t things you catch in a checklist review. They’re things you learn by listening.
In another session, an Android user who relies on Voice Access showed us something equally important:
- Holding and dragging interactions are difficult with voice control
- App-level voice commands can interfere with system-level voice access tools
Features designed to feel innovative can unintentionally create barriers. That tension is where real accessibility work happens.
This experience wasn’t just eye-opening for me. My teammate Nicole reflected:
“Working with Fable was a great experience. One takeaway that stood out was how low vision users face similar challenges to anyone using their phone outside in bright sunlight, especially around contrast. It also made us think more about designing for an aging population… building in accessibility now sets us up to serve more users over time. Overall, it broadened our perspective, helped us build empathy, and made the product better. This kind of research should be a standard part of the design process.”
That last line stays with me: This kind of research should be standard.
These sessions fundamentally changed how I approach design. Accessibility now shows up much earlier in my process: not as a final pass, but as a lens.
When defining problems, I ask:
- What happens if this is heard instead of seen?
- How does this interaction work without touch?
- Could this increase cognitive load?
- Are we designing for someone unlike ourselves?
It’s no longer a checklist I review at the end. It’s something I carry from the beginning. And it makes our critiques stronger, our conversations sharper, and our decisions more intentional.
Accessibility also deeply aligns with Mozilla’s mission. We will always stand behind our belief that the internet should be open, usable, and available to everyone. Designing accessibly is just one of the ways we can achieve that.
When we remove barriers, we’re not just improving usability; we’re protecting participation, agency, and inclusion on the web.
Of course, no process is perfect. Deadlines are real. Technical constraints are real. Accessibility can feel overwhelming, especially if you’re new to it.
But you don’t have to know everything to start. A lot of it is just learning as you go.
- Start with the basics
- Take advantage of resources you do have
- Advocate for testing with real users
Most importantly: don’t treat accessibility as an afterthought. The more you practice it, the more it becomes instinctive.
Accessibility extends beyond pixels.
It’s not about compliance. It’s about empathy. And when we design with accessibility in mind, we’re not designing for a small group of users.
We’re designing for everyone.
Helpful resources
- Web Content Accessibility Guidelines (WCAG)
- Fable
- Stark for Figma (accessibility plugin)
- WebAIM Contrast Checker
- Book: Accessibility for Everyone by Laura Kalbag
Originally published on Medium.com