Re: use of aria-hidden to provide a text description not visible on the page.

On Sep 10, 2010, at 12:09 PM, Steven Faulkner wrote:

> hi leif, 
> so are you saying it shouldn't do what it does?
> 
> the definition of aria-hidden starts with
> 
> "Indicates that the element is not visible or perceivable to any user."
> http://www.w3.org/TR/wai-aria/complete#aria-hidden
> 
> which is exactly the same sentence in the definition of hidden you cited:
> "Indicates that the element is not visible or perceivable to any user."

Steve, your interpretation is correct. Rendering engines that support AT do not expose content that is 'hidden' with a variety of CSS techniques, including visibility:hidden and display:none. By definition, those would count as 'hidden' content, as well as elements marked with html @hidden. ARIA's @aria-hidden is a way to explicitly hide content that, for whatever reason, should be hidden to assistive technology. 

The spec recommends authors always SHOULD update the value of aria-hidden, but in practice, when using visibility:hidden or display:none it's rarely needed since all popular screen readers rely on rendering engine support. Less common AT that is not supported by a rendering engine (I think only FireVox, atm) relies on the DOM being updated correctly, too. Also, if you use a different technique to visibly 'hide' elements from sighted users (e.g. negative text indent, abs positioned off screen, opacity:0) and that content should also be hidden from AT, you would need to set aria-hidden="false" to APIs don't get that content.

> also I got the idea from James Craig's email that my interpretation was confirmed. 
> 
> "That's correct. The label of visible elements should still be exposed to accessibility APIs (as a computed string), even if the labeling element (that contained all or some of that string) is hidden."

Leif probably didn't see my reply, as the HTML lists bounce emails from addresses that are not subscribed. I've included him in the CC this time.

James