Search topics
Single-key shortcuts that can't be turned off
A shop's / and S keys jump to the search box from anywhere on the page, so a dictated sentence ends up as a search.
event.key === 's' The problem
Speech input users, and anyone who presses a key by mistake, are thrown into the search box, and what they say next goes with them.
A shop's product page has a search box in its header, with / and S drawn in it as key caps. Press / or S anywhere on the page, unless you are typing in a field, and focus jumps to the search box. A customer who uses speech input adds the product to their basket and dictates a gift message: "thank you so much". Their last command left focus on the page rather than in the Gift message field, so the speech software types the words into the page, one key at a time. The first letters do nothing; the S of "so" moves focus to search, and "o much" is typed into the search box, which offers no results. The gift message stays empty. A keyboard user who starts typing before clicking into a field, or knocks the / key, lands in search in the same way.
Success criterion 2.1.4 covers any shortcut made only of character keys: a letter, in upper or lower case, a number, punctuation or a symbol, including ones such as ? that need Shift to type. Such a shortcut passes only if people can turn it off, if they can remap it to include a key that types nothing, such as Ctrl or Alt, or if it works only while its component has focus. These two keys are listened for on the whole document and offer none of the three. The last option can't help here: a key whose job is to reach search from anywhere can't wait for search to have focus. Skipping key presses in text fields doesn't change the result: everywhere else on the page, / and S still act.
The words aren't lost on screen, which makes the failure easy to miss: they sit in the search box, while the field they were meant for stays empty.
2 of 10 groups affected
- No vision (not affected)
- Low vision (not affected)
- Colour vision (not affected)
- No hearing (not affected)
- Hard of hearing (not affected)
- No speech (not affected)
- Motor (affected)
- Reach, strength (not affected)
- Cognitive (affected)
- Seizures (not affected)
- Limited manipulation Speech input types what it hears into whatever has focus, and an S with nothing focused sends focus to search, so the rest of the sentence becomes a search. Keyboard users who knock / or S lose their place on the page the same way.
- Limited language, cognitive and learning abilities The words appear in a box nobody chose and the field they were meant for stays empty, with nothing to say why, so it is hard to work out what happened and how to go back.
The markup is a labelled search field, so a static scan finds nothing wrong. The shortcut lives in a keydown handler, and only pressing keys shows it. Even then, a tool can't tell whether a setting somewhere on the site turns it off. Search widgets and AI coding tools add / as a search key readily, because large sites have it, and they usually add the check for text fields and stop there.
Try it
Before clicking into Gift message, say the message with the speech input above the window.
Speech input types into whatever has focus, one key at a time. Watch where the words go, then click into Gift message and say it again. You can also click the page and press / or S yourself.
Broken Can you fix this?
Northfield Home
Linen napkins, set of 4
$24
Search box: empty
Gift message: empty
The fix
Add Ctrl or ⌘ to the key, or let people turn the single keys off.
- 1No bare letter, number or symbol key acts on the whole page unless people can turn it off.
- 2Show the shortcut by the search box, and in
aria-keyshortcutswhile it works. - 3Whatever else you do, ignore key presses in text fields.
<form role="search" action="/search"> <label for="search">Search</label> <input id="search" name="q" type="search"> <kbd>/</kbd> <kbd>S</kbd></form>Ctrl + K, or ⌘K on a Mac
<form role="search" action="/search"> <label for="search">Search</label> <input id="search" name="q" type="search" aria-keyshortcuts="Control+K Meta+K"> <kbd>Ctrl K</kbd></form>Every / and S pressed outside a text field moves focus to search, and nothing turns that off. Dropping the S and keeping / is not a fix: / is a character key too, and speech input types it whenever someone says "slash".
A shortcut that needs Ctrl or ⌘ is no longer a character key shortcut, so 2.1.4 no longer applies, and speech input never holds Ctrl while it types a sentence. The key still works from anywhere on the page, including inside other fields. Ctrl + K is the combination many sites and apps already use for search, so people may know it. aria-keyshortcuts tells screen reader users about it on the field it moves to; on a Mac, show ⌘K in the key cap instead.
Both pass 2.1.4. Use Ctrl + K: the setting passes only once someone finds it, while Ctrl + K does the same job with nothing to find. Its costs are a two-key press, which someone typing with one finger or a mouth stick can manage with Sticky Keys, and the browser's own use of Ctrl + K, covered below. Keep single keys behind a setting only when your customers really use them, and then start them off. Deleting the shortcut also passes: the search box is a Tab or two away, and few shoppers know / is there.
Ignore key presses in text fields with every fix, so people can type an S into a review or a gift message. That check is not a fix on its own: the Before already has it.
aria-keyshortcuts names a shortcut to assistive technology; it makes nothing work. Put it on the field the shortcut moves focus to, list only the keys that work right now, and remove it when the shortcut is turned off or changed. Show the same keys on screen as well, as the key cap in the search box, so sighted people learn them the same way.
Chrome and Firefox use Ctrl + K themselves, to search from the browser's address or search bar. While your page has focus, its handler takes the key; people can still reach the address bar with Ctrl + L. If you would rather not take it, another combination with Ctrl or ⌘ passes just as well, as long as you try it in every browser, operating system and screen reader you support. Check ctrlKey or metaKey together, so the same handler works on Windows, Linux and Mac.
Screen readers use single letters themselves in browse mode, such as H for the next heading, so the page never sees those presses; in focus mode, when the reader passes keys through, the page's shortcuts fire. Don't add role="application" to make your keys reach the page: it takes the reader's own keys away.
Some keys are easy to leave out when you list a page's shortcuts.
- Keys that need Shift to type, such as ? for a shortcut help dialog: they are character keys all the same.
- Sequences, such as G then C to go to the basket: each step is a character key, so the whole sequence is covered.
- Keys added by third-party scripts, such as a search widget's / or an embedded player's K to pause: check whether each acts only while its widget has focus, or can be turned off, and switch off any that act on the whole page.
Fixing this with an AI coding assistant? Get this guide as Markdown
Verify the fix
4 checks, no mouse.
Test with: Keyboard, Speech input, Screen reader
Record the OS, browser and assistive-technology versions, the build, the date, and the actual result of each step. Repeat after adding a shortcut or a third-party script.
Limits
This is a starting pattern, not a guarantee for every application. The snippets leave out the search itself and saving the setting to a customer's account. Test the complete journey with a keyboard, speech input and your target assistive technology.
This is a recreated teaching example, not a finding about a named client. The code is a starting pattern: test it in your own product. No completed assistive-technology test is claimed here.
Keep this fixed as your code changes.
Turn guides like this into rules your coding agents and CI follow, then have the result retested with a keyboard and screen readers.