For several years, Firefox support for the VoiceOver accessibility technology on MacOS was mostly non-existent. In 2020, the team is finally changing that. Here is some insight into what’s happening.
In late 2019, the accessibility team at Mozilla resourced work on improving MacOS accessibility support over the course of 2020. In January, several members gathered in Berlin during an all-hands to scope out the work. There was a lot of old, mostly dysfunctional, code lying around that needs to be modernized and brought up to today’s standards. We agreed to tackle the problem in two stages.
The first stage, due by the end of June, aims to implement basic VoiceOver support. For the most part, this means correcting and completing specific properties for various HTML elements and widgets. This is to give VoiceOver and other accessibility features correct information about what is happening inside our web area.
The aim of this first stage is to give web developers the chance to test their web sites with VoiceOver. The output should be good enough so they can feel confident that users visiting their offerings with assistive technology will get an accessible experience.
In the second stage, which we plan to complete by the end of the year, the goal is to improve the user experience for visually impaired VoiceOver users. This encompasses performance, text editing, live region support, and rotor item support. It will also include other bits that might turn out missing as more users start testing what we have.
Firefox 75, released in April, saw the first fruits of this work. Most notably, we learned our way around the Mac code base and the accessibility APIs. In the process we uncovered a small, but significant, piece we were missing that made us very fast all of a sudden. This small, but mighty, patch, enabled us to progress much more rapidly than we had expected. We also made the VoiceOver cursor visible, and made it follow focus. Also, if navigating with VoiceOver, we made focus follow it if VoiceOver’s setting for that was enabled. And, we also fixed some initial labeling inconsistencies across the board.
Morgan and Eitan also developed some testing and benchmarking utilities. These allowed them to compare the accessibility property output between Safari and Firefox. It also gave us some first measures of performance. And let’s just say, the numbers weren’t bad at all!
Loaded with confidence, the team started into the Firefox 76 development cycle. They quickly made much more progress with various elements, events, and properties. But most importantly, they developed a testing framework. This framework allows us to automatically test the attributes on the Mac platform for correctness. So for each element, we can query things such as the AXRole, AXSubRole, and other items that VoiceOver might ask for. If anything breaks, we now get immediate notification from our continuous integration cluster. Firefox 76 saw a total of 28 bug fixes, many of which contained more than one patch. Firefox 76 was released in May. If you are a Mac user, you can turn on VoiceOver and try out what we have so far.
In Firefox 77, which is in beta at the time this is written, work continued on more testing coverage. The team also added more correctness for elements and modernization of the Mac specific accessibility code. This helps us to comply with current standards on the MacOS platform.
At the time of this writing, we are in the Firefox 78 development cycle. So far, we have already tackled some more complex widgets. Also, we now have a much better understanding of how the Mac accessibility framework works. We will therefore spend some time refactoring the code to streamline how we do things internally to make it more future-proof. Thankfully, our test coverage is so good by now that the team feels confident to do the refactor. Any breakage will get flagged immediately.
The final piece for the first phase will be the Firefox 79 cycle, which will happen in June. What we will work on depends largely on how well this 78 cycle is going. We are using some collections of accessibility samples, such as a11ysupport.io, to manually test how well we’re doing and where we still have gaps.
And then, we will start with phase 2, which will be all about making Firefox on MacOS fit for use by heavy VoiceOver users, such as visually impaired users. This will offer them another choice of an accessible browser on the Mac giving them all the features that they might already know from Firefox on Windows or Linux. We aim to enable full text editing support and live regions. By the end of this project, the rotor (VoiceOver Modifier+U) will no longer come up empty. Consequently, the rotor gestures and quick navigation will work as you’d expect.
At some point later in this project, we will want your help in finding and fixing edge cases or user scenarios we didn’t anticipate. Right now, we are still very much aware that the support has gaps, and we’re working furiously on closing them. But as our Mac accessibility support matures, it will become important that you, who might have a Mac and be a VoiceOver user, try out what we have and give us feedback. We can test a lot of things, but we cannot test everything. We want to hear from you what you think, what bugs you might encounter, or what paper cuts make your lives difficult with Firefox on the Mac.
When the time comes, we will publish a call to action on this blog and in our Discourse forum. Until then, feel free to follow along our detailed progress. Links to all the open and fixed bugs are on our dedicated project wiki page. And if you’re curious and not afraid of cutting edge technology, by all means try it out for yourself. The first improvements are in either Nightly or Beta, or even on the current release.
Are you excited? We certainly are! And we always welcome your thoughts and comments.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。