RE: Duplicate Accesskey Values

Access keys, and keyboard shortcuts in general, are definitely not just for screen reader users. And in fact one could argue the opposite: they're primarily to help sighted keyboard-only users. The vimium plugin for various browsers is almost exclusively for that group, and its whole purpose is to reduce the need to use a mouse on sites that are otherwise not providing shortcuts.

From: Adam Cooper <cooperad@bigpond.com>
Sent: Thursday, December 15, 2022 14:35
To: 'Keim, Oliver' <oliver.keim@sap.com>; 'John Foliot' <john@foliot.ca>
Cc: 'Wai-Ig' <w3c-wai-ig@w3.org>; 'WCAG' <w3c-wai-gl@w3.org>
Subject: RE: Duplicate Accesskey Values

Given that accesskeys are largely only presented to screen reader users the circular focus is redundant because all screen readers have mechanisms to navigate by control type just as efficiently and familiarly.

personally, as someone who has been using a screen reader for decades, I'd prefer that pressing an accesskey actually activated a control rather than merely focused it.

this is especially useful in repetitive tasks such as incrementing and decrementing etc.  as it cuts out yet another keystroke (using a keyboard can be death by a thousand keystrokes).

In fact, I'd go as far as saying that future specifications - accessibility or otherwise - should specify the allocation of accesskeys to certain functions to help with overcoming designer ignorance and developer indolence.

there are keystrokes which are now universal in operating systems and applications such as CTRL + C | V| X so why not the web?




From: Keim, Oliver <oliver.keim@sap.com<mailto:oliver.keim@sap.com>>
Sent: Friday, December 16, 2022 5:14 AM
To: John Foliot <john@foliot.ca<mailto:john@foliot.ca>>
Cc: Wai-Ig <w3c-wai-ig@w3.org<mailto:w3c-wai-ig@w3.org>>; WCAG <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>>
Subject: 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<mailto: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"