> The reality is different. Most modern Text User Interfaces (TUIs) are often more hostile to accessibility than poorly coded graphical interfaces.
The Claude Code rendering UI is the first place where I realized the TUI is more like a DOS or Borland UI system rather than a command line interface.
I was poking about CLAUDE_CODE_NO_FLICKER=1 setting when I realized what exactly this TUI is, it is layers of stuff showing up on top of each other with terminal codes.
Ended up reading the Ink Terminal implementation of React
Fascinating how it ends up looking Wordperfect or Wordstar from the past instead of pixel based graphics.
The usability for a vision impaired user is about the same, though I remember braille pads for DOS tools (80x25) which work better than all the screen readers which came later.
The more you look into these trendy TUIs the worse it gets -- it's like the developers took the accumulation of all the worst practices since the dawn of programming, and wrapped it all into one unwieldy, overweight, under-performant gelatinous blob that threatens to collapse under its own weight.
I've always been a bit mystified by the popularity of TUIs. To me, the power of the terminal is the streaming model. Composible utilities is something that is much less common in GUIs.
I get it that maybe the constraints of terminals force design of TUIs to be more focused on the purpose of the tool than polish, but it's not that compelling of a point to me.
The command line shell has that benefit of piping text between programs. TUIs are runnable from the command line shell. -- So you can get many of the benefits of a GUI (e.g. discoverability) while sticking close to the terminal where you're doing things.
If you're going to "run command, edit command, run command", performing the edits from the terminal you're running the commands in seems reasonable/intuitive. (In contrast, for tools like VSCode, I think it's more common for terminals to take up a fraction of the screen space rather than switching it to full screen. And then developers will say they need a huge monitor).
It also seems to be that keyboard-driven programs are more commonly TUI than GUI. e.g. magit or lazygit. Or lazydocker. Or k9s.
For some basic stuff like vim it works fine. But for almost everything else I'd rather a regular CLI tool or a web interface. I suspect a lot of the popularity comes from people who want to feel like a hacker using 10 terminal windows, but actually want a GUI like experience.
Obviously people want GUIs. That's why TUIs should be compared to GUIs, not to CLIs. TUIs are nice since you get a lot of the benefits of a GUI, without having to leave the context of the terminal.
...but without the web's accessibility options, without good text editing, with very basic customisation options, requiring trusted compute instead of working in a sandbox...
They're a long way from web apps, far worse on most axes.
I'd agree with this assessment. Moreover, if developers were to stick with the eminently satisfactory CUA (IBM's Common User Access) interface standard and further regularize that then things would be much easier. https://en.wikipedia.org/wiki/IBM_Common_User_Access
If developers want to experiment with various UI configs then let them but keep a CUA in the background that can be called upon by machines and humans alike. (Unfortunately, ergonomics has never been a strong point for developers.)
I don't think the issue is using declarative UI frameworks, it's that the rendering engines these frameworks are outputting to are not taking accessibility into account.
Totally. I had a colleague who was a pretty awesome programmer and was completely blind. When I first met him, he was working on a braille 3270 terminal. Those IBM terminals were capable of all sorts of stuff.
> The real problem is that pretty much the whole stack has a terrible AX story.
> First, most GPU-rendered terminal emulators don't engage in system-provided accessibility APIs AT ALL. Because text is GPU-rendered, AX tooling can't "read" it, it just shows up as an image. This applies to Kitty, Alacritty, WezTerm. My own terminal Ghostty is AX-readable (on macOS), and so are others like iTerm2 and Terminal.app (which admittedly do it better than me, we have gaps to fill).
> Second, there are no terminal sequences or initiatives at all for TUIs to communicate AX information to the emulator, so the emulator itself can't do much more than display a blob of text to AX tooling. We need the equivalent of ARIA-style annotations but for terminal cells, runs, and regions. No such initiative exists. Even if TUIs do great things with the cursor, this is going to bite a lot of use cases.
> As an example of combining the above, I've been working on something with Ghostty where we integrate semantic prompt (OSC133) and AX APIs so that we can present each shell prompt, input, and command as structurally significant to AX tooling (rather than simply a text box where the cursor is somewhere else). This shows the importance of the relationship between terminal specs (OSC133), TUIs (which must emit OSC133), and terminal emulators (which must both understand OSC133 AND communicate it to AX APIs).
> The whole stack is rotten. And no one is earnestly trying to fix it (including me, I have limited time and I do my best but this is a WHOLE TOPIC that requires a huge amount of time and politicking the ecosystem and I don't have it, sorry).
Bonus: a simultaneously awesome and horrible reality is that AI is really helping to improve AX here. A lot of AI tooling uses/abuses AX APIs to make things happen. How is OpenAI reading your list of windows, typing into them, etc? Accessibility frameworks! So a lot more apps are taking AX integration a lot more seriously since its table stacks for AI using it... Sad it requires that but the glass half full is more software is doing that.
>> AX originated in reference to UX (User Experience) and stands for Accessibility Experience. AX is also sometimes used as a synonym for accessibility.
Modern software is a joke.
I saw a "lightweight" fui for Spotify the other day, written in rust!
800mb binary.
The bloated electron app is almost half that size.
So yes, when developers are literally retarded, even vibed cli programs with --Help given you 15 pages of command, it's time to reboot technology and go back to unikernel running forth or basic
As I said before [0], the same web developers that are the ones that ruined the web are now bringing their Java/Typescript, React mess into terminals where it is not needed.
React is software development cancer and it just entered metastasis. It can't be cured anymore, it will spread throughut the entire stack and kill it from the inside. We already have it on the web, on mobile, on Windows 11 and, now, it's coming for the terminal emulator.
> The reality is different. Most modern Text User Interfaces (TUIs) are often more hostile to accessibility than poorly coded graphical interfaces.
The Claude Code rendering UI is the first place where I realized the TUI is more like a DOS or Borland UI system rather than a command line interface.
I was poking about CLAUDE_CODE_NO_FLICKER=1 setting when I realized what exactly this TUI is, it is layers of stuff showing up on top of each other with terminal codes.
Ended up reading the Ink Terminal implementation of React
https://github.com/vadimdemedes/ink
Fascinating how it ends up looking Wordperfect or Wordstar from the past instead of pixel based graphics.
The usability for a vision impaired user is about the same, though I remember braille pads for DOS tools (80x25) which work better than all the screen readers which came later.
The more you look into these trendy TUIs the worse it gets -- it's like the developers took the accumulation of all the worst practices since the dawn of programming, and wrapped it all into one unwieldy, overweight, under-performant gelatinous blob that threatens to collapse under its own weight.
I've always been a bit mystified by the popularity of TUIs. To me, the power of the terminal is the streaming model. Composible utilities is something that is much less common in GUIs.
I get it that maybe the constraints of terminals force design of TUIs to be more focused on the purpose of the tool than polish, but it's not that compelling of a point to me.
The command line shell has that benefit of piping text between programs. TUIs are runnable from the command line shell. -- So you can get many of the benefits of a GUI (e.g. discoverability) while sticking close to the terminal where you're doing things.
If you're going to "run command, edit command, run command", performing the edits from the terminal you're running the commands in seems reasonable/intuitive. (In contrast, for tools like VSCode, I think it's more common for terminals to take up a fraction of the screen space rather than switching it to full screen. And then developers will say they need a huge monitor).
It also seems to be that keyboard-driven programs are more commonly TUI than GUI. e.g. magit or lazygit. Or lazydocker. Or k9s.
For some basic stuff like vim it works fine. But for almost everything else I'd rather a regular CLI tool or a web interface. I suspect a lot of the popularity comes from people who want to feel like a hacker using 10 terminal windows, but actually want a GUI like experience.
Obviously people want GUIs. That's why TUIs should be compared to GUIs, not to CLIs. TUIs are nice since you get a lot of the benefits of a GUI, without having to leave the context of the terminal.
This. A lot of folks picked it up for that reason when they were young and now are terminal-all-the-things out of sheer inertia.
They are very useful when working on remote servers, VMs and containers. Much much more convenient and robust than, say, X forwarding.
TUIs were supposed to be the simple option. now they're just web apps wearing a terminal costume
...but without the web's accessibility options, without good text editing, with very basic customisation options, requiring trusted compute instead of working in a sandbox...
They're a long way from web apps, far worse on most axes.
I'd agree with this assessment. Moreover, if developers were to stick with the eminently satisfactory CUA (IBM's Common User Access) interface standard and further regularize that then things would be much easier. https://en.wikipedia.org/wiki/IBM_Common_User_Access
If developers want to experiment with various UI configs then let them but keep a CUA in the background that can be called upon by machines and humans alike. (Unfortunately, ergonomics has never been a strong point for developers.)
I don't think the issue is using declarative UI frameworks, it's that the rendering engines these frameworks are outputting to are not taking accessibility into account.
Does a terminal even have any accessibility support tho?
The article mentions several TUI programs that rendering in an accessible way for screen readers.
Oh well I did't read the article as is tradition
Totally. I had a colleague who was a pretty awesome programmer and was completely blind. When I first met him, he was working on a braille 3270 terminal. Those IBM terminals were capable of all sorts of stuff.
Yes. Well, for cli yes.
I wouldn't have assumed a TUI is accessible just because it's on the terminal. I guess the author encounters people who do.
I am surprised, though, that something like "turning off the cursor" enhances the accessibility.
I use mc as a file manager. I have no idea what you are talking about.
Mitchell Hashimoto has a great response on lobste.rs https://lobste.rs/s/ifbdw1/text_mode_lie_why_modern_tuis_are...
> It isn't fair to blame TUIs.
> The real problem is that pretty much the whole stack has a terrible AX story.
> First, most GPU-rendered terminal emulators don't engage in system-provided accessibility APIs AT ALL. Because text is GPU-rendered, AX tooling can't "read" it, it just shows up as an image. This applies to Kitty, Alacritty, WezTerm. My own terminal Ghostty is AX-readable (on macOS), and so are others like iTerm2 and Terminal.app (which admittedly do it better than me, we have gaps to fill).
> Second, there are no terminal sequences or initiatives at all for TUIs to communicate AX information to the emulator, so the emulator itself can't do much more than display a blob of text to AX tooling. We need the equivalent of ARIA-style annotations but for terminal cells, runs, and regions. No such initiative exists. Even if TUIs do great things with the cursor, this is going to bite a lot of use cases.
> As an example of combining the above, I've been working on something with Ghostty where we integrate semantic prompt (OSC133) and AX APIs so that we can present each shell prompt, input, and command as structurally significant to AX tooling (rather than simply a text box where the cursor is somewhere else). This shows the importance of the relationship between terminal specs (OSC133), TUIs (which must emit OSC133), and terminal emulators (which must both understand OSC133 AND communicate it to AX APIs).
> The whole stack is rotten. And no one is earnestly trying to fix it (including me, I have limited time and I do my best but this is a WHOLE TOPIC that requires a huge amount of time and politicking the ecosystem and I don't have it, sorry).
Bonus: a simultaneously awesome and horrible reality is that AI is really helping to improve AX here. A lot of AI tooling uses/abuses AX APIs to make things happen. How is OpenAI reading your list of windows, typing into them, etc? Accessibility frameworks! So a lot more apps are taking AX integration a lot more seriously since its table stacks for AI using it... Sad it requires that but the glass half full is more software is doing that.
What is AX in this context?
>> AX originated in reference to UX (User Experience) and stands for Accessibility Experience. AX is also sometimes used as a synonym for accessibility.
The language of accessibility – Staffnet | ETH Zurich https://ethz.ch/staffnet/en/service/communication/digital-ac...
accessibility. Also regularly seen as a11y.
Modern software is a joke. I saw a "lightweight" fui for Spotify the other day, written in rust! 800mb binary.
The bloated electron app is almost half that size.
So yes, when developers are literally retarded, even vibed cli programs with --Help given you 15 pages of command, it's time to reboot technology and go back to unikernel running forth or basic
As I said before [0], the same web developers that are the ones that ruined the web are now bringing their Java/Typescript, React mess into terminals where it is not needed.
[0] https://news.ycombinator.com/item?id=47364817
React is software development cancer and it just entered metastasis. It can't be cured anymore, it will spread throughut the entire stack and kill it from the inside. We already have it on the web, on mobile, on Windows 11 and, now, it's coming for the terminal emulator.
You’re a bit late to the game if you think that’s new. That has been a thing for the past 10y or so
Most people don’t care. It just the truth.
Maybe someone should come up with AI for blind people. TUAIs :-)