WebAIM - Web Accessibility In Mind

E-mail List Archives

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


From: Jonathan Avila
Date: Oct 31, 2015 3:49PM

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

Yes, I think this would also really help speech users. Also, I'd like to take this a step further and say that controls should expose all of their interactions through device independent methods so the user could just pull up a menu of actions for a control and be able to perform those actions without requiring specific keystrokes. This idea may tie into IndieUI -- but why have keystroke specific commands. Consider the benefit to mobile users who may not have a physical or virtual keyboard but want to use speech or a mobile screen reader to change an ARIA slider that today requires pressing up or down arrows. I envision a web where the user would just land on the control and then have some sort of actions list like the rotor on iOS to review the available actions and then select the desired action. This would reduce many interactions down to single taps making custom controls available to users of switch control, prosthetics, and screen readers users who don't want to carry around a keyboard, etc.


Jonathan Avila
Chief Accessibility Officer

703-637-8957 (o)
Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter

-----Original Message-----
From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf Of <EMAIL REMOVED>
Sent: Friday, October 30, 2015 4:32 PM
To: WebAIM Discussion List
Subject: Re: [WebAIM] JavaScript library for display and customization of keyboard shortcuts?

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:

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


Deborah Kaplan