alt Hacker NewsThe text mode lie: why modern TUIs are a nightmare for accessibility
Comments
> 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.
> This is unacceptable. Closing an accessibility report because the maintainers haven't touched it in months is not “tidying up”; it is hiding evidence. It effectively says that if a bug is ignored long enough, it ceases to exist.
Another perspective from a project maintainer’s point of view:
The people who own and maintain the project get to decide what the status Open and Closed means in the context of a ticket. Users do not necessarily have to agree.
For example, a project maintainer may choose to assign to a status of Open the meaning “this is untriaged or we’re actively working on it”, and Closed could mean “we have looked at this ticket and determined that no team member is going to work on it right now.” In other words, Closed does not have to mean “rejected and this decision is final” but can mean “it’s not something we’re currently working on.” These semantics might not be intuitive for everyone but can be justifiable if they help the project members organize their workload.
This is a well documented issue, TUI vs. windows.
Back in the 90s when most SAP systems switched from AS/400 terminals to Windows NT, people reported massive losses in productivity.
I've never worked on SAP, my mother did. And basically, she went from a fully tabular, function-key based oriented workflow, to holding a mouse, moving around and clicking a lot (tabbing and F keys were lost for many functions).
She showed me how she could go from ESC ESC F4 F3 TAB TAB and she was across the whole system a super speed. And this was a terminal, not the actual system!
The short of the story is this
Windows based application work best for discoverability and new users
Terminal based applications work best for faster, memory based navigation and power users.
>The mythical, it's text, so it's accessible. There is a persistent misconception among sighted developers: if an application runs in a terminal, it is inherently accessible.
Nope, nobody believes that. Devs say that for text documents which is somethig else entirely -- and, with provisions, for terminal single command apps (like grep, cut, ls, and so on). Nobody said it for TUIs.
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.)
TUIs were supposed to be the simple option. now they're just web apps wearing a terminal costume
TUI will be rediscovered without the window shit. Few people realise it yet, it it’s g. be sprite based as in c64 consoles. Perhaps someone is already doing it somewhere.
Windows and panes… are free to go. The calming environment of text, which as of 2026 is still integral part of humanity’s cultural dna, and is super underexplored in this medium.
I would say the cognitive agression of modern web is more of a nightmare really in the very psychedelic sense of it with all the imagery and video and ads completely devoid of context.
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.
We should make a terminal accessibility testing interposer (screen/tmux/ascinema style) that collapses all horizontal whitespace to a single space character, disables all color, doesn't allow hardware cursor hiding, slows down to teletype speeds, and forces all output to the end of the buffer unless echoing a typed character. This would be pretty indicative of the experience a screen reader user gets (and I say this as a screen reader user). You'd get some false positives; that tool would be problematic with some patterns which do actually work though.
If your TUI works in conditions like these, or can at least be accessibly configured to do so, you're pretty much done accessibility-wise.
There are some quick wins to be made here; disabling spinners, gratuitous animations and status lines, moving the hardware cursor as you navigate through menu options, even if there's a color or emoji-based selection indicator present, avoiding unnecessary re-renders (don't redraw the whole prompt if you're just echoing a single character, I'm looking at you, Python 3.13+), sorting line segments by importance (timestamps should go at the end, messages at the beginning), that sort of thing.
The real fix would involve an aria-style protocol that lets you actually communicate semantics to a screen reader, but that would require buy-in from TUIs, TUI libraries, terminal emulators, operating systems and screen readers, so it will never happen.
The hacker aesthetics of TUIs, especially around coding agents, is undeniable and the fact that you can mostly run them on any shell (even remote) is neat.
But the UX? If you the goal is not to read a single line of the code churned by these agents, and perhaps that is the point, then they are fine - type the prompt and cross your fingers.
Anything else that requires reading and changing needs an IDE of sorts. I am not saying you cannot have your workflow works with TUIs - plenty of people do. It is just not as good and flexible as full desktop applications.
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.
There is no cross platform standard that accomplishes the goals that authors turn to TUIs to solve. There is no widely distributed remotely accessible interface that pops up GUI windows from a shell context that works everywhere.
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.
Are there any recommendations for testing accessibility for TUI applications? The article mentions speakup, but as far as I understand, you need a hardware synthesizer to use that. Is it also possible to use orca?
I wonder how Turbo Vision (still the only good TUI framework) does on screen reader accessibility.
I'm sure there's a proposal for this somewhere, but I've always wondered if it wouldn't be most viable to just have a separate "reader mode" that replaces all the TUI elements with some sort of templated descriptive string of text, something like "Page one. Foo entry. ' bar'"
Seems a lot more viable than trying to get new standard escape codes and outputting those along with visual content that may be flickering erratically. Also probably gets too complex faster than those proposals with more intricate UIs, but IMO it's really hard to defend TUIs for anything but relatively simple programs as an in-between a CLI and a native application.
Hey Claude how do I get around signed binaries and App Store hell created by the likes of Apple and Microsoft?
Maybe that’s why we have them? Tbh I don’t mind them, beats some space inefficient bubbly ui showing virtually no info per screen.
I have been saying that since vim and emac . Vim and emac are good because their keyboard driven input system, not because of TUI. Emac gui is proof of that, vim have none properly
I agree with some of the sentiment here, but why is it presented in an AI slop format? It's really a self-defeating message.
"TUI" is for people who cant learn text commands: looks pretty, easy to use, not flexible and not powerful. just use a GUI already.
I hear CC users relying on Braille not being very happy with how CC renders, and uses the cursor...
OTOH, I am also a Braille user and think codex works just fine.
Maybe check the alternatives before declaring an accessibility crisis?
For accesibility edbrowse https://github.com/cmb/edbrowse and anything CLI shines such as SIC + Bitlbee to talk with chat platforms, and maybe pjsua for SIP. These can be combined wth yasr (terminal reader)+speech-dispatcher as a TTS.
NCurses can be hooked with ease; IDK about the rest.
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.
I'm slowly working on this, trying to figure out what works as I add accessibility to TUIs. Having better structured information on screen feels so so so compelling to me.
I wish the terminal-wg was more active. There's a bunch of weird odd OSC's folks have tried to make for enhancing structure of the terminal, for various ways to emit more layout-coupled semantic info. Accessibility APIs are great but in most forms a huge chunk of their capabilities feel pretty disconnected from the actual drawing on the screen, are somewhat a parallel construct to what's on screen. Using OSC to layer in more information about what is being drawn feels righter.
Two examples, collapsible regions, semantic prompt regions, https://gitlab.freedesktop.org/terminal-wg/specifications/-/... https://gitlab.freedesktop.org/terminal-wg/specifications/-/...
But in general feels like, for all the TUI interest, not many folks are about and working together to actually figure out how to advance the terminal itself.
The "T" in "TUI" means "Terminal" not "Text".
I use mc as a file manager. I have no idea what you are talking about.
[flagged]
[flagged]
Maybe someone should come up with AI for blind people. TUAIs :-)
Emacs is a seemingly [0] excellent compromise between modern TUIs and accessibility since it keeps the text-centric paradigm but allows for much cleaner accessibility. [1]
[0]: I do not need any accessibility features myself.
[1]: https://diesenbacher.net/blog/entries/speaking-emacs.html