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.
combining-case-accesskey-manual.html
This tests what happens when using the values accesskey="A"
("A"), accesskey="a"
("a"), accesskey="a"
("a"), accesskey="A"
("A"), and accesskey="b"
("b").
Tested on Mac only. Firefox applies a sequential focus, cycling through the first four, if the A is used as an accesskey without the shift key. shift-ctrl-alt-A has no effect. In blink/webkit browsers, shift-ctrl-alt-a and ctrl-alt-a both activate the fourth link directly. The "b" link works as expected in all browsers.
combining-case-greek-accesskey-manual.html
This tests what happens when using the values accesskey="Α"
("Α"), accesskey="α"
("α"), accesskey="α"
("α"), accesskey="Α"
("Α"), and accesskey="β2;"
("β2;").
Tested on Mac only. Firefox applies a sequential focus, cycling through the first four, if the α is used as an accesskey without the shift key. shift-ctrl-alt-α has no effect. In blink browsers, shift-ctrl-alt-α and ctrl-alt-α both activate the fourth link directly, while in webkit ctrl-alt-α activates the third link and shift-ctrl-alt-α activates the fourth link. The "β" link works as expected in all browsers.
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.