How do I explain keyboard controls in a product interface?
Quick answer
List only keyboard controls verified in the current interface. For each one, name the key or combination, where it works, what it does, and any relevant platform difference. Distinguish controls that move focus from those that activate a function. Treat example keys as placeholders until checked: general guidance cannot confirm a particular product’s shortcuts or behavior. Keep ordinary keyboard navigation explained separately from optional shortcuts.
The question, the details, the next step.
What’s a clear way to explain keyboard controls in a product interface without accidentally documenting a shortcut that doesn’t work?
Start with the interface, not with a list of familiar-looking key combinations. Check each control in the current product, then write down the exact key, the context where it works, and the result a user should observe. Mark any platform differences instead of assuming the same combination works everywhere.
A useful entry format is:
[Key or combination] — In [interface area or context], [verified result]. [Platform or other condition, if applicable.]
For example, as a placeholder rather than a claim about any real product: [Key combination] — In [dialog name], moves focus to [control name].
Keep the description observable: “moves focus to the Search field” is more useful than “helps you navigate.” W3C guidance distinguishes shortcuts that move focus from shortcuts that activate a function, and says shortcuts should supplement, not replace, basic keyboard navigation. [S1] The guidance is general, not a shortcut list for your product; it cannot verify your keys, behavior, or platform differences.
How should I describe a key that changes which control is selected versus one that performs an action?
Name the result precisely. If a key changes the current focus, say which control receives focus or how focus moves. If it triggers an operation, say what operation happens. Avoid using “selects,” “opens,” or “activates” interchangeably unless that is exactly what you verified.
You can use two distinct sentence patterns:
[Key]— Moves focus to[control or destination]in[context].[Key]— Activates[function]in[context].
These are writing templates, not product facts. Replace every bracketed item only after checking the interface. If a control both changes focus and triggers an action, document the sequence only if you verified both parts and can explain them without ambiguity.
What should I check before publishing the reference, especially if behavior differs between platforms?
Verify each entry in the current interface and note the context and platform you checked. Confirm the key combination as displayed, what happens when it is used, and whether the same result occurs in each platform or configuration the reference covers. If you cannot verify a difference, don’t invent one: leave it out or mark it for confirmation before publication.
Also make the reference discoverable and check for possible conflicts. W3C guidance discusses discoverability and avoiding conflicts with assistive technologies, browsers, and operating systems. [S1] That guidance does not establish which combinations your product uses or whether any particular combination conflicts. Don’t claim a shortcut is conflict-free based on this general guidance alone.
Can you give me a copyable reference that makes unverified details hard to mistake for confirmed controls?
Use a short scope note, then one entry per verified control. Keep placeholders visible in drafts and remove them only when the details have been checked. For example:
“Keyboard controls for [product area] — checked in [interface/platform and version, if relevant] on [date].
[Key or combination]— In[context], moves focus to[destination].[Key or combination]— In[context], activates[verified function].
Basic keyboard navigation: [brief description based on the current interface].
Platform differences: [verified difference, or ‘None identified in the platforms checked’].”
Use “None identified in the platforms checked” only if those checks were actually made; it does not mean no differences exist elsewhere. Keep the navigation note separate from optional shortcuts. Before release, remove entries that remain unverified rather than presenting placeholders as instructions.
A practical checklist
Check every key or combination in the current interface before documenting it.
Record the context where the control works and its observable result.
Label whether the result moves focus or activates a function.
Verify platform differences for the platforms the reference claims to cover.
Separate basic keyboard navigation from optional shortcuts.
Leave unverified details as explicit placeholders in drafts; do not publish them as facts.
A few more useful answers
Can I use familiar keyboard shortcuts as examples?
Only if you verify that they work as described in the current interface. Otherwise, use bracketed placeholders so readers do not mistake an illustration for a product instruction.
Should a keyboard reference explain basic navigation as well as shortcuts?
Yes, keep the topics distinct. General W3C guidance says shortcuts supplement rather than replace basic keyboard navigation; it does not specify how your product’s navigation works. [S1]
What if I haven’t checked every platform?
State which platforms were checked, or keep the reference limited to the verified environment. Don’t imply that untested platforms behave the same.
Sources
References used for this guide.