Re: Duplicate Accesskey Values

Hi Adam,

accesskeys (and accelerator keys) are a technique invented in the early 90's for native operating systems (OS2, Windows). It is widely used by keyboard power users to have immediate direct focus access to input elements or controls. It saves a big amount of tabbing effort to actually reach required fields. This is specifically important to power users who know the user interface and are focused on maximum throughput for data input and task completion.

Design Rationales:
A conservative interaction design model focuses on intended triggers to activate actions to enhance predictability and robustness. Although on one hand this model requires a small amount of additional motor work for pressing a SPACE key it on the other hand avoids memory work (e.g. pure recall) for recognizing and understanding what just had happened and how to undo an unintended activation of a control, plus mental and motor work for finding and executing an reverse/undo action, if needed. This model is also reflected in WCAG 3.2.1 and 3.2.2.

For applications which offer a large set of inputs the technique of using multiple accesskeys is a well appreciated technique and efficiency function.

Immediately triggerable actions may be bound to a CTRL key, as a shortcut/hotkey. These keyboard commands execute directly when pressing the key combination. The CTRL keys can also be used to have effect on manipulating input values, or even without, such as the Plus or Minus keyboard keys would offer to increment or decrement a value in focus. The metaphor is also based on common knowledge (math).

A separation of CTRL for immediate execution and ALT for focus navigation without automatic execution is also a great pattern for reliability and predictability. The user is in control and can predict what happens, before the user actually hits the key combination. In addition this model is also conforming to WCAG 3.2.1 onFocus, so elements can be focused without unpredictable effects.

A UI focused on efficiency may therefore map an access key to a "Save" button (e.g. ALT+S) plus associate a hotkey for direct execution (e.g. CTRL+S).  Advantages: The access key additionally allows a user to navigate to the place of the Save button and then allows tabbing to controls near this control, which is also beneficial to keyboard users.

Keyboard power users unfortunately do not have access to navigation options like screen readers offer, such as navigating to landmarks, headings, control types, or all the other great focus navigation options of a screen reader. Therefore the access key-based focus navigation model is one appreciated alternative for power uses without screen readers to speed up moving the focus on a dialog, screen or page.

Best regards, Oliver.


Am 12/15/22 um 11:35 PM schrieb Adam Cooper <cooperad@bigpond.com>:

Sie erhalten nicht oft eine E-Mail von cooperad@bigpond.com<mailto:cooperad@bigpond.com>. Erfahren Sie, warum dies wichtig ist<https://aka.ms/LearnAboutSenderIdentification>
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 thatduplicate 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"