WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Fourth rule of aria > aria-hidden

for

From: Steve Faulkner
Date: Jan 22, 2018 6:23AM

In this super simple test case:

https://s.codepen.io/stevef/debug/NXJaGQ

JAWS 2018:
button is navigable via tab key, in case of IE and Chrome, the heading is
announced when the button is focused, in firefox nothing is announced.
NVDA latest:
button is navigable via tab key, in case of IE and Chrome, nothing is
announced when the button is focused, in firefox button name and role is
announced.

--

Regards

SteveF
Current Standards Work @W3C
<http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>;

On 22 January 2018 at 12:46, Patrick H. Lauke < <EMAIL REMOVED> >
wrote:

> On 22/01/2018 12:45, Patrick H. Lauke wrote:
>
>> The rule, in essence, says: you don't want an AT user setting focus to
>> "nothing", as they're left wondering what they just set focus to. If it's
>> aria-hidden (or contained inside an aria-hidden container), but received
>> focus, it's an empty step in the focus cycle.
>>
>> Nobody dies when this happens, to be clear. And the "rules" of using ARIA
>> are more good practice maxims, not hard failures.
>>
>> IF you can justify why something still receives keyboard focus but isn't
>> announced at all to AT users, cool.
>>
>
> At that point, you may even consider adding some SR only text to the page
> that explains what's going on, before the user encounters those "focusable
> but unannounced" controls, mind.
>
> P
>
> --
> Patrick H. Lauke
>
> www.splintered.co.uk | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> > > > >