GUIs should be fully keyboard-driven • Hacker News Board

Re: GUIs should be fully keyboard-driven

#381

Post by miki123211 » Sat, Aug 29, 2026, 6:55 AM UTC

Velocifyer wrote: post #297

jaggederest wrote: post #255

Earlier quoted context omitted.

Some of the things we take for granted in UI/UX originated that way, like automatic hamburger menu hide/show (for very large zoom) and "scroll to content/top" buttons for screenreaders, which, if you've ever tried to read a recipe online are pretty critical. Captions on videos are also like that, although there you might share blame to them for enabling the poor sound mastering on things like, legendarily, Tenet, per…

What are the advantage of “scroll to content/top” buttons over for screen readers? I think that the use of those buttons is for when the CSS fails to load.

Such buttons are more visible to (screen reader) users who navigate the web exclusively with arrow keys.

Landmarks are important, but to navigate by landmark, you need to be experienced enough to know the right quicknav keys. Some beginner users might not be.

Re: GUIs should be fully keyboard-driven

#382

Post by [deleted] » Sat, Aug 29, 2026, 7:02 AM UTC

sublinear wrote: post #2

TUIs are an abomination and most GUIs should just be web. CLIs should be preferred when available. Learning them pays you back when it's time to write a script or pipe massive amounts of data.

[deleted]

Re: GUIs should be fully keyboard-driven

#383

Post by Timwi » Sat, Aug 29, 2026, 7:09 AM UTC

It's so weird for me to live through software evolution to the point where this no longer goes without saying.

In the Windows 3.1 days, it was nearly impossible to make a program that wasn't fully keyboard-usable. Even if you left out all the hotkeys in the menus and messed up the tab order, it was still possible (even if annoying) to get through it with the keyboard, and adding the hotkeys (as well as actual shortcuts) and setting a sensible tab order was super easy and straightforward.

Nowadays more than half of all software is made using non-native GUI toolkits (or sometimes no toolkits at all) that refuse to implement any of the typical keyboard navigation that would previously have come for free.

The keyboard makes computers a joy to use for me. Seeing it disappear makes me very sad. Seeing how the vast majority of people don't care that it disappeared makes me feel like an alien from another planet.

Re: GUIs should be fully keyboard-driven

#384

Post by red_admiral » Sat, Aug 29, 2026, 7:11 AM UTC

marcellus23 wrote: post #240

red_admiral wrote: post #215

It used to annoy me that on Windows I could press ENTER to close a message box, but on Mac I had to reach for the mouse.

Hm, you should generally be able to hit Return to close a message box on Mac. Or, more specifically, to activate the default action in a dialog (the button whose background is the tint color of the application). Spacebar activates the button that has the focus ring around it, which may or not be the default button, but you can use Tab to move the focus around. At least, this is the way it's always been on OS X and la…

This was classic Mac era.

Re: GUIs should be fully keyboard-driven

#385

Post by MrVandemar » Sat, Aug 29, 2026, 7:16 AM UTC

nonethewiser wrote: post #312

MrVandemar wrote: post #275

Earlier quoted context omitted.

> It is a business opportunity as well. I worked at a company that paid for an audit before LLMs. There is tremendous cost savings possible here. Do you know one of the most underemployed groups are disabled people? And do you know where a number of disabled people get employment? Disability audits (unsurprisingly they're extremely good at this). Congratulations on recommending further marginalising an extremely marg…

Wait what? We should withhold accessibility features to not marginalize disabled people?

No, we should not withhold accessibility features. I wrote nothing to suggest that we should.

I wrote that a group of marginalised people would be further marginalised, and deprived of income and meaningful work in a sector where they are, by circumstance, subject matter experts. Anything else is projection.

Re: GUIs should be fully keyboard-driven

#386

Post by harhargange » Sat, Aug 29, 2026, 7:17 AM UTC

This is also why i like the blackberry still. iPhone uses too much of cognitive overhead. At least the iPad is a good mix and i mostly depends on my keyboard/mouse connected iPad to use my apps if I’m not virtualising them.

Re: GUIs should be fully keyboard-driven

#387

Post by miki123211 » Sat, Aug 29, 2026, 7:18 AM UTC

jameshart wrote: post #277

rootedbox wrote: post #152

I work on ADA a lot for my company. Please put on some headphones, turn on the voice assistant of your OS, put on some blinders, and run your app or website… no mouse, just keyboard. 1. Democracy is about access; make sure everyone has access to your software. 2. The keyboard allows folks with disabilities and power users to fly through your website/app… that being said… the second a tab is off, the person with a dis…

In the context of discussing TUI vs GUI (as the article does), the accessibility and keyboard control balance probably swings very strongly to native GUIs; in a TUI you’re at the whim of the TUI framework’s stabs at accessibility support, while on a full fledged native UI you have all the bells and whistles of focus management and text to speech and voice control and high contrast and magnification and motion adjustm…

It's very hard to make a TUI (or a web app) that has 0 screen reader accessibility. It's also much harder to make a TUI that has great screen reader accessibility (it's much easier for web apps). "native" apps are a much wider spectrum.

With a TUI or a web app, screen readers will always have some access, because no matter what you do, the text layer is always there. This may not be enough accessibility to use the app or to complete some specific workflow, but a screen reader user will at least have a rough idea of what's going on. For web apps, that's a good basis to start from once you finally realize that accessibility is something you need.

Desktop apps are much more of a mixed bag. Most frameworks draw their UI themselves, basically pixel by pixel, instead of using some text-based platform primitives. 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. If you're just a developer using that framework, it's a very difficult situation to get out of, once a11y becomes a business requirement.

GTK on anything but Linux is the major offender these days, so are many niche Rust frameworks and anything involving game or game-like UI. QT, Java Swing and Flash used to be this way historically.

Re: GUIs should be fully keyboard-driven

#388

Post by ckardaris » Sat, Aug 29, 2026, 7:19 AM UTC

eviks wrote: post #363

ckardaris wrote: post #350

Earlier quoted context omitted.

Maybe not complicated, but unorthodox. A developer who is not familiar with the correct design patterns may, for example, create a dialog using a FrameworkWindow instead of a FrameworkDialog. In that case the framework can not provide any automation, because the developer is not following the guidelines. I would argue that any sufficiently powerful framework also provides more ways to diverge from the "proper way", s…

But a framework can provide user keybinds conditional on that Dialog-As-Win being shown so users could reclaim some of that lost automation And more pressure from more options doesn't follow, you only need to study if you actually want to diverge

> But a framework can provide user keybinds conditional on that Dialog-As-Win being shown so users could reclaim some of that lost automation.

The "conditional" is carrying a lot of weight here. The developer needs to know what to do. For example, in my GTK application I had to learn how to identify a menu as the "primary" menu, so that the framework will automatically bind it to the well-known shortcut.

  
    true

This is easy to omit and then you will never know about the automation.

Then, you can go into a different discussion. How does the framework guide you to the correct functionality? Does it force you to include a primary menu? Does it check that if you have at least one menu, then one should be primary? What if the developer creates an unorthodox menu by creating a simple button that opens a popup with a list of buttons?

Re: GUIs should be fully keyboard-driven

#389

Post by duskdozer » Sat, Aug 29, 2026, 7:20 AM UTC

greggsy wrote: post #347

rootedbox wrote: post #152

I work on ADA a lot for my company. Please put on some headphones, turn on the voice assistant of your OS, put on some blinders, and run your app or website… no mouse, just keyboard. 1. Democracy is about access; make sure everyone has access to your software. 2. The keyboard allows folks with disabilities and power users to fly through your website/app… that being said… the second a tab is off, the person with a dis…

Also, please avoid animations and transitions, or at least add a button to reduce them.

My people. I can't tell you how much time I spend trying hack these out, especially when base libraries hard code them. Accessibility isn't just sight/non-sight.

Re: GUIs should be fully keyboard-driven

#390

Post by duskdozer » Sat, Aug 29, 2026, 7:22 AM UTC

ckardaris wrote: post #352

greggsy wrote: post #347

Earlier quoted context omitted.

Also, please avoid animations and transitions, or at least add a button to reduce them.

This is where using a common framework pays dividends. For example, on the desktop I can disable animations for all GTK applications.

I stopped using GNOME after 3, but there were still quite a few animations in the GNOME core programs despite having the disable animation setting set. I wonder if that's changed.