Understanding for 2.1.4 Character Key Shortcuts may require some disambiguation

[patrickhlauke]

From a recent discussion on Slack about 2.1.4 Character Key Shortcuts, it seems there's some confusion about Shift as a modifier key. Dumping some of the discussion here verbatim:

Bruce B 3 hours ago
Another question about SC 2.1.4. Just want to clarify, do punctuation and symbol characters include those that need the Shift key to be accessed? For example, the "?" key takes two key simultaneous key presses Shift + /. Would this still be considered a single character key shortcut and thus one of the three options would be required (turn off, remap, active on focus only)? (edited)

Patrick H. Lauke 3 hours ago
yes, it's about the single character/punctuation mark...as on some keyboard layouts, ? may be accessible directly without Shift.
only non-printable characters/key combinations are excluded

Bruce B 2 hours ago
Thank you @patrick H. Lauke. That is what I thought but I guess I was second guessing myself because the SC makes a note to point out that both lower case and upper case letters are included, and you need Shift for those, so I wasn't 100% sure if they were making an exception for Shift when it concerns letters. I see now that it is the character itself, not the actual keys that are important.

[...]

Bruce B 36 minutes ago
@patrick H. Lauke As you suggested, if on some keyboards ? might be directly accessible without Shift, then could Shift + ? be considered two keys, one of them being a non-printable key, and thus meet 2.1.4 as is? Well, I guess on that keyboard the Shift would produce a different character than ? so it would be impossible to have the key combination Shift + ?? I guess my ultimate question is whether Shift can ever count as a non-printable keyboard key. (edited)

andrewmacpherson 17 minutes ago
I'm unsure if it's safe to assume that a question mark will always require shift.
The USB Human Interface Device scan codes don't differentiate between slash and question-mark. Assuming a keyboard follows USB-HID, question mark is always shift + slash. That would also be true for a USB keyboard with a dedicated question-mark key.
For instance, I have a bunch of keyboards with programmable firmware. I could make a dedicated question mark key, but under the hood the keyboard will send USB shift and slash codes to the computer.
But... not all keyboards follow USB HID :-(
Many laptops' built-in keyboards are still using the PS/2 keyboard standard. I haven't delved into that yet much. Worse, some laptop built-in keyboards are use proprietary non-standards. Cynical me thinks it's a matter of time before Apple, Google, Lenovo, or someone else, messes about with the question mark.
Windows 10 touchscreen keyboards have a question mark key that doesn't need shift. I don't own a Windows touchscreen device, so I've never checked what codes the OS or web browser get. For HTML inputs, the keyboard layout may depend on the type or inputmode.

Patrick H. Lauke 15 minutes ago
@bruce B again, forget about whether it's one key or a combination of keys, and on all or some keyboard, etc. the SC isn't about the key combinations, but about printable and non-printable single characters.

Patrick H. Lauke 8 minutes ago
as printable characters may accidentally be triggered by speech users. Shift on its own is a safe non-printable key, and Shift in combination with another key that doesn't generate printable characters (like F1 for instance) is also safe. but again, don't focus on the key/key combination itself, but on the output...if it's a single printable character you're listening to as a shortcut (upper or lowercase letters, punctuations, ...), then it's a character key shortcut

It would probably be good to somehow reinforce this idea in the understanding document https://www.w3.org/WAI/WCAG21/Understanding/character-key-shortcuts.html that it's not necessarily a single "key" per se that is the problem, but the printable character itself (whether or not the user needed to also use Shift to generate it). Shift itself isn't really a "modifier key" as, if used with a key that generates a printable character, it also results in a printable character (which also falls under the SC) even though it's a two-key keystroke.

The same even applies to keys like AltGr (for instance, on a UK keyboard, Alt + e results in é which is also a single character key that falls under the SC). In short, focus should be perhaps even more on the printable vs non-printable character aspect, and whether or not a modifier or two-key or three-key combination on a particular keyboard layout leads to it or not is irrelevant.

[bruce-usab]

I am all for refreshing Understanding for 2.1.4.

My own understanding is that [early inspiration for] 2.1.4. was more about avoiding conflicts with screenreading software (like JAWS) which, when used with read-only content like a web page, provides un-modified keyboard shortcuts for navigation. For example, plain old h to jump to the next heading.

In the first years after 2.0, Accesskeys (A Good Idea Implemented Poorly) started to gain traction. Typical implementations were good for visual keyboard-only users, for example someone using a mouthstick, but introduced a new problem for screenreaders users.

I am finding very little of that history and context reflected in Understanding for 2.1.4. Ping to @mraccess77 and @awkawk who might affirm or refute my recollection.

[patrickhlauke]

My own understanding is that 2.1.4. was more about avoiding conflicts with screenreading software (like JAWS) which, when used with read-only content like a web page, provides un-modified keyboard shortcuts for navigation. For example, plain old h to jump to the next heading.

Note that JAWS and NVDA don't "pass on" most keys that they themselves consume. So taking the example of h for headings, JAWS/NVDA process this, jump to the next heading, and no actual keyboard event is fired by JavaScript on the page itself.

(this can be checked with something like https://patrickhlauke.github.io/web-tv/input/keyboardevent.html and accessing it with JAWS/NVDA)

[patrickhlauke]

The aim of 2.1.4 is really more specifically about voice access / speech recognition, and accidentally triggering shortcuts when speaking inadvertently while the AT is listening, and then firing emulated keystrokes/key sequences to the page (where they do trigger JavaScript key events)

[bruce-usab]

Again, I am just relying on my own poor memory here. While I believe Accesskeys – and the early problems it was causing for JAWS users – to be the genesis/inspiration for 2.1.4, the barrier in actual practice was resolved by screen reader developers. As you note, nowadays the webpage never gets that h key.

Somewhere along the line, it was noted that users of voice recognition software (e.g., Dragon Dictate) were also having a similar difficulty with unmodified keys (a.k.a. printable characters) being used as accelerator keys. 2.1.4 made it to 2.1 (obviously), with the normative phrasing as proposed originally (or something very close) even as the emphasis in Understanding shifted (appropriately, since Accesskeys stopped being a problem for JAWS (et al.) users).

I am also vaguely remembering a pass through Understanding to de-emphasis support for screen reading software, and emphasize support for any and all other use of assistive technology.

[patrickhlauke]

While I believe Accesskeys – and the early problems it was causing for JAWS users – to be the genesis/inspiration for 2.1.4

2.1.4 was pushed for in the (incorrectly named) Mobile Accessibility TF in the context of voice access by Kim Patch. but it likely fed into / took inspiration from earlier discussions around collisions between things like accesskeys and AT commands.

Anyway, regardless of its origin story, the primary point still stands that the understanding doc should really clarify that this isn't necessarily about single keyboard key shortcuts (where you only press a key), but rather about single character (even if it requires two or more simultaneous key presses to actually generate the printed character)

[bruce-usab]

Agreed. The focus on that slack conversation with regard to shift key is missing the point. There is not much appetite in the WG for dunking on well-intentioned swing-and-a-miss stuff like Accesskeys. Even now it is not obvious to me how (or even if) that early history is helpful. But I think if slack Bruce B ☺ knew more about the background and intent, the question about slash versus question mark would have resolved itself.

Also HT to @jared-w-smith for that excellent article, and so many others!

[mraccess77]

In my experience accesskeys like the accesskey attribute require a modifier to be pressed. While non-access key single key strokes can be issues for users of screen readers - some screen readers have a way to pass them through for specific sites automatically like Twitter - but they would not be preventing access unless that is the only way of performing an action.

Typically, if there is an access key and not proper role associated that allows forms mode I would likely fail under SC 4.1.2.

The intent of 2.1.4 from my knowledge was always around speech recgonition.

[alastc]

So the action is to revise the understanding doc to make sure it is clearly about single character short-cuts rather than pressing single keys?

[patrickhlauke]

@alastc yes, i think so. i can have a think about it/propose a PR in the next few days perhaps

(admittedly, in an ideal world, we'd rename the actual SC to "Single Character Shortcuts" instead of "Character Key Shortcuts", but I guess that's too disruptive a change)

[patrickhlauke]

Added an initial note in this PR #2455 - hope it gets the point across (it handwaves the fact that "key" was probably the wrong term to use for the SC)

[juliemoynatPro]

Sorry to interfere in the discussion but I read you're talking about "single character shortcuts". I'm wondering… what about shortcuts with several characters (like g+i or A+1, etc)? Are they included in the criterion?

Gmail has some like this (you need to activate them before so it's OK but this is an example).

[bruce-usab]

Thanks for that Gmail example @juliemoynatPro — but am I reading that correctly — hold down g tap i ???

JAWS has the option to turn the ins key as a modifier key, and that comes with problems enough. I have to believe there are some complications with using an alphabetical letter as modifier key!

[mraccess77]

I assume these are multiple sequence key presses such as alt+f then release followed by the letter a by itself.

[bruce-usab]

@mraccess77 that is what I would have assumed -- before I read that Gmail documentation link.

[juliemoynatPro]

If you activate the option to use keyboard shortcuts in your Gmail settings, you can test the "Jumping" shortcuts easily. For instance, to go to sent messages, you press "G" and then "T". It works if you press them both together (like a modifier key) or one after the other (multiple sequence key presses).

[JAWS-test]

It works if you press them both together (like a modifier key)

According to my understanding of 2.1.4, this would not be an violation of this SC

or one after the other (multiple sequence key presses).

... but that would be a violation

[bruce-usab]

I am a bit intrigued . With a desktop email client, there would frequently be a text cursor, so holding down the g key would be problematic! I guess that is less of an issue with a web page?

I am relieved g and t can be pressed sequentially. Still, I think that might be a compatibility problem with some AT. It is exactly the behavior 2.1.4 aims to curtain -- and the Gmail implementation allows turning the feature off, so it's a pass.

The other thing I will mention, and 2.1.4 reflects this, is that this sort of unconventional behavior is problematic for anyone relying upon Sticky Keys.

[patrickhlauke]

at a very high level, if a site implemented a series of single key shortcuts that you have to activate in a certain sequence, i'd argue that each individual key you need to press is a single-key shortcut in its own right, so would fail (if there was no way to turn it off etc). the fact that nothing immediately happens after pressing the first single-key shortcut in the sequence is possibly irrelevant, and something does in fact happen behind the scenes...it primes the page to then listen for the next key in the sequence. gets a bit metaphysical to rationalise this though. but the fact remains: if it's a problem that speech users may accidentally trigger a single-key shortcut, it may just as well be a problem is it's a sequence of such single-key shortcuts.

(there's also some cross-over here with 2.1.1 Keyboard that talks about requiring a sequence of keypresses with a certain timing, but this is only applicable if the shortcut sequence was the only way to trigger that functionality)

[juliemoynatPro]

So, if I understand well, the way the criterion is actually written when talking about "single-key shortcuts" (or eventually "single character shortcuts" in the future?) is relevant with this case, right? Wouldn't there still be a need for clarification of this case within the criteria?

[bruce-usab]

Yes, this SC is relevant with this case, I think a very good example actually. But again, this non-conventional behavior is not the default -- and the end user can turn it off.

[GreggVan]

hmmmm I think it is the "eating of keystrokes" that is the problem. So two-key-hotkey sequences are the same as single-key-hotkeys in terms of the problem they present as Patrick points out. But can someone remind me what is the problem we are trying to solve? If the browser is eating keystrokes that are needed for other things — and if it eats them even if you are in an entry field — then that is a problem. But would be a problem for everyone - not just an accessibility problem. But what is the problem if the single keystroke is used for navigation when the keystroke otherwise would have just been ignored? Is it that it can cause the focus to jump around without a person (say a blind person) knowing what was going on because all sighted people could see it jumping around? (Wouldn’t the blind person also notice that they had jumped to new content pretty quickly/) I’m not questioning that there is a problem - just asking for reminder of what it is. Thanks G

…

On Aug 31, 2022, at 7:40 AM, Patrick H. Lauke ***@***.***> wrote: at a very high level, if a site implemented a series of single key shortcuts that you have to activate in a certain sequence, i'd argue that each individual key you need to press is a single-key shortcut in its own right, so would fail (if there was no way to turn it off etc). the fact that nothing immediately happens after pressing the first single-key shortcut in the sequence is possibly irrelevant, and something does in fact happen behind the scenes...it primes the page to then listen for the next key in the sequence. gets a bit metaphysical to rationalise this though. but the fact remains: if it's a problem that speech users may accidentally trigger a single-key shortcut, it may just as well be a problem is it's a sequence of such single-key shortcuts. (there's also some cross-over here with 2.1.1 Keyboard that talks about requiring a sequence of keypresses with a certain timing, but this is only applicable if the shortcut sequence was the only way to trigger that functionality) — Reply to this email directly, view it on GitHub <#2314 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNGDXRZRZNWVJ7VIFKZHW3V35VHRANCNFSM5T2FTR2Q>. You are receiving this because you are subscribed to this thread.

[patrickhlauke]

But can someone remind me what is the problem we are trying to solve?

per https://www.w3.org/WAI/WCAG21/Understanding/character-key-shortcuts.html

The intent of this Success Crition [sic] is to reduce accidental activation of keyboard shortcuts. Character key shortcuts work well for many keyboard users, but are inappropriate and frustrating for speech input users — whose means of input is strings of letters — and for keyboard users who are prone to accidentally hit keys. To rectify this issue, authors need to allow users to turn off or reconfigure shortcuts that are made up of only character keys.

even if you have a shortcut that's a sequence of character key shortcuts, they may be accidentally triggered following the rationale there.

[bruce-usab]

I will suggest that Understanding should probably clarify what is meant by character keys. I will take a stab:

Character keys are letters, numbers, and some symbols that are conventionally typed from a keyboard and typically result in the letter, number, or symbol being entered on-screen. Character keys include upper and lower case variants of letters, and some pairs of symbols are mapped to a single keyboard key by using the Shift modifier key.

[patrickhlauke]

why try to define it, if it's right there in the normative SC text? "using only letter (including upper- and lower-case letters), punctuation, number, or symbol characters"

also...i forgot that i've actually got this PR filed at the time #2455 ... would be nice if this could be discussed/revisited? (and incidentally, it would have saved me filing a separate PR #2723 just this morning to correct a typo that #2455 also already addressed)

[patrickhlauke]

i'd also try to stay away from a definition that talks specifically about "keyboard", as that aspect just opens up ambiguity like "what if on my keyboard i have to use THIS combination to trigger the shortcut, does that count?" (where it's irrelevant how the user physically produces that character, but whether or not that character falls under the printable characters listed in the SC text)

[GreggVan]

There are some pages where the shortcut key is a single character WITHOUT A MODIFIER. This make it impossible to use this key on the keyboard for anything This is usually used on a page where the author did not expect the user to have to be typing anything - but for people with disabilities - they may need to for other reasons. That is what it was trying to prevent.

…

On Oct 11, 2022, at 3:10 AM, Patrick H. Lauke ***@***.***> wrote: But can someone remind me what is the problem we are trying to solve? per https://www.w3.org/WAI/WCAG21/Understanding/character-key-shortcuts.html <https://www.w3.org/WAI/WCAG21/Understanding/character-key-shortcuts.html> The intent of this Success Crition [sic] is to reduce accidental activation of keyboard shortcuts. Character key shortcuts work well for many keyboard users, but are inappropriate and frustrating for speech input users — whose means of input is strings of letters — and for keyboard users who are prone to accidentally hit keys. To rectify this issue, authors need to allow users to turn off or reconfigure shortcuts that are made up of only character keys. even if you have a shortcut that's a sequence of character key shortcuts, they may be accidentally triggered following the rationale there. — Reply to this email directly, view it on GitHub <#2314 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNGDXWEYEVAXEHFYJFUPALWCU4KHANCNFSM5T2FTR2Q>. You are receiving this because you commented.

[patrickhlauke]

This make it impossible to use this key on the keyboard for anything

define what you mean there for "anything". if you mean "they can't control their screen reader" or similar, then no, that's not the case, as the screen reader will generally intercept the keyboard press before it goes to the browser.

[patrickhlauke]

and to be clear, at least at the time it was conceived, this SC was not intended to be about fixing situations where a page may "swallow" or block a particular key from being used for other things. it explicitly intended to solve the issue that speech recognition users may encounter. However, it does have additional benefits of basically avoiding "accidental activation" of features in the page even by keyboard users. but that's more a side effect, not part of the original intent of the SC.

[patrickhlauke]

regarding shortcuts made up of a sequence of characters keys, i've added a further note to my proposed PR #2455

<div class="note">
  <p>The Success Criterion also applies to situations where a shortcut is based on a <em>sequence</em> of character keys – for example, pressing <kbd>G</kbd> and then <kbd>A</kbd> in quick succession to trigger an action. While the individual character key presses don't immediately trigger the action, overall these types of shortcuts still rely on a series of <em>character keys</em>.</p>
</div>