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

  Thanks James,

On 12/10/10 3:02 PM, James Craig wrote:
> On Oct 12, 2010, at 8:15 AM, David Bolter wrote:
>
>> 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).
>
> That's one of two reasons.
>
>> Personally, I would have preferred aria-hidden be removed from the 
>> spec than have it actually prune the accessibility tree.
>
> Many technologies have the potential for abuse, but there remain 
> plenty of legitimate cases where it is appropriate to hide a visible 
> element from the accessibility tree. We *have* to provide a way for 
> that to be made possible, or web developers will just avoid making 
> their apps accessible.

We have role="presentation".


>
> Desktop accessibility APIs already allow this; now the web does, too.
>
>> What should we do if focus goes into this aria-hidden section of the DOM?
>
> The implementation guide covers that in:
> http://www.w3.org/TR/wai-aria-implementation/#keyboard-focus_tabindex
>
> "All elements which are focusable MUST be exposed in the accessible 
> tree, so that when they receive focus, there is an object for which to 
> fire an accessibility event."
>
> Although it is somewhat vague as to who should be doing the work. It 
> should probably say:
>
> "User agents MUST expose all focusable elements in the accessible 
> tree, so that when they receive focus, there is an object for which 
> to fire an accessibility event."
>

Right, and this is a cardinal rule in gecko's accessibility implementation.

I see ambiguity here though... should the focused element (inside an 
aria-hidden tree) be connected in the accessibility tree? I don't really 
want to explore this in time consuming detail, but just pointing out 
there is potential muck here.

cheers,
David