Audit What Your Editor Leaves Unreachable Without a Mouse

There is a published answer to what your editor should reach from the keyboard, and it is all functionality, at the lowest conformance level a standard offers. No automated scanner will measure it for you. This is the audit you run by hand — with a worked example on an artifact you can download and check yourself.

The argument comes around every few months, and it came around again on 28 August 2026 — Charalampos Kardaris published "GUIs should be fully keyboard-driven" and Hacker News carried it past 600 points inside a day.^{1 2} His claim is about effort rather than about graphics: "It is not a matter of feasibility, but a matter of will on the application developer's part."³

Search the same site for keyboard driven and 271 stories match the query.⁴ This is a recurring appetite, not a spike.

Underneath the opinion sits something less negotiable. A W3C Recommendation has said what should be reachable, in the same words, since 2008 — not as advice, and not as a manifesto. It is a testable predicate with a number behind it, and almost nobody has ever pointed it at the tool they write in.

This post hands you the procedure, then runs it on a real, pinned artifact so you can see the shape of an answer before you produce your own.

The standard already says what should be reachable

WCAG Success Criterion 2.1.1 Keyboard sits at Level A — the lowest of three conformance levels, the floor rather than the aspiration. It asks for all functionality, with one narrow exception for input that depends on the path of a movement rather than its endpoints. The sentence has not changed since 2008.

The criterion, verbatim: "All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints."⁵

Level A is the floor, and the arithmetic makes that concrete. WCAG 2.1 defines 78 success criteria across three levels — 30 at A, 20 at AA, 28 at AAA — so this is one of the thirty cheapest things the standard asks anyone for.⁶ WCAG 2.2 raised the total to 86, of which 31 sit at Level A, and left 2.1.1 untouched.⁷

Run the criterion's text against WCAG 2.0, 2.1 and 2.2 and all three match exactly — eighteen years, one sentence, no revisions.⁸

W3C also states plainly who this is for: "Many people rely on the keyboard interface, including blind and some mobility impaired people."⁹ The abstract of a 2021 paper by Paul Chiou, Ali Alotaibi and William Halfond puts the same point in one line: "The keyboard is the most universally supported input method operable by people with disabilities."¹⁰

Two notes follow the criterion, and both matter more than the criterion's fans usually admit.

Read Note 2 first, because it disposes of an argument this post is not making: "This does not forbid and should not discourage providing mouse input or other input methods in addition to keyboard operation."¹¹ The standard protects the mouse. Nothing here asks you to give up pointing at things.

Note 1 closes the escape hatch most people reach for: "This exception relates to the underlying function, not the input technique."¹² Drag-and-drop is the usual test case, and W3C answers it directly: "Drawing straight lines, regular geometric shapes, re-sizing windows and dragging objects to a location (when the path to that location is not relevant) do not require path dependent input."¹³ Dragging a note into a new position is not exempt. Freehand sketching is.

The criterion was written for web content, which is a genuine limit, and this post returns to it at the end. What survives that question is the yardstick: all functionality, minus one precisely defined exception, published and stable for eighteen years.

No tool will hand you this number

Automated accessibility scanners are good at contrast and missing alternative text, and nearly blind to keyboard failures. In Deque's published audit corpus, 97.51% of the issues recorded against the keyboard criterion were found by a person and 2.49% by a machine. The two neighbouring focus criteria score 100.00% manual.

Deque Systems publishes the table. Across more than 2,000 first-time audits spanning 13,000+ pages and nearly 300,000 issues, row 7 of its Table 1 reads: SC 2.1.1 Keyboard — 9,412 total issues, 9,178 manual, 234 automatic.¹⁴ The rows on either side are worse. Focus Order (2.4.3) shows 9,553 issues, 100.00% manual, zero automatic; Focus Visible (2.4.7) shows 7,312 issues on the same terms.¹⁵ The whole keyboard cluster is invisible to the scanner.

Now the part a one-sided post would leave out.

Deque published that table while arguing the opposite case. Its headline finding is that automation caught 57.38% of total issues across the corpus — far above the 20-to-30% figure that circulates as folklore.¹⁶

Its own framing says so: "In our analysis we found automated issues for 16 out of the 50 Success Criteria under WCAG 2.1 Level AA. This supports the 20 to 30% automated coverage claims that many experts claim today. However, our analysis indicates that this definition does not accurately reflect the number of issues found in testing real web pages as they exist in the wild."¹⁷

Both things are true at once. Automation catches most issues by volume — and almost none of the keyboard ones. The 97.51% row is a concession against its publisher's own interest, which is exactly what makes it worth quoting.

The scale of what scanners do catch is not small either. The WebAIM Million, in its eighth consecutive year, ran the WAVE engine against the top one million home pages in February 2026 and detected WCAG 2 failures on 95.9% of them — 56,114,377 distinct errors, an average of 56.1 per page, a 10.1% rise on 2025.¹⁸ Those are the automatable failures, and there are 56 million of them.

W3C states the limit of the whole instrument category in one sentence: "Web accessibility evaluation tools can not determine accessibility, they can only assist in doing so."¹⁹ The two-word spelling of "can not" is W3C's own.

In 2017 the Government Digital Service tested that claim empirically. It built a page it called the world's least accessible, planted 143 failures across 19 categories, and ran ten tools at it. Report the headline the way GDS reported it — the tools together picked up 71% of the barriers.²⁰

Then the minority result: 42 of the 143, or 29%, were missed by every tool tested.²¹ The best single tool in that test was Tenon at 37% counting errors and warnings, or Asqatasun at 41% once manual-inspection prompts were counted; the worst was Google Developer Tools at 17%.²²

Mehmet Duran's conclusion has aged well: "So just because a tool hasn't picked up any accessibility issues on a website, doesn't mean those issues don't exist."²³ And his practical version: "They are most effective when combined with manual testing."²⁴

That study is from 2017 and tools have improved since. The current-decade version is peer-reviewed.

At CHI 2023, Chiou, Alotaibi and Halfond measured five tools against twenty real web pages across three types of keyboard-navigation failure. Average F1 across the three types: 15% for Axe DevTools Pro, 23% for QualWeb, 43% for WAVE, 15% for ARC Toolkit — and Tenon Check returned zero precision and zero recall on all three.²⁵ Their summary: "None of the other tools are capable of detecting all three types of KNFs."²⁶

One finding from the same paper cuts against the everything-is-broken reading, and belongs here rather than in a footnote. The authors' final set of twenty subjects excluded government and education sites, because they did not observe any keyboard-navigation failures in the ones they encountered.²⁷ Regulated sectors did better.

The audit: enumerate, attempt, classify

The method is the one the researchers used. Interact with every part of the interface using only the keyboard, and write down what happens. Enumerate the command surface, attempt each command, and sort the result into reachable, reachable-but-trapped, or unreachable. The output is a fraction and a list.

There is no cleverer version available. The ground truth in the CHI paper was built by hand: "the authors manually interacted with the page's UI and their underlying functional components via the keyboard to create the ground-truth."²⁸

GNOME's Human Interface Guidelines give application developers the same instruction in one line — "Test how accessible your app is by trying to use it with just a keyboard."²⁹ Our post on the dialog that asks whether to save works those guidelines at length.³⁰

Step 1 — enumerate the surface. Write down every command you can find, from every place commands hide: the menu bar, every right-click menu, the command palette, the documented shortcut list, the toolbar, the gutter, the status bar, and anything that only appears on hover. The enumeration is the hard part — and it is where most audits quietly cheat.

Step 2 — unplug the mouse. Literally. A trackpad within reach makes the results worthless — the hand does not report what it did.

Step 3 — attempt each command and classify it. Four outcomes are enough.

flowchart TD
  A[Pick one command] --> B{Reached by<br/>keyboard alone?}
  B -->|No| C[Unreachable]
  B -->|Yes| D{Focus escapes<br/>afterwards?}
  D -->|No| E[Trapped]
  D -->|Yes| F{Key was<br/>discoverable?}
  F -->|No| G[Reachable,<br/>undocumented]
  F -->|Yes| H[Reachable]

Figure: The per-command triage. For each command you enumerated, first ask whether the keyboard alone can invoke it; if not, it is unreachable. If it can, ask whether keyboard focus can leave whatever the command opened; if focus cannot leave, it is trapped, which is a separate and more serious failure. If focus leaves cleanly, ask whether you could have found the key without reading the source or guessing; if not, record it as reachable but undocumented. Only a command that passes all three questions counts as plainly reachable.

Keep the record in a table you can paste anywhere, because the list is worth more than the percentage:

| # | Command | Where it lives | Key or path | Result | Note |
|---|---------|----------------|-------------|--------|------|
| 1 | Toggle heading level | Format menu | Ctrl+Alt+1 | reachable | |
| 2 | Reorder note in sidebar | drag handle only | — | unreachable | drag-to-reorder |
| 3 | Rename a file | right-click menu | F2 | undocumented | key appears in no label |
| 4 | Insert table | palette | palette only | reachable | no direct key |
| 5 | Close the export dialog | dialog | Esc ignored | trapped | see SC 2.1.2 |

Enumerated: 5 · reachable 3 (60.0%) · undocumented 1 · trapped 1 · unreachable 1

One honest rule governs the whole exercise: report the denominator you actually tested, and never extrapolate past it. A coverage figure is a statement about the commands you found, not about the application. Two people auditing the same editor will disagree about the denominator, and that disagreement is information — it tells you where the surface is undiscoverable.

The command palette is the first row of the audit, not the answer

A command palette reaches the commands an application registered and chose not to hide. That is a great deal, and it is not the same thing as all functionality. The vendor whose documentation popularised the stronger claim also documents the two mechanisms that narrow it.

We have written the stronger version ourselves. Our post on writing without leaving the keyboard calls the palette "one shortcut to reach the rest," and cites Visual Studio Code's own documentation for the phrase "access to all functionality within VS Code."³¹ That came from the vendor, in good faith, and the advice built on it survives this post entirely: learn the palette first, because it is still the highest-leverage single key in any editor.

The precise version is narrower, and the receipt comes from the same vendor's API reference. Commands registered by an extension appear in the palette by default — and then: "To allow more control over command visibility, there is the commandPalette menu item. It allows you to define a when condition to control if a command should be visible in the Command Palette or not."³² The documented example makes one command visible only while text is selected:

{
  "commands": [
    {
      "command": "extension.sayHello",
      "title": "Hello World"
    }
  ],
  "menus": {
    "commandPalette": [
      {
        "command": "extension.sayHello",
        "when": "editorHasSelection"
      }
    ]
  }
}

Separately, in the same reference: "However, the Command Palette doesn't show icons nor disabled commands."³³

So two categories of command are invisible to a palette by design — the ones a when clause hides, and the ones currently disabled. Then add the third category no palette ever claimed. Dragging a pane divider is not a command. Neither is a hover-only affordance, a canvas gesture, or a control implemented directly as a context-menu handler. Functionality that was never registered as a command cannot be listed by the thing that lists commands.

The palette is therefore the first row of your audit — not a substitute for it. Run it, mark everything it reaches, and then go looking for what it does not list. That second search is the whole measurement.

A worked measurement: 62 of 102 commands

Run the audit on something you can download. Version 6.11.0 of the open-source editing package @codemirror/commands exports 102 commands, and its two default keymaps together bind 62 of them. Forty ship no default key at all. That is 60.8% default keyboard coverage — a documented design choice, not a defect.

Start by pinning the artifact, because a moving branch is not a measurement:

curl -sL -o cm.tgz \
  "$(curl -s https://registry.npmjs.org/@codemirror/commands/6.11.0 \
     | python3 -c 'import sys,json;print(json.load(sys.stdin)["dist"]["tarball"])')"
sha256sum cm.tgz
# 733b58273c308944e6175423203d316e6369d5dd3a699199e04d2b2b737207fb  cm.tgz
tar xzf cm.tgz

Then count the exported commands, and count the ones a default key actually reaches:

import re
src = open('package/dist/index.js', encoding='utf-8').read()
dts = open('package/dist/index.d.ts', encoding='utf-8').read()

def block(name):
    i = src.index(f'const {name} = '); j = src.index('[', i); depth = 0; k = j
    while True:
        if src[k] == '[': depth += 1
        elif src[k] == ']':
            depth -= 1
            if depth == 0: break
        k += 1
    tail = src[k:src.index(';', k)]
    return src[j:k+1], re.findall(r'\.concat\((\w+)\)', tail)

def fns(name, seen=None):
    seen = seen if seen is not None else set()
    if name in seen: return set()
    seen.add(name)
    body, concats = block(name)
    out = set(re.findall(r'run:\s*(\w+)', body)) | set(re.findall(r'shift:\s*(\w+)', body))
    for c in concats: out |= fns(c, seen)
    return out

exported = set(re.findall(r'declare const (\w+)\s*:\s*(?:Command|StateCommand)\b', dts))
bound    = (fns('defaultKeymap') | fns('historyKeymap')) & exported
print(len(exported), len(bound), len(exported - bound),
      f'{100*len(bound)/len(exported):.1f}%')
# 102 62 40 60.8%

The .concat() recursion in block() is the whole reason that script is longer than it looks. defaultKeymap is defined as a list concatenated with standardKeymap; a bracket matcher that stops at the first closing ] silently drops 36 bound commands and reports 25.5% coverage. That wrong number was this post's first answer, and it was an extractor bug rather than a finding.³⁴ Any audit that produces a suspiciously low figure deserves the same suspicion.

The sub-counts are worth having: standardKeymap alone reaches 36 of the exported commands, defaultKeymap 58, historyKeymap 4, and emacsStyleKeymap 19 — the last of which is not part of defaultKeymap and only applies if an application opts into it.³⁴

This is not a criticism of CodeMirror, and reading it as one would be a factual error. The project's own guide says what it ships: "@codemirror/commands defines a lot of editing commands and some key bindings for them."³⁵ A library that hands you commands and expects the application to bind them is behaving correctly. The 60.8% is the documented design; the application built on top is where the remaining bindings belong.

Three limits on the number, stated before anyone else states them.

First, it measures a library's defaults rather than a finished product. Any editor built on this package adds its own keymap, and the shipped coverage will be higher.

Second, many of the forty unbound commands are directional or platform variants of bound ones — cursorCharForward is unbound while cursorCharRight is bound — so the count of genuinely unreachable capabilities is smaller than forty.

Third, a definition this specific is only comparable to itself: exported Command/StateCommand symbols reachable from defaultKeymap ∪ historyKeymap, and nothing else.

What survives all three caveats is the concrete part. deleteTrailingWhitespace, transposeChars and all four subword-motion commands — cursorSubwordForward, cursorSubwordBackward, selectSubwordForward, selectSubwordBackward — ship with no default key and no bound equivalent. If you want them, someone has to bind them. That sentence is the audit in miniature, and it is true of every editor.

A different property of the same package is measured in our post on reparsing the paragraph rather than the document; this one spends no ground that post covers.³⁶

Reachable is not escapable

WCAG separates two properties that feel like one. SC 2.1.1 asks whether you can get to a control. SC 2.1.2 No Keyboard Trap asks whether you can get away from it — and it is one of only four criteria that apply to every part of a page, whether or not that part is relied upon for conformance.

The criterion in full, including the clause that paraphrases usually drop: "If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away."³⁷

"Or other standard exit methods" is load-bearing. Escape is a standard exit method. The rule is not "arrow and tab only" — it is that a non-standard exit has to be announced. Drop the clause and you have quoted a stricter standard than the one that exists.

Conformance Requirement 5, Non-Interference, is where the severity lives. Four criteria "apply to all content on the page, including content that is not otherwise relied upon to meet conformance, because failure to meet them could interfere with any use of the page: 1.4.2 - Audio Control, 2.1.2 - No Keyboard Trap, 2.3.1 - Three Flashes or Below Threshold, and 2.2.2 - Pause, Stop, Hide."³⁸ A trap does not fail a widget. It fails everything around it.

In an editor, traps cluster in the same four places every time: modal dialogs, embedded preview panes, code blocks that host a nested editor, and find-and-replace bars that swallow Tab. The unsaved-changes prompt is the canonical case, which is why it earned its own post.

People notice. On Super User, "How can I confirm the 'change screen resolution dialog' in Windows 10 using keyboard only?" has 19 votes and 2,406 views; "How do I paste the Windows clipboard into my PuTTY session, using only the keyboard?" has 171 votes and 441,430 views.^{39 40} Both are the same question in different clothing — the user knows the action exists and cannot reach it from where their hands are.

There is a stricter version available if you want it. SC 2.1.3 Keyboard (No Exception) is the same sentence at Level AAA with the path-dependence carve-out removed.⁴¹ Even the exception is optional.

What the number does not mean

A coverage count measures your command surface. It is not an accessibility audit and it is not a conformance claim. WCAG conformance is defined for web pages as a whole, across thirty Level A criteria; this measures part of one of them, and only across the commands you thought to enumerate.

Four reasons, each independently sufficient:

1. Scope. WCAG's conformance requirements are written about web pages, and 2.1.2 draws its severity from exactly that framing — a keyboard trap interferes with the use of the page as a whole.³⁸ A desktop editor is not the object the standard adjudicates.
2. Subset. SC 2.1.1 governs all functionality. A command list enumerates the functionality someone chose to name.
3. Arithmetic. Level A is thirty criteria.⁶ You measured a slice of one.
4. Property. Reachable and escapable are different criteria with different tests.³⁷

WebAIM states the general form of this fence better than we can, about its own tool: "All automated tools, including WAVE, have limitations—not all conformance failures can be automatically detected. Absence of detected errors does not indicate that a page is accessible or conformant."⁴² The same asymmetry applies to a hand audit. A high number is evidence of care. It is not a certificate, and this post makes no accessibility claim about any named application, including ours.

The objection that WCAG governs web pages is correct, and the answer is that a yardstick is not a jurisdiction.

The same principle is stated independently for native desktop software. GNOME's guidelines say "Just as it should be possible to perform every action with a pointing device, every action should also be possible with the keyboard" — and, in a separate section, "It should be possible to move around and interact with every part of your user interface using the keyboard."^{43 44} WCAG is a W3C Recommendation and the GNOME text is design guidance — different in force, the same in what they ask for, and neither claiming jurisdiction over your text editor.

Coverage is also not usability, and W3C says that too: "If content does not follow the platform/user agent conventions it may be difficult to use, as users will need to learn different interaction methods."⁴⁵ A five-chord binding nobody can remember passes SC 2.1.1 and fails the writer. One hundred percent reachable can still be miserable.

Nor is this a speed argument. Our post on writing without leaving the keyboard already went through the mouse-versus-keyboard efficiency literature and found it does not support the claim.³¹ The case for reach is not that it is faster. It is that a command you cannot invoke is a command you do not have.

Finally, a scope line: this describes a technical standard, not the law. Conformance obligations vary by jurisdiction, and nothing here claims who is required to meet WCAG or when.

Frequently Asked Questions

These are the questions people type when a menu item exists and the keyboard cannot reach it. Each answer is scoped to what the standards and the published studies actually say, because the distance between "here is a coverage number" and "here is an accessibility verdict" is exactly one careless sentence.

Can I use my note app entirely with the keyboard?

Probably not — and the honest answer is that nobody has measured it for you. No published study reports keyboard coverage for note editors as a category. That absence is why this is a method rather than a ranking: you enumerate your editor's commands, attempt each one keyboard-only, and produce the number yourself in an afternoon.

Does a command palette reach every command in an app?

No. A palette reaches the commands the application registered and did not hide. Visual Studio Code's API reference documents a when condition that controls palette visibility, and states separately that "the Command Palette doesn't show icons nor disabled commands."^{32 33} Functionality never registered as a command — drag handles, hover affordances — is outside the palette entirely.

What is WCAG 2.1.1, and does it apply to a desktop app?

SC 2.1.1 Keyboard is a Level A success criterion requiring that all functionality be operable through a keyboard interface, with one exception for path-dependent input.⁵ It is defined for web content, so it does not adjudicate a desktop application. It remains the clearest published yardstick for what "reachable" should mean.

How do I test my app with only a keyboard?

Unplug the mouse and use it. GNOME's guidelines say exactly that: "Test how accessible your app is by trying to use it with just a keyboard."²⁹ It is also the academic method — the CHI 2023 ground truth was built by authors who "manually interacted with the page's UI ... via the keyboard."²⁸ Enumerate first, then attempt, then record.

Is drag-and-drop exempt from the keyboard requirement?

Usually not. W3C states the exception is about the underlying function rather than the input technique, and gives examples: "dragging objects to a location (when the path to that location is not relevant) do not require path dependent input."^{12 13} Reordering a list by dragging is therefore in scope. Freehand drawing, where the path is the content, is out.

Does a keyboard coverage number mean my app is accessible?

No. It measures part of one criterion out of thirty at Level A, over the commands you enumerated, and says nothing about screen readers, contrast, focus visibility, or timing. WebAIM's formulation covers the general case: "Absence of detected errors does not indicate that a page is accessible or conformant."⁴²

What counts as a keyboard trap?

Focus that can enter a component and cannot leave it using the keyboard alone, without the exit method being announced. SC 2.1.2 allows a non-standard exit provided the user is told about it, and it is one of four criteria under Conformance Requirement 5 that apply to every part of a page.^{37 38} Modals and embedded panes are where they cluster.

Will keyboard-first work make me faster?

The evidence does not support that promise, and this post does not make it. Our earlier post on the habit went through the mouse-versus-keyboard efficiency literature and found the popular studies do not hold up.³¹ Reach is a capability argument: an action you cannot invoke without a pointing device is an action you do not have when your hands are elsewhere.

Keyboard reach is not a preference and not a personality. It is a published floor, a testable predicate, and — for the editor open on your screen right now — an unmeasured number that takes one afternoon and one unplugged mouse to produce.

This post was prompted by Charalampos Kardaris's argument that full keyboard operation is a question of will rather than feasibility; the measurement is our attempt to give that claim a denominator.¹

If your notes should outlive whichever editor wins that audit, MNMNOTE keeps them as open Markdown files on your own device.