- From: Joseph Scheuhammer <clown@alum.mit.edu>
- Date: Thu, 17 May 2012 18:52:23 -0400
- 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
container's.
> 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:
http://clown.idrc.ocad.ca/Fluid/aria/nestedInvisibles.html
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.
--
;;;;joseph.
'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