Case sensitivity in accesskey

[r12a]

6.5.2 The accesskey attribute
https://html.spec.whatwg.org/multipage/interaction.html#the-accesskey-attribute

If specified, the value must be an ordered set of unique space-separated tokens that are case-sensitive, each of which must be exactly one code point in length.

I ran some tests using https://w3c.github.io/i18n-tests/html/editing/assigning-keyboard-shortcuts/the-accesskey-attribute/exp_accesskey_000 with the following results.

Action:

Set accesskey value to 'S', and type 's'

Result:

Mac: accesskey is activated on Chrome, Safari, and Firefox on Mac
Windows: activated on Firefox, Chrome, Edge on Windows. (Although Firefox requires Alt+Shift+key on Windows, so that test is really moot.)
So it seems that none of these browsers respects the case-sensitive requirement of the above spec text when it comes to accelerator keys in ASCII text.

---

Action:

Set accesskey value to 'f', and type 'F'

Result:

same result as previous test

---

Action:

set the value to ‘Α’ (upper case Greek alpha), and type ‘α’ using a Greek keyboard

Result:

Mac: activated on Firefox & Chrome; not activated in Safari
Windows: activated on Edge & Chrome (Firefox requires shift anyway, so test moot)

---

Action:

set the value to ‘α' (lower case Greek alpha), and type ‘Α’ using a Greek keyboard

Result:

Mac: not activated in Safari or Firefox; activated in Chrome
Windows: activated on Edge & Firefox; not activated in Chrome

---

So, in summary, the requirement for case-sensitivity does not appear to be the standard for major browsers, and so should probably be changed. The question is, what kind of case matching is or should be used. Also, how to deal with cases such as Turkish i/İ ı/I (although interestingly, a quick test showed that Safari seems to support that locale-specific case insensitivity).

[asmusf]

If browsers can require the use of the shift key etc., then the accesskey means the key for the letter, not the unicode value of the letter generated when the key is pressed on its own in text entering.

There are probably some keyboard/UI related terminology around that (which I'm not familiar enough with to give further guidance).

[r12a]

Actually, although it's not clearly stated in the spec, the browsers all use the KeyboardEvent.code value, rather than the KeyboardEvent.key value (see https://www.w3.org/TR/uievents/#events-keyboardevents). But, yes, Firefox's comandeering of the shift key does throw a small spanner in the works.