Re: Best practice for aria-disabled and keyboard focus management

I agree that there should be no normative language stating that certain types of disabled controls should be focusable or not. Whether they are "focusable" depends on several things: the platform UI guidelines, the type of control, the user's settings, and even what type of "focus" you're referring to.

You're right that it's more fitting for the APG than the spec, but I don't see any harm in stating (in either document) that authors should make ARIA-based controls behave like native controls to the best of their ability. 


On May 20, 2014, at 2:59 PM, Matthew King <mattking@us.ibm.com> wrote:

> Now, this is a topic for a potential holy war ... 
> 
> I am not convinced the ARIA spec should include any normative language, or perhaps any language, on this topic. We could some treatment of pros, cons, and possible best practices in the APG. 
> 
> What would be the reason for putting it in the spec? 
> 
> From: James Craig <jcraig@apple.com> 
> 
>> Moving to public-pfwg. 
>> 
>> Disabled controls are not focusable on any platform UI that I know of. VoiceOver allows navigation to disabled controls for the cases Bryan mentioned, but full keyboard access (Tab navigation) does not. I think ARIA-based controls should behave the same way as standard keyboard interaction. If assistive technologies wish to provide additional navigation mechanisms, they may do so. 
>> 
>> Please feel free to suggest spec changes to reflect this. 
>> 
>>> On May 20, 2014, at 10:18 AM, Bryan Garaventa <bryan.garaventa@ssbbartgroup.com> wrote: 
>>> 
>>> Is this general? 
>>> 
>>> I can see the benefit of having disabled buttons not be in the tab order, however when arrowing within menus it’s often useful to know which menu items are disabled as within standard menus. 
>>> 
>>> From: Gunderson, Jon R [mailto:jongund@illinois.edu] 
>>> 
>>>> Subject: Best practice for aria-disabled and keyboard focus management 
>>>> 
>>>> The aria spec seems a little vague where disabled controls should be focusable. 
>>>> 
>>>> Is the best practice to make the container widget focusable (the widget in tab order) and disable focus moving to children of the  parent widget. 
>>>> 
>>>> The coding pattern being proposed is that the disabled control is discoverable through the tab order, but more complex keyboard interaction is disabled until the form control is enabled. 
>>>> 
>>>> Jon 
>>>> 
>>>

Received on Wednesday, 21 May 2014 17:43:25 UTC