Disabling accessibility on Windows breaks screen readers
We need to compile Tor Browser 8 with accessibility disabled as mingw-w64 does not work with it right now. See: https://bugzilla.mozilla.org/show_bug.cgi?id=1430149 for the Mozilla bug and https://sourceforge.net/p/mingw-w64/bugs/648/ for the underlying WIDL bug.
Maybe there is a workaround we can use? Or we could get the WIDL bug fixed?
Activity
I talked to a Windows user today on #tor who uses a screen reader and was reporting that Tor Browser 8 doesn't work for them. They reported that the Firefox ESR does work for them.
I guess it's because Firefox ESR is built with clang, and we want to build with mingw, for reproducible build purposes?
In any case, count another user affected by this bug.
It was not suggested before, just mentioning that this should not be activated per default (#26505 (moved)), even if it worked (and users should be informed more about the consequences):
Firefox Accessibility Service is a technology built into Firefox that provides 3rd party applications running on the same device the ability to inspect, monitor, visualize, and alter web page content hosted within Firefox. https://support.mozilla.org/en-US/kb/accessibility-services
Replying to arma:
I talked to a Windows user today on #tor who uses a screen reader and was reporting that Tor Browser 8 doesn't work for them. They reported that the Firefox ESR does work for them.
I guess it's because Firefox ESR is built with clang, and we want to build with mingw, for reproducible build purposes?
Yes and no. The reason for the bug is that mingw-w64 does not support the new accessibility related code in Firefox (widl is the problem here, to be more exact) regardless if you are using clang with it (which we will be doing soonish) or GCC (which we are doing now) as the compiler. mingw-w64 "just" provides the Windows headers etc.
-
Replying to arma:
We had another person on #tor today asking about this.
I wonder if we can use our twitter power to draw attention to the widl bug?
We could do that. My idea was to ask around at a less noisy scale first to find someone who could help us with fixing this bug. But I guess we could to both in parallel.
#27862 (moved) is a duplicate.
Trac:
Cc: jacek to jacek, Rastislav, Kissgot an answer by jacekc on #mingw-w64 today
- try to avoid using the -acf option
- use an .idl input file instead
- we should look at widl bugs in wine
-
Could anyone being affected by this bug test the custom bundle below? It should have the fixes Jacek wrote for https://bugzilla.mozilla.org/show_bug.cgi?id=1430149 and is not exploding on my Windows 7 testing machine:
https://people.torproject.org/~gk/testbuilds/torbrowser-install-win64-tbb-nightly_27503_en-US.exe https://people.torproject.org/~gk/testbuilds/torbrowser-install-win64-tbb-nightly_27503_en-US.exe.asc
Note: you might have trouble connecting to the Tor network when starting up Tor Browser the first time. In that case, closing Tor Browser and starting it again should fix that (I am currently looking into providing a bug report for that behavior for the network folks).
Trac:
Status: new to needs_information 
Thank you for working on this! Tor button and browser controls are now accessible again. However, it appears that web content is not being exposed to the screen reader, so where the website should be rendered, there's just something called "unknown". I'm not sure what the cause of that is, but it is across all sites. I tested with about:tor, youtube and wikipedia. I tested with Windows 7 using NVDA as a screen reader. To summarise, screen reader users cannot interact with websites, but everything that is not web content works.
Trac:
Username: onionsoup-
Replying to onionsoup:
Thank you for working on this! Tor button and browser controls are now accessible again. However, it appears that web content is not being exposed to the screen reader, so where the website should be rendered, there's just something called "unknown". I'm not sure what the cause of that is, but it is across all sites. I tested with about:tor, youtube and wikipedia. I tested with Windows 7 using NVDA as a screen reader. To summarise, screen reader users cannot interact with websites, but everything that is not web content works.
Thanks for the feedback. I guess the big question is "Is that caused by a missing accessibility patch OR by some other patches we ship"? I guess I compile a vanilla Firefox with the accessibility patches and we'll find out...
Trac:
Owner: tbb-team to gk
Keywords: N/A deleted, TorBrowserTeam201811, GeorgKoppen201811 added
Status: needs_information to assigned -
onionsoup (or anybody else): can you test the following zipped Firefox:
https://people.torproject.org/~gk/testbuilds/27503_test.zip https://people.torproject.org/~gk/testbuilds/27503_test.zip.asc
?
On my Windows machine double-clicking on the .zip file in the explorer makes a Browser directory available. Then I dragged that one on the desktop and double-clicked on it. Double-clicking then on the
firefox.exeshould start Firefox. It's an ESR 60 Firefox just with Jacek's accessibility patches (without any we use for Tor Browser).Does that one work for anyone with accessibility support (i.e. both chrome and content are rendering properly)?
Trac:
Status: assigned to needs_information -
Replying to onionsoup:
Hi Web content is still not rendering properly for me with the clean Firefox, it behaves like the Tor Browser build. I run NVDA for screen reader on Windows 7.
Great, then let's dig deeper. One guess I have is that the problem is multi-process (e10s)/sandboxing related. Could you disable e10s by flipping
browser.tabs.remote.autostarttofalsein yourabout:configand restart both Tor Browser and the Firefox I gave you? Does that change things?(And no worries about not being well-versed in terminology. :) Just ask if I speak too jargon-y)
