Success Criterion 2.1.4: Character Key Shortcuts (Level A)

[samogami]

From Success Criterion 2.1.4:

If a keyboard shortcut is implemented in content using only letter (including upper- and lower-case letters), punctuation, number, or symbol characters, then at least one of the following is true:

• Turn off: A mechanism is available to turn the shortcut off;
• Remap: A mechanism is available to remap the shortcut to include one or more non-printable keyboard keys (e.g., Ctrl, Alt);
• Active only on focus: The keyboard shortcut for a user interface component is only active when that component has focus.

Additional Guidance When Applying Success Criterion 2.1.4 to Non-Web Documents and Software:

• This applies directly as written, and as described in Intent from Understanding Success Criterion 2.1.4 (also provided below).

Note The WCAG2ICT interpretation is that the WCAG definition of a keyboard shortcut does not include a long press of a key (2 seconds or more) or other accessibility features provided by the platform. See the [keyboard shortcut](https://w3c.github.io/wcag2ict/#dfn-keyboard-shortcuts) definition for more details.

[samogami]

Some additional thoughts on SC 2.1.4:

1. Additional note: SC is only applicable when the system provides a keyboard interface.
2. Additional note: Non-character keys include but are not limited to: Function keys (F1...), Esc, Locking keys (Caps Lock, Num Lock, ...), Shift, Backspace, and arrow keys.
3. Some devices do not include non-character keys other than shift. Would the SC still be applicable?
4. The understanding SC 2.1.4 primarily focuses on the benefit to speech input interface users; many systems do not provide this interface type and have limited physical input options. Is the SC applicable when software does not provide a speech input interface for users?

[maryjom]

@samogami Is this ready to have an initial review?

[maryjom]

My thoughts, marked with "MJ:" on your points in the Dec. 13 comment above:

1. Additional note: SC is only applicable when the system provides a keyboard interface.

MJ: Should we instead state that non-web documents and software designed for and installed on devices that have no keyboard interface would automatically meet this requirement?

2. Additional note: Non-character keys include but are not limited to: Function keys (F1...), Esc, Locking keys (Caps Lock, Num Lock, ...), Shift, Backspace, and arrow keys.

MJ: I wonder if this is needed, as WCAG already gives a couple of examples (Ctrl, Alt). I'm not sure I want to get into a debate on what modifier keys are OK vs. not OK or what are best practice. I would prefer to avoid providing sufficient technique details in this document. If the group feels that WCAG should expand on what keys are recommended/acceptable, we should ask them to clarify and open an issue.

If this note is kept, I suggest using the phrase "Non-printable keyboard keys" instead of "Non-character keys" as stated in the SC.

3. Some devices do not include non-character keys other than shift. Would the SC still be applicable?

MJ: I think it would still be applicable. The method of meeting the SC in this case would be to have a setting to turn off the shortcut keys. Remapping keys wouldn't be possible due to the lack of other non-character keys. One could also ensure that character key shortcut activation is limited to the particular UI component that has focus (e.g. in menus) rather than globally available - these are both sufficient techniques in WCAG.

4. The Understanding SC 2.1.4 primarily focuses on the benefit to speech input interface users; many systems do not provide this interface type and have limited physical input options. Is the SC applicable when software does not provide a speech input interface for users?

MJ: I think it would still be applicable. Though it is primarily important for speech input, keyboard-only users who have dexterity challenges can also be prone to accidentally hitting keys.

[Lboniello]

@samogami & @maryjom - When using "Keyboard interface" does this include or also mean tactile input device? If yes, can we shift to using that language instead, as it covers keyboard and others, and is how ADA and other standards reference physical input devices (vs on screen keyboards or inputs)?

(No need to discuss, incorporate if you think it applies, do not incorporate if you do not think it applies here).

[GreggVan]

Keyboard interface - means that it accepts keystrokes from any source. All of these devices end up with "keystrokes" in the keystroke buffer/api to the software. The software does not know where they keystrokes are coming from. - keyboard - on screen keyboard - assistive technology - speech dictation/control If talking about a physical device - (not just software) then - it does not require that you ADD a keyboard - but if you have text input and some way to accept alternate source for text (e.g. bluetooth) then text from that source should also be accepted as keystrokes. But we are only talking about Software and edocuments so — no need to delve into this last part That help? gregg ——————————— Professor, University of Maryland, College Park Founder and Director Emeritus , Trace R&D Center, UMD Co-Founder Raising the Floor. http://raisingthefloor.org The Global Public Inclusive Infrastructure (GPII) http://GPII.net The Morphic project https://morphic.org

…

On Jan 20, 2023, at 8:37 AM, Laura Boniello Miller ***@***.***> wrote: @samogami <https://github.com/samogami> & @maryjom <https://github.com/maryjom> - When using "Keyboard interface" does this include or also mean tactile input device? If yes, can we shift to using that language instead, as it covers keyboard and others, and is how ADA and other standards reference physical input devices (vs on screen keyboards or inputs)? (No need to discuss, incorporate if you think it applies, do not incorporate if you do not think it applies here). — Reply to this email directly, view it on GitHub <#76 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNGDXTO74MUD55EZBK32ATWTK5NVANCNFSM6AAAAAAS4JA6WA>. You are receiving this because you are subscribed to this thread.

[bruce-usab]

From call 1/26, @GreggVan suggested that note might clarify that keys that are held for more than 2 seconds are not keyboard shortcut

[GreggVan]

From the call - the suggestions (as I remember them) were

1. remove the current 2 notes

2. replace them with
   Note: The task force interpreted that the "turn off shortcut" option in the SC included both turning off an individual shortcut or a mechanism that turned off all shortcuts.

3. Modifying our statement on the applicability to say that
   "This SC applies to both [nonweb softw and docs] if you replace xxxx with yyyyy as long as definition of "keyboard shortcut" did not include keys held down for more that 2 seconds before activation."

This would then point the reader to the definition where we could say
NOTE: The task force interpreted of keyboard shortcut did not include actions caused by keys that are held down for more that 2 seconds before activation

The note on the SC is important - because, if the Working group rejected our note on the definition - there needs to be a notation on the SC itself that Task force would no longer accept it as written with just the word substitution.

[loicmn]

From the call, I was asked to write down my position, and I will do so by answering to Gregg's proposal:

1. I agree to remove the current 2 notes
2. I don't agree to add a note to explain that "turning off all shortcuts" is a way of meeting this SC. The reason is that this also happens for web content, and there is nothing specific to "non-web software and documents" for this note. If the WCAG2ICT TF agrees that it is important to clarify this idea of turning off all shortcuts, then I think that we should ask AG for this note to be included in WCAG 2.2.
3. I agree to have some form of note to point to the definition of "keyboard shortcut". What I don't know is the best approach for it. It could be made as Gregg's proposes, or it could be a note or an "note to editors". Whatever works best for the TF.

[maryjom]

@mapluke @trog Please add your thoughts in this issue so we can all learn about your concerns indicated in the poll during the 26 January meeting (See the meeting minutes):

Poll: Clarify second note that individual or all at once turning off satisfies..., add Gregg's proposed note regarding definition and address in the definition of keyboard shortcuts.

[maryjom]

I have a proposal for the definition of "keyboard shortcut".

keyboard-shortcuts

From the WCAG 2.0 definition for keyboard shortcut:

alternative means of triggering an action by the pressing of one or more keys

Additional Guidance When Applying the Definition of “keyboard shortcut” to Non-Web Documents and Software:

This applies directly as written and as described in the WCAG 2.2 glossary.

Note: A key command issued by a long press of a key (2 seconds or more) is not considered a keyboard shortcut. Such commands often occur when there are limited keys, or no modifier keys, present on a device.

[samogami]

Propose that:

1. Remove Note 2
2. Rewrite Note 1 in SC

Note: Long press of a key is not considered a keyboard shortcut. See the keyboard shortcut definition for more details.

3. Add in the WCAG2ITC definitions for keyboard shortcut

NOTE
A key command issued by a long press of a key (2 seconds or more) is not considered a keyboard shortcut. Such commands often occur when there are limited keys, or no modifier keys, present on a device.

[maryjom]

@samogami This seems a reasonable approach, though on closer reading of Gregg's original proposed text we may want to say "long key press (2 seconds or more) before activation". We'll discuss in today's meeting.

[mapluke]

@mapluke @trog Please add your thoughts in this issue so we can all learn about your concerns indicated in the poll during the 26 January meeting (See the meeting minutes):

Poll: Clarify second note that individual or all at once turning off satisfies..., add Gregg's proposed note regarding definition and address in the definition of keyboard shortcuts.

My only concern was related to the way that the long press issue was handled - I now no longer have any concerns.

[bruce-usab]

I am noting that the "at least 2 second" with 508 is under hardware. 407.4 Key Repeat

Where a keyboard with key repeat is provided, the delay before the key repeat feature is activated shall be fixed at, or adjustable to, 2 seconds minimum.

[maryjom]

@ChrisLoiselle The text has been updated in this issue, so you can make the changes in the document now.

[GreggVan]

Just found this old unsent email in drafts…. Sending FYI gregg ——————————— Professor, University of Maryland, College Park Founder and Director Emeritus , Trace R&D Center, UMD Co-Founder Raising the Floor. http://raisingthefloor.org The Global Public Inclusive Infrastructure (GPII) http://GPII.net The Morphic project https://morphic.org

On Jan 18, 2023, at 7:45 AM, Mary Jo Mueller ***@***.***> wrote: My thoughts, marked with "MJ:" on your points in the comment above: Additional note: SC is only applicable when the system provides a keyboard interface. MJ: Should we instead state that non-web documents and software designed for and installed on devices that have no keyboard interface would automatically meet this requirement?

Hmmmmm I think Both of these are not right.. Keyboard interface is not about a keyboard — it is about an applications ability to receive text from anything that is a keyboard or keyboard equivalent. If the device provides voice input that is changed to text and fed to a program - that is fed through the programs "keyboard interface" even if the device has no actual keyboard. Ditto for on-screen keyboards etc. Basically — If it has text input it needs to provide operation through keyboard interface. That does not mean PHYSICAL keyboard - but it needs to be controllable from a keyboard interface. So I think the note is wrong and revised note is wrong too.

Additional note: Non-character keys include but are not limited to: Function keys (F1...), Esc, Locking keys (Caps Lock, Num Lock, ...), Shift, Backspace, and arrow keys. MJ: I wonder if this is needed, as WCAG already gives a couple of examples (Ctrl, Alt). I'm not sure I want to get into a debate on what modifier keys are OK vs. not OK or what are best practice. I would prefer to avoid providing sufficient technique details in this document. If the group feels that WCAG should expand on what keys are recommended/acceptable, we should ask them to clarify and open an issue. If this note is kept, I suggest using the phrase "Non-printable keyboard keys" instead of "Non-character keys" as stated in the SC.

We should not say anything at all about "non-character" keys. Their name is clear and any list is just going to end with etc. which means we are just throwing it open anyway. Best to keep hands off to avoid unintended consequences.

Some devices do not include non-character keys other than shift. Would the SC still be applicable? MJ: I think it would still be applicable. The method of meeting the SC in this case would be to have a setting to turn off the shortcut keys. Remapping keys wouldn't be possible due to the lack of other non-character keys. One could also ensure that character key shortcut activation is limited to the particular UI component that has focus (e.g. in menus) rather than globally available - these are both sufficient techniques in WCAG.

Agree

The Understanding SC 2.1.4 <https://www.w3.org/WAI/WCAG22/Understanding/character-key-shortcuts.html> primarily focuses on the benefit to speech input interface users; many systems do not provide this interface type and have limited physical input options. Is the SC applicable when software does not provide a speech input interface for users? MJ: I think it would still be applicable. Though it is primarily important for speech input, keyboard-only users who have dexterity challenges can also be prone to accidentally hitting keys.

It is applicable to so many different input techniques. Speech, morse code, scanning, gesture-based text input, Direct Brain Input (DBI) and the list goes on. Speech is just one example.

…

— Reply to this email directly, view it on GitHub <#76 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNGDXQEZHPBJMQSDJZKEGLWTAFZDANCNFSM6AAAAAAS4JA6WA>. You are receiving this because you are subscribed to this thread.

[maryjom]

@GreggVan We discussed, agreed upon, and made a resolution on the one note that is now in the very top description in this issue, as well as the definition interpretation content during last week's meeting. See the 2 Feb. meeting minutes for more details and the discussion.

[maryjom]

AG WG has a survey open until 16 March with AG WG survey results discussion at a TBD future date (after CSUN conference).

[maryjom]

On 21 March, the AG WG approved this content with changes that have since been merged.