Keyboard shortcuts need to be configurable

(this is because a different discussion started morphing)

Keyboard shortcuts need to be configurable, for various reasons. They are important to various users. Common use case for them include

• “Enterprise apps”. Things that are heavy on “button pressing” like email systems, data management, accounting, etc.
• Browser extensions. Simple functions that are meant to enhance the browser functionality for some pages
• “Accessibility” use cases - for various reasons many users rely heavily on the keyboard (can’t see the mouse, don’t have the body strength to keep moving it around all day, etc).

Current mechanisms for describing keyboard shortcuts fall into two groups:

1. Javascript listeners These are the common approach now. A big benefit is that it allows for real shortcuts (rather than 3- or 4-key combinations). A major drawback is that there is virtually no way to determine what assigned listeners actually do, which makes it very hard to reconfigure anything based on them.

2. accesskey This much-maligned attribute has been somewhat improved in HTML5. It’s big benefit is that it is declarative - it is always visible through the DOM, which means it is easy for two or more scripts that interact to determine what has been assigned already. It is easy for browsers to make accesskeys configurable, allowing a user to reassign an accesskey to a shortcut that is useful although current browser implementation is generally not very helpful. Fortunately, the worst problems which caused it sometimes to be harmful have generally been fixed.

I recently wrote about this issue at more length, so I am not going to repeat it here, but think it is worth looking at further work on accesskey. The HTML Accessibility Task Force is also looking at the issue of focus management including keyboard (but there are other issues such as voice control).

For what it’s worth, Chrome does have a page for configuring extension shortcuts.

Beyond that, I think their mindset is “don’t make behaviors like this something that can vary from user to user”.

The right thing to do is move back to accesskey. It was maligned in the old days for a reason, but many of those reasons have gone away, and others are easy fixable in the browser / AT / add-on pool.

1. It needs to be a standard, so AT and user agents all deal with the keystrokes in the same way.
2. And please can we not do that thing because there were problems in speccing and implementing the standard 10 years ago, we scrap it all and start from scratch.
3. Accesskeys have always had some conflicts with AT, yes. But it has way fewer than it used to in modern implementations, and it has nothing on the clashes between random homegrown Javascript keyboard navigation. There are entire sites I’ve been unable to use because the keyboard navigation can’t be turned off and my AT shortcuts conflict all over the place. Anything that uses unmodified numbers as keyboard shortcuts causes massive problems. And then there’s the way it’s become a pattern to use “/” to get to site search, breaking Firefox and Opera’s wonderful single-key page search.

Asking every webdev to reinvent the wheel because we couldn’t get it together making accesskey work is the opposite of a solution. It’s similar to how everyone hated the problems which happened with target=_blank, so instead of coming up with a standard replacement, every site implements its own modal lightboxes, never accessibly, never with standard ways of getting rid of them, still deeply problematic on mobile or high magnifaction, and we’ve managed to invent the web’s most loathed advertising mechanism.

When individual sites each reimplement the wheel, we get the web we have today, with:

• Completely undocumented keyboard shortcuts on many sites. YouTube, for example, hides an inaccurate list of current keyboard shortcuts on its screen reader page. Accesskey, on the other hand, is self documenting.

• Keystrokes that can’t be exposed to user agent or to AT. Accesskey, which is, can be manipulated, navigated, examined, reported on by browsers, AT, and extensions. In theory, accesskeys could be user-configurable via extension.

• Commands which conflict heavily with some AT, yet which can only be disabled by turning off Javascript – likely to break many modern websites, let alone the single-page apps on which JS keyboard commands are nigh-ubiquitous. Accesskeys, on the other hand, can easily be disabled; I have an extension installed right now which will do just that.

I think in this world of add-ons and extensions – that horse has long since dopplered away from the barn, alas.

Worth noting for devs who didn’t read the other thread and aren’t familiar with the space that “AT” stands for “assistive technologies” like text-to-speech engines / non-visual navigation systems.

Also, for people (like me) who weren’t already familiar with it: accesskey on MDN, on Wikipedia.

More to the point, we effectively need it to vary from user to user, although I understand why that is not an ideal situation.

• As @deborahgu mentioned, people who are using extensions already have a “non-standard” setup, and browsers compete on user interface which seems like a reasonable thing.
• People with screenreaders tend to have a massive set of shortcuts (pages of them, if you read them as a list).
• People who swap keyboard regularly (e.g. working in a non-latin language and having to do anything so backward as write code that only works with latin characters, or hopping around reading email from other people’s computers, or just being used to an AZERTY or a QWERTZ or something because they were born in a large European country) have different shortcuts available depending on what they are doing now.

Effectively web developers should not document the behaviour they expect from the user - in particular because they have no way of knowing if the user can do that, let alone whether it is helpful or causes a crash in a critical system someone has.

Web developers should be identifying things that should have shortcuts, providing a suggestion - that user agents may well ignore, although probably only with a good reason, since it implies extra work - and focus on ensuring that there is a way to know what an assigned shortcut will trigger.

For things with accesskey set, this would match the “accessible name computation”. There is a draft spec, and since 80% isn’t necessary it is easier to read than it looks, if not wonderful.

What is interesting, by which I mean “can’t easily be done today”, is giving a javascript function an accessible name. It isn’t terribly difficult to find a dirty hack or two, but it would be nice if there were a clean standard way to do this task.

I went away and did some thinking and writing: Now there is a proposal.

One technique I’ve had success with is using a single key to activate “keyboard mode”, which then listens for the next keypress (or combo) and fires that. It’s usually implemented with a seldom-used input key, like ;.

When that key is pressed, use JavaScript to announce “keyboard mode” to both visual users and assistive technology, label each accesskeyed element with its shortcut and function, and place role="application" on the body, so the next keypress doesn’t get filtered by assistive technology.

As long as users can remap the “enable keyboard mode” key if it conflicts, this usually works about as well as it can within the constraints provided.

@tigt

Is the application role applied temporarily to the body in order to capture the next keystroke after keyboard mode is invoked?

Yes, this is how Opera 12 works. By default it used shift-esc to activate an accesskey menu, which was then navigable with the mouse as well as being able to press the keys directly. Personally I would remap the command to “,” since that was bound to something I didn’t use.

I had an extension for it (the code is still on Bitbucket, and I would like to update it for modern browsers including the new Opera, although Yandex.browser is my primary target) that let the user select keys to be used, and then accesskeys were reassigned from among that set if they weren’t in it already.

I think this is going to be the way forward if systems want to support sensible keyboard interaction for web apps.

I suspect the sensible approach for e.g. screen readers that already use a lot of the keyboard is to provide their own pass-through keys allowing the user into accesskey mode - which can in turn either be a one-off or continuous for the “gaming” use case.

I’ll raise all these as issues against my proposal "for accesskey"

Yep, and then promptly removed.

One problem that comes up a lot: accesskey is fine for alphanumerics, and works “okay” for common punctuation, but there’s no way to indicate more functional keys are used by the web application. Keys like:

• Esc
• Tab
• Shift
• Backspace/Delete
• Enter/Return
• The spacebar (the enumerated keys in accesskey are space-separated, so…)
• Arrow keys

For games, these could be critical. The best suggestion I’ve seen is using the Control Pictures Unicode block, which indicate such keys without actually invoking them:

• ␛ (Escape)
• ␉ (Horizontal Tab)
• ␎ (Shift Out, maps to Shift)
• ␈ (Backspace)
• ␊ (Linefeed, maps to Enter)
• ␠ (Space)

However, this leaves some leftovers without a Control Picture assigned:

• The Function row of keys (F1, F2, etc.)
• Caps Lock
• The modifier keys: Fn, Ctrl, Alt, and Cmd
• Which side of the keyboard some keys are on, such as Left and Right Shift
• Laptop “hardware function” keys. The media control keys that send “Play/Pause” commands would be especially useful, and I think there’s a spec already in the works for those.
• The arrow keys have no shortage of Unicode arrows to choose from, but is that correct?

Complicating the issue is that accesskey values can only be a single code point, despite already being space-separated.

Did the XHTML Access Module solve any of these problems, or did they just modularize it for its own sake?

Yes. And those keys are indeed important.

This is one reason I propose changing the “acceptable values”.

In any event, the current crop of browsers don’t recognise a space-separated list of tokens anyway, so whatever we do we are talking about a change in implementations and that constraint is only theoretical.

The XHTML access module didn’t directly solve this problem, but it seems (on a quick skim - it is years since I read it carefully) to have taken the same approach I do of allowing the shortcut to be anything, not just a keyboard interaction.

Agreed. One problem is the variety of keyboards and input methods out there; this is a topic browser vendors are way more experienced on. (Microsoft’s full support matrix for languages/input methods/assistive technology is dizzying.) We’ll need them involved for results that don’t bite everyone in the butt.