Re: Duplicate Accesskey Values

Hi John,

with version 6 of the Internet Explorer a solution for using duplicate access keys has been invented: the duplicate use of the same access key moves focus around, circular, among all UI elements which are mapped to the same access key. So 1, 2 or more UI elements could be mapped to an access key, like "n", to access a number of UI elements by using a short sequence of repeated Alt+n hits.

The prerequisite for enabling a circular focus movement is that no UI element, for which an access key was triggered, does automatically trigger an action.
Buttons were usually doing this in older versions of browsers or operating systems.

With an implemented prerequisite of not automatically executing actions once a button receives focus via access key (or accelerator key)  a repeated use of an access keys provides a great and efficient way to move focus quickly around all mapping UI elements.

So, the duplicate use of accesskeys is not really an issue once all user agents implement the prerequisite.
Alternatively Alt+letters can be catched via Javascript and with focus() the focus can be moved around among all elements matching the accesskey property value.
In these cases a dupliate accesskey would not show up as a failure but rather as an additional opportunity for efficiency.

Best regards, Oliver.

Oliver Keim
Accessibility Expert, Development Architect
SAP SE, Dietmar-Hopp-Allee 16, 69190 Walldorf, Germany


Am 12/15/22 um 5:13 PM schrieb John Foliot <john@foliot.ca>:

Hi All,

Putting aside the fact that Accesskeys are, in context, fairly rare today, I am wondering what others do when they encounter two unique controls that share the same accesskey value.

I've gone through all of WCAG 2.x multiple times, and this use case doesn't seem to have surfaced. The closest analogy I can find is SC 4.1.2, where (I argue) a duplicate Accesskey Value has the same functional impact as a duplicate ID value: i.e. two unique things that share the same trigger mechanism, and no way to address conflict resolution. Currently SC 4.1.2 states "...elements do not contain duplicate attributes..." but the issue isn't a duplicate attribute, but rather a duplicate attribute VALUE. (FWIW, I do note that axe-core's rule set currently calls this out as a Best Practice).

Polling your thoughts - would you fail a duplicate Accesskey value under SC 4.1.2, despite the fact that duplicate Accesskey values are not specifically called out in that SC?

JF
--
John Foliot |
Senior Industry Specialist, Digital Accessibility |
W3C Accessibility Standards Contributor |

"I made this so long because I did not have time to make it shorter." - Pascal "links go places, buttons do things"