Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use of modifier keys for accesskey #1012

Closed
r12a opened this issue Sep 8, 2017 · 6 comments

Comments

Projects
None yet
4 participants
@r12a
Copy link

commented Sep 8, 2017

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.

@r12a r12a added the i18n-comment label Sep 8, 2017

@chaals chaals self-assigned this Sep 8, 2017

@chaals chaals added the editorial label Sep 8, 2017

@chaals

This comment has been minimized.

Copy link
Collaborator

commented Sep 9, 2017

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

This comment has been minimized.

Copy link

commented Sep 10, 2017

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)

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

This comment has been minimized.

Copy link
Collaborator

commented Sep 10, 2017

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

This comment has been minimized.

Copy link
Author

commented Sep 15, 2017

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

This comment has been minimized.

Copy link
Author

commented Sep 15, 2017

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

This comment has been minimized.

Copy link
Collaborator

commented Sep 19, 2017

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?

@chaals chaals added this to the HTML5.3 WD1 milestone Dec 14, 2017

chaals pushed a commit that referenced this issue Jan 28, 2018

chaals
Clarify accesskey
fix #1012 , #1023

Editorial.

Clarify the suggestions to authors.

LJWatson added a commit that referenced this issue Jan 30, 2018

Clarify accesskey (#1159)
* Clarify accesskey

fix #1012 , #1023

Editorial.

Clarify the suggestions to authors.

* Whoops. Commit changes

(missed some of the changes made)

* Added Russian language markup, corrected Capitalisation.

* Capitalisation fix

* fxi typo
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.