Firefox 57 from an NVDA user’s perspective

Firefox 57, also known as Firefox Quantum, will be released on November 14. It will bring some significant changes to the Firefox rendering engine to improve performance and open the door for more new features in the future. Here is what you need to know if you are a user of the NVDA screen reader.

For users of the NVDA screen reader, some of these changes may initially seem like a step backward. To make the accessibility features work with the new architecture, we had to make some significant changes which will initially feel less performant than before. Especially complex pages and web applications such as Facebook or Gmail will feel slower to NVDA users in this Firefox release.

Improvements in the pipeline

Fortunately, NVDA users will only have to put up with these slowdowns for one Firefox release. Firefox 58, which will move to beta the moment Firefox 57 is being released, will already improve performance so significantly that most smaller pages will feel as snappy as before, larger pages will take a lot less time to be loaded into NVDA’s browse mode buffer, and web applications such as Gmail or Facebook will feel more fluid.

And we’re not stopping there. In Firefox Nightly, then on version 59, performance improvements will continue, and more big pages and web applications should return to a normal working speed with NVDA.

I need full speed

If you do require Firefox to perform as fast as before and cannot or do not want to wait until the above mentioned performance improvements arrive on your machine, you have the option to switch to the Extended Support Release (ESR), which is on version 52 and will receive security fixes until long into 2018.

However, we encourage you to stick with us on the current release if you possibly can. Your findings, if you choose to report them to us, will greatly help us improve Firefox further even faster, because even we might not think of all the scenarios that might be day to day sites for you.

I want to stick with you. How can I help?

That’s great! If you encounter any big problems, like pages that take unusually long to load, we want to know about them. We already know that long Wikipedia articles such as the one about World War I will take about 12 seconds to load on an average Windows 10 machine and a current NVDA release. In Firefox 58 beta, we will have brought this down to less than 8 seconds already, and the goal is to bring that time down even further. So if you really want to help, you can choose to upgrade to our beta channel and re-test the problem you encountered there. If it is already improved, you can be certain we’re on top of the underlying problem. If not, we definitely want to know where you found the problem and what steps led to it.

And if you really want to be on the bleeding edge, getting the latest fixes literally hours or days after they landed in our source code, you can choose to update to our Firefox Nightly channel, and get new builds of Firefox twice a day. There, if you encounter problems like long lags, or even crashes, they will be very closely tied to what we were recently working on, and we will be able to resolve the problems quickly, before they even hit the next beta cycle.

In conclusion

We know we’re asking a lot of you since you’ve always had a very fast and efficient browsing experience when you used Firefox in combination with NVDA. And we are truly sorry that we’ll have to temporarily slip here. But rest assured that we’re working hard with the full team to kick Firefox back into gear so that each followup release will bring us back closer to where we were before 57, plus the added benefits Quantum brings for all users.

More information

23 thoughts on “Firefox 57 from an NVDA user’s perspective”

  1. Marco,

    I know that this is not the blog objective but I am extremely curious to know how do you plan to take performance back in a some what technical way … because the way I understand it screen readers are slow on ff 57 because the browser now uses multi process rendering and thus can not easily feed the screen reader virtual buffer in a progressive way like it did before, making the screen reader wait for the whole thing to be complete before the buffer is finally feed.
    This plus the fact, and I am not completely sure, that injection is no longer allowed to happen making ipc the only alternative and slowingg the comunication between these two parts.

    This being what happens, I can not see how you would increase back thhe performance unless virtual buffers are no longer used but I don’t think this will happen soon. Further more, this would be a NVDA release not a FireFox release. How are you going to take performance bback to the expected levels on this new architecture? Curious …

    1. DLL injection is currently still allowed in the main process, which we call the browser or browser chrome process, having nothing to do with the browser of the same name. What we do not allow, is screen readers to inject into the content processes. That’s why, in 57, things are so much slower indeed. However, there are things that we as a browser vendor can do to mitigate at least some of this problem. And the results are looking very good. This has to do with caching, advanced Windows COM stuff, and being smart about what screen readers usually want the most. As hinted in the post, initial work lands in 58, and this already speeds up a lot of things. Furthermore, we’ve provisioned for an optimization that hopefully will make it into an NVDA release soon that will speed certain things up from their end, too. The pull request on that is awaiting review and merging as we speak. So, stay tuned! 🙂

      As for the future, I’d like to refer you to an earlier post on this blog titled The Future of Web Accessibility on Windows, where I lay out some thoughts on future changes to browsers and screen readers to give the Windows world a more future-proof approach than virtual buffers. But first, we need to get the basics in place, and that also means not regressing users too much if we possibly can.

      1. Thank you for your clarifications.

        Being a c++ programmer (although not a browser dev) I am interested in following this topic. If there is documentation or discussions about it please do point where those would

        About your post of the future of web accessibility on Windows, let’s see how things go. I tend to believe that some things a virtual buffer can do may enhance productivity in ways that no virtual buffer solutions can not.

        VoiceOver provides fast navigation by elements already for native applications. TalkBack is going the same rout. I think that this is a tendence that should stay.

        1. I am sorry the comment was cut at the wrong place.

          For example, some pages will still be pages, not web apps. Take a look at blogs, tutorials, electronic books and foruns ….. these will be text based, no mather what. And there is no better thing to deal witht hat than a virtual cursor (conceptually, not talking about implementations here ) … or one might try to read a text bbook on the web using the review cursor, but this is not going to be a good experience.

          On Mac OS before El Cappitan (if I remember correctly ) access these kinds of content was a very frustrating way. It got some what better when we started to be able to arrow through the page. So I would say I am a some what supporter of the virtual cursor concept, although not necessarily of the current implementations. Curious to hear your thoughts by the way.

  2. I am probably not staying with the new Firefox. It will not let me use the Navigational Sounds extension which I have come to depend on for telling me when a page is generating activity. Unless some form of this extension appears either within Firefox or as a new extension, I may have to migrate to something else with navigational sounds.

  3. is there any site or bugzilla bug I can get specific metrics for various screen readers? I’m doing a blog about this, at a much deeper technical level and want to have citations for some of the claims I’ve seen floating around including the improvements already happening.

  4. Why not disable multiprocessor through the setting browser.tabs.remote.autostart.2 to false?
    It really helped me to improve the responsiveness of NVDA in Firefox 57, and other screenreaders have to work.

  5. Thanks for the information. I’ve since tried FF 57 (Quantum) with NVDA (for A11y audits). Although it works OK on some pages, it’s so slow on some others that I had to “kill” the Firefox process (after killing some other processes first, so that I’d be able to do so).

  6. Since I’d read that Firefox 57’s multiprocessing was (at least partly) to blame for this problem, I’d tried to temporarily turn multiprocessing off by setting all entries starting with “browser.tabs.remote.autostart” in Firefox’s about:config to false.

    I had 2 such entries:
    • browser.tabs.remote.autostart which was already false
    • browser.tabs.remote.autostart2 which was true

    Setting them both to false did seem to help.

    What do others of you see if you make this change?


  7. Hello, thanks for this article. I have a disability and use accessibility software, and this info helped clear up panic and confusion that set in when I updated from ESR to version 57 and all of a sudden my browser didn’t work (just submitting this comment has taken an extraordinary amount of time and effort). A few questions:

    1. Are you aware of other people With accessibility software other than screen readers having trouble with the new version? I use Dragon NaturallySpeaking (a speech recognition software) along with a program called Voice Computer that enhances DNS’s ability to interface with different programs.

    2. Is there a simpler way for folks with accessibility needs to answer your call, try out 58 or nightly, and submit feedback? I LOVE Firefox and want to help advance accessibility , but when I looked at the bugzilla page, I was overwhelmed with Everything I would have to read, learn, and do to submit a bug (especially the comments suggest that new users seek out help from more experienced users). My suggestion is that if you truly want people with disabilities to contribute to the development of Mozilla, it would be helpful to make our participation as clear and simple as possible. Given that my browser is currently nonfunctional, making the investment required to contribute info on bugs is not feasible.

    Thanks, and I hope I can get more involved!

  8. I was looking for a special information. Wasn’t there another article describing the new interaction concept for extensions from a blind user’s perspective? The major problem for me with Firefox Quantum and latter, the addons are web extensions now, thus, I still didn’t find a good and quick way to interact with their corresponding controls. As for now, I’ve switched off all addons, but this could only be a momentary workarround. I really would apreciate to get my most essential things, as NoScript and anti-tracking, back and working as quickly as possible. Maybe you can help me with further information.

    1. You can use NVDA‘s quick navigation to interact with the toolbar and find the Add-On‘s button. The UI then opens in a web document that, now in Firefox 58, is also again reliably accessible. JAWS has something similar called the touch cursor, but JAWS and Firefox 58 are still not recommended to be used together. So, you might want to read up on NVDA‘s object navigator concept and use that for now.

      1. Thanks Marco. I already use NVDA as my main screenreader. It never let me overthink that decision except in rare special cases with office and development software. In short, JAWS can do better with Excel and MS Visual Studio. However, in general NVDA is so much more stable and on the edge from a technical point of view.

        That’s for the evangelism. 🙂 How can I find the toolbar using quicknav keys? Isn’t the toolbar outside the virtual document and for that reason only reachable with tab jumping? I’ll give it a try of course. Would be great if it needs only a bit of re-learning concepts to solve my issue. Honestly, I will miss the context menus at first.

        1. You can, for example, press CTRL+L to go to the address field, go to the parent, then navigate to the next sibling until you find the buttons. Then, use the Activate Navigator Item to execute a button, simulate a mouse click, or whatever is appropriate for that control. Works great for me. We are currently looking into a better solution, but that is still a bit away.

What are your thoughts?