Re: aria-kbdshortcuts feedback

On Thu, 25 Feb 2016 18:49:27 +0100, Dominic Mazzoni <dmazzoni@google.com>  
wrote:

> 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.

Hmm. As it is, yes...

> 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.

True enough.

Which is not the same as mathematically true. I think it is the case that  
most sites using the currently JS-heavy ARIA patterns would be fine since  
the keys generally don't conflict. I haven't made a test case for e.g.  
accesskey="→", and you can't use named keys like backspace or enter at the  
moment.

> 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,

Which is the path I think we should follow. See my comments elsewhere on a  
micro-syntax for shortcuts that is explicit about modifiers, and the fact  
that the first thing we need to do is fix almost all browsers to stop  
rejecting accesskey attribute values longer than 1 character.

This isn't entirely trivial, but nor does it obviously strike me as  
impossible - or even close to it.

> or we should just make it a new attribute that won't conflict.

We could do that, but it leads toward http://xkcd.com/927 … I figure that  
we might as well see if we can fix the thing we already have.

That said, there are some attractive features to a new attribute, like it  
not being immediately associated only with key combinations in the mind of  
developers.

(How I got to working on fixing accesskey over implementing aria-something  
was like James - the aria solution requires enterprise-quality engineering  
which is demonstrably lacking even in some well-known enterprises, so it  
seems to offer more footguns, although it requires less work from  
browsers. And it works for people who don't normally rely on AT, or AT  
that reads accessibility APIs, which I believe is the case for many  
keyboard users).

cheers

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

Received on Thursday, 25 February 2016 19:04:01 UTC