RE: Native keyboard support based on roles

Native keyboard support would solve a major problem with current ARIA usage, many developers do not understand the keyboard or focus management aspect of using ARIA.   The problem with adding this type of feature now would be compatibility with existing Javascript libraries and ARIA implementations, what happens when the browser and javascripting for keyboard events both try to support keyboard accessibility for a role=menu.

Automatically adding keyboard (or any other input device) support seems to require a new type of attribute like "behavior" or probably better elements like "Menu" or "tree"to indicate this element has the "behavior" of a "menu" or "tree".   The browser can then look at the behavior roles to determine the input and focus management behavior for role.

I think if we want native keyboard (or other input device support) we would best try to get element level support in HTML 5.x, rather than trying to retrofit ARIA to fill this need.
 
Jon



-----Original Message-----
From: Marco Zehe [mailto:mzehe@mozilla.com] 
Sent: Tuesday, December 16, 2014 9:27 AM
To: 'WAI Protocols & Formats'
Subject: Re: Native keyboard support based on roles

On a related note, what I was thinking about when I first read Léonie's proposal was: "How is the browser supposed to know how to act on certain elements"? For button or link mappings this is still relatively easy, for check boxes and radio buttons maybe, too. But if we went the whole route and said "each role that maps to a native HTML widget", and we start to deal with comboboxes and listboxes, things get more tricky.
Like how are we, as the browser vendor, supposed to know where the next or previous element is that we should move keyboard focus to? Just iterating through children might not be enough, especially when it comes to dealing with rich content inside the option elements and such. So the author would still have to do some significant amount of coding for the browser to know where to go from one particular item to the next or previous, and how to interact.

And yes, as Rich said, then there are different interfaces such as keyboard, mouse, and touch.

So while it could be feasible for the browser to emmit certain commands like "go next" and such, it would still be up to the web component or widget author to do the actual magic in response to that. And that would only slightly lift the burden from them.

Marco

On 16.12.2014 15:28, White, Jason J wrote:
>
>> -----Original Message-----
>> From: Léonie Watson [mailto:lwatson@paciellogroup.com]
>> Could you give some examples?
>>
> In some user agent implementations, moving the focus to a radio button in a group of radio buttons is sufficient to select it and therefore to change the value of the control. There are situations in which the application's author has good reason to prevent this behavior so that the user can review the options easily without changing the value. In this situation, a non-standard keyboard interface is needed; we don't want the native keyboard interface of the control to be applied.
>
>
> ________________________________
>
> This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited.
>
>
> Thank you for your compliance.
>
> ________________________________
>

Received on Tuesday, 16 December 2014 16:14:07 UTC