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

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?

Matt King
IBM Senior Technical Staff Member
I/T Chief Accessibility Strategist
IBM BT/CIO - Global Workforce and Web Process Enablement 
Phone: (503) 578-2329, Tie line: 731-7398
mattking@us.ibm.com



From:   James Craig <jcraig@apple.com>
To:     "Gunderson, Jon R" <jongund@illinois.edu>, Bryan Garaventa 
<bryan.garaventa@ssbbartgroup.com>, 
Cc:     public-pfwg <public-pfwg@w3.org>
Date:   05/20/2014 10:25 AM
Subject:        Re: Best practice for aria-disabled and keyboard focus 
management



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] 
Sent: Monday, May 12, 2014 7:20 AM
To: W3C WAI-PFWG
Cc: W3C WAI-XTECH
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