Hacker News Reader

Comment by jameshart | Hacker News Reader

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 adjustments…

The idea that it must be more accessible because it’s confined to a mono space typeface and communicates state mostly by changing the foreground and background color of the text it renders makes no sense to me.

View on HN

> The idea that it must be more accessible because it’s confined to a mono space typeface and communicates state mostly by changing the foreground and background color of the text it renders makes no sense to me.

That's not why. It's because TUI apps have to be designed around the strong possibility that a mouse isn't even available.

Also in a TUI you never ever have that issue that some text isn't copy/pastable like some dialogue boxes, in which case the screen reader might have issues picking it up too.

And in a TUI you don't have to deal with that window management crap. Moving stuff around because something else is on top. Everything happens within that little square.

> Also in a TUI you never ever have that issue that some text isn't copy/pastable like some dialogue boxes

May I present OpenCode, which somehow managed to break copy from terminal: https://github.com/anomalyco/opencode/issues/4283

Not requiring a mouse isn’t a magic pathway to ‘accessibility’ though. The fact that something can be used with a keyboard does not obviate developers from the need to consider other aspects of accessibility.

Also: when I copy paste out of an application I don’t want a bunch of spurious chrome glyphs and newlines - copying just the text contents of a TUI scrollable text field isn’t trivial and isn’t always guaranteed to work

> Also in a TUI you never ever have that issue that some text isn't copy/pastable

Telle that to Anthropic, as Claude code doesn't let me copy any text from its TUI.

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.

I’m specifically talking about native apps. iOS apps built using UiKit are going to have first class accessibility support.

Besides the TUI program itself, you also have your terminal emulator (unless in a TTY) and possibly a multiplexer like tmux. I use irssi inside tmux from my phone a lot and you can get pretty precise control with keyboard shortcuts that make up for some of the flaws of a touchscreen. Like instead of mashing or holding the arrows to go back and fix a typo, I'll use the readline binds and hit esc and b a bunch of times to close most of the distance, then switch to arrows at the end if needed. The tmux copy mode is also pretty friendly in the same way, you can vary gradually adjust your selection start/end without having to hold anything down.

There's TUI and there's CLI. TUI has always been poor man's GUI, back in the day it was even literally called GUI. CLI on the other hand has zero similarities with GUI. You write the command and the command executes and that's it. Writing commands is inherently the most accessible form of controlling computers, second only to dedicated single-purpose buttons that don't mesh well with this whole "general purpose computing" thing.

> Writing commands is inherently the most accessible form of controlling computers

Not if you don't know enough of the commands and have to research every one you need, and it's for a problem you likely won't encounter again. Oh, and you have to do this without breaking anything. To say this can slow a person down is a dramatic understatement.

There is a reason menus were invented very early on in computing history, well before 1970.

Most accessible, not most convenient/efficient/easy to learn. It's very very hard to beat entering text in terms of how many people on Earth are physically capable of doing it (considering all the available methods, including text to speech).

Yes, but this article is about TUIs

Reply on news.ycombinator.com