accessKeyLabel - author-accessible info about shortcuts

Continuing the discussion from Keyboard shortcuts need to be configurable:

We removed the accessKeyLabel IDL attribute from HTML for lack of implementation - only Firefox does it, and there are quite a lot of bugs if you use the HTML5 version of accesskey that make it much less helpful than it should be.

But it is probably still a useful thing. On the downside browsers fail to make accesskeys discoverable, which is under-implementation, then claim counter to the “priority of constituencies” design principle that it is because the authors should use accessKeyLabel to do that. But it allows developers to add further information that is probably accurate (which is why it is better than aria-kbdshortcut which will rely on the developer accurately implementing then guessing at the overall resulting UX) into the flow of their app.

So I made a draft accessKeyLabel extension proposal. Comments and brickbats - and Pull Requests, especially for the missing things marked as issues there - are most welcome.

Would this be a good place to ask about additional functionality? In particular:

• Assigning multiple keys to the same element — such as both WASD and the arrow keys for movement

• Key combinations — not as common, but they’re out there

• Non-alphanumeric key assignment — the arrow keys are the biggest candidates, but declaratively hooking into the space bar, Tab, and the number pad would be excellent

• To implement the above, perhaps allowing key codes and modifier key enums like the JS keyboard interfaces would be most consistent.

• And of course, fallback options for when certain keys are unavailable/taken

I’m a fan of declaring keyboard shortcuts within HTML for no-JS fallbacks, and also to clearly indicate possible conflicts with existing browser shortcuts. Twitter’s press-/-to-search shortcut and Firefox’s equivalent “quick find” function are the worst example off the top of my head. It also lets the JS functionality go “hands-off” for when the current modifier-key-combo for accesskeys is pressed for a given keyboard shortcut.

The functionality of accessKeyLabel is pretty minimal - explain what shortcuts are assigned. Functionality for shortcuts in general is part of the User interaction for web apps topic…

@chaals Can you elaborate regarding the below statement in the Accesskey improvement draft?

“Only Firefox implements the DOM accessKeyLabel attribute, and that implementation is both fragile and not according to the HTML5 specification.”

In what way is it fragile or non-standard?

We use access keys and access key labels in production at Wikimedia Foundation for all Wikipedia sites. These have been in production since at least 2004 (!).

Specifically, they’re set on action buttons provided by the MediaWiki software. Access keys on anchor links open a url, access keys on buttons simulate a press. This works well by default, and required no custom code on our side, besides a simple attribute on the HTML element.

For example, access key “h” on https://en.wikipedia.org/wiki/WHATWG brings you to the Edit history view of that article. These access keys are used by power users and experienced editors of Wikipedia.

The main problem at the moment is discovery. We currently attempt it by showing the access key in a tooltip using the title attribute (set server-side). In addition, we’d like to provide users with the required key-combination for the access key, since this varies wildly by browser and platform.

The MediaWiki software currently depends on JavaScript module to reverse-engineer the appropiate key-combination at run-time. https://github.com/wikimedia/mediawiki/blob/c749bf6b/resources/src/jquery/jquery.accessKeyLabel.js#L39-L119

We do use accessKeyLabel where possible, such as in Firefox. And this works without issue as far as I can tell. Having more browsers implement this would be a welcome improvement and would simplify the code considerably.

I find it rather unfortunate that W3C has decided to remove accessKeyLabel from the HTML 5.1 revision of the spec. At the moment the Living Standard from WHATWG still specifies it, which is what vendors tend to follow.

But a consistent signal would help here. Would you be willing to reconsider https://github.com/w3c/html/pull/144?

I know the current minimalistic spec of a free-form string explaining the key combination isn’t ideal, but I don’t think machine-readability should be a blocker here.

In addition, I’d actually propose a new property for this. Perhaps a property that exposes an array of machine-readable key descriptions. The UIEvents spec has something for this that could be used. In addition, this property could return other formats as well for non-keyboard triggers (voice commands, gestures, etc.). Rather than a plain array, a class might be even more appropiate. E.g. An AccessTrigger object could have a ‘type’ property describing how the sequence works (keyboard, gesture, voice, etc.), and a ‘sequence’ property with the values for that type. Or perhaps even an array of zero or more AccessTrigger objects. They could have a localisable toString as well.

This seems more scalable in the future as well. As much as I support machine-readability and extensibility, I don’t think trying to fit that into the current string property is appropiate, and inevitably incompatible with the need for a human-friendly text label.

The flexible label currently allows (and encourages) browsers to go one step further and accommodate the user here as best they can. For example, on Mac OS native application menus use symbols instead of words for the keys, and no plus symbols are used to separate them. Firefox reflects this today. That is great!

Web authors shouldn’t have to hardcode or know this fact. Other browsers might do the same, including localisation if appropiate (e.g. “Ctrl and E”), it’s up to the browser and its knowledge of the underlying platform.

Ouch! Half a year is far too long to have replied - I am truly sorry for the long silence.

Roughly:

If there was support for accessKeyLabel from other browsers it would probably go back into HTML, but I think it is the wrong solution as described, and as implemented.

Discovery is indeed a crucial problem. Few browsers ever got this even vaguely right.

Conflict is another one - exacerbated by the failure on discovery. If you can’t learn that ctrl-option-K is meant to do something, and you run voiceover on a mac, you’re at least saved from it working by the implementation. But Wikipedia, trying to do the right thing for Firefox mac users, will tell you it does something different. At the least, a disquieting moment ensues.

The solution is to allow reassignation of accesskeys. Which means that wherever that happens is where the responsibility for discovery has to be (since nobody else can know for sure).

I think accesskey is potentially a really useful idea, allowing shortcuts to be specified - and re-assigned to take account of clashes with reality. But the implementation is not so hot

Authors should not be the ones who determine what shortcut behaviour is used (for that matter, there is no reason it needs to be a key in a world full of speech-enabled devices with motion gesture sensors…). Therefore they are not in a position to set up discovery, which I happen to believe is an important feature of any user interaction.