From 27e0688898e34fcb59b63464e06f0e61fefd87ec Mon Sep 17 00:00:00 2001 From: "Patrick H. Lauke" Date: Thu, 27 Aug 2026 21:47:53 +0100 Subject: [PATCH 01/18] Rework understanding prose * expand the focus to not be primarily about speech users * expand the speech input explainer to match reality a bit better * remove the outdated resources section --- understanding/21/character-key-shortcuts.html | 29 ++++++------------- 1 file changed, 9 insertions(+), 20 deletions(-) diff --git a/understanding/21/character-key-shortcuts.html b/understanding/21/character-key-shortcuts.html index 8d4e7de2ed..58e34dcc3d 100644 --- a/understanding/21/character-key-shortcuts.html +++ b/understanding/21/character-key-shortcuts.html @@ -13,13 +13,13 @@

In brief

Goal
Reduce accidental activation of keyboard shortcuts.
What to do
Ensure character-only shortcut keys can be turned off or modified.
-
Why it's important
Character-key shortcuts are easy to accidentally trigger, especially with speech input.
+
Why it's important
Character-key shortcuts are easy to accidentally trigger, especially for keyboard and speech input users.

Intent

-

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.

+

The intent of this success criterion is to reduce accidental activation of keyboard shortcuts. Character key shortcuts work well for many keyboard users. However, particularly if the shortcuts are mapped to single characters that are triggered without any modifier keys, keyboard users may trigger them accidentally. These shortcuts can also be problematic for certain voice control/speech recognition users, as some of the software used by this user group converts any speech into simulated key presses, which can lead to unintended activations. To rectify this issue, authors need to allow users to turn off or reconfigure shortcuts that are mapped to single character keys.

Even though this success criterion refers to character keys, 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 ? (question mark) symbol is accessed using Shift+/ (forward slash key next to the right-hand Shift key). On a UK keyboard, in Windows, the é (lowercase "e" with an acute accent) requires the use of AltGr+e. 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.

@@ -27,19 +27,18 @@

Intent

The success criterion also applies to situations where a shortcut is based on a sequence of character keys – for example, pressing G and then A 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 character keys.

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. Access keys are also not affected because they are generally (depending on the user agent) activated using modifier keys.

+

Background on the mechanics of speech input

-

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.

-

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.

-

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.

-

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.

-

A user interacting with a web page 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.

+

Speech input users generally work in a single mode where they can use a mix of dictation and speech commands.

+

In most cases, voice control/speech recognition software is "context-aware" – speech is not interpreted as dictation, unless focus is on a form control or field that accepts keyboard input. Otherwise, speech is only interpreted as a command. In addition, even when focus is inside a form control or field that accepts keyboard input, dictation does not generate "faked" synthetic key presses – these only happen when a user gives an explicit command, such as "Press X key".

+

However, there are some voice control/speech recognition programs (such as Talon Voice) that are not "context-aware". All speech is interpreted as either a command or dictation. 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"). Critically, programs that are not "context-aware" will turn dictation into synthetic key presses, meaning that an unintentionally spoken word can become a barrage of single-key commands if the cursor focus happens to be in the wrong place.

Benefits

@@ -55,16 +54,6 @@

Alternate Control

Resources

-

Web apps that use character-key shortcuts and allow users to disable and/or change these shortcuts:

- -

Videos of speech user trouble with single character key shortcuts:

-
{% # Data for associated techniques is defined in understanding/understanding.11tydata.js %} {% include "understanding/techniques.html" %} From 31d448228ae94ba1d48dadf1037fd139fc3b0533 Mon Sep 17 00:00:00 2001 From: "Patrick H. Lauke" Date: Thu, 27 Aug 2026 23:46:48 +0100 Subject: [PATCH 02/18] TODO placeholder: section for SRs and keyboard --- understanding/21/character-key-shortcuts.html | 3 +++ 1 file changed, 3 insertions(+) diff --git a/understanding/21/character-key-shortcuts.html b/understanding/21/character-key-shortcuts.html index 58e34dcc3d..6f88a00fdd 100644 --- a/understanding/21/character-key-shortcuts.html +++ b/understanding/21/character-key-shortcuts.html @@ -32,6 +32,9 @@

Background on the mechanics of speech input

Speech input users generally work in a single mode where they can use a mix of dictation and speech commands.

In most cases, voice control/speech recognition software is "context-aware" – speech is not interpreted as dictation, unless focus is on a form control or field that accepts keyboard input. Otherwise, speech is only interpreted as a command. In addition, even when focus is inside a form control or field that accepts keyboard input, dictation does not generate "faked" synthetic key presses – these only happen when a user gives an explicit command, such as "Press X key".

However, there are some voice control/speech recognition programs (such as Talon Voice) that are not "context-aware". All speech is interpreted as either a command or dictation. 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"). Critically, programs that are not "context-aware" will turn dictation into synthetic key presses, meaning that an unintentionally spoken word can become a barrage of single-key commands if the cursor focus happens to be in the wrong place.

+ +

Screen readers and keyboard interactions

+

Benefits

From f384ccb8952bc276b64e3b08ce8f75d5ca50561a Mon Sep 17 00:00:00 2001 From: "Patrick H. Lauke" Date: Sun, 30 Aug 2026 02:13:07 +0100 Subject: [PATCH 03/18] Add working character key shortcut example --- .../character-key-shortcuts/index.html | 99 +++++++++++++++++++ 1 file changed, 99 insertions(+) create mode 100644 working-examples/character-key-shortcuts/index.html diff --git a/working-examples/character-key-shortcuts/index.html b/working-examples/character-key-shortcuts/index.html new file mode 100644 index 0000000000..f75fd0904e --- /dev/null +++ b/working-examples/character-key-shortcuts/index.html @@ -0,0 +1,99 @@ + + + + + + Character Key Shortcuts + + + +

Character Key Shortcuts

+

This working example logs JavaScript key events being fired on the document. Relates to Success Criterion 2.1.4 Character Key Shortcuts.

+

This paragraph has a role="application" to force Windows-based assistive tech (like JAWS and NVDA) to pass keyboard events directly to the page, rather than intercepting them.

+
+ + + + +
+

Output

+

Log of all JavaScript key events (keydown, keyup, keypress). Also flags if the key event relates to a printable character, meaning it's a character key.

+ + + + From 35089b74a0a108e5738627001bcd0203470f5811 Mon Sep 17 00:00:00 2001 From: "Patrick H. Lauke" Date: Tue, 1 Sep 2026 00:43:03 +0100 Subject: [PATCH 04/18] Tweak speech recognition explanation further --- understanding/21/character-key-shortcuts.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/understanding/21/character-key-shortcuts.html b/understanding/21/character-key-shortcuts.html index 6f88a00fdd..61244d6050 100644 --- a/understanding/21/character-key-shortcuts.html +++ b/understanding/21/character-key-shortcuts.html @@ -29,9 +29,9 @@

Intent

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. Access keys are also not affected because they are generally (depending on the user agent) activated using modifier keys.

Background on the mechanics of speech input

-

Speech input users generally work in a single mode where they can use a mix of dictation and speech commands.

+

Speech input users generally work in a single mode where they can use a mix of dictation and speech commands. 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").

In most cases, voice control/speech recognition software is "context-aware" – speech is not interpreted as dictation, unless focus is on a form control or field that accepts keyboard input. Otherwise, speech is only interpreted as a command. In addition, even when focus is inside a form control or field that accepts keyboard input, dictation does not generate "faked" synthetic key presses – these only happen when a user gives an explicit command, such as "Press X key".

-

However, there are some voice control/speech recognition programs (such as Talon Voice) that are not "context-aware". All speech is interpreted as either a command or dictation. 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"). Critically, programs that are not "context-aware" will turn dictation into synthetic key presses, meaning that an unintentionally spoken word can become a barrage of single-key commands if the cursor focus happens to be in the wrong place.

+

However, there are some voice control/speech recognition programs (such as Talon Voice) that are not "context-aware". All speech is interpreted as either a command or dictation, regardless of where the current focus is. In addition, saying certain specific words will be interpreted by some software as a shorthand for the "Press … key" command, leading to potential unintentional single key presses. Critically, programs that are not "context-aware" may also turn dictation into synthetic key presses, meaning that an unintentionally spoken word can become a sequence of single-key commands if the cursor focus happens to be in the wrong place. Character key shortcuts will be problematic for users of these non-context-aware programs.

Screen readers and keyboard interactions

From 0b4645f834c54f6a8cae9d0deeec0a58e6b43b49 Mon Sep 17 00:00:00 2001 From: "Patrick H. Lauke" Date: Tue, 1 Sep 2026 00:48:23 +0100 Subject: [PATCH 05/18] Further tweaks to speech --- understanding/21/character-key-shortcuts.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/understanding/21/character-key-shortcuts.html b/understanding/21/character-key-shortcuts.html index 61244d6050..eb47a62675 100644 --- a/understanding/21/character-key-shortcuts.html +++ b/understanding/21/character-key-shortcuts.html @@ -30,8 +30,8 @@

Intent

Background on the mechanics of speech input

Speech input users generally work in a single mode where they can use a mix of dictation and speech commands. 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").

-

In most cases, voice control/speech recognition software is "context-aware" – speech is not interpreted as dictation, unless focus is on a form control or field that accepts keyboard input. Otherwise, speech is only interpreted as a command. In addition, even when focus is inside a form control or field that accepts keyboard input, dictation does not generate "faked" synthetic key presses – these only happen when a user gives an explicit command, such as "Press X key".

-

However, there are some voice control/speech recognition programs (such as Talon Voice) that are not "context-aware". All speech is interpreted as either a command or dictation, regardless of where the current focus is. In addition, saying certain specific words will be interpreted by some software as a shorthand for the "Press … key" command, leading to potential unintentional single key presses. Critically, programs that are not "context-aware" may also turn dictation into synthetic key presses, meaning that an unintentionally spoken word can become a sequence of single-key commands if the cursor focus happens to be in the wrong place. Character key shortcuts will be problematic for users of these non-context-aware programs.

+

In most cases, voice control/speech recognition software is "context-aware" – speech is not interpreted as dictation, unless focus is on a form control or field that accepts keyboard input. Otherwise, speech is only interpreted as a command. In addition, even when focus is inside a form control or field that accepts keyboard input, dictation does not generate "faked" synthetic key presses – the spoken text is generally injected directly into the relevant form control/field. Synthetic key presses only happen when a user gives an explicit command, such as "Press X key".

+

However, there are some voice control/speech recognition programs (such as Talon Voice) that are not "context-aware". All speech is interpreted as either a command or dictation, regardless of where the current focus is. In addition, saying certain keywords is interpreted by some programs as a shorthand for the "Press … key" command, leading to potential unintentional single key presses. Critically, programs that are not "context-aware" may also turn dictation into synthetic key presses, meaning that an unintentionally spoken word can become a sequence of single-key commands if the cursor focus happens to be in the wrong place. Character key shortcuts will be problematic for users of these non-context-aware programs.

Screen readers and keyboard interactions

From 93e7acbbf3b5784a81a149fc7732742c43fd5988 Mon Sep 17 00:00:00 2001 From: "Patrick H. Lauke" Date: Tue, 1 Sep 2026 01:15:02 +0100 Subject: [PATCH 06/18] Add initial draft about Windows/macOS SRs --- understanding/21/character-key-shortcuts.html | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/understanding/21/character-key-shortcuts.html b/understanding/21/character-key-shortcuts.html index eb47a62675..eaf771d2ef 100644 --- a/understanding/21/character-key-shortcuts.html +++ b/understanding/21/character-key-shortcuts.html @@ -34,7 +34,9 @@

Background on the mechanics of speech input

However, there are some voice control/speech recognition programs (such as Talon Voice) that are not "context-aware". All speech is interpreted as either a command or dictation, regardless of where the current focus is. In addition, saying certain keywords is interpreted by some programs as a shorthand for the "Press … key" command, leading to potential unintentional single key presses. Critically, programs that are not "context-aware" may also turn dictation into synthetic key presses, meaning that an unintentionally spoken word can become a sequence of single-key commands if the cursor focus happens to be in the wrong place. Character key shortcuts will be problematic for users of these non-context-aware programs.

Screen readers and keyboard interactions

- +

On Windows, screen readers (such as Jaws, NVDA, and Narrator) generally intercept all key presses, as many of the shortcuts to control screen readers use single keys. Key presses are then only passed on to web content depending on the context. For instance, if focus is on a button element, only Space and Enter key presses (and a few generic keys, such as Tab) will be passed to the web content – any other key presses will be "swallowed" by the screen reader. This behavior is overridden in HTML when elements have a role="application", or are children of an element with that role. In general, character key shortcuts won't be problematic for Windows screen reader users, as it's unlikely that they'd accidentally trigger a shortcut.

+

On macOS, the default VoiceOver commands use modifier keys (Command, Ctrl, Option). VoiceOver won't intercept key presses, meaning that any arbitrary key presses will be passed on directly to web content, just as for regular keyboard users. Switching VoiceOver to "single-key quick navigation" will result in key presses associated with commands to be intercepted, while other key presses are still passed on – and role="application" has no influence on this. As a result, screen reader users on macOS may accidentally trigger character key shortcuts, the same way regular keyboard users can.

+

Benefits

From 1334c08d9c4d64dfb5d9b3af50034d6f66e164c6 Mon Sep 17 00:00:00 2001 From: "Patrick H. Lauke" Date: Tue, 1 Sep 2026 01:18:07 +0100 Subject: [PATCH 07/18] Add some emphasis to the "character key doesn't mean single physical keyboard key" section --- understanding/21/character-key-shortcuts.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/understanding/21/character-key-shortcuts.html b/understanding/21/character-key-shortcuts.html index eaf771d2ef..3438dd0faa 100644 --- a/understanding/21/character-key-shortcuts.html +++ b/understanding/21/character-key-shortcuts.html @@ -21,7 +21,7 @@

In brief

Intent

The intent of this success criterion is to reduce accidental activation of keyboard shortcuts. Character key shortcuts work well for many keyboard users. However, particularly if the shortcuts are mapped to single characters that are triggered without any modifier keys, keyboard users may trigger them accidentally. These shortcuts can also be problematic for certain voice control/speech recognition users, as some of the software used by this user group converts any speech into simulated key presses, which can lead to unintended activations. To rectify this issue, authors need to allow users to turn off or reconfigure shortcuts that are mapped to single character keys.

-

Even though this success criterion refers to character keys, 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 ? (question mark) symbol is accessed using Shift+/ (forward slash key next to the right-hand Shift key). On a UK keyboard, in Windows, the é (lowercase "e" with an acute accent) requires the use of AltGr+e. 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.

+

Even though this success criterion refers to character keys, 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 ? (question mark) symbol is accessed using Shift+/ (forward slash key next to the right-hand Shift key). On a UK keyboard, in Windows, the é (lowercase "e" with an acute accent) requires the use of AltGr+e. 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.

The success criterion also applies to situations where a shortcut is based on a sequence of character keys – for example, pressing G and then A 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 character keys.

From 294201273c4c1704244ee7e876d2ce4ff934fd4f Mon Sep 17 00:00:00 2001 From: "Patrick H. Lauke" Date: Tue, 1 Sep 2026 15:27:23 +0100 Subject: [PATCH 08/18] Add Orca/Linux information --- understanding/21/character-key-shortcuts.html | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/understanding/21/character-key-shortcuts.html b/understanding/21/character-key-shortcuts.html index 3438dd0faa..a7b713b90a 100644 --- a/understanding/21/character-key-shortcuts.html +++ b/understanding/21/character-key-shortcuts.html @@ -33,10 +33,11 @@

Background on the mechanics of speech input

In most cases, voice control/speech recognition software is "context-aware" – speech is not interpreted as dictation, unless focus is on a form control or field that accepts keyboard input. Otherwise, speech is only interpreted as a command. In addition, even when focus is inside a form control or field that accepts keyboard input, dictation does not generate "faked" synthetic key presses – the spoken text is generally injected directly into the relevant form control/field. Synthetic key presses only happen when a user gives an explicit command, such as "Press X key".

However, there are some voice control/speech recognition programs (such as Talon Voice) that are not "context-aware". All speech is interpreted as either a command or dictation, regardless of where the current focus is. In addition, saying certain keywords is interpreted by some programs as a shorthand for the "Press … key" command, leading to potential unintentional single key presses. Critically, programs that are not "context-aware" may also turn dictation into synthetic key presses, meaning that an unintentionally spoken word can become a sequence of single-key commands if the cursor focus happens to be in the wrong place. Character key shortcuts will be problematic for users of these non-context-aware programs.

-

Screen readers and keyboard interactions

-

On Windows, screen readers (such as Jaws, NVDA, and Narrator) generally intercept all key presses, as many of the shortcuts to control screen readers use single keys. Key presses are then only passed on to web content depending on the context. For instance, if focus is on a button element, only Space and Enter key presses (and a few generic keys, such as Tab) will be passed to the web content – any other key presses will be "swallowed" by the screen reader. This behavior is overridden in HTML when elements have a role="application", or are children of an element with that role. In general, character key shortcuts won't be problematic for Windows screen reader users, as it's unlikely that they'd accidentally trigger a shortcut.

+

Keyboard use with screen readers

+

The behavior or screen readers when it comes to keyboard interactions, and whether or not key presses are passed on to web content, varies depending on the specific platform and screen reader used.

+

On Windows, screen readers such as Jaws, NVDA, and Narrator generally intercept all key presses, as many of the shortcuts to control screen readers use single keys. Key presses are then only passed on to web content depending on the context. For instance, if focus is on a button element, only Space and Enter key presses (and a few generic keys, such as Tab) will be passed to the web content – any other key presses will be "swallowed" by the screen reader. This behavior is overridden in HTML when elements have a role="application", or are children of an element with that role. In general, character key shortcuts won't be problematic for Windows screen reader users, as it's unlikely that they'd accidentally trigger a shortcut.

On macOS, the default VoiceOver commands use modifier keys (Command, Ctrl, Option). VoiceOver won't intercept key presses, meaning that any arbitrary key presses will be passed on directly to web content, just as for regular keyboard users. Switching VoiceOver to "single-key quick navigation" will result in key presses associated with commands to be intercepted, while other key presses are still passed on – and role="application" has no influence on this. As a result, screen reader users on macOS may accidentally trigger character key shortcuts, the same way regular keyboard users can.

- +

In Gnome/Linux, the Orca screen reader uses a mix of single-key commands and commands that are activated using one or more modifier keys. These commands can also vary depending on the specific application being used, and its level of support in Orca. In general, currently Orca behaves similarly to macOS/VoiceOver – when key presses are associated with screen reader commands, they are intercepted. Otherwise, key presses are passed on to the page. role="application" appears to have no effect.

Benefits

From e87f1c9fb6b4e71aff37b70ec5c085fa00fbef47 Mon Sep 17 00:00:00 2001 From: "Patrick H. Lauke" Date: Tue, 1 Sep 2026 19:42:10 +0100 Subject: [PATCH 09/18] Rename/retitle working example --- .../{character-key-shortcuts => key-event-logger}/index.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename working-examples/{character-key-shortcuts => key-event-logger}/index.html (98%) diff --git a/working-examples/character-key-shortcuts/index.html b/working-examples/key-event-logger/index.html similarity index 98% rename from working-examples/character-key-shortcuts/index.html rename to working-examples/key-event-logger/index.html index f75fd0904e..af00f3aaf6 100644 --- a/working-examples/character-key-shortcuts/index.html +++ b/working-examples/key-event-logger/index.html @@ -3,7 +3,7 @@ - Character Key Shortcuts + Keyboard event logger -

Character Key Shortcuts

+

Keyboard event logger

This working example logs JavaScript key events being fired on the document. Relates to Success Criterion 2.1.4 Character Key Shortcuts.

This paragraph has a role="application" to force Windows-based assistive tech (like JAWS and NVDA) to pass keyboard events directly to the page, rather than intercepting them.

From 56e6f735dcb86c55baead1325964e01bd4427619 Mon Sep 17 00:00:00 2001 From: "Patrick H. Lauke" Date: Tue, 1 Sep 2026 20:59:36 +0100 Subject: [PATCH 10/18] Add link to key event logger from understanding as a resource --- understanding/21/character-key-shortcuts.html | 3 +++ 1 file changed, 3 insertions(+) diff --git a/understanding/21/character-key-shortcuts.html b/understanding/21/character-key-shortcuts.html index a7b713b90a..4d0bb217b6 100644 --- a/understanding/21/character-key-shortcuts.html +++ b/understanding/21/character-key-shortcuts.html @@ -60,6 +60,9 @@

Alternate Control

Resources

+
    +
  • Key event logger – logs all JavaScript key events that reach the document; useful to verify if a specific combination of platform, user agent, and assistive technology fires key events.
    • +
{% # Data for associated techniques is defined in understanding/understanding.11tydata.js %} {% include "understanding/techniques.html" %} From 083595e86df458182fdf2dd64acad88ad50ae0e8 Mon Sep 17 00:00:00 2001 From: "Patrick H. Lauke" Date: Tue, 1 Sep 2026 21:19:04 +0100 Subject: [PATCH 11/18] Refine working example --- working-examples/key-event-logger/index.html | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/working-examples/key-event-logger/index.html b/working-examples/key-event-logger/index.html index af00f3aaf6..75d18abcb6 100644 --- a/working-examples/key-event-logger/index.html +++ b/working-examples/key-event-logger/index.html @@ -57,7 +57,7 @@

Keyboard event logger

Output

-

Log of all JavaScript key events (keydown, keyup, keypress). Also flags if the key event relates to a printable character, meaning it's a character key.

+

Log of all JavaScript key events (keydown, keyup, keypress). Also flags if the key event relates to a printable character, meaning it's a character key. New events appear at the top of the ouput.