WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: JavaScript library for display and customization of keyboard shortcuts?

for

From: Chaals McCathie Nevile
Date: Nov 1, 2015 4:24AM

TL;DR: Deborah is right and
http://chaals.github.io/accesskey/index.src.html is being developed to try
and fix the underlying problem. That might only take a few years...

On Sat, 31 Oct 2015 05:32:10 +0900, < <EMAIL REMOVED> > wrote:

> So I'm wading in here with a response to Bryan's question which less
> practical, and more philosophical. This is something I've been brewing
> ideas about for a while:

I've been thinking about (and discussing with John Foliot) this issue for
more than a decade.

I don't think your suggestion is philosophical, it is intensely practical.

Most of the pieces point to *fixing* accesskey. Browser implementations
have gone from horrible to not very good, which is a step in the right
direction. But there is a bit more to do before we get to where you want
to be:

1. Browsers need to provide discoverability.

This is a bug with existing implementations. The spec should clarify the
requirement.

The nice thing about using accesskey attributes is that querying the DOM
is easy (outside the Edge browser, where we would need to ask MS for
special magic ;( ). HTML now allows multiple suggestions to be given for
the accesskey attribute, but asks the user agent to provide
.accessKeyLabel in the DOM, identifying the shortcut used.

This means we *can* make the extensions that say "what is already bound" -
although they are not yet easy, at least we are not fighting the problem
of trying to interpret arbitrary javascript.

The browser needs to alert the user through the interface that there *are*
shortcuts available, and what they are. Opera for Presto got the second
part right with its accesskey menu - and to the extent that accesskey was
the tool for providing shortcuts, I made an extension to show there are
accesskeys. It is very very simple to do:

if(document.querySelector('*[accesskey]'))
hasAccessKeys = true;
else hasAccessKeys = false;

2. User agents need to handle *actual* key assignment, allowing for
conflict management

I guess this is a lot of what Robert was asking for in his original
request.

Instead of looking for the mythical shortcut - or gesture on touch
devices, or voice command, or whatever - that hasn't been taken up, in
reality we only need to provide shortcuts for a given user that don't
conflict with *their* world. Allowing the user agent to decide, presumably
in concert with the user for whom they are an agent, what to use, is
relatively simple. I built an extension for the old Opera which did this.
The documentation died when Opera killed myopera.com but the code is on
bitbucket still: https://bitbucket.org/chaals/excesskey/src

This means the value authors give the accesskey attribute is a
*suggestion*, and the browser can assign something else. Which is why the
browser has to be responsible for discoverability instead of the author -
besides the fact that browsers know how they work, whereas asking millions
of authors to write documentation for that, which is what we do now with
pages describing the accesskeys, is stupid. Too many people doing a lot of
repetitive work with a high risk of getting it wrong.

3. Browsers should be able to use accesskey to assign a voice command or
gesture

This follows on from 1, 2, and reality.

The accesskey attribute is basically a request for a shortcut method. On
some platforms that means a keyboard, on others it means something else.
Javascript gives keyboard users real shortcuts, and in certain cases might
do so for gestures although writing that is a nightmare. Shift-ctrl-alt-語
might be a legitimate accessKeyLabel value but isn't a *short* cut.

For voice commands, a word should be a valid entry in the list of values
accesskey can take. For touch devices, a gesture.

4. There *should* be a continuous use mode

For some applications such as games, the author should be able to
*request* a mode where shortcut keys are really simple to use. Right now
there is role="application" that does this for screenreaders, but badly.
Having this functionality, with the user in control when needed, would be
pretty useful for many people.

Some of this stuff is documented already as part of a proposal that I am
preparing for HTML. You can see it at
http://chaals.github.io/accesskey/index.src.html and raise issues on
github "pretty easily" at http://github.com/chaals/accesskey/issues but my
plan is to edit out the things that are clearly wrong, and then propose it
for the Web Incubator Community Group at W3C, as a proposal for the next
version of HTML.

> Bryan asked:
>
>> I'm coming into this thread a bit late, is the desire to have
>> customizable key assignments for all widget types? Or is the desire to
>> optionally expose all assigned keystrokes visually? I'm not sure which,
>> and both would have different ways to approach.
>
> Ultimately, this question is a symptom of how we have fallen down on
> the job with respect to the way we deal with the web and keyboard
> bindings ("we" writ large, as the accessibility and web standards and
> browser communities).
>
> Once the ideal was access keys. They were a web standard, albeit a
> standard which needed work.The browser implementations also needed work.
> They were nearly always only advertised to screen reader users. Users
> outside of the screen reader and accessibility communities might not
> even have known that they were something that could be used. Rather
> than fixing the standard and the browser implementations, the modern web
> community switched over to implementing key bindings in the same way
> it's fixed everything else for the last several years: JavaScript. Roll
> your own JavaScript, uniquely implemented per-site, not exposed in any
> meaningful way to the browser. Proto-polyfills, if you will.
>
> This is a mistake.
>
> This is a flat out, unquestionable roll back of the way the web ought to
> work.
>
> Even leaving accessibility out of the equation (all of the ways in which
> site-specific key bindings can help and most definitely hurt web users
> with disabilities), the environment we have now is chaos. On any given
> modern site I go to, my keys may have been hijacked for a number of
> different and site-unique functions. Since they are not exposed to the
> browser in any semantically meaningful way, I can't install some browser
> add-on to say "show me all of the key bindings and their human readable
> names". Since modern designer trends is so minimalist that many sites
> are opposed to even having a link on the page that says "keyboard
> shortcut help", it can be difficult or impossible to discover what those
> keyboard shortcuts are. In addition, it's entirely possible that those
> keyboard shortcuts collide with built-in shortcuts from my browser and
> my browser extensions, let alone my AT.
>
> Any end user, without needing to worry about the technical aspects,
> ought to be able to bring up a list while they are on a webpage that
> says "right now, these are the current key bindings." Ideally, they
> should be able to bring up one that lists both the key bindings for the
> current webpage, and the key bindings that are currently active with the
> browser and the browser extensions. They should be able to have
> something that highlights collisions. In a perfect world, and end user
> would be able to disable key bindings on a case-by-case basis, both at
> large and for any individual site, eg. something like Stylish, but for
> keyboard control. They would be able to redefine key bindings.
>
> And again, your average end-user is not going to really care whether
> those keyboard shortcuts came from the browser, their favorite
> extension, or the webpage. They just want the site to be able to work.
>
> This would require a change in HTML, and a change at the browsers, but
> it really does need to happen. Key bindings are only one of the ways in
> which we have relegated behavior which ought to be standardized so users
> understand how it works to individual, site-specific, roll your own
> JavaScript. (Drop-down menus, for goodness sake. If we had CSS-stylable
> HTML standard drop-down/fly out menus, or modal dialog boxes,
> implemented in the browsers because these are nigh-universal webpage
> constructs so shouldn't they really be implemented in the browsers at
> this point, think how many of us who are accessibility professionals
> would be able to take up croquet with all of our extra free time.)
>
> </soapbox>
>
> Deborah Kaplan
> > > > --
Charles McCathie Nevile - web standards - CTO Office, Yandex
<EMAIL REMOVED> - - - Find more at http://yandex.com