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> 
Sent: Friday, December 16, 2022 5:14 AM
To: John Foliot <john@foliot.ca>
Cc: Wai-Ig <w3c-wai-ig@w3.org>; WCAG <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"