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


Hmmm well that kind a makes some sence.

The way screen readers read does possibly slow things down and it does open a security hole.

So these days access routeens as they are are floored.

The only issue I have is why we didn't close uia earlier.

The other issue or question I have is how to have a reliable uia especially with the issues it seems to have on a day to day basus especially with the ms update cycle as it is, its getting harder and harder to stay with that cycle and screen readers just like programs that are used seem to be taking the brunt.

It would be like every os update you would need a new video card or something like it.

On 26/10/2017 5:55 p.m., Joseph Lee wrote:
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.



Join to automatically receive all group messages.