W3C home > Mailing lists > Public > wai-xtech@w3.org > May 2012

Re: ACTION-1039: aria-hidden and inner/outer elements

From: Joseph Scheuhammer <clown@alum.mit.edu>
Date: Thu, 17 May 2012 18:52:23 -0400
Message-ID: <4FB58127.40100@alum.mit.edu>
To: James Craig <jcraig@apple.com>
CC: Andi Snow-Weaver <andisnow@us.ibm.com>, cyns@microsoft.com, dbolter@mozilla.com, W3C WAI-XTECH <wai-xtech@w3.org>, James Nurthen <james.nurthen@oracle.com>, "Schnabel, Stefan" <stefan.schnabel@sap.com>
On 12-05-15 6:18 PM, James Craig wrote:
> I don't agree that the element should be exposed. If the ancestor is hidden, all descendants should also be hidden. If the same way, if you have CSS display:none on a node, adding display:block to a child element does not make it appear.

One more wrinkle, namely, the use of CSS visibility:hidden on a 
container, and a child element with visibility:visible style.  The child 
element is rendered in this case, since the local CSS overrides the 
> Another technical challenge regarding the AX tree would be that you'd have to promote these child nodes to a higher branch, since the parent element is no longer in the tree. This could result in very unexpected behavior in some APIs.

For visibility:hidden/visible case, FF constructs the a11y tree in just 
that way.  There is no accessible in the a11y tree for the hidden 
container, but there is one for its visible DOM-child.  Furthermore, 
that accessible is promoted up a level.

But, I wouldn't make very much of this.  I think all this amounts to is 
that authors must write their scripts to properly update @aria-hidden 
based on the way they use CSS to show/hide elements.  Another example is 
using CSS offscreen positioning.  In that case, FF's a11y tree shows an 
"offscreen" property for the corresponding accessible in the a11y tree, 
meaning it's, well, invisible.  Hence, authors should ensure that 
@aria-hidden is 'true' in this case as well.

Test file for checking the a11y tree:

Changing topics:  There is an issue with respect to this example:
> Hidden TabPanel (aria-hidden=true) perhaps a different tab is selected
> 	- Paragraph
> 	- Disclosure
> 	-	- Shown Details (aria-hidden=false)

I agree it's not an author error to do this, and also that it's a useful 
way to maintain the state of the "Shown Details" for when the ancestor 
TabPanel becomes visible.  But, there is a problem if an AT accesses the 
"Show Details" DOM element directly.  It might mistakenly conclude that 
the details are visible, when they, in fact, are not.  The mistake is 
possible since the element declares that it is not aria-hidden.

This implies that the AT should either look up the tree for an 
overriding hidden ancestor, or consult the element's styles (which the 
author should correctly set), or look at a11y tree accessible's 
properties to determine if an aria-hidden element is truly hidden.


'A: After all, it isn't rocket science.'
'K: Right. It's merely computer science.'
              - J. D. Klaun -
Received on Thursday, 17 May 2012 22:52:57 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:51:46 UTC