在软件开发领域，存在一个根深蒂固的误解：如果一个应用程序运行在终端中，它生来就是可访问的。这种假设认为，既然没有图形、没有复杂的 DOM 结构、没有 WebGL 画布，那么内容就是原始的 ASCII 文本，屏幕阅读器可以轻松解析。然而，现实恰恰相反。现代文本用户界面（TUI）往往比那些写得糟糕的图形界面更加排斥无障碍访问。正是在这个看似 “纯文本” 的环境中，视障用户面临着最为严峻的挑战。
流与网格：被忽视的架构根本差异
要理解现代 TUI 在无障碍访问上的失败，必须首先区分两个常被混为一谈的概念：命令行界面（CLI）和文本用户界面（TUI）。这两者在技术实现上有着本质的不同，而这个差异直接决定了屏幕阅读器能否正常工作。
CLI（也称为流模式）遵循标准的输入输出模型 stdin/stdout。用户输入一条命令，系统将结果追加到下方，光标向下移动。这种线性的、基于时间顺序的交互方式对于屏幕阅读器，特别是内核级别的阅读器（如 Linux 的 Speakup）而言是理想的。内容按照出现的先后顺序被依次朗读，用户可以准确地跟踪信息的流动。
相比之下，现代 TUI 将终端窗口视为一个二维的字符网格，每个单元格就是一个像素。它抛弃了时间流的线性特征，转而采用空间布局。这意味着应用程序可以随时在屏幕的任意位置写入字符，而不需要遵循从上到下的顺序。这种设计为开发者提供了极大的灵活性，能够创建丰富的交互界面，但对于依赖顺序阅读的屏幕阅读器来说，这是一场灾难。当光标在屏幕的不同区域之间瞬移时，屏幕阅读器试图读取光标所在位置的内容，结果用户听到的是随机拼接的信息片段，完全无法理解。
屏幕阅读器的噩梦：光标纷飞与输入延迟
以 Ink 框架（用于 Node.js 的 React 风格终端 UI 库）构建的工具为例。当用户与这类应用交互时，屏幕阅读器不会仅仅只是失败，它会被持续的信息流所淹没。因为框架将屏幕视为响应式画布，每次更新都会触发重绘。当 AI 模型正在 “思考” 时，工具会更新计时器或旋转指针。为此，框架将硬件光标移动到计时器位置，写入新的时间，然后移回原处。对于视力正常的用户，这个过程瞬间完成。但对视障用户来说，他们听到的是这样的：“响应中，已耗时 1 秒…… 响应中，已耗时 2 秒……（聊天历史片段）…… 响应中，已耗时 3 秒……” 屏幕阅读器的光标在屏幕各处跳来跳去，试图读取每一处更新，最终用户得到的是完全碎片化的信息流，几乎无法集中注意力完成任何任务。
更糟糕的是输入延迟问题。运行在单线程环境中的框架（如 Node.js）在历史记录增长时会遭受严重的性能退化。当用户粘贴一大段文本时，系统需要为数千行文本计算差异并重新布局。在这个过程中，用户按下一个键后可能需要等待长达十秒钟才能看到回显。系统忙于计算如何重绘屏幕，以至于无法处理用户的实际输入。这种延迟对于任何用户来说都是烦恼，对于依赖屏幕阅读器的用户而言则直接导致操作变得不可行。
颜色与字体的隐性门槛
除了架构层面的问题，现代 TUI 还面临着颜色对比度和字体渲染的隐性门槛。终端应用程序通常使用 ANSI 转义序列来定义前景色和背景色，但这些颜色组合往往缺乏足够的对比度。开发者在自己开发的机器上看到的清晰文本，在用户不同的终端主题和配色方案下可能变得难以辨认。一些终端支持 256 色，另一些支持真彩色，但并非所有终端都能正确处理色彩映射，这导致视觉信息的传达存在不确定性。
字体渲染的差异同样是一个被忽视的问题。不同的终端模拟器使用不同的字体渲染引擎，同一套字符在不同环境下的可读性可能存在显著差异。对于低视力用户来说，能够调整字体大小和行距至关重要，但许多 TUI 应用并没有提供这些选项。它们假定所有用户都使用默认的系统字体，而忽视了无障碍访问的基本需求。
老派工具的智慧：为什么旧方法仍然有效
面对现代框架的无障碍困境，一些诞生于二十年前的老工具反而提供了值得借鉴的解决方案。Irssi（流行的 IRC 客户端）被视作无障碍聊天的黄金标准，这并非偶然。它使用了定制的渲染引擎，充分利用 VT100 滚动区域。当新消息到达时，Irssi 告诉终端驱动程序定义一个滚动区域（比如从第一行到第二十三行），然后发送 “向上滚动” 的命令。终端硬件直接处理字符的移动，Irssi 只需要在滚动区域的底部绘制新文本。这种方式最大限度地减少了与输入行的干扰，依赖的是终端的硬件能力，而非软件层面的全屏重绘。
类似地，nano 和 vim 等编辑器允许用户完全隐藏光标。当光标可见且位置跟踪处于激活状态时，屏幕阅读器会优先播报光标位置更新而非字符输入。用户输入 "a" 时听到的不是字母 "a"，而是 “列 2”。通过禁用光标视觉显示或状态栏更新，用户可以强制屏幕阅读器依赖字符输入流而非嘈杂的坐标更新。现代框架很少提供 “无光标” 或 “头戴式” 模式，它们假定视觉光标对所有用户都是必不可少的，这种假设本身就是一种无形的排斥。
现代 TUI 框架为了优化开发者的体验而牺牲了机器渲染文本的效率，最终的代价却由最需要支持的群体承担。当构建者不考虑无障碍访问时，他们实际上在将视障用户群体排斥在工具之外。对于屏幕阅读器用户而言，一个简单的、线性的 CLI 流远比一个看似 “智能” 但充满延迟、信息碎片化问题的现代 TUI 更加友好。理解这些失败模式是改变的第一步，而认识到 “文本模式并非天然可访问” 则是所有终端开发者需要正视的现实。