-
-
Notifications
You must be signed in to change notification settings - Fork 632
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Provide support for aria-hidden #2117
Comments
Comment 1 by vtsaran on 2012-05-07 22:05 |
Comment 2 by jteh on 2012-05-07 23:14
One technical problem is that we have to figure out how to support it properly, allowing for the possibility that aria-hidden might change value. This is complicated by the fact that none of the browsers really implement aria-hidden properly themselves. I'd also argue that aria-hidden is usually (if not always) an incorrect solution to a problem - it isn't even ideal for the use case that John provides, as I've argued in the past - but that's probably an argument for a different forum. |
Comment 3 by johnfoliot on 2012-05-08 03:08 You wrote: Simply, it shouldn't; it should have the same state as tabindex="0" - it's hidden, its not there, it shouldn't take any focus at all. This is the same situation/response to your second comment as well, where you ask about the descendants of aria-hidden="true" elements. You wrote: The '''''WAI-ARIA 1.0 User Agent Implementation Guide''''' is pretty clear here. It states: The key is the phrase "Elements, '''including their descendants'''...". This means (to me) that an anchor inside of a div that has aria-hidden="true" is a descendant and so should not be exposed - period. I recall reading a thread at Mozilla's bug-tracker where you guys figured that if an anchor was in a hidden div that it was likely author error and so you wanted to continue to support the link (at least, this is how I recollect that thread unfolding, but I may very well be wrong). To me, this also means that if an author tries to do this: Paragraph ...that the paragraph remains hidden, and the aria-hidden="false" is never exposed - because if the parent container is hidden, so too everything inside of it. This is an author error, and I remain unconvinced that this will be a prevalent error in the wild - are you seeing numerous instances of this type of thing already? I hope Victor's need will help you reconsider supporting aria-hidden, as it is indeed quite useful under certain circumstances. JF |
Comment 4 by jteh (in reply to comment 3) on 2012-05-08 09:09
My understanding was that ARIA wasn't supposed to affect anything except accessibility API exposure and assistive technologies. What you're suggesting requires it to affect keyboard navigation in the browser. Certainly, what you're suggesting isn't implemented by any browser as far as I know. This means that this is still an open question for NVDA.
Mozilla certainly does not honour this. It just exposes a hidden attribute. IE does seem to expose the invisible state, but it's still part of the tree. Nevertheless, this does clarify what is supposed to happen. |
Comment 5 by vtsaran on 2012-05-09 17:23 |
Comment 6 by jteh (in reply to comment 5) on 2012-05-09 17:58
In that case, this needs to be fixed in Windows browsers first before we can do anything. |
Comment 7 by davidb (in reply to comment 6) on 2012-05-24 16:39
Heyo. What specifically needs to be fixed? We had a few lengthy debates in bugzilla-land with the idea of pruning the a11y tree but there were lots of concerns. I don't know of any browsers that actually police aria-hidden subdom interactivity for keyboard and mouse usage. We could just prune and trust the web dev not to mess up... but currently FF is immune to this. |
Comment 8 by johnfoliot on 2012-05-24 19:38 I think that the issue is more with the inequity of aria-hidden versus other hiding/hidden techniques. For example, what exactly should happen if/when an author writes: Very Critical info The link and tab focus are removed, but a sighted mouse-user could still click on the link and follow on to that page. That an author should do something this stupid is not at question, but what IF?... I've thought a fair bit on this whole "hidden" stuff, and as an accessibility guy I really wish that @hidden, aria-hidden="true", and the css display:none; visibility:hidden; stuff all equaled exactly the same thing - gone, not available to anyone; use any of the above and you get the same user-experience whether sighted or not. Don't have a simple answer here, but at this time NVDA is not supporting aria-hidden at all (AFAIK), where-as we know that at least JAWS and VoiceOver does, so addressing that inequity is I believe important. |
Comment 9 by jteh (in reply to comment 7) on 2012-05-24 22:59
If that were true, that would kill your own test case and justification for aria-hidden; i.e. a link containing a graphic with aria-hidden set on the link. The graphic would not appear to sighted users either.
Sure. Unfortunately, there's no solution we can implement on our side regarding your requirement that when something with aria-hidden="true" gets focus:
That requires a browser change (and is something that no browser currently implements except maybe Safari on Mac). So, we can't satisfy your requirements, which means we'd have a half-baked solution at best. Even if we ignore that requirement, we still have to figure out how to handle it. Replying to davidb:
FWIW, Chrome does seem to prune the tree for aria-hidden. If something in the hidden tree gets focus, it fires a focus event on the parent of the hidden tree.
According to comment:5, Safari on Mac does (though I'm not sure if this is only with !VoiceOver enabled). However, I'd argue this is questionable behaviour at best; see comment:4. |
Comment 10 by jteh on 2012-08-27 06:07 |
Comment 11 by jteh on 2012-08-27 07:10 |
Reported by johnfoliot on 2012-02-21 01:55
Having support for aria-hidden will benefit users and content authors when used appropriately. Please see: http://john.foliot.ca/aria-hidden for use case, comparative support in other screen readers and related background.
The text was updated successfully, but these errors were encountered: