Re: aria-kbdshortcuts

On Thu, 23 Jul 2015 14:34:31 -0400, Richard Schwerdtfeger  
<schwer@us.ibm.com> wrote:

> Hi Dominic,
>
> This is in the current ARIA editors draft:
> http://rawgit.com/w3c/aria/master/aria/aria.html#aria-kbdshortcuts
>
> Please let us know if you have any issues.

I'd like to know what I don't understand, because to me this looks like it  
has all the drawbacks accesskey still has, but loses most of the benefits,  
effectively sending us *backwards*.

1. In particular, unlike accesskey it doesn't even work unless the author  
hooked it up right.

2. Assuming that authors mostly get keyboard listeners right, this  
approach continues the problem of sites like twitter hijacking standard  
browser interaction, which of course is amazingly confusing.

3. It requires developers to use Javascript to detect particular user  
behaviour, and map to their presumed intent. That assumes developers know  
enough about a user's context to determine what behaviours are appropriate  
for interacting with a control, which is simply Wrong™.

4. It encourages developers to document the resulting interface of a User  
Agent about which they don't have enough information, in the context of  
their particular site, rather than providing the user agent sufficient  
information to provide documentation. The half-baked approach of using  
.accessKeyLabel as per HTML5 would be better, as instead of relying on the  
author to get interaction code right, at least all they need to do in  
order to provide documentation is query a simple DOM attribute.

5. Like accesskey it becomes possible to find out what other scripts claim  
they will trap, but unlike accesskey with .accesskeyLabel there is no way  
to know if that is true, let alone "negotiate" among scripts. Using  
accesskey allows that work to be devolved to the browser.

With regards to the editor's note, understanding what an interactive  
component does should come out of computing its accessible name (possibly  
in context, e.g. increasing the month in a date-picker). The only case  
this doesn't apply is where an accelerator is applied to a pure JS  
function, but it isn't hard to imagine a standard approach among the many  
quick hacks that would already work.

cheers

Chaals

-- 
Charles McCathie Nevile - web standards - CTO Office, Yandex
  chaals@yandex-team.ru - - - Find more at http://yandex.com

Received on Tuesday, 28 July 2015 15:40:54 UTC