Examples for SC 2.1.4 too faint - difficult to discern

[spanchang]

Refer to examples for SC 2.1.4 under Related Resources at
https://www.w3.org/WAI/WCAG21/Understanding/character-key-shortcuts.html

The examples are very very faint and extremely difficult to discern.

1. Single character key shortcuts affecting speech input – example 1
2. Single character key shortcuts affecting speech input – example 2

Thanks,
Sailesh

[alastc]

Hi @spanchang,

The videos are external resources, not part of the WCAG information. We can ask @KimPatch if she could produce a video at a smaller resolution at a higher quality of recording. However, that is at up to Kim.

I would note that the examples in the main text cover the same information as the videos.

[spanchang]

Hello @alastc The Understanding doc for the SC describes a situation where the spoken words "Hey Kim" triggers actions within an email app: the Y of "hey" archives the current message and K in "Kim" moves down one conversation.
Explanation for the example of the Understanding doc (Youtube example #2 under Resources on https://www.w3.org/WAI/WCAG21/Understanding/character-key-shortcuts.html) is:
"In Twitter, say "James" and the single character key shortcut J moves down one item, the single character key shortcut m opens the message dialog box, and the "es" is printed in the dialog box".
If this is really happening, is it not the fault of the speech input AT that it parses a word into separate characters and triggers an action based on a phonetic interpretation? I can't understand how "Hey" can be interpreted as "Y" or "Kim" as "K".
If a speech input program (AT) recognizes a shortcut key meant for keyboard action instead of command words, it is something that needs correction / adjustment in the assistive technology. It should not require an action by the content author.
Accidental activation too should not be covered. Surely everyone has experienced calling the wrong person unintentionally or turning on the flash light on an iPhone or perhaps activating a link on a Web page by mistake.
I believe this SC is making developers and designers jump through hoops and increasing the cost of testing and ensuring conformance.
Developers build single character key shortcuts to help certain user groups and now the SC requires them to also incorporate methods by which they can be circumvented. This is not reasonable.
Given that, "Web accessibility depends not only on accessible content but also on accessible Web browsers and other user agents", the onus should be placed on the makers of AT in this instance.
Best wishes and respectfully,
Sailesh

[JAWS-test]

Interestingly, the European accessibility standard prohibits the exclusive use of shortcuts that require two keys to be pressed simultaneously:

5.9 Simultaneous user actions
Where ICT uses simultaneous user actions for its operation, such ICT shall provide at least one mode of operation that does not require simultaneous user actions to operate the ICT.
NOTE: Having to use both hands to open the lid of a laptop, having to press two or more keys at the same time or having to touch a surface with more than one finger are examples of simultaneous user actions (Page 26)

[mraccess77]

In regards to pressing key simultaneously - Most platforms provide a sticky key feature that allows a user to press and release a moodier key. So if that was supported it seems like it could be used.