SC problematic for Closed functionality: SC 2.1.4 Character Key Shortcuts

[pday1]

From closed functionality questionnaire:
https://www.w3.org/2002/09/wbs/55145/wcag2ict-sc-problematic-for-closed/results#xq26

Loïc Martínez Normand | First, I agree with Phil about 2.4.7. In addition, 2.1.2 and 2.1.4 are also related to keyboard access. I suggest that we need them with notes similar to 2.1.1Once we agree on the note for 2.1.1, the notes for 2.1.2, 2.1.4 and 2.4.7 could follow a similar approach.

SC text included for reference

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.

Applying SC 2.1.4 Character Key Shortcuts 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 a long press of a key (2 seconds or more) and other accessibility features provided by the platform do not meet the WCAG definition of a keyboard shortcut. See the keyboard shortcut definition for more details.

[pday1]

Proposed content for SC problematic for Closed functionality section:

2.1.4 Character Key Shortcuts- Requires the system to provide character key shortcuts, and thus implies the entry of longer strings or commands through the keyboard. Some closed systems may offer tactilely discernible input such as a numeric keypad or other functional groups of keys, but do not offer any mechanism for keyboard shortcuts, as their mode of operation is for a single key to operate a single function; for example, the keys are used to select options from a spoken menu rather than to enter longer strings or commands. In this case, there are no keyboard shortcuts, and thus no need to modify them.

[maryjom]

Added to survey: Closed Functionality Bullets: SCS 2.5.2, 3.1.1, 3.1.2, 3.2.3, and 4.1.2

[maryjom]

Survey results indicate this proposal needs some work. The discussion at the Friday meeting (see the minutes from 5 January 2024 where we discussed this survey and search for the discussion on 2.1.4 for the direction.

The attendees felt there needs to be context for closed functionality (not just general) as this type of ICT is more likely to not have a full keyboard. It may only have tactilely discernable keys or basic buttons through a touch UI. It may not have character input or keyboard shortcuts at all. Would be good to provide some of the nuance in the guidance for the term "keyboard interface" as well as a bullet discussing that software on ICT that does not provide single-character key shortcuts to activate functionality or does not have an alphanumeric keyboard would automatically meet the intent of this success criterion.

[pday1]

Agreement in meeting of 18 Jan 2024 was to remove the general comment from 2.1.4, but to add a comment to closed functionality (content still to be agreed).

[samogami]

Proposed text for Closed functionality section:
2.1.4 Character Key Shortcuts --
Note 1: Certain closed systems use input mechanisms that are not a full keyboard interface, such as numeric keypads or other functional groups of keys, and lack a mechanism for keyboard shortcuts because their mode of operation revolves around a single key performing a single function. For such systems, this success criterion is satisfied.

Note 2: Where there is no keyboard interface that provides character key input or keyboard shortcuts, this success criterion is satisfied.

---

References
WCAG2ICT SC 2.1.4 Character Key Shortcuts

Note 1 is from TC discussion on Jan 12, 2024
Note 2 is from TC discission on Jan 18, 2024

Definition of keyboard shortcut
Definition of keyboard interface

[pday1]

For ease of review, here is content pulled from the latest Editor's draft to show the original "Applying SC to Non-Web..." alongside the proposed new content for "SC problematic for Closed...".

The latest editor's draft can be found at https://w3c.github.io/wcag2ict/
(Note this does not contain content that is in pull requests that are open and not yet approved)

Content from Applying SC
https://w3c.github.io/wcag2ict/#applying-sc-2-1-4-character-key-shortcuts-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 a long press of a key (2 seconds or more) and other accessibility features provided by the platform do not meet the WCAG definition of a keyboard shortcut. See the keyboard shortcut definition for more details.

Latest proposed content for SC problematic for Closed functionality section

2.1.4 Character Key Shortcuts --

Note 1: Certain closed systems use input mechanisms that are not a full keyboard interface, such as numeric keypads or other functional groups of keys, and lack a mechanism for keyboard shortcuts because their mode of operation revolves around a single key performing a single function. For such systems, this success criterion is satisfied.

Note 2: Where there is no keyboard interface that provides character key input or keyboard shortcuts, this success criterion is satisfied.

[maryjom]

Survey results for the latest 2.1.4 proposal

TF reached consensus on the following language in the 7 March meeting (edited by Mitch, without the proposed Note 2):

• 2.1.4 Character Key Shortcuts - Certain closed systems lack a mechanism for keyboard shortcuts because their mode of operation revolves around a single key performing a single function. For such systems, this success criterion is satisfied.

This is implemented in PR #318.

[maryjom]

The agreed content in PR #318 has been merged so this issue can be closed.