Re: aria-kbdshortcuts

This is informative information provided by the author that is provided in
a standardized format to define how to activate an element. It is not a
browser behavior directive.

accesskey is busted and has been for over a decade. HTML5 was unable to get
it done even though IBM contributed a patent to the former HTML working
group to solve the problem of access key.

Access key, today, is a hack. It does not tell you what the access key is
for and implementation across browsers is inconsistent. Some browsers give
focus to the element while others do an activation. HTML has set the bar
for hacks here.

I have absolutely no faith that the HTML working group can get a
replacement for access key done. Part of that stems from the move to mobile
where keyboards are used less. I just don't see motivation to do this in
the HTML working group. I personally, burned a lot of cycles in the
beginning to fix access key by working for months with lawyers to get the
IP behind an earlier version of access element donated to the W3C and the
whole discussion went into the weeds trying to resurrect the access key
hack.

Dominic has done a fine job in providing a standard way to share what key
strokes they have applied to respond to keyboard command to activate an
element.




Rich Schwerdtfeger



From: "Chaals McCathie Nevile" <chaals@yandex-team.ru>
To: "Dominic Mazzoni" <dmazzoni@google.com>, Richard
            Schwerdtfeger/Austin/IBM@IBMUS
Cc: PF <public-pfwg@w3.org>
Date: 07/28/2015 10:40 AM
Subject: 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