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


Probably not publicly that doesn't mean its not been tried.

On 26/10/2017 8:58 p.m., Brian's Mail list account via Groups.Io wrote:
So then are they not jumping the gun rather in putting out version57 now with much poorer performance via the old method, but still not come up with a workable alternative for screenreaders? Also is there any proof out there that screenreader type code injection has been successfully used to gain access to an operating system or browser. I read access stuff widely and I've not heard of it.
I guess what I'm saying is this. Is all this just paranoia or has it become a problem. If it has, then I'd have thought this issue would have been tackled back in the windows 7 days.

My feeling on this is that there is an element of justification of existence and one upmanship about all this, and in the middle is the customer who is mostly the weakest link in the security screen of software in my experience.
Sent via blueyonder.
Please address personal email to:-, putting 'Brian Gaff'
in the display name field.
----- Original Message ----- From: "Joseph Lee" <>
To: <>
Sent: Thursday, October 26, 2017 5:55 AM
Subject: Re: [nvda] 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

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

* 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
* 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
* 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

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).


* Zehe, Marco. Rethinking Web Accessibility on Windows, Marco's
Accessibility Blog, September 29, 2017. URL:



From: [] On Behalf Of Gene New
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
To: <>
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

To: <>

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

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

Join to automatically receive all group messages.