Closed Bug 1095971 Opened 10 years ago Closed 10 years ago

jaws and NVDA screen reader don't read anything in screen review mode

Categories

(Firefox :: Disability Access, defect)

Product:
Firefox
Component:
Disability Access
Version:
33 Branch
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: whocrazy, Unassigned)

References

Details

(Keywords: regression) 

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:33.0) Gecko/20100101 Firefox/33.0
Build ID: 20141105223254

Steps to reproduce:

1. Install NVDA or jaws
2. Install firefox version 33.0 or above
3, in NVDA, press insert key 7 on the numpad several times until you hear it say screen review, 
4. Use the numpad keys to try to read what is there.



Actual results:

all you hear is blank, blank, blank, as if the entire screen has nothing on it.


Expected results:

you should have been able to hear the various dialog and parts of the web page and menus being read
Status: UNCONFIRMED → NEW
Component: Untriaged → Disability Access
Ever confirmed: true
Keywords: regressionwindow-wanted
Can anyone see a possible culprit? I'm afraid I can't:
https://hg.mozilla.org/mozilla-central/shortlog/183993
brosnan on IRC linked to http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=cb9f34f73ebe&tochange=9d8d16695f6a
and suggests bug 971054 might be the culprit.
I also noticed bug 899785 is listed which sets

about:config?filter=layers.offmainthreadcomposition.enabled

to true specifically for Windows XP.
Stavros can you please test setting the above pref to false to see if doing that allows screen review mode to work in Firefox 33?
Flags: needinfo?(whocrazy)
Got this response on IRC:
"Yes, setting layers.offmainthreadcomposition.enabled to false fixes whatever it is that stops Jaws and NVDA from reading the screen properly."

So setting this as blocking bug 899785.
Blocks: 899785
Flags: needinfo?(whocrazy)
OMTC became the default in 33 - and fully disabling it is (so far as I know) no longer well-tested (or perhaps even fully supported).  CC-ing a bunch of gfx folks; the "right" solution would be to find a way to adapt NVDA to OMTC.

Marco, any suggestions until a fix can be found?

How widespread is this problem?

Milan, can you make sure the right people are looking at this?  Thanks
Severity: normal → major
Flags: needinfo?(mzehe)
Flags: needinfo?(milan)
(In reply to Randell Jesup [:jesup] from comment #5)
> How widespread is this problem?
From bug 1043387 comment 2 and 3 the outlook isn't good:
> (James Teh): "Display hooking (which is what NVDA screen review uses) won't work with more modern ways of drawing to the screen; i.e. anything other than GDI."
> (Marco Zehe): "we definitely will not do anything to get the old-style screen scrapers to work with TB or Firefox any more"
It's worth noting that while this is a "regression", screen review really isn't necessary in Firefox. Because of Firefox's rich support for accessibility APIs, there are other ways to access it which provide far more reliable and useful information. It certainly shouldn't have ever been a major part of how any NVDA user used Firefox.

For what it's worth, we're certainly not willing to put any time into restoring this functionality for NVDA + Firefox.
I just tried to read the status bar using NVDA's object navigation, and I couldn't do it.  It's the fake one you get when you install the status4evar addon. Currently, the only way to read it is to fall back onto the old screen review method and disable that option in about:config.
Jaws as far as I am aware does not use object navigation, so if you leave firefox to use the new screen drawing method, you can't use jaws to read anything except the window title.
(In reply to Stavros Bolonakis from comment #8)
> I just tried to read the status bar using NVDA's object navigation, and I
> couldn't do it.  It's the fake one you get when you install the status4evar
> addon.
Anything that is exposed by Firefox should be accessible via object navigation, though it may be in a weird place and you may have to disable simple review if it's not exposed correctly. That's most likely something that could be improved in the add-on.
(In reply to James Teh [:Jamie] from comment #9)
> if it's not exposed correctly. That's most likely something
> that could be improved in the add-on.
It seems rather difficult to find specific documentation for add-on developers to help them make things exposed correctly in their extensions. Could you please link to the correct documentation or file a bug to create it/make it easier to find?

There are no results when clicking "documentation" at https://addons.mozilla.org/en-US/developers/search?q=accessibility

There is no section on accessibility at https://developer.mozilla.org/en-US/Add-ons/SDK/Tutorials#Development_techniques

When I went looking with more time and dedication I found something about access keys at
https://developer.mozilla.org/en-US/Add-ons/Overlay_Extensions/XUL_School/The_Essentials_of_an_Extension#Locale
and on the third page of
https://developer.mozilla.org/en-US/docs/tag/Accessibility
I found
https://developer.mozilla.org/en-US/docs/XUL_accessibility_guidelines

Should this responsibility have even been moved from Firefox developers to every extension author?
(In reply to Mardeg from comment #10)
> It seems rather difficult to find specific documentation for add-on
> developers to help them make things exposed correctly in their extensions.
Note that I said most likely. I haven't actually investigated this particular case, so I don't know anything for certain. The point here is that screen review is not the correct solution. There may be accessibility issues that need to be fixed in Firefox or add-ons. There may be issues that need to be fixed in NVDA. Either way, screen review via GDI hooking is not the correct solution going forward.

> Should this responsibility have even been moved from Firefox developers to
> every extension author?
I know very little about add-on development, but as I understand it, you're basically dealing with XUL and HTML as far as UI is concerned. If you use standard XUL or HTML widgets, they should be accessible. If you use custom widgets, you'll need to provide some accessibility information yourself using ARIA.
I am strongly inclined to mark this bug WONTFIX or INVALID. JAWS cursor mode hasn't worked reliably since Firefox 4 days, and it has clearly been stated on several occasions that this functionality will not be restored, or it technically cannot even be restored nowadays any more. Moreover, Windows 8 basically disabled most, if not all, traditional screen scraping by JAWS or Window-Eyes anyway, that's why JAWS now has a Touch Cursor. And as NVDA developer Jamie said above, NV Access won't put any resources into providing screen review support for Firefox, and frankly, they shouldn't waste their time on this, so I fully agree with Jamie.

As for reliably reading the status bar: Firefox exposes a status bar accessible that can be found by MSAA/IAccessible2, so the JAWS ReadStatusBar script can be adjusted to not rely on the old-fashioned screen scraping mechanism. I suggest that interested parties work with Freedom Scientific that they get this implemented properly.
Flags: needinfo?(mzehe)
Surely you can't rely on every webmaster or addon developer knowing everything about firefox accessibility?
I think it's good to have screen review mode to fall back on sometimes, when you find a web page that isn't very accessible.  for jaws users, altering that option in about:config is a quick fix while we wait for freedom scientific to get their act together
(In reply to Stavros Bolonakis from comment #13)
> Surely you can't rely on every webmaster or addon developer knowing
> everything about firefox accessibility?
They don't have to know everything. They have to know enough to make non-standard widgets accessible. This is not unique to Firefox; this is true for any developer using any platform.

> I think it's good to have screen review mode to fall back on sometimes, when
> you find a web page that isn't very accessible.
At least in Firefox with NVDA, there shouldn't be anything you can access with screen review that you can't access via browse mode or, outside of a document, object navigation. Let me put it this way: I cannot think of a *single* case where this isn't/hasn't been true, even if one has to do some convoluted object navigation to get to it. I can't speak for JAWS.
Filed bug 1096227 for the JAWS case.
I'm inclined to agree with comment 12 (and comment 7). Comment 10 probably has some good spin off doc bugs. Alexander can you check with Brett about this bug and any plans?
Flags: needinfo?(surkov.alexander)
Is this Windows XP only, or do we have a problem on other Windows versions as well?  What's about:config graphics section say for the machine that does reproduce the problem?
Flags: needinfo?(milan)
(In reply to David Bolter [:davidb] from comment #16)
> I'm inclined to agree with comment 12 (and comment 7). Comment 10 probably
> has some good spin off doc bugs. Alexander can you check with Brett about
> this bug and any plans?

FS doesn't have plans to work on it. I guess we can close it as wontfix.
Status: NEW → RESOLVED
Closed: 10 years ago
Flags: needinfo?(surkov.alexander)
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.