An internet for everyone: Meet Mozilla’s accessibility team

Mozilla’s mission is making the online world open and accessible to all—and that includes people with disabilities. Below, Accessibility team members Asa Dotzler (Senior Product Manager), Morgan Rae Reschenberg (Platform Engineer), Jamie Teh (Staff Engineer and Tech Lead), and Marco Zehe (Senior Platform Engineer and Evangelist) explain how they collaborate with the rest of the team and company—and beyond—to help build every product with accessibility in mind.

First, tell us about your roles at Mozilla.

Morgan: I’m a platform accessibility engineer, and I focus on the Mac platform. When I first joined the team a couple of years ago, I worked primarily on projects for users who have low vision, giving them more options for things like zoom and contrast. This year, I’ve been working on our support for VoiceOver, the native screen reader for MacOS.

Marco: I do a mix of engineering work, but my primary focus is testing and quality assurance for accessibility features in Firefox and other Mozilla products. I make sure everything is working well with third-party assistive technologies like screen readers—I’m blind, so I use them myself. I also do some development work on automated testing, to help us speed up the review process.

Asa: I’m the product manager for Firefox accessibility. Day to day, I’m helping build the feature roadmap, figuring out what we should address and when. I also work with the team to communicate the importance of accessibility to the rest of Mozilla—which includes reviews, where I focus mostly on visual content.

Jamie: I’m an engineer and tech lead, and most of my work is on the core accessibility engine, which is what Firefox uses to share information with assistive technologies. I work across operating systems, but mostly on the Windows side. I handle reviews, as well—like Marco, I’m blind and a screen reader user myself. And along with Asa and others, I help figure out Mozilla’s overall strategy and process for accessibility.


Why did you decide to work at Mozilla—and in accessibility?

Jamie: Accessibility has always been a big passion of mine. It’s not just the right thing to do, it’s a way to empower people. I think each of us has a right and responsibility to contribute whatever they can to make the world better, and if we deny someone the tools they need to do that, we’re denying them and everyone else the benefit of their potential.

I joined Mozilla as an employee a few years ago, but I’d worked pretty closely with the Accessibility team for about a decade before that—as the co-founder of an organization called NV Access (NVA), which develops a screen reader called NVDA. Actually, NVA was able to hire me because of a grant from the Mozilla Foundation. I always liked Mozilla’s focus on people over profit and their mission to make the internet open and accessible to everyone, which of course includes people with disabilities. And I saw that this team wanted to go beyond just checking the boxes and doing merely a passable job at accessibility, which can be really frustrating for users. Instead, we talk about “delightful accessibility.” Just as teams do across Mozilla, we’re prioritizing design and user experience—we want to make our products a joy to use.

Marco: I’ve always cared deeply about accessibility, too—I’ve seen how it helps me and others, whether we’re reading the news, connecting with friends, or just getting things done on the web. I also started contributing to the accessibility module before I actually joined the company 13 years ago, and that was a good way to get a sense of the culture; it’s important to know you’ll feel welcome when you’re part of a minority group. To me, working here was an opportunity to make an impact on a large scale—potentially hundred of millions of users.

Morgan: I came to Mozilla through education rather than tech; I worked as a teaching assistant and lecturer in computer science and am a big proponent of access to CS education and technology in general. I like accessibility work because it’s focused on helping people, rather than just doing tech for tech’s sake. In our world, you often hear browsers referred to as “user agents,” and I think that’s very apt; we facilitate people’s connections to their online world, and we have a lot of power to make the internet easier to use.

Asa: Like Jamie and Marco, I started as a volunteer—though that was a long time ago; I’ve been with Mozilla 22 years now! I’ve had lots of different roles, but I feel like I really found my niche with accessibility. Someone’s demographics should never determine their online access, nor the quality of their experience. Plus, everyone faces situational or temporary disability at some point in their life. Maybe you have a broken arm and can’t use your mouse, or you want to scroll through a recipe but your hands are covered in cake batter. Curb cuts in sidewalks were initially designed for people who use wheelchairs, but they ended up helping parents with strollers and delivery workers with dollies. Accessibility benefits all of us.

It’s also such an exciting space to work in—especially here. As Jamie said, we’re trying to deliver experiences that are actually delightful. So much has gone undone for decades because people thought about accessibility in terms of doing the minimum. But when you take a broader view, there’s a huge opportunity for innovative work.


Who does your team collaborate with and how?

Jamie: That’s one of the interesting things about this team—we get to work with people in every part of the company. It’s a massive footprint across the entire code base. That does mean we have a lot to keep an eye on, but our automation efforts are helpful, and we’re also working on formalizing some of our processes as Mozilla grows—giving people documentation to help them figure out when to come to us, and what to give us, to get our help.

Marco: That process has definitely changed—it was more reactive a few years ago. A new feature would hit and then we’d test it to figure out what didn’t work. Now, people are reaching out to us and asking for help ahead of time, which is great. The earlier we get involved, the more solid things will be from an accessibility standpoint.

Asa: Absolutely. Mozilla always had a good track record of shipping high-quality accessible experiences, but it often required pretty heroic efforts pretty late in the game. Recently, we’ve gotten more involved in design and user research rather than just development and testing. This way, when a design document reaches an engineer, they don’t have to wonder if the contrast will work for someone with low vision or whether we used colors that colorblind users—who are close to five percent of the population—can’t see.

We’re also involved at the end of the cycle, all the way to marketing. Across the board, not just at Mozilla, there’s often not enough communication about accessibility improvements, and that means some users miss out on features that could help them. So we help make sure accessibility is part of release notes and blog posts, as well.

Morgan and Jamie with their Accessibility teammate Eitan at Mozilla All Hands in Berlin

Jamie: We also collaborate beyond Mozilla—sometimes that’s with the people and organizations who build and maintain accessibility tools, and sometimes it’s standards work. Mozilla’s in a unique position to influence the future and make sure users with disabilities don’t have to trade things like privacy in order to have online access.

And sometimes we collaborate with users themselves. One of the great things about Mozilla is that our software is open source, and our tracking and reporting systems are open, too. Anyone can use Bugzilla, and people reach out on social media about things they think we should look at.

Morgan: Yeah, we get a lot of information out of those casual interactions—I get tagged in Twitter threads all the time. When people know and trust you as someone they can go to with questions, that’s really powerful. And as Jamie mentioned, we have the opportunity to make sure accessibility is something people in our industry are thinking about even beyond Mozilla—I’m part of the CSS working group, for example. As a browser company, there are a lot of standards we get to have a say in, and it’s very gratifying to be able to represent users with disabilities in those conversations.


Tell us about some of the projects you’ve worked on.

Morgan: The increased support for VoiceOver this year has been a big improvement; we’ve never really kept pace with Apple’s updates in the past. Now we’re bringing ourselves up to speed, but we’re also optimizing—thinking about how VoiceOver should ideally work, not just how it works in other browsers. Apple’s products are largely closed-source, so it takes a lot of black box poking around. But it’s been awesome, especially because I’ve gotten to work with Marco, who has a perspective I don’t on how a VoiceOver power user would want the technology to work.

Marco: That project has been super exciting. As Morgan said, it’s a lot of tinkering—reverse engineering what Apple has done with Safari and how other browsers approach similar technologies—but then improving on that, as well. And when you finally start to see things work that never did before, it’s phenomenally rewarding. One year ago, even basic tasks were very slow. Now you can use VoiceOver for all kinds of things, including Gmail, Twitter, and Google Docs, and the difference is night and day.

Jamie: One thing I like about the projects we take on is the huge amount of diversity. One day I’ll be working on the UI, figuring out how to make the purpose of video controls clearer to someone using a screen reader, and the next day I’m doing deep architectural engineering.


What are you looking forward to right now?

Marco: One of my hopes for the next year or two is to develop or rework some models to make transitioning from desktop apps to web apps with a screen reader more seamless. As I get older, I’m noticing all the context-switching takes an increasing toll on my concentration; you have to figure out the best way to manipulate each new element, and that’s all the more difficult with speech because it’s a sequential medium—you can only get one piece of information at a time. There are some really complex, interesting questions there, and the answers will hopefully help lift the cognitive burden for users like me in the decades ahead.

Morgan: I’m looking forward to getting closer to VoiceOver API completeness—or getting at least as far as we can given what Apple offers us. We’re really happy with the progress we’ve made so far, but there’s always polishing and performance tweaks to be made. We’re considering implementing custom rotors, for example, so VoiceOver users can natively access specific sets of Firefox commands or information on a web page. It’s something no one does yet, but we’re trying to figure it out.

Jamie: A lot of my thinking right now is around the next generation of our Windows accessibility architecture. The majority of our users are on Windows, so it’s been kept up relatively well—but the web never stops changing and growing, and the architecture is starting to show its age and have some performance issues. Microsoft has released a new framework called UI Automation, and we’re figuring out whether to adopt that and what the implications will be. It’s an opportunity to reevaluate decisions that were made a decade ago or more in light of the modern web, which is scary but really exciting.

Asa: It is. Because UI Automation is still a work in progress, it will mean a lot of give and take, working with Microsoft to get issues resolved. But it also means getting to push for an approach that’s more flexible, expressive, and maybe faster.

In the shorter term, I’m excited to find ways to support users with a wider range of disabilities. We’ve already begun by moving beyond our initial focus on screen readers into low vision use cases, making layouts and controls more accessible. Next, I’d like to do more for users who have cognitive disabilities, and those with impaired mobility. An amputee, for example, might use a single switch to navigate the web, and we support that on Android today. What would it take to bring that support to the desktop, or to develop gaze control, where your computer can move your mouse with the help of a computer that tracks your pupils? The more we can expand our work, the closer we are to creating an internet that really is accessible to all.


Interested in working with the Mozilla team? Check out our open roles.