The text mode lie: why modern TUIs are a nightmare for accessibility
41 points by natfu
41 points by natfu
The conclusion on this is incorrect IMHO
The problems Reeves describes seem to stem not so much from TUIs being inherently inaccessible, but from modern frameworks not actually making use of the terminal’s core feature set. I really hope this Reeves’ article shines a light on this problem, and that the people developing these modern TUIs start taking accessibility more seriously.
The issue is that the protocols aren't sufficient for the specific UX workloads that modern TUI apps want to put through them. There's a large capability gap that needs better protocol work, not just application layer stuff. VT100 scrolling regions doesn't solve most or any of that.
Yes, but by the time you've solved it, you've invented RDP, VNC, Waypipe, X11, devdraw, or similar -- just with a great deal more legacy baggage.
Local terminal rendering over ssh tends to be so much more polished than a graphical bitstream over a network, though. The windows look like other desktop windows, and things like subpixel AA and gamma work properly.
You can build a local GUI client that speaks ssh, but that's a lot of work (across 3+ platforms) for something a TUI gives you for free. (Then you might say "Electron", and that would complete our survey of the reasonable points in the design space.)
There's one GUI client I use that speaks SSH and it's Visual Studio Code, and if I need anything more than that I think it just makes more sense to make a website.
Sure, but note that TUIs compose with VS Code (you can run a TUI in a terminal inside) and other GUIs don't.
Hmm I think all you need is a terminal compositor, similar to Wayland, but using json for messaging instead of a shared memory pixel buffer.
You’d get much better a11y support and to compound things you also get a much better terminal protocol. All these multiplexers are falling into the same trap: ansi bytestreams get corrupted very easily and alt mode loses native scrollback.
What the terminal needs is to break away from the PTY and build out a compositor protocol.
SSH could still work as well, just need to remote forward the Unix socket for the protocol
I do not know real reason behind it but somehow my guts and insticts is not accept any of TUI apps even i am terminal guy. I think if need TUI then why i not using GUI (except performance concerns), only tui that i use is nmtui and the reason is I am too lazy to install a gui for it and i am not using it too much. I know the article discuss accessibility for blind people mostly but even other people the TUIs are not gives good dx. imo.
They've been a boon for my personal accessibility needs. I'm not sight impaired, but have RSI issues, which make using the mouse painful at times. Keyboard-first interfaces help me a lot with that, and as a side benefit are generally more efficient to use. Of course, GUIs can also have keyboard shortcuts, but they tend to be an afterthought, and only cover a subset of features. In my experience only certain IDEs have a keybinding for literally every feature.
Mouse-dominant TUIs can't go away fast enough. Worst of both worlds.
This is why CLI interfaces are superlative. Scriptable, composable, by default accessible, the universal FFI (exec).
There's a reason all the "agents" can wrangle bash for days but struggle to navigate Google Flights to buy a ticket. Text was once king, TTY after all stands for teletype.
what can you automate at all: GUI or TUI?
(as a person who automated GUI app for living for several years) both are horrible and fragile, but not impossible. Still horrible and fragile. TUI is a bit worse due to different conventions, that GUI apps usually share (e.g. TAB moves cursor further the list of positions — you can rely on it in 90% of windows apps, maybe 60% of TUI?).
I think the quality that made oldschool teletype line-by-line char-by-char apps super valuable was linearity in time; it made them easier to be streamed (e.g. over the audio) and easier to automate.
Yeah TUIs aren't good for people who need screen readers so they shouldn't be the only UI available. But it's very nice to have as it makes many tasks simpler and quicker.
Half of modern TUIs might have questionable usability gains if not being an outright ergonomic regression. But the other half shines as a beacon of UI pragmatism, discover ability and utility.
The terminal is essentially a cozy design space. The limited matrix of chars forces the user to be economical about screen real estate. The lack of mouse as a first class input, skews application authors towards keyboard centric operation which tenda to be faster.
The absence of graphics removes visual ambiguity, distractions. And imposes a familiar look and feel that eliminates the need to visually scan and figure out what's chrome and what's data.
Take for example k9s. I get what I want on screen using k9s some 10-50 times faster than using a webui.
I just wish we had proportional fonts in the terminal somehow. I find monospace to be harder to read for anything that isn't code. But the use of character grids for tui layouts necessitates fixed width characters.