Re: aria-kbdshortcuts feedback

> On Feb 24, 2016, at 1:25 PM, Dominic Mazzoni <dmazzoni@google.com> wrote:
> 
> On Wed, Feb 24, 2016 at 1:14 PM James Craig <jcraig@apple.com <mailto:jcraig@apple.com>> wrote:
> Note the time. I agree with John Foliot. ;-)
> 
> In addition, an accesskey replacement spec would have the ability to specify end use behavior (and event model changes) in a way that would be inappropriate to do in an ARIA spec. Dominic, would you be willing to pursue the solution in that spec rather than in ARIA?
> 
> No, but I support doing both in parallel and making them compatible if possible. If we like the accesskey spec, maybe we should call it aria-accesskey and align its syntax.

Seems reasonable. The ARIA property should be forthright that it does not create any event handling magic. This must all be managed by the author in JavaScript.

Both specs should list explicit attribute parsing rules, since this does not fit the pattern of DOMString or DOMTokenList. Note, I started working on a DOMOrderedTokenList interface (push/pop/insert/etc rather than add just add/remove) before abandoning IndieUI Events. It may be worthwhile to resurrect or create a similar interface for the accesskey spec.

> The majority of ARIA roles, states, and properties are not necessary if you use appropriate HTML5 elements and attributes, but that doesn't mean we deprecate them, it means authors have choices. It's preferable to use the native elements and attributes when possible, but when you need to roll your own approach for various reasons, ARIA allows you to do so without sacrificing accessibility.
> 
> I think that applies here. It's a lot easier for an existing web app to add aria-kbdshortcuts support than to switch to accesskeys, and it's less risky and requires less testing.

Certainly less risky, but also less likely to be implemented correctly, except by enterprise-quality engineers.

James