Use of modifier keys for accesskey

[r12a]

5.5.2 The accessKey attribute
http://www.w3.org/TR/html51/editing.html#the-accesskey-attribute

Authors should not use " ", nor characters that normally require a modifier key to generate, as a value of accesskey.

This is a comment from the i18n WG.

What does 'modifier key' include? Does it include the shift key? We think it should, since many writing systems without upper- vs lower-case forms rely on the shift key to reach ordinary characters in their alphabet.

We are also curious as to why the examples use uppercase letters. We don't see any indication that access keys are case-insensitive (which is good!), so i would suggest that the access keys in the examples be given in lower case, anyway.

[chaals]

What does 'modifier key' include? Does it include the shift key?

I don't think we point to a formal definition - perhaps we should. Yes, in my understanding, and I wrote that text, it includes the shift key.

We are also curious as to why the examples use uppercase letters.

Because they were already there... there is no very good reason to do so.

... i would suggest that the access keys in the examples be given in lower case, anyway.

That seems like a good idea in practice. I'll do it...

[aphillips]

The larger problem here is that accesskey is underspecified and makes some inherent assumptions about how keyboard shortcuts work. The spec is a mix of over- and under-specificity. Before I add a few other comments, I'll make mention that WG members think we've addressed similar issues recently, but can't remember where. It might be the "Input Events" spec?

This may not be entirely editorial.

For example, the text says:

If specified, the value must be a single printable character: a string exactly one Unicode code point in length.

It's doubtful that user-agents will test for "printability". Also, some keyboard keys produce multiple Unicode code points. And obviously, not all Unicode code points can be accessed with a single keypress.

I think there is an assumption of case insensitivity, even though the spec doesn't mention it (shortcut keys work with CAPSLOCK on)

7. Fallback Optionally, the user agent may assign a key combination of its choosing as the element’s assigned access key and then abort these steps.

This is also kind of weird, since it says "key combination" but accesskey is elsewhere forced to be a single code point (there is even a step to strip additional code points).

[chaals]

It seems you are looking at outdated text. Please comment on the latest version which has different text. I would also encourage you to look back through #485 which is where you dealt with this before and which links to various tests that show how inconsistent reality is..

Shortcut keys may or may not work with caps lock on, depending on implementations.

In practice, accesskey is not very well specified although it has improved somewhat since HTML 4 which encouraged implementors to do things which broke user experience and trust in nasty ways, and HTML 5.0 which encouraged authors to do things that didn't work.

The implementation is not especially good either.

The assumption is that the user agent should provide a quick and discoverable way to activate elements that the author has identified as needing that, and that the author might give a hint about what may be memorable about the shortcut to associate it with the element.

The reality is that discoverability is generally left to the author, which assumes they know things about the user's environment that they cannot actually determine. And instead of treating the accesskey as a hint, user agents just mix it into some combination of their own devising, which may or may not interfere with the standard user interface.

What happens in practice with the shift key is inconsistent - some user agents trigger on the key that corresponds to the assigned value, some on generating it directly - e.g. "%" is treated differently by different user agents. Values that use latin characters are often treated as case-insensitive, but e.g. greek characters are case-sensitive.

[r12a]

The tests at https://www.w3.org/International/tests/repo/results/accesskey indicate that:

1. When it comes to simple keypresses, Firefox on Mac doesn't support Greek (but Chrome and Safari do), and Edge doesn't support Devanagari.

2. Firefox and Safari on Mac only treat ASCII case-sensitively (Chrome ignores case for other Latin and for Greek). Edge ignores case for Greek, but not for non-ASCII Latin.

3. Chrome & Safari on Mac allow use of shift to modify the key to be matched against the accesskey value. Firefox doesn't. On Windows, Chrome only does this for Devanagari and Edge only for Greek (which could be related to case-insensitive matching). Firefox results for Windows are not given, but this will be problematic, since shortcut keys for Firefox on Windows require alt+shift always.

4. Chrome & Safari happily match keys that produce mulitple characters with accesskey attributes. Firefox doesn't, but that may be because the only keys of that kind i found so far require use of the shift key to reach them. So another test case is needed really. Edge also fails this test, possibly for the same reason.

[r12a]

I can't help thinking that the different behaviours here are down to a lack of standardisation earlier on that looked at the various possible use cases. It may help to add things to the spec in order to clearly standardise what we can at this point, and maybe look at what changes could be made to current browser behaviour to standardise further, rather than just describe the unruly mess of what currently happens.

[LJWatson]

In the interests of getting HTML5.2 into PR soon... is there anything editorial we should try to do before we exit CR, as opposed to the work we evidently need to do to tighten up this bit of the spec in the future?