10 ms·

The text mode lie: why modern TUIs are a nightmare for accessibility

296 points by SpyCoder77 5mo ago

NIckGeek 5mo ago
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.
- slopinthebag 5mo ago
  Does a terminal even have any accessibility support tho?
  - NewJazz 5mo ago
    Yes. Well, for cli yes.
  - paulbgd 5mo ago
    The article mentions several TUI programs that rendering in an accessible way for screen readers.
    - slopinthebag 5mo ago
      [flagged]
  - Spooky23 5mo ago
    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.
- MBCook 5mo ago
  I think it’s clear from the article declarative UI could be done, with correct implementation and some options to disable noise. Clearly no one put thought into any of that. It was just “make terminal, but pretty”.
gopalv 5mo ago
> 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 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.
- user3939382 5mo ago
  I tried everything to customize the colors of some elements in CC’s TUI, like the dispatched prompt bg/fg, and found it impossible. A lot of issues that surface for people with colorblindness or adjacent sight issues also arise for eInk monitors.
swaits 5mo ago
[flagged]
tux 5mo ago
Maybe someone should come up with AI for blind people. TUAIs :-)
Lihh27 5mo ago
TUIs were supposed to be the simple option. now they're just web apps wearing a terminal costume
- danpalmer 5mo ago
  ...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.
acjohnson55 5mo ago
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.
- SchemaLoad 5mo ago
  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.
  - zbentley 5mo ago
    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.
  - xboxnolifes 5mo ago
    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.
    - yellowapple 5mo ago
      I feel like the better solution here (than trying to shoehorn a GUI into an interface meant for text) is to make terminal windows graphically-aware, like how things work in Plan 9.
      - SchemaLoad 5mo ago
        At that point what you want is just a tiling window manager rather than a terminal that supports GUIs.
btbuildem 5mo ago
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.
- MBCook 5mo ago
  They’re not terminal UIs. They’re attempts at pretending to have Windows (etc.) GUIs in a terminal. Same stuff people made for DOS when Windows wasn’t common or good enough yet. I’m not surprised they’re a disaster. Or built without understanding the abilities of the terminal they’re running on.
  - sethaurus 5mo ago
    If you don't want people calling these apps TUIs, what would you prefer people call them? And what does the term TUI refer to, if not this?
    - bitwize 5mo ago
      Text User Interface.
      - ColonelPhantom 5mo ago
        But what _is_ a "Text User Interface"? Google Images just returns what is being discussed here: "GUIs" that run in some kind of text mode. And to me, that's also what a TUI is. A more textually oriented environment (like a normal Unix shell) is, in my experience, usually referred to as a CLI: Command Line Interface. I did find an interesting hybrid in the Pi coding agent: it seems to leverage the normal terminal scrollback, while still enhancing it with things like transient input fields and status lines, so that it can display those without cluttering scrollback.
        bitwize 5mo ago
rgoulter 5mo ago
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.
hilbert42 5mo ago
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 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.)
rvz 5mo ago
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 https://news.ycombinator.com/item?id=47364817
- dgellow 5mo ago
  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
  - rvz 5mo ago
    7 years later and nothing has changed [0] and just more of the same web slop now fully taking over its next target. [0] https://news.ycombinator.com/item?id=20503158 https://news.ycombinator.com/item?id=20503158
- doodlesdev 5mo ago
  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.
  - llbbdd 5mo ago
    What do you think React is?
    - kajman 5mo ago
      It's true though. I accidently put a React component in my Postgres schema and all the data was dropped. It really poisoned the whole stack.
- anthk 5mo ago
  Javascript it's already on some ARM processors as a dedicated instruction.
joshka 5mo ago
Mitchell Hashimoto has a great response on lobste.rs https://lobste.rs/s/ifbdw1/text_mode_lie_why_modern_tuis_are#c_awixrd 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.
- dgellow 5mo ago
  What is AX in this context?
  - irickt 5mo ago
    >> 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-accessibility/language-of-accessibility.html https://ethz.ch/staffnet/en/service/communication/digital-ac...
heliumtera 5mo ago
[flagged]
- tomhow 5mo ago
  We've banned this account for repeatedly posting comments that break the guidelines and seem LLM-generated.
  - heliumtera 5mo ago
    [dead]
Beijinger 5mo ago
I use mc as a file manager. I have no idea what you are talking about.
- dvhh 5mo ago
  admittedly mc is far from being a "modern" TUI
- sedatk 5mo ago
  mc adheres to NC standard, so you already have an extremely accessible system. The whole UI knowledge can be transferred easily among mc, TotalCmd, or NC from 1988 or whatever. Not the case with most TUIs. I had to use aptitude and git's text mode merge tool recently, and both had terrible accessibility, not to mention entirely different designs too. I'm sure I'd get good at them once I read their manual but they were extremely non-intuitive and hard to explore.
keyle 5mo ago
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.
- orbital-decay 5mo ago
  That's a problem with the specific GUI, not GUI as a concept. Good GUI frameworks should be built for predictability and keyboard-driven fast paths, and have this included by default so you don't have to make these decisions for each app. In fact, all successful applications for professionals/power users are built with fast paths in mind. Even Microsoft's ribbon which gets a lot of hate for some reason is an example of that, it's keyboard-driven, customizable, and discoverable at the same time.
  - chihuahua 5mo ago
    In fact, just about everything in Windows (not apps, since those can be created by 3rd party developers who may or may not care, but the OS) can be operated by keyboard: login, start menu, settings, even ancient tools like Event Viewer.
    - no-name-here 5mo ago
      Except, strangely, for setup - if you don’t load your laptop’s touchpad/trackpad driver during the early select a partition screen, you seem to get stuck on later screens like when you are required to connect to WiFi.
- baq 5mo ago
rietta 5mo ago
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.
- cmrdporcupine 5mo ago
  Sure there is. It's called HTML. Yes it's gronky. But so are VT100 escape codes.
v3ss0n 5mo ago
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
jauntywundrkind 5mo ago
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/-/work_items/4 https://gitlab.freedesktop.org/terminal-wg/specifications/-/... https://gitlab.freedesktop.org/terminal-wg/specifications/-/work_items/3 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.
- ximm 5mo ago
  I am not sure it is helpful to shoehorn terminals into being a second web. The terminal's strength is its simplicity. For example, I really dislike mouse support in TUIs. 100% of the times I used the mouse on a TUI, I wanted to copy a piece of text. If the TUI hijacks the mouse and does something different with it (e.g. vim switching into visual mode) that is just annoying. Of course a11y is important. But it barely works on the web and we won't get perfect semantics on the terminal without a lot of work. I say the better option is to strip down the experience to the parts that work well.
  - arcanemachiner 5mo ago
    > If the TUI hijacks the mouse and does something different with it (e.g. vim switching into visual mode) that is just annoying. tmux is great for this. Just press Ctrl+[ and the cursor can select whatever text is in the window.
  - opan 5mo ago
    I agree that accidental mouse actions in a TTY are horrible, but generally speaking if you hold shift when clicking and dragging, it will work at the terminal emulater layer instead of sending the clicks to the program in the terminal. I have been shift-clicking like this for years. More because I'm generally in tmux than anything else. If I click and drag without shift I think tmux intercepts it usually.
kajman 5mo ago
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.
- zozbot234 5mo ago
  > 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'" We have a term for that, it's called a CLI. For example, ed and ex are the historical CLI counterparts to vi.
  - kajman 5mo ago
    I suppose that would just be an interactive CLI. Usually I think of them as one-and-done invocations like sed. It's definitely not an ideal mode as evidenced by the current popularity of vim over ed, but it's better than a program being unusable.
    - skydhash 5mo ago
      claude code would fit this model as the most important point is the prompt. Just make the rest of the interactions be commands.
zobzu 5mo ago
"TUI" is for people who cant learn text commands: looks pretty, easy to use, not flexible and not powerful. just use a GUI already.
pxx 5mo ago
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.
anthk 5mo ago
NCurses can be hooked with ease; IDK about the rest.
anthk 5mo ago
For accesibility edbrowse https://github.com/cmb/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.
ragall 5mo ago
The "T" in "TUI" means "Terminal" not "Text".
maxrev17 5mo ago
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.
ximm 5mo ago
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?
- ryanshrott 5mo ago
  [dead]
_pdp_ 5mo ago
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.
coldtea 5mo ago
>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.
larodi 5mo ago
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.
lynx97 5mo ago
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?
Hackbraten 5mo ago
> 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.
- __alexs 5mo ago
  gemini-cli is not some volunteer maintained open source thing. Google generally try to be good at accessibility and even publish conformance reports for most of their products https://belonging.google/accessibility-conformance-reports/ https://belonging.google/accessibility-conformance-reports/
miki123211 5mo ago
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.
kaszanka 5mo ago
I wonder how Turbo Vision (still the only good TUI framework) does on screen reader accessibility.
Hendrikto 5mo ago
[flagged]
mcookly 5mo ago
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 https://diesenbacher.net/blog/entries/speaking-emacs.html
trashb 5mo ago
Aside from screen readers are the input methods and hotkeys those are often not consistent or unchangeable in modern tools. However I guess that is not only applicable to TUIs. For example ctrl+arrow to jump over words is not very consistent in all text fields which is a problem for accessibility also.
strideashort 5mo ago
That really depends on disability. A single screen with no distractions really helps me focus. That said, dark terminal bg (which i like) kinda sucks for astigmatism (but that’s not unique to TUIs).
skeledrew 5mo ago
That's just the kind of thing you get when you shove something that's native to web browsers into a terminal. Which is what web devs are constantly trying to do in their quest to use their favorite framework and language everywhere. It's the nightmare concept of Electron everything now encroaching on the text-dominant space.
scuderiaseb 5mo ago
I use ghostty and tmux, that makes it really nice to be in th terminal and have access to good TUIs. I use neovim and k9s mostly and those are such amazinng tools, AI stuff sure but that’s because I don’t really have any other choice. I also use lazygit lately but that’s mostly to get familiar and to have a nicer view of commit history than ’git log —graph’. Also I hate electron apps so well made TUIs are a step up compared to running a web browser for one app.
hbogert 5mo ago
I would be perfectly fine not using TUIs if only GUIs were a lot saner for keyboard driven workflows. Second thing is minimalism. I'm not overloaded with information other than the stuff i care about. Of course this is not inherent to TUIs, but just a common theme (and o.c. there are exceptions.)
piposlab 5mo ago
[flagged]
ryanshrott 5mo ago
[dead]

296 points by SpyCoder77 5mo ago

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.

slopinthebag 5mo ago
Does a terminal even have any accessibility support tho?
- NewJazz 5mo ago
  Yes. Well, for cli yes.
- paulbgd 5mo ago
  The article mentions several TUI programs that rendering in an accessible way for screen readers.
  - slopinthebag 5mo ago
    [flagged]
- Spooky23 5mo ago
  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.
MBCook 5mo ago
I think it’s clear from the article declarative UI could be done, with correct implementation and some options to disable noise. Clearly no one put thought into any of that. It was just “make terminal, but pretty”.

gopalv 5mo ago

> 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 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.

user3939382 5mo ago
I tried everything to customize the colors of some elements in CC’s TUI, like the dispatched prompt bg/fg, and found it impossible. A lot of issues that surface for people with colorblindness or adjacent sight issues also arise for eInk monitors.

swaits 5mo ago

[flagged]

tux 5mo ago

Maybe someone should come up with AI for blind people. TUAIs :-)

Lihh27 5mo ago

TUIs were supposed to be the simple option. now they're just web apps wearing a terminal costume

danpalmer 5mo ago
...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.

acjohnson55 5mo ago

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.

SchemaLoad 5mo ago
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.
- zbentley 5mo ago
  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.
- xboxnolifes 5mo ago
  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.
  - yellowapple 5mo ago
    I feel like the better solution here (than trying to shoehorn a GUI into an interface meant for text) is to make terminal windows graphically-aware, like how things work in Plan 9.
    - SchemaLoad 5mo ago
      At that point what you want is just a tiling window manager rather than a terminal that supports GUIs.

btbuildem 5mo ago

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.

MBCook 5mo ago
They’re not terminal UIs. They’re attempts at pretending to have Windows (etc.) GUIs in a terminal. Same stuff people made for DOS when Windows wasn’t common or good enough yet. I’m not surprised they’re a disaster. Or built without understanding the abilities of the terminal they’re running on.
- sethaurus 5mo ago
  If you don't want people calling these apps TUIs, what would you prefer people call them? And what does the term TUI refer to, if not this?
  - bitwize 5mo ago
    Text User Interface.
    - ColonelPhantom 5mo ago
      But what _is_ a "Text User Interface"? Google Images just returns what is being discussed here: "GUIs" that run in some kind of text mode. And to me, that's also what a TUI is. A more textually oriented environment (like a normal Unix shell) is, in my experience, usually referred to as a CLI: Command Line Interface. I did find an interesting hybrid in the Pi coding agent: it seems to leverage the normal terminal scrollback, while still enhancing it with things like transient input fields and status lines, so that it can display those without cluttering scrollback.
      - bitwize 5mo ago

rgoulter 5mo ago

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.

hilbert42 5mo ago

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 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.)

rvz 5mo ago

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 https://news.ycombinator.com/item?id=47364817

dgellow 5mo ago
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
- rvz 5mo ago
  7 years later and nothing has changed [0] and just more of the same web slop now fully taking over its next target. [0] https://news.ycombinator.com/item?id=20503158 https://news.ycombinator.com/item?id=20503158
doodlesdev 5mo ago
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.
- llbbdd 5mo ago
  What do you think React is?
  - kajman 5mo ago
    It's true though. I accidently put a React component in my Postgres schema and all the data was dropped. It really poisoned the whole stack.
anthk 5mo ago
Javascript it's already on some ARM processors as a dedicated instruction.

joshka 5mo ago

Mitchell Hashimoto has a great response on lobste.rs https://lobste.rs/s/ifbdw1/text_mode_lie_why_modern_tuis_are#c_awixrd 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.

dgellow 5mo ago
What is AX in this context?
- irickt 5mo ago
  >> 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-accessibility/language-of-accessibility.html https://ethz.ch/staffnet/en/service/communication/digital-ac...

heliumtera 5mo ago

[flagged]

tomhow 5mo ago
We've banned this account for repeatedly posting comments that break the guidelines and seem LLM-generated.
- heliumtera 5mo ago
  [dead]

Beijinger 5mo ago

I use mc as a file manager. I have no idea what you are talking about.

dvhh 5mo ago
admittedly mc is far from being a "modern" TUI
sedatk 5mo ago
mc adheres to NC standard, so you already have an extremely accessible system. The whole UI knowledge can be transferred easily among mc, TotalCmd, or NC from 1988 or whatever. Not the case with most TUIs. I had to use aptitude and git's text mode merge tool recently, and both had terrible accessibility, not to mention entirely different designs too. I'm sure I'd get good at them once I read their manual but they were extremely non-intuitive and hard to explore.

keyle 5mo ago

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.

orbital-decay 5mo ago
That's a problem with the specific GUI, not GUI as a concept. Good GUI frameworks should be built for predictability and keyboard-driven fast paths, and have this included by default so you don't have to make these decisions for each app. In fact, all successful applications for professionals/power users are built with fast paths in mind. Even Microsoft's ribbon which gets a lot of hate for some reason is an example of that, it's keyboard-driven, customizable, and discoverable at the same time.
- chihuahua 5mo ago
  In fact, just about everything in Windows (not apps, since those can be created by 3rd party developers who may or may not care, but the OS) can be operated by keyboard: login, start menu, settings, even ancient tools like Event Viewer.
  - no-name-here 5mo ago
    Except, strangely, for setup - if you don’t load your laptop’s touchpad/trackpad driver during the early select a partition screen, you seem to get stuck on later screens like when you are required to connect to WiFi.
baq 5mo ago

rietta 5mo ago

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.

cmrdporcupine 5mo ago
Sure there is. It's called HTML. Yes it's gronky. But so are VT100 escape codes.

v3ss0n 5mo ago

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

jauntywundrkind 5mo ago

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/-/work_items/4 https://gitlab.freedesktop.org/terminal-wg/specifications/-/... https://gitlab.freedesktop.org/terminal-wg/specifications/-/work_items/3 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.

ximm 5mo ago
I am not sure it is helpful to shoehorn terminals into being a second web. The terminal's strength is its simplicity. For example, I really dislike mouse support in TUIs. 100% of the times I used the mouse on a TUI, I wanted to copy a piece of text. If the TUI hijacks the mouse and does something different with it (e.g. vim switching into visual mode) that is just annoying. Of course a11y is important. But it barely works on the web and we won't get perfect semantics on the terminal without a lot of work. I say the better option is to strip down the experience to the parts that work well.
- arcanemachiner 5mo ago
  > If the TUI hijacks the mouse and does something different with it (e.g. vim switching into visual mode) that is just annoying. tmux is great for this. Just press Ctrl+[ and the cursor can select whatever text is in the window.
- opan 5mo ago
  I agree that accidental mouse actions in a TTY are horrible, but generally speaking if you hold shift when clicking and dragging, it will work at the terminal emulater layer instead of sending the clicks to the program in the terminal. I have been shift-clicking like this for years. More because I'm generally in tmux than anything else. If I click and drag without shift I think tmux intercepts it usually.

kajman 5mo ago

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.

zozbot234 5mo ago
> 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'" We have a term for that, it's called a CLI. For example, ed and ex are the historical CLI counterparts to vi.
- kajman 5mo ago
  I suppose that would just be an interactive CLI. Usually I think of them as one-and-done invocations like sed. It's definitely not an ideal mode as evidenced by the current popularity of vim over ed, but it's better than a program being unusable.
  - skydhash 5mo ago
    claude code would fit this model as the most important point is the prompt. Just make the rest of the interactions be commands.

zobzu 5mo ago

"TUI" is for people who cant learn text commands: looks pretty, easy to use, not flexible and not powerful. just use a GUI already.

pxx 5mo ago

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.

anthk 5mo ago

NCurses can be hooked with ease; IDK about the rest.

anthk 5mo ago

For accesibility edbrowse https://github.com/cmb/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.

ragall 5mo ago

The "T" in "TUI" means "Terminal" not "Text".

maxrev17 5mo ago

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.

ximm 5mo ago

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?

ryanshrott 5mo ago
[dead]

_pdp_ 5mo ago

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.

coldtea 5mo ago

>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.

larodi 5mo ago

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.

lynx97 5mo ago

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?

Hackbraten 5mo ago

> 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.

__alexs 5mo ago
gemini-cli is not some volunteer maintained open source thing. Google generally try to be good at accessibility and even publish conformance reports for most of their products https://belonging.google/accessibility-conformance-reports/ https://belonging.google/accessibility-conformance-reports/

miki123211 5mo ago

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.

kaszanka 5mo ago

I wonder how Turbo Vision (still the only good TUI framework) does on screen reader accessibility.

Hendrikto 5mo ago

[flagged]

mcookly 5mo ago

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 https://diesenbacher.net/blog/entries/speaking-emacs.html

trashb 5mo ago

Aside from screen readers are the input methods and hotkeys those are often not consistent or unchangeable in modern tools. However I guess that is not only applicable to TUIs. For example ctrl+arrow to jump over words is not very consistent in all text fields which is a problem for accessibility also.

strideashort 5mo ago

That really depends on disability. A single screen with no distractions really helps me focus. That said, dark terminal bg (which i like) kinda sucks for astigmatism (but that’s not unique to TUIs).

skeledrew 5mo ago

That's just the kind of thing you get when you shove something that's native to web browsers into a terminal. Which is what web devs are constantly trying to do in their quest to use their favorite framework and language everywhere. It's the nightmare concept of Electron everything now encroaching on the text-dominant space.

scuderiaseb 5mo ago

I use ghostty and tmux, that makes it really nice to be in th terminal and have access to good TUIs. I use neovim and k9s mostly and those are such amazinng tools, AI stuff sure but that’s because I don’t really have any other choice. I also use lazygit lately but that’s mostly to get familiar and to have a nicer view of commit history than ’git log —graph’. Also I hate electron apps so well made TUIs are a step up compared to running a web browser for one app.

hbogert 5mo ago

I would be perfectly fine not using TUIs if only GUIs were a lot saner for keyboard driven workflows. Second thing is minimalism. I'm not overloaded with information other than the stuff i care about. Of course this is not inherent to TUIs, but just a common theme (and o.c. there are exceptions.)

piposlab 5mo ago

[flagged]

ryanshrott 5mo ago

[dead]