accesskey tests

It seems that implementation of the accesskey element is poorly tested, at least in the last decade. I have therefore put together a series of tests to accompany my proposal to update interaction with Web Applications, which itself centres on accesskey as a method for resolving various problems.

All the tests provide one or more controls, and attempt to use the DOM attributes accessKey and accessKeyLabel to provide more information about the assigned shortcut. Results are recorded in the individual test pages, and roughly summarised below.

The following tests are available:

accesskey-cyrillic-latin-link-manual.html

This test uses accesskey="я g" to test whether browsers support the HTML5 processing model. For users whose keyboard does not generate cyrillic, but does generate latin characters, the user agent should assign an accesskey based on "g".

Except in IE/Edge, browser don't make any accesskey available.

accesskey-cyrillic-latin-manual.html

This test uses accesskey="я g" to test whether browsers support the HTML5 processing model. For users whose keyboard does not generate cyrillic, but does generate latin characters, the user agent should assign an accesskey based on "g".

Except in IE/Edge, browser don't make any accesskey available.

accesskey-cyrillic-manual.html

This tests whether browsers usefully implement accesskey as specified by HTML4, relying on the user having a cyrillic keyboard to generate the character "я" as a shortcut.

Results so far are good - all tested browsers assign a usable accesskey when the user has a cyrillic keyboard.

accesskey-duplicate-key-manual.html

This tests what happens when the same value is used for the HTML accesskey attribute on two different elements. Neither HTML 4 nor HTML5 explain what should happen in this case.

IE, Edge and Firefox move the focus sequentially to each item with the same accesskey, Webkit/Blink-based browsers activate the last item in source order

accesskey-focus-manual.html

This tests what happens when an accesskey attribute is placed on an h3 element that has an activation behaviour thanks to an onclick attribute. HTML5 requires that activating the assigned accesskey shortcut activates the element, or fires a click event at it, but not that it is focusable.

Results so far are "interesting". Browsers implement the spec requirement, but if you don't have the relevant shortcut available there is no way to focus and activate the heading using the keyboard.

accesskey-hiragana-manual.html

This tests what happens with accesskey="こ", and a hidden link that has accesskey="b".　This is a difficult test: Most users in Japanese use the latin-based romaji input method, and keyboards run composition mode automatically.

Results on Mac browsers are that the "b" accesskey is triggered.

accesskey-latin-with-spaces-manual.html

This tests a basic requirement of the HTML5 processing model, that the value of accesskey can be optionally surrounded by spaces.

Only IE/Edge assign an accesskey.

accesskey-multiple-keys.html

This tests what happens when there are three elements with accesskey attributes valid for HTML 4 and HTML5.

Results so far are good. Many browsers pass this test, although Yandex' implementation is hard to use because the popup blocker is triggered.

accesskey-percent-manual.html

This tests a basic requirement, that the value of accesskey can be a punctuation character which normally requires a modifier key to generate.

Results so far are good - all browsers tested assign an accesskey. Firefox' behaviour is unusual in that it assigns an accesskey based on the "5" key that generates the character, without using modifier. IE focuses the link rather than activate it.

accesskey-reflected-manual.html

This tests a basic requirement of the HTML5 definition, that the DOM accessKey reflect the HTML attribute, so any changes to its value are also made to the DOM attribute.

Results so far are good - all browsers tested do reflect the attribute.

accesskey-space-manual.html

This tests what happens with accesskey=" ".

No MacOS browser enables the accesskey to be triggered. Edge on Windows activates the link, but a pop-up warning is triggered. IE focuses the link. Firefox and Yandex on windows open the window menu - the default system action.

accesskey-two-latin-manual.html

This tests a basic requirement of the HTML5 processing model, that using space-separated tokens results in some accesskey being assigned if possible.

Results so far are depressing - except IE, no browser assigns an accesskey.

accesskey-word-manual.html

This tests what happens if the value of the HTML attribute is a word rather than single space-separated characters.

Only IE/Edge assign an accesskey, which is the first letter of the word.

accesskeylabel-manual.html

This test uses accesskey="話 я g" to test implementation of the HTML5 processing model - since the character "話" is not available from any normal keyboard, it should never be assigned, and one of the other characters or a fallback character of the user agent's choosing should be used instead.

No browser found to pass.

There are another set of tests available, as part of my random testcase repository.

combined-hindi-accesskey-manual.html

This tests what happens when a Devanagari character that represents more than one code point is used, as in accesskey="क्ष" where the character represents 3 distinct code points - as shown if you copy it and then try to delete it with backspace.

Some browsers on Mac and Windows recognise the accesskey, with an appropriate keyboard, others don't.

combining-accesskey-manual.html

This tests what happens when using the values accesskey="ç", accesskey="ñ" ("ñ"), accesskey="n" to compare with the previous one, and accesskey="A" ("A").

No browsers on Mac and Windows recognise the accesskey "ñ", the others work as expected.

This project is on github including these tests, and I welcome contributions, issues, and especially results for platforms I have not tested yet.

Summary of results

Testing a handful of browsers on Mac, the results suggest that the HTML5 processing model for accesskey is not implemented by any of them. The DOM accessKey attribute is reflected as required in all browsers tested so far, and Firefox has a (not very clever, and not conformant) implementation of the accessKeyLabel. But otherwise anything except a single character value of the HTML accesskey attribute does nothing useful at all.