Comment 1 by vtsaran on 2012-05-07 22:05
I am sure the lack of comments on this ticket has its reasons. Was there a discussion behind the scenes on this issue?
Support for aria-hidden would be a critically-needed feature for a product we are building.
Are there any plans to support aria-hidden in the near future?

Comment 2 by jteh on 2012-05-07 23:14
There are a couple of practical problems with aria-hidden:

1. If aria-hidden="true" but the element or one of its descendants is focusable, we have to figure out how to handle the situation where a so-called "hidden" element gets focus. It certainly can't magically appear in the document if it happens to get focus. As I understand it, Mozilla doesn't properly implement the invisible state on aria-hidden elements for this reason.
2. The spec is unclear about what happens if aria-hidden="true" is set on an outer element but aria-hidden="false" is set on some inner element. If this is allowed, this will cause serious problems for us. Thankfully, I don't think it is, but the spec isn't explicit. We need some clarification on this point.

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
Greetings James.

You wrote:
"If aria-hidden="true" but the element or one of its descendants is focusable, we have to figure out how to handle the situation where a so-called "hidden" element gets focus."

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 spec is unclear about what happens if aria-hidden="true" is set on an outer element but aria-hidden="false" is set on some inner element."

The '''''WAI-ARIA 1.0 User Agent Implementation Guide''''' is pretty clear here. It states:
"The following elements are not exposed via the accessibility API and user agents SHOULD NOT include them in the accessibility tree: Elements, including their descendants, that have a WAI-ARIA global attribute of aria-hidden="true" and no other host language semantics specifying that the element is hidden."
Source: http://www.w3.org/WAI/PF/aria-implementation/#exclude_elements

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:
''

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
Replying to johnfoliot:

If aria-hidden="true" but the element or one of its descendants is focusable, we have to figure out how to handle the situation where a so-called "hidden" element gets focus.

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.

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.

This is the same situation/response to your second comment as well, where you ask about the descendants of aria-hidden="true" elements.

 "The following elements are not exposed via the accessibility API and user agents SHOULD NOT include them in the accessibility tree: Elements, including their descendants, that have a WAI-ARIA global attribute of aria-hidden="true" and no other host language semantics specifying that the element is hidden."

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
I see no problem with the way Safari implements aria-hidden and the way the resulting pages work with VoiceOver.
Essentially, the block of the document marked with aria-hidden=true is taken out of the accessibility tree as well as out of the keyboard navigation and is no longer available to the AT user.
What I'd like to confirm is whether aria-hidden triggers HTML5's hidden attribute (although it shouldn't accordion to the spec).

Comment 6 by jteh (in reply to comment 5) on 2012-05-09 17:58
Replying to vtsaran:

I see no problem with the way Safari implements aria-hidden and the way the resulting pages work with VoiceOver.

Essentially, the block of the document marked with aria-hidden=true is taken out of the accessibility tree as well as out of the keyboard navigation and is no longer available to the AT user.

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
Replying to jteh:

Replying to vtsaran:

I see no problem with the way Safari implements aria-hidden and the way the resulting pages work with VoiceOver.

Essentially, the block of the document marked with aria-hidden=true is taken out of the accessibility tree as well as out of the keyboard navigation and is no longer available to the AT user.

In that case, this needs to be fixed in Windows browsers first before we can do anything.

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
Hi David,

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
Replying to johnfoliot:

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.

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.

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.

Sure. Unfortunately, there's no solution we can implement on our side regarding your requirement that when something with aria-hidden="true" gets focus:

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.

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:

We had a few lengthy debates in bugzilla-land with the idea of pruning the a11y tree but there were lots of concerns.

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.

I don't know of any browsers that actually police aria-hidden subdom interactivity for keyboard and mouse usage.

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
Changes:
Milestone changed from None to 2012.3

Comment 11 by jteh on 2012-08-27 07:10
Done in be4dd16. Note that if something inside an aria-hidden element gets focus, it may not be reported correctly in browse mode. This is considered to be author error.
Changes:
State: closed