Cem Kesemen

Firefox is getting a new accessibility inspector.

This tweet was the first time I -and probably anyone outside of Mozilla- had heard of the new accessibility inspector coming to Firefox.

Last night, I got to watch Marco demonstrate the new feature in an #a11yTO meetup in Mozilla’s Toronto office.

And I have to say, it looks (and sounds) fantastic.

The Inspector

A disclaimer first: I found an empty spot at the last minute, so I missed the first 10 minutes. I arrived just as Marco said “I intentionally left the labels missing for this demo”, explaining a login form with email and password fields.

The inspector looks similar to the web inspector that is already available. It has its own menu item in the contextual menu, and brings up a panel with the new features inside it.

It basically exposes what screen readers see. It shows the entire accessibility tree on one side, and on the other side it shows the selected items properties. It also returns additional information like button types (reset, submit, etc.) and some CSS attributes as well, such as display values. It allows developers to discover how a screen reader perceives a website.

Not a Compliance Tool

Unlike aXe or similar tools, this new inspector is not meant to be a compliance checker. Where aXe acts more like a linter, Mozilla’s tool acts like a debugger. They are complementary, if anything.

This tool is meant to give a better understanding of what screen readers see when you apply WCAG techniques, such as seeing what applying a for attribute to a label does. It helps catch missing attributes like labels for input fields, and see how screen readers react to changes in realtime. Tools like aXe check for other things that the Accessibility Inspector does not, like color contrasts and missing main parts.

Reading Faster

James Teh, who is an Accessibility Engineer at Mozilla, was the other speaker at the event. He talked about the improvements in user experience regarding accessibility, and Mozilla’s future plans.

The way screen readers currently work, as he described it, they slurp up everything a browser offers, and parse the whole document. Then they are tasked with keeping up with the changes, which is also taxing.

When the next generation Firefox Quantum launched with v57 in November 2017, a lot changed with how the browser interacts with the OS. Before then, screen readers could just inject themselves into the Firefox instance, and get everything they need; the new security features meant more abstraction, and more calls, to be able to get the necessary information.

Their benhcmark, a Wikipedia page for World War 1, took 13 seconds to render under Quantum.

That is why JAWS and NVDA users were advised to stay on Firefox v52, the Extended Support Release version of the pre-Quantum releases.

However, the v60 update (which is currently in Nightly) speeds things up quite a bit, and can help NVDA render the page in about 2.2 seconds. So users of assistive technologies will be able to update to the modern version of Firefox soon enough.

Innovating on the “Full Stack”

Even though there is a huge improvement in performance with the latest update, “this is not sustainable” says James, “the web is not getting any smaller”. As web apps get more complicated, new methods are required to keep screen readers up to date and performant.

As both NVDA and Firefox are open source, they can work together and experiment to find new ways to improve how accessibility API’s work. So instead of slurping up the whole tree, a screen reader can grab the necessary parts or just the changes as needed, resulting in more dynamic and instantaneous experiences. It would also help solve the more cumbersome interaction patterns, such as autocompletes, by providing additional interaction methods.

Near Future & Other Accessibility Features

James and Marco have said that other accessibility improvements were also in the works.

JavaScript console is said to be getting accessibility support so disabled developers can use the feature as well.

Keyboard accessibility is being worked on, especially to help guide new Chrome-like add-ons and extensions in Quantum, so that NVDA’s object navigator is not needed to navigate the toolbars.

Color filtering is another new feature that is currently in the works, so that people with color blindness disabilities can differentiate items more easily. (iOS has a similar feature, and it’s great to see that coming to desktop browsers.)

Additional accessibility improvements for Firefox on Android are also in the pipeline, starting with the availability of Web Speech API in the short term.

Release Date

Marco did not want to comment on the timeline for the new features release, but he thinks it might be available in v61, with Nightly releases due sometime in April.

On privacy and accessibility

During Q&A, a question was asked about exposing assistive technologies used to the website visited, so that context switching might be used, as well as information on percentage of visitors using assistive technologies can be obtained, and management can be persuaded to follow up on certain accessibility needs.

Even as the question was being asked, I though to myself, “that would be one hell of a way to track people”, because if you give evil ad companies any feature that has any potential to differentiate users, they will find a way to abuse it.

Marco thought the same way, and mentioned that he had written his thoughts about it in a post on his blog, titled “Why screen reader detection on the web is a bad thing”.

He also mentioned that instead of making different versions of websites for different people, an effort should be made the current versions work as intended.

In this day and age, it is not that hard to create accessible websites that look and perform good while also adhering to all the accessibility requirements. It is actually harder to create non-accessible websites than it is to make WCAG-conformant ones, and if you stick to standards, you’ll be on the right side of the web.