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

  Hi James,

The browser already knows what is visible and what is not. The reason 
aria-hidden was added in the first place was for assistive technology 
that looked directly at the DOM (and didn't rely solely on the 
accessibility tree exposed on the desktop). Personally, I would have 
preferred aria-hidden be removed from the spec than have it actually 
prune the accessibility tree.

What should we do if focus goes into this aria-hidden section of the DOM?

Cheers,
David

On 13/09/10 3:30 PM, James Craig wrote:
> copying David Bolter and Andi Snow-Weaver.
>
> On Sep 11, 2010, at 1:04 PM, Leif Halvard Silli wrote:
>
>> Leif Halvard Silli, Sat, 11 Sep 2010 17:10:41 +0200:
>>
>> Now I have deinstalled Jaws 10, and reinstalled Jaws 11, and the bug in
>> the interpretation of the test page [*] continues to be there. However,
>> I also found something that appears as a workaround: Aria-labelledby
>> can contain more than one idref. And if at least one of the idrefs
>> points to an element that has not been hidden, then all the elements
>> will be used, even if some of them are hidden. The visible element can
>> simply be an empty element.
>
> The fact that the browser should sent a string value as the label was 
> a relatively recent clarification in the ARIA Implementation Guide 
> (within the last few months, I think). What Mozilla used to do was use 
> the IDREF pointer in the accessibility API, which was problematic if 
> that labeling element was hidden in the API. VoiceOver already 
> calculated the string label on the user agent, and then passed the 
> string label to the API. If I remember correctly, the PFWG decided 
> VoiceOver was doing the right thing here, so what you're seeing is 
> likely just a legacy implementation in Firefox. David may be able to 
> comment on whether or not a more recent build of FF has updated that 
> behavior.
>
> James
>