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

Original Article ↗ Hacker News Discussion ↗

Modern terminal user interfaces (TUIs) built with frameworks like React and Ink are coming under fire for being less accessible to blind and visually impaired users than both traditional command-line tools and many graphical apps. Commenters argue that these “GUI-in-a-terminal” tools often ignore screen readers, misuse the hardware cursor, flicker excessively, and sit atop a stack (terminal emulators, escape codes, OS accessibility APIs) that has poor accessibility support overall. While some see TUIs as convenient for remote work and keyboard-heavy workflows, others suggest web UIs, classic ncurses-style apps, or better terminal standards (ARIA-like semantics, OSC extensions) as more promising paths to usable, accessible tools.

Core critique of modern TUIs

  • Thread strongly agrees with the article’s main point: most modern TUIs are not inherently accessible despite being “text.”
  • Many new TUIs behave like mini-GUIs in a terminal: layers of overdraw, flicker, custom cursors, spinners, and animations that confuse screen readers and braille displays.
  • Misuse of the hardware cursor is a recurring complaint; emulated cursors via colors or blocks break accessibility.
  • Some tools are described as “vibecoded,” heavy, and brittle — more about aesthetics than ergonomics.

Accessibility stack problems & proposals

  • Several comments emphasize the entire stack is weak:
    • Many GPU-rendered terminal emulators don’t expose text via OS accessibility APIs, so the screen reader just sees an image.
    • There is no standard way for TUIs to convey semantic structure (roles, focus, regions) to the terminal.
  • Suggested direction: ARIA-like annotations for terminals (per-cell or per-region metadata), leveraging things like OSC sequences (e.g., semantic prompts).
  • Others propose practical stopgaps: an “accessibility testing interposer” that disables color, collapses whitespace, locks the cursor to focus, and slows output to mimic screen readers.
  • One simple rule is highlighted as very effective: always place the real terminal cursor at the focused element.

Experiences from blind users

  • At least one blind commenter prefers TUIs to web UIs despite better web semantics, due to web slowness, verbosity, and heavy stacks.
  • Others note that some TUI tools render acceptably for braille users, while some popular AI coding TUIs do not.
  • CLI-style tools (edbrowse, SIC+Bitlbee, SIP clients, etc.) plus terminal screen readers are cited as working well.
  • Emacs is mentioned as a good compromise: text-centric but with strong accessibility integrations.

Why TUIs remain popular

  • Reasons given:
    • Work over SSH and in containers with no extra setup.
    • Fit into terminal-centric workflows (Vim, tmux, etc.).
    • Easier cross-platform distribution than native GUIs; avoid Electron.
    • Uniform look/feel and strong keyboard control.
  • Others are skeptical, seeing TUIs as unnecessary complexity versus plain CLIs or web UIs.

Standards, UX, and consistency

  • Older TUI paradigms (ncurses, Midnight Commander, TN3270, CUA-style conventions) are praised for predictable, keyboard-driven workflows.
  • Inconsistent hotkeys, lack of focus rules, and non-standard interactions in modern TUIs are seen as major accessibility and usability regressions.
  • Some warn against turning terminals into a “second web” and advocate simplifying rather than layering on more semantics.