Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Don't expose content of ARIA applications in virtual buffers #990

nvaccessAuto opened this Issue Oct 22, 2010 · 13 comments


None yet
2 participants

Reported by mike.reiser on 2010-10-22 17:18
On some pages, nvda can get stuck in iframes and the only way to get out is to press the tab key. Steps to reproduce:

  1. Go to http://mediamemo.allthingsd.com/20101021/hulu-plus-take-two-hows-4-95-a-month/?mod=twitter&utm_source=twitterfeed&utm_medium=twitter
  2. Arrow through the article until you get to the iframe where you can tweet, etc.

Actual results: NVDA will get stuck not allowing you to arrow through the iframe. Tab must be used to get out of it.

Expected results: nvda should let you arrow through as normal. This happens in the latest nightly build and in 3.6.11.

Comment 1 by pvagner on 2010-10-23 05:42
There is an application inside the iframe so when focus goes in there NVDA automagically switches to the focus mode thus arrow keys are not working like in the virtual buffer.
I think this is expected behaviour for a document marked as application.
The question is whether we should another shortcut or something to deal with this issue? Or expand NVDA+ctrl+space to work in this context?
I am not really sure.
Milestone changed from None to None

Comment 2 by jteh on 2010-10-24 10:34
Actually, NVDA+control+space already works to get out of this. However, it's annoying that we "fall into" applications like this. The solution is to expose applications in the same way we expose embedded objects; i.e. you have to press enter to interact with it. We've been meaning to do this for a while now. :)
Changed title from "Nvda sometimes gets stuck in iframes on some sites." to "Don't expose content of ARIA applications in virtual buffers"
Milestone changed from None to near-term

Comment by jteh on 2011-04-12 00:07
(In #1452) I assume you mean when an element with document role is inside an ARIA application? A test case would be great if possible.

This probably sort of worked before #277 was fixed because we didn't care about ARIA applications inside buffers back then, which was incorrect.

We actually need to render a separate buffer for the document inside the application. Thus, it also needs #990 to be fixed so we don't render the application inside its parent document.

Comment by jteh on 2011-06-09 07:45
(In #1452) Documents in ARIA applications (both iframe and ARIA documents) are supported for IE in 44487c9.

ARIA documents work as of Firefox 6 (not yet released), as MozillaBug:653607 has been fixed.

We'll address #990 separately, as it isn't necessary if the top level document is an application.

Comment 5 by jteh on 2012-08-20 02:29
Mick, I seem to remember you starting work on this at some point, but running into some obstacle. Do you remember anything about this or am I mistaken?

Comment 6 by mdcurran on 2012-08-20 03:01
I think it was that that some nodes with a role of application did not necessarily accept setting focus i.e. no way to jump inside them.

Comment 7 by jteh on 2012-08-20 06:14
Damn. That could be a problem. I guess the only thing we could do in that case is set focus to the first focusable descendant we can find. Is that something we should even consider?

Comment 9 by jteh on 2012-09-10 10:51
Milestone changed from near-term to 2012.3

Comment 10 by jteh on 2012-09-11 03:04
Done in 0d443cc.
State: closed

Comment 11 by tkeenan79 on 2012-11-09 08:16
Not sure if this will be read, but this new way of treating applications makes it extremely cumbersome to use the DisQus application to read comments on blogs and other sites.
Not sure if there's anything to be done about this except to have some sort of toggle that enables browse mode navigation inside applications.
I'm sure this isn't the only instance when those navigation commands would be handy inside an application. In fact, now that I think of it, it would also be useful to navigate the circular of my local grocery market, as they use an application to display that content.

Comment 12 by jteh on 2012-11-09 08:52
Previously, you would have "fallen into" the application and gotten stuck. This change just makes it so that you have to press enter to move inside the application. Browse mode navigation was never possible in applications.

If you feel browse mode navigation would be useful in a given application, it very likely shouldn't be an application at all and you should suggest this to the site's author.

Comment 13 by tkeenan79 (in reply to comment 12) on 2012-11-09 09:53
I see. In the past, NVDA didn't treat Disqus as an application, but that changed a few months ago when your fix went in.
I've been wondering if anyone has brought this up on the support list. I'll move this discussion there.

Comment 14 by jteh on 2012-11-09 10:38
We haven't changed what is treated as an application, only that the content of applications is no longer included in the document. As I said, this is because doing otherwise means you can "fall into" an application and get stuck without realising it. I should clarify that this would only have happened if you hit an interactive control such as a button, form field, etc. while in the application portion. If Disqus doesn't have many interactive controls, you might not have noticed this problem. It certainly sounds like Disqus shouldn't be marked as an application.

@nvaccessAuto nvaccessAuto added this to the 2012.3 milestone Nov 10, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment