Keyboard-first documentation tool: how to pick one

TL;DR. A keyboard-first documentation tool is one you can operate end to end without the mouse — command palette, slash commands, page navigation, search, and link insertion all on the keys. Most tools bolt a few shortcuts onto a mouse-first design and call it keyboard-friendly. Raccoon Page ships 30+ shortcuts on every plan, a Cmd+K palette, and / slash commands; Shift+? lists the lot. Sub-second loads. Keyboard- first. The honest version of this post tells you when none of that matters.

Most “keyboard shortcut” pages are a printed list nobody opens twice. (We have read several. We regret it on your behalf.) The question worth asking isn’t which shortcuts does this tool have — it’s can I do my actual job without the mouse. Those are different questions, and the gap between them is where most documentation tools quietly fail.

A keyboard-first documentation tool is one where the keyboard is the primary surface, not a secondary one. You open a page, create one, move through the tree, search the whole wiki, format as you write, and drop in a link — all without your hand leaving the keys. If you have to reach for the mouse between any two of those, the tool is keyboard-friendly at best. The distinction is the whole post.

The test is the unplugged mouse

Here is the cheapest evaluation you will ever run. Open the tool. Unplug the mouse, or shove it across the desk. Now try to write a page from scratch: create it, give it a parent, write three sections with a code block and a table, link it to two other pages, and find a fourth page you wrote last week.

A keyboard-first tool lets you finish. A mouse-first tool with shortcuts bolted on strands you somewhere in the middle — usually at “give it a parent” or “find a fourth page,” because navigation and structure are the parts vendors leave to the mouse longest. The editor gets shortcuts first because that is the demo. The tree gets them last because that is the work.

Run the test before you read a single feature comparison. It is more honest than any of them, including ours.

Five keyboard surfaces that actually matter

“Keyboard support” is too broad to evaluate. Break it into the five surfaces a documentation tool is made of. A tool is keyboard-first only when it covers all five — not when it covers the easy two.

Surface	What it does	Keystroke that proves it
Command palette	Jump to any page or action by typing	Cmd+K / Ctrl+K
Slash commands	Insert blocks while writing	/ in the editor
Page navigation	Move through the tree, switch pages	Arrow keys, palette jump
Search	Find content across the whole wiki	One keystroke to focus
Link insertion	Connect pages without the mouse	Inline, from the keyboard

The first two are common. Plenty of modern tools have a Cmd+K palette and / slash commands — that is table stakes in 2026. The last three are where tools separate. Navigation, search- focus, and keyboard link insertion are the surfaces that decide whether you ever touch the mouse during a normal session. A tool that nails the palette and strands you on the tree has solved the demo, not the day.

Which tools have which surfaces

Factual, no name-calling. The pattern across the category is consistent: editor-side keyboard support is good and getting better; navigation-side keyboard support is the long tail.

• Notion has a strong Cmd+K quick-find and / slash commands. Editing is comfortable on the keyboard. Moving through a large workspace and reorganising still leans on the mouse and drag-and-drop.
• Confluence ships some editor shortcuts and a quick-search keystroke. Tree navigation, restructuring, and most actions expect the pointer. It was not designed keyboard-first, and it shows on the structure side.
• Obsidian is the keyboard zealot’s favourite — a command palette, hotkeys for nearly everything, and a community that rebinds keys for sport. The trade-off is that it is a single-player vault first; the team-wiki shape is grafted on.
• One major incumbent in this category ships effectively no general keyboard surface at all. We will state that as a fact and decline to make it a punchline. The mouse is the interface; the keyboard is an afterthought. Teams that type for a living feel it within a week.
• Raccoon Page covers all five surfaces on every plan. Cmd+K opens the command palette. / triggers slash commands in the editor. 30+ shortcuts span navigation, editing, and search. Shift+? shows the full list in-app, so you are never reading a stale PDF of shortcuts that shipped two versions ago. Keyboard-first. Mouse-optional.

For the editor-by-editor view of the same question — who writes markdown well, who round-trips it, who only pretends to — our best markdown editor ranking covers the writing surface in depth. This post is about the selection criterion; that one is about the eight editors it sorts.

Keyboard-first is an invariant, not an enhancement

This is the hill. Keyboard-first is an invariant, not an enhancement. A tool that treats shortcuts as a feature you can add later will always strand you somewhere, because the parts that got built mouse-first never get retrofitted. A tool that treats the keyboard as the primary surface ships every feature with a shortcut from day one — and when a shortcut is awkward, that is the signal the feature itself is wrong.

The number behind the opinion: Raccoon Page ships 30+ keyboard shortcuts on every plan, including Free. Not “the editing ones,” not “the pro-tier ones.” The command palette, slash commands, navigation, and search are all there at $0. A tool that hides keyboard navigation behind a paid tier has told you it considers the keyboard a luxury. It is not a luxury. It is the difference between a wiki you check and a wiki you avoid.

Our resident keyboard zealot — Zyberion Glitchpaw, who has opinions about ergonomic layouts we have learned not to solicit — puts it more bluntly than we will in print. The short version survives editing: if your hand reaches the mouse during a write, the tool added friction you are paying for in flow state.

Where this came from

There is a 04:11 story in our company lore. An engineer was reading server logs at four in the morning, trying to work out why the company handbook had taken eleven seconds to load again. He closed the logs tab, started a Postgres container, and told a colleague he would build a faster wiki before his coffee finished brewing. The coffee machine — slow, like everything else that night — took nine minutes. The first page of the thing he built rendered in 87 milliseconds.

The part that matters for this post is what he reached for next. Not a mouse. The very first interaction the new wiki shipped with was a command palette, because the team that built it could not stand the idea of clicking through a menu to open a page they already knew the name of. Keyboard-first wasn’t a roadmap item. It was the second decision, right after “make it fast.” (The 87ms is canon flavour, not a benchmark — but the speed is real, and it is half the reason the keyboard matters: a shortcut is wasted on a page that makes you wait for it.)

When keyboard-first does not matter

Honest section, because the brand voice requires we tell you when not to bother.

Keyboard-first helps the people who write. If your wiki is mostly read, it helps almost nobody. A public help-centre where two people maintain the articles and ten thousand people only read them — the keyboard surface helps the two, and is invisible to the ten thousand. A customer-facing docs portal is a read-optimised surface; the authoring keyboard ergonomics barely register in the buying decision.

Same for teams that genuinely prefer the mouse. Some people think faster with a pointer, reorganise visually, and never built the shortcut muscle memory. For them a keyboard-first tool is a nice option to have, not a reason to switch. Buy for how your team actually works, not for how a blog post says they should. If your fastest writers live in the mouse and like it there, optimise for something else — speed, search, the importer — and treat the keyboard surface as a bonus.

The teams keyboard-first is for are the ones whose writers type more than they click, whose documentation is a daily working surface and not a brochure, and who lose the thread every time a spinner or a menu hunt interrupts the sentence. If that is your team, the unplugged-mouse test will tell you in ten minutes which tools deserve a second look.

How to choose, in order

The decision tree, briefly:

1. Run the unplugged-mouse test on your shortlist. Cut anything that strands you before you finish a page.
2. Check all five surfaces, not the two everyone ships. Palette and slash commands are table stakes; navigation, search, and link insertion are the tiebreakers.
3. Confirm the keyboard surface is on the plan you’ll buy. If shortcuts are paywalled, the vendor doesn’t believe in them. Raccoon Page’s full surface is on Free.
4. Pair it with speed. Keyboard-first removes the mouse round-trip; sub-second loads remove the wait. You want both, or the keyboard just gets you to the spinner faster.
5. Check the exit. A tool you can’t leave makes “best” a small word — export to Obsidian-compatible Markdown anytime keeps the choice reversible.

For the wider category this sits inside — what a corporate wiki is for, how teams outgrow the one they have — our corporation wiki explainer is the companion read. If you’re arriving from Confluence specifically, the ten-minute Confluence import is the shortest path off it, and the pricing block has the honest numbers.

Things people actually ask

What makes a documentation tool keyboard-first? A keyboard-first documentation tool lets you do the whole job — open a page, create one, navigate the tree, search, format, insert a link — without touching the mouse. The test is simple: unplug the mouse and try to write a page. If you stall, the tool only added shortcuts on top of a mouse-first design. Keyboard- first means the keyboard is the primary surface, not a secondary one.

What is a command palette and why does it matter for docs? A command palette is a single keystroke — usually Cmd+K or Ctrl+K — that opens a search-as-you-type menu of every action and every page. Instead of hunting through menus, you type what you want and press Enter. It collapses navigation, search, and commands into one muscle memory. In Raccoon Page, Cmd+K opens the palette on every plan, including Free.

Do slash commands count as keyboard-first? Slash commands are part of it but not the whole. Typing / in the editor to insert a heading, table, code block, or callout keeps your hands on the keys while you write. That covers editing. A truly keyboard-first tool also covers navigation, search, and link insertion the same way, so you never reach for the mouse between writing and finding.

Does Confluence have keyboard shortcuts? Confluence ships some editor shortcuts and a quick-search keystroke. The gap most teams notice is navigation and structure — moving through the page tree, reorganising, and triggering most actions still expects the mouse. It is not the same as a tool designed keyboard-first from the start.

Is keyboard-first the same as fast? Related but not identical. Keyboard-first removes the mouse round-trip; sub-second loads remove the wait. A tool can be one without the other. Raccoon Page does both — pages load in 50-150ms depending on your network, and 30+ shortcuts cover navigation, editing, and search.

How many keyboard shortcuts should a documentation tool have? Count is less important than coverage. The five surfaces that matter are a command palette, slash commands, page navigation, search, and link insertion. A tool with 30 shortcuts covering all five beats a tool with 50 that only covers editing. Raccoon Page ships 30+ across all five; Shift+? lists them in-app.

When does keyboard-first not matter? When the audience reads more than it writes. A public help-centre or a read-only docs portal helps the maintainers and is invisible to everyone else. If your team lives in the mouse by preference, keyboard-first is a nice option, not a deciding factor. Buy for how your team actually works.

Can I try a keyboard-first wiki for free? Yes. Raccoon Page is free for up to 3 users, 1 space, and 100 pages, with no card. The full keyboard surface is on the Free tier, not held back for paid plans. Unplug the mouse and write a page on Free before you decide.

---

The fastest way to evaluate a keyboard-first documentation tool is the slowest part of any other evaluation: just use it. Unplug the mouse, open Raccoon Page Free — three users, one space, a hundred pages, no card — press Cmd+K, and try to get lost. If you reach for the mouse before you’ve written the page, tell us where. Zyberion will want the exact keystroke that was missing. We will probably ship it.