Keyboard-driven GUIs: why TUI fans are wrong about the terminal's advantage

Keyboard accessibility is one of those things that tends to get swept under the rug or forgotten about entirely alongside accessibility in general. The funny thing is that the former usually falls out of the latter.

Part of the blame lands on the shoulders of popular UI frameworks (or in the case of those choosing to eschew use of such, the developers who made that choice). The older frameworks tend to make this fairly easy; for example, in Cocoa/AppKit (Mac native UI framework), one can pretty easily wire up their entire UI for proper keyboard navigation entirely visually (mostly just consists of connecting nextKeyView outlet between controls to produce a logical chain to tab-focus through). Defining key shortcuts is also simple; add a menu item for a command and set its corresponding shortcut (which in turn allows the user to rebind the shortcut in System Settings at will).

That sort of design has fallen out of favor with newer frameworks, unfortunately. The new preferred style seems to be a wireframe that the dev chooses which parts fill in, and often only the barest of essentials makes the cut.

Power user experience is not the same thing as user experience in general. If you want to make the argument that all developer tooling should be keyboard-driven, fine, be my guest. But most people aren't willing to deal with the learning curve of keyboard-driven GUIs, and that's okay. We shouldn't force it.

HN's insistence on acting like all users are Arch Linux efficiency perfectionist hacker types is painfully corny.

(This reads harsher than I intended. Sorry about that. I love Arch Linux people. It's just think it's no less noble to serve the average Joe than to create the perfect tool for power users.)

What does it mean though for a GUI to be keyboard-driven?

The obvious way is that every action simply gets a shortcut assigned.

My counter would be that that is not really keyboard-driven, but merely keyboard-compatible.There is the issue of discoverability. The best practice right now seems to display the shortcuts of buttons in tooltips, menu items, or when pressing a different shortcut.

I’d content that buttons are a fundamental mismatch with keyboards. A keyboard driven UI shouldn’t have buttons.

The issue is that genuinely keyboard driven UIs like CLI or TUI suffer terrible discoverability that being the reason that mouse driven UI exists in the first place. So can we have a keyboard-driven UI that is as intuitive as clicking with a mouse?

last time i built a crud app (oh maybe about 24 years ago) i made it a point to do this. i remember watching the payroll people fly through their terminal mode vax vms applications with such speed and dexterity that it would make any unix admin well versed in the art of the command line blush and it made me think "oh yeah, all these 90s point and click guis got it all wrong. if people are required to make heavy use of a system at work, they would prefer a learning curve followed by speed, comfort and dexterity over an easier learning curve that trades dexterity for discoverability."

it was a webapp framework, but... all browsing/listing screens included row ids and a focused text box- so that typing the row id and enter would select. all action buttons had an underline to signify which ctrl-shift hotkey triggered them. all edit screens defaulted focus to the first editable textbox and at no time was the mouse actually necessary. finally, load times were optimized to target 75ms.

amusingly, the user feedback was "the keyboard control is pretty good but can you please make it faster."

what i thought was chrome ended up being critical to the users not being miserable.

I agree but I think being usable by the keyboard isn't enough, because the shortcuts are often hard to discover and remember. I think the ideal is - like good TUIs - GUIs should put obvious hints on screen how to navigate via keyboard.

It would be really great to have some GUI frameworks for the common platforms (including web!) designed to do this and have some opinions on common shortcuts for common actions so we can standardize on something.

The author makes an excellent point. There are too many poor Terminal UIs created just for the sake of having a TUI. Often these are not well constructed or lack sufficient thought to be effective/productive.

But the broader trend in GUI apps has been to target marketshare not deliver productivity for keyboard users. Back in the 80s and 90s Photoshop, Illustrator etc. became the powerhouses they are today because they focused on allowing professionals to be extremely efficient using their array of powerful keyboard shortcuts. In 2026 when software companies are dying of KPItis scoring their product management on creating compelling subscription models to hook customers, attention to actually delivering productivity for keyboard users is often an after thought. Mobile apps don't have keyboard shortcuts and desktop apps seem to increasingly be treated as as the narrow "edge case" with only a few hundred million target users versus the billions available on mobile devices. It's an opportunity for those who get serious about delivering value by leveraging the power of keyboard shortcuts to make their GUIs highly productive and comprehensively usable from the keyboard. For all their faults, Microsoft got this right with VSCode.

> In fact, many GUI framework application guidelines explicitly encourage GUI application developers

Instead they should be engineered in a way that allows users to bypass those developers in a (at least) framework-consistent way as there will never be a time when they collectively become "keyboard-wise".

I recently had a revelation when I made an extended qwerty midi controller app that permanently shows the states and functions of all keys including when modifiers are held.

It occurred to me that this is a wonderful way to design software: you immediately know the keyboard shortcuts because you’re already looking at them. I’m working on taking what I’ve built for the qwerty midi keyboard controller (which is built on hammerspoon) and making it just a generic interface for any kind of app.

If the end goal is navigating and controlling the app via keyboard shortcuts, so why not bake that into the design of the GUI itself?

My project if you’re curious: https://github.com/mattdanielmurphy/qwerty-midi-hammerspoon

Couldn't agree more, but I think it's majorly a "geek" thing. I'm using i3 on my personal linux and aerospace on my work mac ; vimium in the browser, Neru on the other apps (does something similar to Neru). I recently ended up finding a way to create user-scripts for electron app and since then I'm adding vimium-esque extensions (e.g. in Teams) wherever I go.

I wish this was a default, but also that there was more of a standard to navigate UIs. That's why I really like vimium and other similar extensions, it's following the vi logic across websites, rather than having to learn everyone's idea of how to navigate.