W3C home > Mailing lists > Public > public-aria@w3.org > February 2016

Re: aria-kbdshortcuts feedback

From: Dominic Mazzoni <dmazzoni@google.com>
Date: Thu, 25 Feb 2016 17:49:27 +0000
Message-ID: <CAFz-FYybJhdZit8=01v-Qhov817egf6c+vP1Lpc01m9MSi5XJA@mail.gmail.com>
To: Chaals McCathie Nevile <chaals@yandex-team.ru>, James Craig <jcraig@apple.com>, John Foliot <john.foliot@deque.com>
Cc: Rich Schwerdtfeger <richschwer@gmail.com>, ARIA Working Group <public-aria@w3.org>
On Thu, Feb 25, 2016 at 6:22 AM Chaals McCathie Nevile <
chaals@yandex-team.ru> wrote:

> > The accesskey spec doesn't support *any* of these.
>
> Actually, the spec supports them all. There is nothing to stop an
> implementation from using the bare key, although as far as I know only old
> mobile browsers and iCab ever did.
>

Sure there is - backwards compatibility.

First of all, the spec only allows for the user agent to choose the
modifier key combination. It doesn't provide a way for authors to assign
shortcuts involving multiple keys to a command, like Alt+F for one command
and Ctrl+C for another. Every one of those sites above has shortcuts
involving different permutations of modifiers, and some of them have more
than 26+10 different shortcuts so a single modifier key is not even
sufficient.

Second, there's no way user agents would change the interpretation of
accesskey and break compatibility with millions of existing sites. Any site
that currently uses accesskey and *also* uses JavaScript to listen to bare
keys would break if browsers suddenly started interpreting accesskeys as
bare keys.

If you want to support the functionality that a lot of existing apps depend
on, the accesskey spec needs to either define a backwards-compatible path,
or we should just make it a new attribute that won't conflict.
Received on Thursday, 25 February 2016 17:50:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:58:21 UTC