The post argues against a common claim that TUIs are inherently better than GUIs for serious work because they are keyboard-driven. The author’s actual point is narrower and stronger: anything stable and knowable in advance inside a GUI should be operable from the keyboard, while the mouse remains best for genuinely spatial tasks like arbitrary point selection. That lands as both a usability argument for heavy users and an accessibility argument for anyone who cannot rely on a pointer.
Most of the useful discussion converged on that accessibility framing. Several people said the simplest test is brutal and revealing: turn on a screen reader or voice assistant, put the mouse away, and try to complete real tasks. When tab order is wrong or focus disappears, the interface becomes unusable fast. Commenters kept stressing that this is not a niche concern. Keyboard access helps blind users, people with motor impairments, and ordinary office workers who spend eight hours a day in data-entry or workflow tools. The recurring example was old business software,
POS systems, accounting apps, Excel, and terminal-era line-of-business tools that users could operate at extreme speed once they learned them. The shared complaint is that modern software often optimizes onboarding and visual cleanliness at the expense of throughput for people who live in the product.
A second strong theme was that native GUI frameworks used to make this much easier. Windows, old Mac APIs,
Cocoa/AppKit, classic
Win32, and long-standing keyboard UI specs already had conventions for focus movement, menus,
mnemonics,
accelerators, default buttons, and discoverable shortcuts. A lot of commenters blamed the regression on
Electron-style or web-style app stacks, custom-drawn widgets, and newer design trends that throw away standard controls and accessibility trees. That is where the practical warning landed: if you bypass native widgets or draw everything yourself, you inherit all the work of focus management, screen reader support, shortcut discoverability, and text-to-speech hooks, and many teams simply do not finish that work.
People also sharpened an important distinction the article only implied: “keyboard accessible” is not the same thing as “keyboard driven.” Tabbing through every control may technically satisfy accessibility requirements, but it still makes dense apps miserable to use. The better target is a layered model. Start with sane focus order and full operability. Then add shortcuts for common actions, visible hints, menus with accelerators, jump navigation, command palettes, or hint overlays like
Vimium,
Ribbon keytips,
which-key, and
Helix. That makes keyboard use discoverable instead of turning it into a memorization contest.
The mood was broadly pro-keyboard, but not in a purist way. Few people wanted mouse-only or keyboard-only design. The strongest consensus was that good software should support both cleanly. The mouse is still the right tool for many 2D tasks and for novice discovery. The keyboard wins when work is repetitive, text-heavy, or latency-sensitive. Where commenters got impatient was with apps that force constant hand travel, remove old shortcuts, ignore Enter on forms, break standard tab behavior, or make visible text impossible to copy. The discussion treated those not as taste differences but as avoidable design failures.
ckardaris.com