The author, a screen reader user, argues that modern TUI apps like lazygit, k9s, and bottom switch to the alternate screen buffer and paint character-based canvases with ANSI escape sequences, making them completely opaque to screen readers. Despite being 'text-based,' these tools are paradoxically less accessible than their GUI counterparts, which at least implement platform accessibility APIs.
By surfacing this article on Hacker News (145 points, 62 comments), the submission highlights the editorial's core observation: most TUI framework authors in the Charm/Bubbletea, Textual, and Ratatui ecosystems hadn't deeply considered accessibility at all. The persistent myth that 'it's text, so it's accessible' went unchallenged because few screen reader users were in the feedback loop.
The editorial synthesis draws a clear architectural distinction: traditional CLI tools like git, grep, and curl output sequential text to stdout that screen readers can parse linearly. Modern TUI frameworks break this contract by taking over the viewport and managing their own focus, layout, and rendering — effectively building inaccessible GUI-like applications inside the terminal. The regression is specifically in the frameworks, not in terminal-based tooling as a concept.
A blog post on xogium.me titled "The text mode lie: why modern TUIs are a nightmare for accessibility" hit 145 points on Hacker News, sparking one of the more uncomfortable conversations the developer tooling community has had in recent memory. The author — who relies on a screen reader — lays out a damning case: the explosion of modern TUI (Text User Interface) applications has created a class of developer tools that are, paradoxically, less accessible than their GUI counterparts.
The tools in question aren't obscure. We're talking about lazygit, lazydocker, k9s, bottom, and dozens of other terminal applications built on frameworks like Charm's Bubbletea (Go), Textual (Python), and Ratatui (Rust). These are some of the most beloved tools in the developer ecosystem — regularly featured in "awesome CLI tools" lists, trending on GitHub, and praised for making terminal workflows feel modern. But for developers who use screen readers, these tools might as well not exist.
The Hacker News discussion revealed something uncomfortable: most TUI framework authors hadn't deeply considered accessibility at all. Not out of malice — out of ignorance. The assumption that "it's text, so it's accessible" turns out to be one of the most persistent and damaging myths in developer tooling.
To understand the problem, you need to understand how screen readers interact with terminals. Traditional CLI tools — `git status`, `grep`, `curl` — output sequential text to stdout. A screen reader can parse this linearly, and it works. The terminal's text buffer is the interface, and screen readers can read that buffer.
Modern TUI frameworks do something fundamentally different. They switch to the alternate screen buffer, take over the entire terminal viewport, and render custom layouts using ANSI escape sequences. They're essentially painting a canvas with characters — positioning elements at specific coordinates, handling their own focus management, creating scrollable panes and modal dialogs. From a screen reader's perspective, this is indistinguishable from a blank screen or a wall of meaningless characters.
The technical mechanism is straightforward: when a TUI app sends `\e[?1049h` to enter the alternate screen, it leaves the primary buffer (where screen readers look) behind. The custom rendering that follows — box-drawing characters, color-coded status bars, split panes — has no semantic meaning. There's no accessibility tree. No ARIA-equivalent labels. No focus management that external tools can hook into. The screen reader sees raw escape sequences or, at best, a jumble of characters with no navigable structure.
This is particularly cruel because the terminal used to be the accessible option. Before GUIs matured their accessibility APIs (MSAA, UIA, ATK, NSAccessibility), the command line was where blind developers could work most effectively. The modern TUI movement has taken the one interface that reliably worked for screen reader users and rebuilt it using patterns that break accessibility.
The numbers make the scope clear. Charm's Bubbletea framework alone has over 28,000 stars on GitHub and powers hundreds of CLI tools. Textual has over 25,000 stars. Ratatui, the Rust successor to tui-rs, has over 12,000. These aren't niche frameworks — they're the default choice for anyone building a terminal application in 2026. Every new TUI built on these frameworks without accessibility consideration adds another tool to the pile that blind developers cannot use.
The core issue isn't that individual developers are lazy. It's that the frameworks themselves don't provide accessibility primitives. If you're building a web application, the browser gives you a DOM, an accessibility tree, ARIA attributes, and screen reader integration essentially for free — you have to actively break it. If you're building a native GUI, the OS provides accessibility APIs that your UI toolkit likely implements by default.
TUI frameworks offer none of this. There is no standard protocol for terminal accessibility beyond "output text sequentially." The terminal itself has no concept of an accessibility tree, focus rings, or semantic regions. This means that even a well-intentioned TUI developer has no clear path to making their application accessible. They'd have to invent the entire accessibility layer from scratch.
Some in the Hacker News discussion pointed to potential solutions. One approach: TUI frameworks could maintain a parallel text representation — a linearized, screen-reader-friendly view of the interface state that gets written to stdout or a dedicated pipe. Think of it as a "headless mode" that outputs structured text instead of visual rendering. When a screen reader is detected, the application could switch to this mode automatically.
Another approach borrows from the web: define a terminal accessibility protocol. A specification that allows TUI applications to expose their widget hierarchy, labels, and state changes through a standard interface that screen readers can consume. This would require buy-in from terminal emulators, screen reader vendors, and TUI framework authors — a significant coordination challenge, but not an impossible one.
A third, more pragmatic suggestion: TUI tools should always provide a non-interactive fallback. If lazygit offers a beautiful TUI for staging commits, it should also support `lazygit stage file.txt` as a direct command. This doesn't solve the accessibility problem for interactive workflows, but it at least provides functional access.
If you maintain a TUI application or are considering building one, here's the uncomfortable inventory you need to do:
Audit your tool for screen reader compatibility. Install NVDA (Windows), turn on VoiceOver (macOS), or use Orca (Linux), then try to use your own tool. If you can't navigate to every interactive element and understand the current state, your tool is inaccessible. Most TUI developers have never done this.
Provide CLI fallbacks for critical operations. Every action available in your TUI should also be available as a non-interactive command. This isn't just an accessibility concern — it's also what makes your tool scriptable and composable with other Unix tools. The TUI should be a layer on top of a functional CLI, not the only interface.
If you're choosing a TUI framework, be aware that none of the major options (Bubbletea, Textual, Ratatui) currently have meaningful accessibility support. This doesn't mean you shouldn't use them — but you should plan for accessibility from the start, even if the framework doesn't help you yet. Track the relevant GitHub issues: accessibility is now an open discussion in all three major framework communities, and contributions to this effort have disproportionate impact.
If you're a team lead selecting developer tools, consider whether mandating a TUI tool (say, k9s for Kubernetes management or lazygit for version control) excludes team members who use assistive technology. The `kubectl` CLI and `git` CLI remain the most accessible options for their respective domains.
The 145-point Hacker News showing suggests this post has crossed the threshold from niche accessibility complaint to mainstream developer concern. The pattern is familiar: the web went through the same reckoning in the 2010s, eventually producing WCAG standards and legal mandates that made accessibility non-optional. Terminals are a decade behind that curve. The question isn't whether TUI accessibility will become a framework-level concern — it's whether it happens through proactive design or through the slower, more painful process of blind developers simply being excluded from modern tooling until someone with enough leverage forces the issue. The frameworks that solve this first will earn a significant competitive advantage. The ones that don't will eventually have to answer for it.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.