GUIs should be fully keyboard-driven
TL;DR
Being keyboard-driven is a weak argument for building TUIs instead of GUIs. Nothing stops a GUI from being fully usable by keyboard. Platform guidelines already ask for it. So a GUI that can't be driven from the keyboard shows a missing effort by its developer.
The article
- The post answers a recent HN debate over a call to stop building terminal UIs. It targets one pro-TUI argument in particular: that TUIs win because they are keyboard-driven.
- A random TUI is more likely than a random GUI to work fully from the keyboard. The author reads that as a sign of poor keyboard support in many GUIs. He does not see it as a reason to pick TUIs.
- GUI frameworks can do keyboard navigation as well as a TUI, or better. The GNOME Human Interface Guidelines say every action possible with a pointer should also be possible with the keyboard.
- The author gave his own first GUI app, Klisi, shortcuts for its whole range of actions. He argues the work is usually not hard. So the gap comes down to developer will.
- A footnote grants that some tasks still need a mouse's dexterity. It also grants that portability is a stronger argument for TUIs than keyboard control.
Why it matters
The post takes two minutes to read. It adds little beyond this summary, besides the GNOME guideline wording and the link to the earlier TUI debate. The thread has the substance, especially for anyone building desktop or web apps. It shows where keyboard and screen-reader support usually breaks.
The discussion
The thread mostly agreed and was warm. Many shared nostalgia for Windows 3.1, AS/400 and DOS-era business apps that office staff drove at full speed. The largest subthread treated keyboard support as an accessibility question. The rest argued over whether average users want any of this, what "keyboard-driven" should mean, and whether TUIs deserve their reputation for it.
Keyboard support is accessibility, and accessibility helps everyone
The top thread started from someone who does ADA work and asked developers to try their app with a screen reader and no mouse. Many replies cited the curb cut effect and "situational disabilities" like a broken touchpad or full arms, saying accessible design ends up better for everyone. Xirdus pushed back that accessibility and usability can conflict, with color coding, small fonts and sticky keys as examples, and the thread never settled it. A side argument about using AI to audit accessibility drew the objection that audits employ many disabled people.
The thing that I consistently found was that, the more accessible a website was, the better the experience for *everyone*, not just people with disabilities.
There are things that increase usability for fully abled people but decrease it for disabled people. Color-coding is a common one.
Old toolkits gave it for free, new ones dropped it
Veterans recalled that Win32 and Windows 3.1 apps were keyboard-usable almost by default, through tab order, Alt mnemonics and menus. They blamed Electron, custom-drawn frameworks and phone-style redesigns in Windows 10/11 and Apple's iOS ports for losing it. On macOS, Tab reaches every control only after you turn on a setting that is off by default. A screen reader user said self-drawn widgets can expose nothing to assistive tech, in GTK outside Linux, many Rust toolkits and game-style UIs.
In the Windows 3.1 days, it was nearly impossible to make a program that wasn't fully keyboard-usable.
If your framework doesn't expose UI semantics to the OS, a screen reader user gets absolutely nothing, basically a blank window with no visible content or controls.
Power users versus everyone else
One commenter called the push for keyboard-driven GUIs an HN power-user fixation that average users don't want. Most replies said the post asks for keyboard support as an option, not a requirement. Others said the real power users are clerks and point-of-sale staff who live in one app and revolt when a redesign takes their shortcuts. Skeptics replied that most Excel users are mouse-first and that even smart academics go to the Edit menu to copy.
Commercial software is THE power user use case. Your users will be using your software 8 hours a day, 5 days a week, for years.
My wife is a UX Design consultant and she had an engagement where a bunch of state government accountants were bemoaning how a redesigned procurement platform took away all their keyboard shortcuts.
Shortcuts on buttons are not a keyboard-driven design
Several commenters argued that giving every button a shortcut makes an app keyboard-compatible, not keyboard-driven, and that the hard part is discoverability. Ideas offered were underlined mnemonics, shortcut hints next to every control, which-key style popups, command palettes and Office's Ribbon key tips. jerf pointed to old mainframe UIs that buffered keystrokes so trained staff could type ahead of slow screens. Others said a good keyboard scheme has to be systematic enough to predict, not a pile of bindings to memorize.
My counter would be that that is not really keyboard-driven, but merely keyboard-compatible.
Keyboard input can, when designed well, be fully predictable and require no feedback loop with the computer.
TUIs are not more accessible or more consistent
Commenters who sided with the author said TUIs have no accessibility tree, so screen readers hear the box-drawing characters. Each TUI also invents its own keybindings, while GUI frameworks ship common ones. TUI fans replied that terminals guarantee every visible character can be copied by keyboard, which GUIs often don't. Others answered that copying out of modern TUIs breaks on borders and panes, and named Claude Code and OpenCode.
for most TUIs, if you close your eyes and have the UI read to you, you're going to hear "dash dash dash dash dash dash bracket dash", because the fundamental concept of a TUI is in-band UI signalling.
One problem with this argument in particular is that every TUI reinvents the wheel and designs its own schema.
Consensus
Every action in a GUI should be reachable from the keyboard, while mouse use stays fully supported. Native toolkits make this cheap. Web-based and custom-drawn UIs are where it got lost.
Dissent
A minority said the demand reflects HN's own habits more than those of users, who are mostly on phones or mouse-first. Some named places where a keyboard mandate makes no sense: drawing, 3D modeling, games and touch-driven industrial screens. Others called "should" an added cost small teams can't always pay.