Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add note to 2.1.4 Character Key Shortcuts understanding #2455

Merged
merged 13 commits into from
Aug 27, 2024
Merged

Add note to 2.1.4 Character Key Shortcuts understanding #2455

Changes from all commits
Commits
Show all changes
13 commits
Select commit Hold shift + click to select a range
ee41a48
Add note to 2.1.4 Character Key Shortcuts understanding
patrickhlauke May 22, 2022
b4d5531
Remove the "Note" after the actual note, use `<kbd>` for other shortc…
patrickhlauke May 22, 2022
7a24182
Typo
patrickhlauke May 22, 2022
1ed832a
Tweak the wording around accesskeys
patrickhlauke May 22, 2022
f93375a
Remove punctuation at end of heading
patrickhlauke May 22, 2022
2086d3f
Reformat markup of the understanding document
patrickhlauke Oct 16, 2022
a3c9e40
Add extra note about sequences of character keys
patrickhlauke Oct 16, 2022
6f5ced2
Merge branch 'main' into patrickhlauke-issue2314-character-key-unders…
patrickhlauke Jul 31, 2024
bb5bd5a
Reintroduce all intended changes after a hasty merge commit that wipe…
patrickhlauke Jul 31, 2024
8bcd334
Update understanding/21/character-key-shortcuts.html
mbgower Aug 7, 2024
716f7ce
Clarify `AltGr` being Windows-specific, and use nested `<kbd>`
patrickhlauke Aug 8, 2024
4f33278
Remove unnecessary whitespace
patrickhlauke Aug 8, 2024
ff59653
Update understanding/21/character-key-shortcuts.html
patrickhlauke Aug 20, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
69 changes: 34 additions & 35 deletions understanding/21/character-key-shortcuts.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -15,62 +15,61 @@ <h2>In brief</h2>
<dt>What to do</dt><dd>Ensure character-only shortcut keys can be turned off or modified.</dd>
<dt>Why it's important</dt><dd>Character-key shortcuts are easy to accidentally trigger, especially with speech input.</dd>
</dl>

</section>

<section id="intent">
<h2>Intent</h2>
<p>The intent of this Success Criterion 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 &#8212; whose means of input is strings of letters &#8212; 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.
</p>
<p>Note that this success criterion doesn't affect components such as listboxes and drop-down menus. Although these components contain values (words) that may be selected by one or more character keys, the shortcuts are only active when the components have focus. Other components such as menus may be accessed or opened with a single non-character shortcut (e.g., Alt or Alt+F) before pressing a single character key to select an item. This makes the full path to invoking a menu a two-step shortcut that includes a non-printable key. <a href="https://www.w3.org/TR/html5/single-page.html#the-accesskey-attribute">Accesskeys</a> are also not affected because they include modifier keys.</p>
<h3>Background on the mechanics of speech input:</h3>
<p>Speech Input users generally work in a single mode where they can use a mix of dictation and speech commands. This works well because the user knows to pause before and after commands, and commands are usually at least two words long. So, for instance, a user might say a bit of dictation, such as "the small boat", then pause, and say a command to delete that dictation, such as "Delete Line". In contrast, if the user were to say the two phrases together without a pause, the whole phrase would come out as dictation (i.e., "the small boat delete line"). Although speech input programs often include modes that listen only for dictation or only for commands, most speech users use the all-encompassing mode all the time because it is a much more efficient workflow. It could decrease command efficiency significantly if users were to change to command mode and back before and after issuing each command.</p>
<p>Speech users can also speak most keyboard commands (e.g., "press Control Foxtrot") without any problems. If the website or app is keyboard enabled, the speech user can also write a native speech macro that calls the keyboard command, such as "This Print" to carry out Ctrl+P.</p>
<p>Single-key shortcuts are the exception. While using single letter keys as controls might be appropriate and efficient for many keyboard users, single-key shortcuts are disastrous for speech users. The reason for this is that when only a single key is used to trip a command, a spoken word can become a barrage of single-key commands if the cursor focus happens to be in the wrong place.</p>
<p>For example, a speech-input user named Kim has her cursor focus in the main window of a web mail application that uses common keyboard shortcuts to navigate ("k"), archive ("y") and mute messages ("m"). A coworker named Mike enters her office and says "Hey Kim" and her microphone picks that up. The Y of "hey" archives the current message. K in "Kim" moves down one conversation and M mutes a message or thread. And, if Kim looks up and says "Hey Mike" without remembering to turn off the microphone, the same three things happen in a different sequence.</p>
<p>A user interacting with a webpage or web app that doesn't use single-character shortcuts doesn't have this problem. Inadvertent strings of characters from the speech application are not interpreted as shortcuts if a modifier key is required. A speech user filling in a text input form may find that a phrase that is accidentally picked up by the speech microphone results in stray text being entered into the field, but that is easily seen and undone. The Resources section of this page contains links to videos demonstrating these types of issues.</p>
<p>The intent of this Success Criterion is to reduce accidental activation of keyboard shortcuts. Character key shortcuts work well for many keyboard users. However, they can be inappropriate and frustrating for speech input users whose dictation is interpreted as 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.</p>
<div class="note">
<p>Even though this Success Criterion refers to <q>character keys</q>, note that it's not relevant whether a shortcut can be activated using a single physical key on a keyboard, or if it requires a combination of keys to be pressed. For instance, on most full-size US and UK keyboard, the <kbd>?</kbd> (question mark) symbol is accessed using <kbd><kbd>Shift</kbd>+<kbd>/</kbd></kbd> (forward slash key next to the right-hand <kbd>Shift</kbd> key). On a UK keyboard, in Windows, the <kbd>é</kbd> (lowercase "e" with an acute accent) requires the use of <kbd><kbd>AltGr</kbd>+<kbd>e</kbd></kbd>. The specific key combination required for certain characters will also vary depending on the user's keyboard layout. However, shortcuts that use these characters still fall under the requirements of this Success Criterion. What matters is that a shortcut relies on a printable character (letters, punctuation, numbers, symbol characters), and not the number of physical keyboard keys that users need to press to trigger it.</p>
</div>
<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>
<p>This success criterion doesn't affect components such as listboxes and drop-down menus. Although these components contain values (words) that may be selected by one or more character keys, the shortcuts are only active when the components have focus. Other components such as menus may be accessed or opened with a single non-character shortcut (e.g., <kbd>Alt</kbd> or <kbd><kbd>Alt</kbd>+<kbd>F</kbd></kbd>) before pressing a single character key to select an item. This makes the full path to invoking a menu a two-step shortcut that includes a non-printable key. <a href="https://www.w3.org/TR/html5/single-page.html#the-accesskey-attribute">Accesskeys</a> are also not affected because they are generally (depending on the user agent) activated using modifier keys.</p>
<h3>Background on the mechanics of speech input</h3>
<p>Speech Input users generally work in a single mode where they can use a mix of dictation and speech commands. This works well because the user knows to pause before and after commands, and commands are usually at least two words long. So, for instance, a user might say a bit of dictation, such as "the small boat", then pause, and say a command to delete that dictation, such as "Delete Line". In contrast, if the user were to say the two phrases together without a pause, the whole phrase would come out as dictation (i.e., "the small boat delete line"). Although speech input programs often include modes that listen only for dictation or only for commands, most speech users use the all-encompassing mode all the time because it is a much more efficient workflow. It could decrease command efficiency significantly if users were to change to command mode and back before and after issuing each command.</p>
<p>Speech users can also speak most keyboard commands (e.g., "press Control Foxtrot") without any problems. If the website or app is keyboard enabled, the speech user can also write a native speech macro that calls the keyboard command, such as "This Print" to carry out <kbd><kbd>Ctrl</kbd>+<kbd>P</kbd></kbd>.</p>
<p>Single-key shortcuts are the exception. While using single letter keys as controls might be appropriate and efficient for many keyboard users, single-key shortcuts are disastrous for speech users. The reason for this is that when only a single key is used to trip a command, a spoken word can become a barrage of single-key commands if the cursor focus happens to be in the wrong place.</p>
<p>For example, a speech-input user named Kim has her cursor focus in the main window of a web mail application that uses common keyboard shortcuts to navigate (<kbd>k</kbd>), archive (<kbd>y</kbd>) and mute messages (<kbd>m</kbd>). A coworker named Mike enters her office and says "Hey Kim" and her microphone picks that up. The Y of "hey" archives the current message. K in "Kim" moves down one conversation and M mutes a message or thread. And, if Kim looks up and says "Hey Mike" without remembering to turn off the microphone, the same three things happen in a different sequence.</p>
<p>A user interacting with a webpage or web app that doesn't use single-character shortcuts doesn't have this problem. Inadvertent strings of characters from the speech application are not interpreted as shortcuts if a modifier key is required. A speech user filling in a text input form may find that a phrase that is accidentally picked up by the speech microphone results in stray text being entered into the field, but that is easily seen and undone. The Resources section of this page contains links to videos demonstrating these types of issues.</p>
<section id="benefits">
<h3>Benefits</h3>
<ul>
<li>Speech users will be able to turn off single-key shortcuts so they can avoid accidentally firing batches of them at once. This will allow speech users to make full use of programs that offer single-key shortcuts to keyboard users.</li>
<li>Keyboard-only users who have dexterity challenges can also be prone to accidentally hitting keys. Those users would be able to avoid problematic single character shortcuts by turning them off or modifying them to include at least one non-character key.</li>
<li>Allowing <em>all</em> shortcut keys to be remapped can help users with some cognitive disabilities, since the same shortcuts can be assigned to perform the same actions across different applications.</li>
</ul>
<li>Speech users will be able to turn off single-key shortcuts so they can avoid accidentally firing batches of them at once. This will allow speech users to make full use of programs that offer single-key shortcuts to keyboard users.</li>
<li>Keyboard-only users who have dexterity challenges can also be prone to accidentally hitting keys. Those users would be able to avoid problematic single character shortcuts by turning them off or modifying them to include at least one non-character key.</li>
<li>Allowing <em>all</em> shortcut keys to be remapped can help users with some cognitive disabilities, since the same shortcuts can be assigned to perform the same actions across different applications.</li>
</ul>
</section>
</section>
<section id="examples">
<h2>Examples</h2>
<section class="example">

<h3>Disable Shortcuts</h3>
<p>A mechanism is provided to allow users to disable character-key shortcuts. The character key shortcuts are not the only way to carry out these commands. A speech user disables the shortcuts and can prevent words that are picked up by the microphone from triggering single-key shortcuts.</p>
<h3>Disable Shortcuts</h3>
<p>A mechanism is provided to allow users to disable character-key shortcuts. The character key shortcuts are not the only way to carry out these commands. A speech user disables the shortcuts and can prevent words that are picked up by the microphone from triggering single-key shortcuts.</p>
</section>
<section class="example">

<h3>Alternate Control</h3>

<p>Keyboard-only users are in a long issues thread. While reading the thread they accidentally hit the S key, which moves focus to the search bar at the top of the document. This causes them to lose their place and train of thought. However, a mechanism is provided to allow users to change character-key shortcuts. They change the shortcut to include another key so they can avoid future interruptions.</p>
<h3>Alternate Control</h3>
<p>Keyboard-only users are in a long issues thread. While reading the thread they accidentally hit the S key, which moves focus to the search bar at the top of the document. This causes them to lose their place and train of thought. However, a mechanism is provided to allow users to change character-key shortcuts. They change the shortcut to include another key so they can avoid future interruptions.</p>
</section>

</section>
</section>
<section id="resources">
<h2>Resources</h2>
<p>Web apps that use character-key shortcuts and allow users to disable and/or change these shortcuts:</p>
<ul>
<li>Gmail</li>
<li>WordPress</li>
</ul>
<p>Videos of speech user trouble with single character key shortcuts:</p>
<ul>
<li><a rel="nofollow" href="https://www.youtube.com/watch?v=xzSyIA4OWYE">Single character key shortcuts affecting speech input – example 1</a></li>
<li><a rel="nofollow" href="https://www.youtube.com/watch?v=OPjfpDU9S08">Single character key shortcuts affecting speech input – example 2</a></li>
</ul>
</section>
<ul>
<li>Gmail</li>
<li>WordPress</li>
</ul>
<p>Videos of speech user trouble with single character key shortcuts:</p>
<ul>
<li><a rel="nofollow" href="https://www.youtube.com/watch?v=xzSyIA4OWYE">Single character key shortcuts affecting speech input – example 1</a></li>
<li><a rel="nofollow" href="https://www.youtube.com/watch?v=OPjfpDU9S08">Single character key shortcuts affecting speech input – example 2</a></li>
</ul>
</section>
<section id="techniques">
<h2>Techniques</h2>
<section id="sufficient">
<h3>Sufficient</h3>
<h3>Sufficient</h3>
<ul>
<li><a href="../../techniques/general/G217">G217</a></li>
</ul>
Expand Down