How Do You Design Keyboard Shortcuts for a SaaS App?

How do you design keyboard shortcuts for a SaaS app?

Start with the five actions your heaviest users repeat all day, give those a shortcut, and make every shortcut either remappable or switchable off. Then tell people the shortcuts exist. A shortcut nobody can discover is a feature you paid for and shipped to nobody.

We see two failure modes. Products with no shortcuts, where power users do everything with a mouse, and products with forty undocumented shortcuts that fire while somebody is typing a customer's name.

Here is how we decide what gets a shortcut, and the accessibility rule that constrains the whole design.

Who actually uses keyboard shortcuts?

The people who live in your product, and the people who cannot use a mouse comfortably. Those two groups look different in your analytics and want the same thing: to complete a repeated task without moving their hands or their attention.

This is a long-standing design principle rather than a trend. Jakob Nielsen's ten usability heuristics, first published in April 1994 and last updated in January 2024, put it under flexibility and efficiency of use.

Nielsen's wording is worth keeping in the brief: shortcuts, hidden from novice users, may speed up the interaction for the expert user, so that the design can cater to both inexperienced and experienced users. Hidden, not absent.

Which actions deserve a shortcut?

The ones done more than ten times a session, and the ones that interrupt flow. Creating a record, searching, saving, moving to the next item, and closing whatever is open. That list covers most products and it is deliberately short.

Look at your own event data rather than guessing. The actions with the highest repeat count per user per day are the candidates, and they are rarely the ones the product team finds interesting.

Do not give a shortcut to a destructive action unless it is reversible. A single keystroke that deletes something permanently is a support ticket generator, whatever the confirmation dialog says.

What does WCAG require about single-character shortcuts?

You must give users a way out. Success criterion 2.1.4 Character Key Shortcuts sits at Level A. If a shortcut uses only letter, punctuation, number or symbol characters, one of three things must be true. Either a mechanism turns the shortcut off, or a mechanism remaps it to include a non-printable key, or it is active only on focus.

Level A is the baseline, not the stretch goal. If your product has single-letter shortcuts and no settings screen to disable them, it fails the criterion.

The reason is concrete. The W3C explains the intent as reducing accidental activation, and gives the example of a speech input user whose dictated words trigger several commands at once, such as saying a phrase that archives, navigates and mutes in an email application.

How do you avoid clashing with the browser and the operating system?

Assume the platform wins and design around it. Anything the browser or the operating system already claims, including find, print, save, new tab and window switching, is not yours to take. Overriding those makes your app feel broken rather than powerful.

Check your shortcut set on both major desktop platforms, because the modifier keys differ and a combination that is free on one may be taken on the other.

Prefer single letters for navigation inside your own interface, with the escape hatch the criterion requires, and reserve modifier combinations for actions with consequences. That split is easy to learn and hard to trigger by accident.

How do people discover the shortcuts?

Three places, every time. A help panel listing all of them, a hint next to the action in the interface, and the shortcut shown in the tooltip or menu item for the thing it triggers. The convention of opening the list with the question mark key is widely understood and worth following.

Put the shortcut next to the button it duplicates. That is how people learn without reading documentation: they see the hint while doing the slow version, and eventually they stop clicking.

Mention them once during onboarding and then never nag. Our notes on SaaS onboarding flow design cover where that fits without cluttering the first session.

Should shortcuts be remappable?

Ideally yes, and at minimum switchable off. Remapping satisfies the WCAG requirement directly, and it solves the real conflicts your team will never predict: assistive software, browser extensions, keyboard layouts in other languages, and people who have muscle memory from a competing product.

If full remapping is too much work for now, ship a single toggle that disables character-key shortcuts, and store it with the user rather than the device. That is a small settings row and it makes the product usable for people who currently cannot use it at all.

Put it somewhere findable. A preference buried three levels deep is not a mechanism anyone will find in the moment they need it. Our guide to SaaS settings page UX covers where this kind of control belongs.

How do you handle shortcuts inside text fields?

Turn them off entirely while the user is typing. Any input, textarea or rich text editor should swallow character shortcuts before they reach your global handler, so that typing the letter n inside a note does not quietly create a new record behind the panel somebody is writing in.

This is the bug that makes users distrust a keyboard-first product, and it is usually an oversight in a global key handler rather than a design decision. It shows up most in comment boxes and search fields added later by a different team.

Test every field, including the ones inside modals and inline editors. Those are the ones that get missed, because they were built after the shortcut system.

What about a command palette instead?

It is the best single investment if you are only going to build one thing this quarter. A palette opened with one key combination, listing every action by name with fuzzy search, gives you both discoverability and full coverage without asking anybody to memorise a table of keys.

It also reduces the number of dedicated shortcuts you need. Five direct shortcuts plus a palette beats thirty shortcuts nobody remembers, and it scales as the product grows.

Show each action's own shortcut in the palette row. That turns the palette into the teaching surface for the rest of the system, which is exactly how experts get made.

How do you test them?

With real users, on their own machines, doing their own work rather than a scripted task. Watch where they reach for the mouse out of habit, and watch for any shortcut that fires when they did not intend it. Both of those tell you something no specification review will.

Include at least one person who uses speech input or has limited mobility. The WCAG example about dictation triggering commands is not theoretical, and a ten minute session will show you whether your escape hatch works.

You do not need a big study. Our piece on testing with five users covers how far a small sample gets you.

What would we ship first?

A command palette, five direct shortcuts, a help panel on the question mark key, hints next to the matching buttons, and one settings toggle that turns character shortcuts off. That set is defensible, accessible and small enough to build in a sprint.

Everything after that should come from watching what your heaviest users repeat. Shortcuts are one of the few features where the request list writes itself if you look at the data.

If you want help auditing a product's keyboard behaviour against the accessibility criteria, we are happy to take a look. You can see how we approach product and interface work at phoenix.studio.