Re: Mandatory advisory: when Firefox 57 lands, do NOT check "prevent accessibility services" checkbox


Hi everyone,

It is there as part of a foundation for a very huge work that’ll fundamentally change how screen readers think about communicating with web browsers. The story goes like this (and if you want, please do pass this onto others):

In the early days of web accessibility for screen reader users (back when there was no UIA, no visible standards organizations for accessibility, etc.), the only effective way for screen readers to present web content was sending out “scouts” who’ll bring back envelopes containing the entire HTML code for a webpage. These scouts would use a highway called “code injection” to speed up their travel. Once the envelopes are opened, screen readers will thread the contents together into a “navigable document”. In other words, a web document was constructed twice for you: once on the web browser window, and rendered by your screen reader a second time on top of that.

The advantage of this method is that screen readers knew where things were, because they had a “map” in front of them that pointed to where the next given element was, listing postings with routes to links on the document and so on. This meant navigating around a page was simple and very fast. However, this opened a chasm: if a screen reader was walking along a path and was “kidnapped” one day, the “kidnapper” would force the screen reader to give commands to “scouts”, whose only job was to fetch something on behalf of their leader.

Fast forward almost two decades, and current screen reader and web browser landscape is filled with those who travel by the code injection highway, and those who send and receive “letters” and “beacons”. The former is the case with Internet Explorer and older versions of Firefox, and the latter is for Microsoft Edge. These days, more web browsers are asking screen readers to send more letters than scouts, which has huge implications for users and developers.

Technical (if you want, please do send this out to others): first, some definitions:

  • Scout: code injection routines, typically a DLL from a screen reader that inserts a piece of screen reader code inside a web browser to construct webpages.
  • Code injection: programs inserting code into each other’s workspaces with or without others (including operating systems) noticing it.
  • Workspace: memory used by programs. Typically called “address space”.
  • Letters: API and other well-documented routines or contracts.
  • Beacons: instructions from web browsers for screen readers, especially referring to document movement routines.

With this in mind, the geeky version is as follows:

When MSAA first came out in late 1990’s, it was designed to let screen readers receive information about program controls, mostly static ones. Hence, it wasn’t really designed for places such as web browsers where document content can change without notice. For this case, screen readers will inject part of their code (typically in the form of a DLL) inside a web browser process to monitor events such as when a website is being loaded. Once the DLL realizes that you’ve navigated to a new page, it’ll fetch the entire HTML code for that page and send it back to main screen reader code. This main code, typically in the form of a document formatting library, will construct (technically, reconstruct) a webpage according to rules it knows best.

But imagine a malware comes along and takes over a screen reader (which can actually happen if a malware holds special privileges and exploits a weakness in screen readers). Unless the malware doesn’t know about it, it now has a way to inject itself into other processes (not just web browsers) in the form of a screen reader DLL or redirecting the DLL’s operation to the malware module. This is made more possible by the fact that screen readers are deemed TRUSTED by operating systems, which means screen readers can perform tasks other programs are envious of (including starting early). This is perhaps one of the most critical security holes that can be opened by anyone (besides taking over an operating system routine or an important DLL or a driver). In theory, you can get around this by starting a pristine (clean) screen reader, but even that can be attacked if the malware wishes to do so.

These days, web browsers are taking the initiative to close the code injection gateway. An early start was some old browsers, including Internet Explorer 7, but even then, screen readers have found a way to open the gateway. Due to security concerns, Microsoft Edge will not allow code injection; instead, screen readers are asked to use UIA to communicate with Edge and to yield document navigation routines to Edge itself. Same will happen with a future version of Firefox, but we don’t know when that’ll happen. NV Access is taking this possibility seriously and are actively working with Mozilla to rectify this as soon as possible (also, don’t forget that a former NVDA developer is now working for Mozilla Foundation, and NV Access and Mozilla have a good relationship regarding mutual support, especially when it comes to web standards and accessibility).






From: [] On Behalf Of Gene New Zealand
Sent: Wednesday, October 25, 2017 9:23 PM
Subject: Re: [nvda] Mandatory advisory: when Firefox 57 lands, do NOT check "prevent accessibility services" checkbox


Hi Joseph


Why would they put in such a setting?


I am guessing if checked it would speed up the browser for the sighted but be use less if checked for us.


Gene nz



On 10/26/2017 4:50 PM, Joseph Lee wrote:


You need to keep this checkbox unchecked. And I haven’t found an easy way to reverse this at the moment (Alt+T, O won’t work here).



From: [] On Behalf Of Gene
Sent: Wednesday, October 25, 2017 8:43 PM
Subject: Re: [nvda] Mandatory advisory: when Firefox 57 lands, do NOT check "prevent accessibility services" checkbox


How do you disable it if you can't work with menus and all the other structures you discussed?  Can you use the command alt t then o to get into the options dialog and can it be worked with?  Are you saying that we need to check this check box in the options dialog?



----- Original Message -----

From: Joseph Lee

Sent: Wednesday, October 25, 2017 10:34 PM

Subject: [nvda] Mandatory advisory: when Firefox 57 lands, do NOT check "prevent accessibility services" checkbox


Hi all,

Well, the tests ended so fast…


The following is a community-based advisory that is mandatory for you all to listen up and follow:


If Firefox 57 is set to prevent accessibility services, you won’t be able to use Firefox at all. The following NVDA features will fail:


  • Browse mode and focus mode
  • Web browser features such as elements list and first letter navigation commands
  • Object navigation and review modes
  • OCR functionality


ADVISORY: when Firefox 57 lands, DO NOT check “prevent accessibility services” checkbox in Firefox options. By default, this checkbox is unchecked.


Technical: NVDA uses mixture of code injection and accessibility API routines to access Firefox. However, when accessibility services are turned off, Firefox enters a mode where the UI and browse mode functionality will not work with screen readers. This means no announcements regarding menu bar, no toolbar navigation feedback, no feedback when you type into address bar, no browse mode and so on. The only way to restore it so far is disabling the checkbox described above until NVDA finds a way to interact with Firefox Quantum.






Check out my website for NVDA tutorials and other blindness related material at Regardless of where you are in New Zealand if you are near one of the APNK sites you can use a copy of the NVDA screen reader on one of their computers. To find out which locations (or location) is near to you please visit (Aotearoa People's Network Kaharoa). To find an NVDA certified expert near you, please visit the following link The certification page contains the official list of NVDA certified individuals from around the world, who have sat and successfully passed the NVDA expert exam.

Join to automatically receive all group messages.