How to Add Keyboard Shortcuts and a Command Palette to Your Product

To add keyboard shortcuts and a command palette to your product, start with the five to ten actions your daily users repeat most, give them keys people already expect (Cmd+K or Ctrl+K for the palette, ? for a shortcut list, Esc to close, j and k to move through a list), and never take keys the browser, the operating system or a screen reader already uses. Single-letter shortcuts must stay quiet while someone is typing, and users need a way to turn them off. Then make the palette do two jobs, run actions and jump to places, show each item's shortcut next to it, and log what people search for and do not find. That last list is free feature research.

This guide is for solo makers with a web app people open daily. The worked example is made up; the standards, docs and libraries are real, linked and checked in October 2026.

Is your product worth adding keyboard shortcuts to?

Keyboard shortcuts pay off when the same person does the same thing many times a day. They are usually worth it when:

• Your product is a list people work through. Inboxes, ticket queues, task boards, review queues. Moving to the next item and acting on it is the whole job.

• Your product is an editor. Docs, notes, form builders. Hands are already on the keys.

• Your best users ask for it. "Is there a shortcut for this?" in support or feedback is the clearest signal you will get.

• Your app has grown past one screen. With more than a handful of places, a palette is the fastest way to get anywhere.

Skip it for now if your product is a monthly report, a booking page or a tool people set up once. A Cmd K menu on a product nobody opens daily is a nice demo and nothing more.

Which shortcuts should you add first?

Pick from real usage, not from a list of what other apps have. Three sources are enough:

1. Your event data. If you track product events, sort actions by how often a single active user repeats them per day. Archive, assign, mark done, next item and search usually float to the top.

2. Your own screen. Use the product for a real hour and tally every action you do more than five times.

3. Support and feedback. Search for "shortcut", "keyboard", "faster" and "clicks" in your inbox.

Stop at five to ten. A short set people learn beats sixty nobody remembers. Write a shortcut map before any code, so clashes show early:

Fill the last rows with your own verbs. If two actions want the same letter, the more frequent one wins and the other lives in the palette only.

Which key conventions do users already expect?

The best shortcut is one your users already know from another app:

• Cmd+K or Ctrl+K opens a command palette or search. GitHub opens its command palette with Ctrl+K or Ctrl+Alt+K on Windows and Linux, and Command+K or Command+Option+K on Mac, and lets people change those keys in settings.

• ? opens a list of shortcuts. On GitHub, typing ? brings up a dialog with the shortcuts for the current page, as its keyboard shortcuts documentation describes. Gmail does the same.

• j and k move down and up a list. In Gmail's shortcut list, j is older conversation and k is newer, and e archives.

• g then a letter jumps somewhere. GitHub uses g then c for the Code tab and g then i for Issues. Sequences give you many "go to" keys without using modifiers.

• / focuses search, Esc closes things, Enter opens or confirms.

Then map modifiers per platform. Cmd on Mac is Ctrl on Windows and Linux for the same shortcut. Show the right one to each user: "Cmd+K" to Mac users and "Ctrl+K" to everyone else, not "Cmd/Ctrl+K" everywhere. The small library tinykeys has a $mod key for exactly this, which means Meta on Mac and Control elsewhere, per the tinykeys README.

On many non-US layouts, symbols like ? and / need Shift or AltGr, so test your symbol shortcuts on at least one other layout.

Which shortcuts must you never take?

• Browser and OS keys. Leave Cmd+W, Cmd+T, Cmd+N, Cmd+L, Cmd+R, Cmd+Q and their Ctrl versions alone. Apple's Mac keyboard shortcuts page lists Command-W as close the front window and Command-Q as quit the app.

• Know what Ctrl+K costs. In Chrome on Windows and Linux, Ctrl+K or Ctrl+E means "search from anywhere on the page" according to Chrome's own shortcut list. Many web apps take Ctrl+K anyway. Know you are making that trade, and keep a visible search button as a second way in.

• Text editing keys. Cmd+B, Cmd+I, Cmd+Z, Cmd+A and arrow keys belong to whatever text field has focus. Inside a rich text editor, Cmd+K is often "insert link", which GitHub's docs also list for its Markdown fields. Decide who wins there before users find out.

• Screen reader keys. The free screen reader NVDA uses single letters in browse mode to jump around a page: h for the next heading, k for the next link, f for the next form field, per the NVDA user guide. For those users, single-letter shortcuts may never reach your page, so every shortcut needs a visible button too.

The rule that saves the most pain: single-key shortcuts must not fire while focus is in a text field. A small guard at the top of your key handler does it:

if (e.isComposing || e.target.closest('input, textarea, select, [contenteditable="true"]')) return;

The isComposing check skips key presses while someone is typing through an input method, common for Chinese, Japanese and Korean. MDN notes that isComposing is not supported in every major browser yet, so test it rather than trusting it blindly. Modifier shortcuts like Cmd+K can still work inside fields; letters and ? should not.

How do you keep keyboard shortcuts accessible?

WCAG 2.1 has a rule written for exactly this. Success Criterion 2.1.4, Character Key Shortcuts, says that if a shortcut uses only letters, numbers, punctuation or symbols, at least one of these must be true: the user can turn it off, the user can remap it to include a non-printable key like Ctrl or Alt, or it only works when that component has focus. The W3C explanation of Character Key Shortcuts gives the reason: speech input users dictate words, and each letter can fire a command. Its example is a person saying "Hey Kim" near a mail app where y archives, k moves and m mutes. Sequences like g then a count too.

GitHub shows the cheap way to comply: its accessibility settings let you turn off character key shortcuts while keeping modifier ones. For a small product, one settings toggle covers it.

Three more checks:

• Every shortcut is a second way, never the only way. Each action also has a button, a menu item or a palette entry.

• No keyboard traps. Focus must be able to leave anything it enters using the keyboard alone, which is WCAG Success Criterion 2.1.2. Modals are the usual offender.

• Visible focus. When j moves the selection, the selected row must look selected.

If you have not done a keyboard-only walk of your product yet, do it before you add shortcuts. Our guide to running a one-day accessibility pass before launch covers that walk, focus order and modal traps in one sitting.

What makes a good command palette?

A command palette is a search box that runs things, and the place people learn your shortcuts.

What goes in the palette on day one

• Actions and places together. "Create invoice", "Archive", "Switch to dark mode" next to "Go to Settings" and "Go to Billing".

• Forgiving search. Match partial words, typos and synonyms. If customers say "client" and your UI says "contact", add "client" as a keyword on the contact items.

• Recent items first. With an empty query, show the last few commands and records the person used.

• The shortcut next to each item. If "Archive" has a key, show it on the right. This is how people learn shortcuts without a tutorial.

• Context. Actions for the selected item come first. Hide what cannot run.

• A useful no-results state. "No command for 'export csv'. Search help docs or tell us what you wanted." Then log that query.

How the palette should behave with a keyboard and a screen reader

The palette is a modal dialog with a search input and a list. W3C's modal dialog pattern covers the frame: focus moves into the dialog when it opens, Tab stays inside it, Esc closes it, focus returns to whatever opened it, and the container has role="dialog", aria-modal="true" and a label. The combobox pattern covers the inside: arrow keys move through results while DOM focus stays in the input, aria-activedescendant points at the highlighted option, and Enter accepts it. The same pattern warns against capturing the keys browsers use for text editing in the input. Test it once with a screen reader.

Should you build it yourself or use a library?

For most small teams, a library saves a week. These are open-source projects on GitHub, described by what their own pages say, as of October 2026:

• cmdk: a fast, unstyled command menu component for React that filters and sorts items for you and has a dialog version.

• kbar: a Cmd+K interface for React sites, opened with Cmd+K on Mac or Ctrl+K on Linux and Windows.

• ninja-keys: a keyboard shortcuts interface that works with plain HTML and JavaScript as well as Vue, React and Svelte.

• tinykeys: a very small keybinding library with sequences like "g i" and the $mod modifier.

• hotkeys-js: a dependency-free JavaScript library for capturing keyboard input.

Whichever you choose, test its accessibility yourself. Keep one list of commands (name, keywords, shortcut, handler) so the palette, the ? sheet and your tooltips read from the same source and never drift apart.

How will people find your shortcuts?

Most users never open a help doc. Put shortcuts where people already look:

• Tooltips. "Archive (E)" on hover tells people the key at the exact moment they reach for the mouse.

• Menus. Show the key on the right of each menu item, like desktop apps do.

• The ? sheet. One overlay with every shortcut, grouped by where it works.

• The palette itself. Each item shows its key, as above.

• One onboarding mention. A single line like "Press Cmd+K to find anything" in the empty state of the main screen. Not a tour.

• Your changelog. Shortcuts make a good small entry for active users. Here is how to write a changelog that brings silent users back.

How do you know anyone uses them?

Track shortcuts like any other feature. Four events are enough:

• shortcut_used with the command name and the key.

• palette_opened, with how it was opened (keys or button).

• palette_command_run with the command name and the query typed.

• palette_no_results with the query.

From those, watch two numbers weekly: the share of active users who used at least one shortcut or palette command, and the top ten no-result queries. The second is a list of features and words your users expect and cannot find. If you have not set up product events yet, start with tracking product metrics before your first 100 users.

When should you let users customise shortcuts?

Later, with one exception. The turn-off switch for single-key shortcuts belongs in version one, because of WCAG 2.1.4 and because some users simply type into the wrong place. Full remapping can wait until people ask. When you build it, store bindings per user, detect clashes and offer a reset.

What about mobile and touch?

On a phone, shortcuts barely exist, so build nothing mobile-specific. Keep a visible search button so the palette works with a tap, and remember tablet users with a hardware keyboard will use your shortcuts too.

A made-up example: Proofwhistle adds shortcuts in a week

This is an invented example to show the process. Proofwhistle is a made-up proof-approval inbox for small print shops, run by a made-up founder, Kwabena. Shop staff work through a queue of customer proofs, approving them, requesting changes or assigning them.

Kwabena counts actions in a week of his own event data. Moving to the next proof, approving and requesting changes make up most of the clicks. He writes a shortcut map: j and k to move, a to approve, c to request changes (which opens a comment box), Shift+A to assign, ? for the sheet, Cmd+K or Ctrl+K for the palette. He adds the text-field guard on day one, because the comment box is where people type the most.

The palette starts with twelve items: the five actions, "Go to" for each queue and settings, and recent proofs. A settings toggle turns single-key shortcuts off.

In the first fortnight, the no-result queries are the surprise: staff type "reprint" and "rush", which Proofwhistle has no word for. "Rush" becomes a tag the next week, and he adds "reprint" as a keyword on the duplicate-proof command. These numbers and results are made up; the habit of reading no-result queries is the point.

What mistakes make shortcuts annoying?

A 7-day plan to ship shortcuts and a command palette

This is a planning guess for one maker working part of each day, not a benchmark.

Keyboard shortcut FAQ

Should Cmd+K always open the command palette?

Cmd+K or Ctrl+K is the most familiar choice in web apps, so start there. If your product is a rich text editor where Cmd+K already inserts links, pick a second combination for the palette, as GitHub does with Ctrl+Alt+K, and show it in the UI.

Do single-letter shortcuts break accessibility rules?

Not by themselves. WCAG 2.1.4 allows them if users can turn them off, remap them to include a modifier, or if they only work when the component has focus. A settings toggle is the simplest route.

Is a command palette worth it for a small product?

Yes, if people use your product daily and it has more than a few screens. If they visit once a week, a good search box and clear menus will do more.

Give your daily users their time back

Shortcuts make your most loyal users happier every day. Start small, guard the text fields, let people turn single keys off, and read what they search for. And when the product is ready for more makers to try, MakerHunt is a friendly place to launch it.