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