Force browse mode on demand for broken ARIA applications #2023

Closed
nvaccessAuto opened this Issue Jan 3, 2012 · 22 comments

2 participants

@nvaccessAuto

Reported by parham on 2012-01-03 07:47
The application mode (my own on-the-spot term for the mode NVDA goes into when encountering elements with the aria role of application) should be a toggle, meaning that I can disable it if I want. Right now, pressing NVDA+ctrl+space takes me out of that mode (E.G. in TinyMCE editor), but pressing down arrow puts me back to that mode. If I need to access the controls outside the editor, I have to repeatedly press the down arrow, nvda+ctrl+ctrl+space, and so forth. Most of these editors also make the "tab" key output a tab character, so tabbing passed this editors is not an option.

@nvaccessAuto

Comment 1 by jteh on 2012-01-03 11:09
As far as NVDA is concerned, this is not a "mode". We don't use browse mode for anything other than documents. Even if we could do what you suggest, there would be serious problems and confusion when there are documents inside applications, etc.

You can always use object navigation to move around and focus elsewhere, whether in browse mode or otherwise.
Changes:
Added labels: wontfix
State: closed

@nvaccessAuto

Comment 2 by camlorn on 2013-02-18 18:32
Well, I'm going to have to chime in here. The issue is this. Many, and I do mean many, web developers who want to support accessibility haven't got a clue, and few actually test accessibility. i don't know if my specific case is an aria role of application, the one I just encountered that made me find this ticket, but I have had problems in the past. When Aria roll of application is used improperly, or even at all at least in my experience, the web site is typically inaccessible until it is turned off. Jaws makes this a mode, though toggling it (at least as of jaws 13) is a bit of a hack, involving reenabling the virtual cursor. I literally can't think of any web site that uses Application role and is accessible with any screen reader supporting it. I'm sure it exists somewhere, but I have yet to see it.
it needs to be possible to make NVDA ignore this. Maybe it isn't toggling, a mode but an option to ignore this needs to be present, at least until support for Aria is much, much better. Aria is a good thing, it really is, but only when used properly, and many web sites aren't going to do that. The issue is: Aria is the new "big thing", for accessibility, and people are jumping on that bandwagon; people without the knowledge to actually use it properly or even test. In many cases, the people doing it don't even have the desire to test.
My specific case was google drive, just 5 minutes ago. The sharing dialog is completely inaccessible in NVDA. It may not be using role of application, but it made me find this ticket, as NVDA isn't the only screen reader that needs this functionality, and it was exhibiting the same problems as web sites that use Application Role. If there's interest, I'll go confirm if google drive specifically is using Aria roles of application, but it is a web site that claims to be accessible and has screen-reader specific documentation. I'm almost certain it is. Also, I know for a fact that blackboard, as in the blackboard used by many, many universities, just updated the editors there to use role of application, as that is one of the places I've encounterd this issue.
One final thought: most users won't know what the problem is and will just assume that the web site isn't accessible. Adding an option to fix this won't necessarily magically make them aware that this might be the problem, but it will at least allow others to tell them to go check a box when using such a web site. For me, as it stands, i'll have to go back to jaws for these cases--there really is no choice.

@nvaccessAuto

Comment 3 by pitermach on 2013-02-18 20:02
Another use case, the discuss comment system (appologies for the spelling). It used to work fine, but recently they updated it to use roll application very inproperly. While before it seemd to only exist for the comment editor, now it covers the entire frame. At this point you can only tab to links for the different authors, and reading text with object navigation in this case isn't at all plesent, or newbie friendly for that matter. If you want to see it in action, one site that uses it is iDownload blog.

@nvaccessAuto

Comment 4 by pitermach on 2013-02-18 20:02
Changes:
Removed labels: wontfix
State: reopened

@nvaccessAuto

Comment 5 by erion on 2013-02-18 20:28
I second this request.
Hungarian universities now seem to favour a specific web application suite that is designed to access university-related features online. Unfortunately, because of its poor design, no screen reader is able to access its content properly.
True, NVDA should support technologies that are designed to increase accessibility, however, as said before, those developers who follow set accessibility rules are regarded as an exception. Despite what and how we think, this is the case we have to deal with for now.
Developers adding accessibility features due to a request are even more rare, there are cases when people are begging for accessibility for at least 10 years but still nothing happened.
Having a toggle ignoring this role, even though on some pages it could lead to unseen problems, would be an immense help.

@nvaccessAuto

Comment 6 by jteh on 2013-02-18 22:16
Ideally, this needs to be a toggle to force browse mode on a case by case basis. A configuration option would break the application role for sites where it is actually used properly. I haven't yet figured out how to do this elegantly in NVDA, since NVDA literally doesn't see these as web documents at all.
Changes:
Changed title from "Toggle Application mode" to "Force browse mode on demand for broken ARIA applications"
Milestone changed from None to near-term

@nvaccessAuto

Comment 7 by egogi on 2013-02-19 10:41
I have been able to get 50 comments shown on www.torrentfreak.com by pressenter on the word application, bringing up the context menu going to the frames submenu and pressing enter on show this frame only. I don't know how to get more than 50 comments though.

@nvaccessAuto

Comment 8 by camlorn on 2013-02-19 18:49
Well, is the problem web sites or the internet browser? I'm not personally sure, but have never once seen a not-broken web site using aria role of application. Do we even have an example of that?
The obvious solution is just make NVDA render everything to the virtual buffer, and pretend that the parts that have role=application don't exist unless we ask for them by turning on the force ignore. In all honesty, such an approach could be used to improve web sites using the role, by using the same rules for searching for labels to checkboxes and such as used in regular internet browsing. As this solution is the incredibly obvious one, I'm sure there's also a good reason not to, though.
If there is one thing I would want to remove from Aria, it would be role=application. I'm not sure I would even call web sites using it broken, as we can't be sure that it's not the screen reader. That's the problem: there's no way to tell which it actually is, not that I know of.
Also, more and more web sites seem to be trying to use it. I.e. Facebook's latest overhaul. Aria, in general, everywhere, but not really used like it should be. The priority of this, I suspect, is going to be proportional to the time that passes before it is implemented.
I would say that Google drive makes a good test site for Aria in general, as google claims that NVDA is supported and it at least appears to be using many html5 features. I think that a lot could be improved by finding a web site that uses a ton of aria correctly, and finding everywhere nvda needs to be improved.

@nvaccessAuto

Comment 9 by egogi on 2013-02-19 19:01
Only firefox lets you read the comments because you can show only that frame. Internet explorer shows the word application but once you click on it, you can't find the frames option in the context menu. chrome doesn't even give you an option to bring up the disqus comments.

@nvaccessAuto

Comment 10 by jteh (in reply to comment 8) on 2013-02-20 23:31
Replying to camlorn:

Well, is the problem web sites or the internet browser?

Web sites.

I'm not personally sure, but have never once seen a not-broken web site using aria role of application. Do we even have an example of that?

Yahoo! Mail and Google Docs both use the application role correctly.

The obvious solution is just make NVDA render everything to the virtual buffer, and pretend that the parts that have role=application don't exist unless we ask for them by turning on the force ignore.

That defeats the whole point of the application role for sites which implement it correctly. Breaking sites that implement this correctly to work around sites which don't is unacceptable and encourages poor authoring.

In all honesty, such an approach could be used to improve web sites using the role, by using the same rules for searching for labels to checkboxes and such as used in regular internet browsing.

NVDA never searches for labels. If the control isn't labelled, it remains as such. Searching for labels can be inaccurate, which can mislead the user with potentially dire consequences.

If there is one thing I would want to remove from Aria, it would be role=application.  I'm not sure I would even call web sites using it broken, as we can't be sure that it's not the screen reader.

This doesn't make sense. The whole point of the application role is to specify that something should be treated like a normal application, not a document. That's precisely what NVDA does when the role is used.

@nvaccessAuto

Comment 11 by camlorn on 2013-02-22 04:18
Well, I see no reason not to have the content rendered and ignored. it's there if one needs it. I'm not saying that it should be treated as part of the web page, just that rendering it to the virtual buffer (or whatever nvda calls this) isn't necessarily a bad idea. From my perspective: content that is prepared but ignored--because it's in the parts of the web page with the role of application--isn't there, and we can just pretend that it isn't until such time as someone forces the ignore. This solves the problem from the I'm not an nvda coder perspective. I'm going to assume that NVDA uses some sort of tree. Mark the nodes of the tree inside the role=application as being inside an application, and then make it like the focus mode [1], with the option to either automatically enable it or not. I know that it's offering this functionality, but it's not forcing me to view it that way if it's broken or I'm an advanced user who doesn't want to, for some reason. I can turn it on and off as needed.
I didn't know Google Docs actually worked. I looked at it last with jaws, a while ago, and it was a horrible, horrible experience. I'll need to try this with NVDA. My point about google drive is made more valid by that, though: if Google Docs is using Aria correctly, why isn't google drive? This could be google's fault, but if one part of it is, I'd imagine the rest should at least be close (not that close is good enough).
I don't see why the roel of application should force this, to be quite honest. I'll have to check the spec again, but the parts of how screen readers actually use aria seems to just be broad suggestions, not hard and fast rules. My thought is this: yes, it's an application, but it really seems to cause a ton more problems than it solves. I honestly believe that more than 75% of web sites using Aria are going to be broken by the definition we mean here.
Finally, searching for labels. Yes, this can be destructive. I'm not sure if I wish to argue the point, as that's a very, very good reason not to, but my counterargument would be this: mostly correct but sometimes wrong information is better than no information in most cases. And then I accidentally purchase something, or something similar and come reopen this ticket. But that's going off on a tangent.

1: Little information is sometimes worse than no information at all, and my statements about how I perceive nvda internals to work are made without having yet looked at the code. I really need to do that at some point.

@nvaccessAuto

Comment 12 by Druify on 2013-06-28 22:11
As [http://community.nvda-project.org/ticket/3198] shows, there seem to be more and more sites with corrupted or non-supported way of aria-roles as application. Can NVDA support mixed roles on one page, which would mean something like regular links for navigation, an application part, and after that a regular webpage? Maybe it would help for such cases to treat applications like objects, opening them with Ctrl+NVDA+Space.

@nvaccessAuto

Comment 13 by Q on 2013-07-30 03:22
I noticed this in a few more places and really hope we can figure out something soon.
Bit Bucket's download page: https://bitbucket.org/pypy/pypy/downloads
Is now using an application
Lowe's hardware, one of the big box home improvement stores in the states has their *entire website declared as an application, rendering it unuseable:
http://www.lowes.com/

@nvaccessAuto

Comment 14 by driemer.riemer@... (in reply to comment 13) on 2013-07-30 04:56
Yes and we should make a command like the command to get out of a flash or other embeded object to force browse mode on broken rich applications. When I was on that site it (sucked) to have to tab everywhere.
Replying to Q:

I noticed this in a few more places and really hope we can figure out something soon.

Bit Bucket's download page: https://bitbucket.org/pypy/pypy/downloads

Is now using an application

Lowe's hardware, one of the big box home improvement stores in the states has their *entire website declared as an application, rendering it unuseable:

http://www.lowes.com/

@nvaccessAuto

Comment 15 by jteh on 2013-07-30 05:49
While we do need a work around here, it'd be great if someone can report this as a bug to Bitbucket. That shouldn't be an application.

In case someone else wants to take a stab at this before i get time, one way of doing this is as follows:

  • Implement a new shouldCreateTreeInterceptor attribute on the base NVDAObject, defaulting to True.
  • In treeInterceptorHandler.update:
    • Add an additional keyword argument: force=False.
    • Don't create a tree interceptor if obj.shouldCreateTreeInterceptor and force are both False.
  • On Mozilla/MSHTMl applications:
    • Expose the same treeInterceptorClass as documents, but set shouldCreateTreeInterceptor to False.
    • Implement a script (probably bound to NVDA+space) to call treeInterceptorHandler.update with the object and force=True. This script will probably also need to override the cached treeInterceptor on the focus object.
@nvaccessAuto

Comment 17 by James Teh <jamie@... on 2013-10-29 04:02
In [d9dcc06]:
```CommitTicketReference repository="" revision="d9dcc06b3338b4e2383f75f233e64fc0ea90f836"
Merge branch 't2023' into next

Incubates #2023.

Changes:
Added labels: incubating
@nvaccessAuto

Comment 18 by jteh on 2013-10-29 04:04
Changes:
Milestone changed from near-term to next

@nvaccessAuto

Comment 19 by Michael Curran <mick@... on 2013-12-13 03:34
In [fd5f201]:
```CommitTicketReference repository="" revision="fd5f2015396a2b1781d08050dab3387e8434bf78"
Merge branch 't2023' into next. Incubates #2023

@nvaccessAuto

Comment 20 by Michael Curran <mick@... on 2014-01-06 07:23
In [0d9ad28]:
```CommitTicketReference repository="" revision="0d9ad28bdd404d5a85d2a4aff6bf4bcc1d12f1c1"
Merge branch 't2023'. Fixes #2023

Changes:
Removed labels: incubating
State: closed
@nvaccessAuto

Comment 21 by mdcurran on 2014-01-06 07:33
Changes:
Milestone changed from next to 2014.1

@nvaccessAuto

Comment 22 by leonarddr on 2014-01-06 17:56
It seems that the browse mode activation sound does not play the first time i switch to browse mode

@nvaccessAuto

Comment 23 by jteh on 2014-01-06 22:59
The sound only plays if you were previously in focus mode. In this case, you weren't; the application isn't treated as a document at all until you press NVDA+space, so there is no such thing as focus mode until after you press it.

@jcsteh jcsteh was assigned by nvaccessAuto Nov 10, 2015
@nvaccessAuto nvaccessAuto added this to the 2014.1 milestone Nov 10, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment