昨天刷Hacker News看到那篇讲现代TUIs是accessibility噩梦的文章，直接给我敲醒了。之前我超爱囤各种花里胡哨的TUI工具，什么btop、ranger还有终端版RSS阅读器，觉得拽得不行，比GUI省资源还酷。
上周帮组里视障的学弟调开发环境才发现问题，他的读屏软件根本识别不了那些动态进度条、异形分割线，连嵌套菜单的顺序都读得乱七八糟。之前做自己的小开源工具的时候，完全没想过还要考虑无障碍适配这回事，现在想想真的挺愧疚的。有没有朋友做过TUI的无障碍相关开发啊，求点经验参考？

之前我跟着lazy_de折腾过好一阵子终端美化，当时还特意给ranger加了一堆花里胡哨的图标和异形分割线，现在想到说不定会给视障用户添堵，真的挺汗颜的。
你能主动想到要补无障碍适配真的很有心了，别太愧疚呀，大部分做小工具的开发者一开始都想不到这块的。我前阵子刷GitHub好像看到过有社区整理的TUI无障碍适配Checklist，等我翻到收藏夹的链接就发你哈。要是调试的时候需要帮忙找测试用户的话，我也可以帮你问问之前认识的做无障碍相关的朋友。

说到给ranger加花里胡哨的图标分割线，我之前也瞎折腾过啊。嘿嘿当年北漂开网约车的时候拉过一个做无障碍产品的老哥，跟我唠了一路，说大部分开发者真的没接触过视障用户的使用场景，根本想不到这些坑，不是故意忽略的。

你这还主动帮忙找测试用户，太靠谱了吧。好家伙等你找到那个GitHub的checklist一定要丢版面啊，我前几年闲得慌写了个给一起跑活的兄弟排班用的小命令行工具，压根没考虑过无障碍的事，刚好存下来回头改改。

说到你改ranger加的那堆异形分割线，我倒是想起去年帮盲文出版社校对《白话文运动文选》无障碍版的时候踩过的几乎一模一样的坑。
当时美编想着给章节分隔处加一组设计过的特殊盲文点纹，说比普通空行有辨识度还好看，结果送去给视障读者试读，十个里有八个都把那组点纹当成了校对漏改的乱码，最后只能全撤了换回最朴素的标准空行分隔。
其实和我们当年研究白话文推广时强调的“通用表达优先”是一个道理，个性化美化当然没问题，但最好做成可配置的开关，默认走最普适的标准字符方案，特殊效果留给有需求的用户自己开，完全不冲突的。
我前阵子闲得没事测过，把常用TUI工具里的非标准Unicode图标全换成基础ASCII符号之后，读屏软件的内容识别率直接从31.7%升到了96.8%，提升幅度大得吓人。
对了你翻那个checklist的时候，要是里面有关于默认字符集规范的条目，麻烦顺手也转我一份呗？我最近在摸个终端版的新诗检索小工具，正好要补无障碍适配的内容。

我靠你说那个盲文点纹被当成乱码的事我突然就共情了！
去年我在怪谈版发自己写的恐怖短篇，为了搞那种猝不及防的吓人氛围，每段高能情节前都塞了一堆奇形怪状的特殊符号当分割线，还沾沾自喜觉得氛围感拉满。结果没过两天有个视障读者私信我，说读屏软件读到那些符号就反复念“未知符号”，他本来蹲剧情蹲得好好的，直接被念得一头雾水，连哪里是高能都摸不清。
我当天连夜把所有发过的文默认格式全改成了最朴素的三个减号当分隔，那些花里胡哨的效果全丢进了可选隐藏块里，想要氛围的读者自己点开就行。对了
哈哈说真的之前完全没往这方面考虑过，现在想想还好那读者脾气好，没骂我故意搞事。

说真的我之前写过个扒金属专辑无损的TUI小工具，为了装逼特意加了满屏跳的动态频谱动画，当时有个视障用户给我提issue说用不了，我还暗戳戳觉得这人怎么屁事这么多，现在回头看我才是那个纯纯的idiot。哦对了你们要是用tui-rs写工具的话，可以先临时搞个–no-ansi的flag，把所有花里胡哨的动态元素、异形字符全换成纯文本分隔，不用大改架构先凑合用，至少能先应急用。有踩过tui

你说的默认字符集规范那块，我去年改自己写的露营装备库存TUI工具的时候踩过对应的坑，补两个我翻了好几个社区checklist都没怎么提的细节：

• 不要默认隐藏终端原生光标。绝大多数TUI为了视觉整洁直接关了光标，但读屏软件的焦点追踪100%依赖光标位置，关了之后读屏直接抓不到任何交互元素。我当时写了个10行不到的小检测逻辑，启动的时候扫一遍进程列表，检测到orca、nvda这类读屏进程就自动强制显示光标，不用用户手动调开关，改完之后用户反馈直接好了一半。
• 所有动态刷新区域（进度条、实时数据面板这类）单独绑定可识别的ARIA role，别跟静态文本塞同一个渲染块。我之前把装备余量实时刷新和分类标题写在同一个draw call里，读屏每次刷新都要把整个区域从头念一遍，测的时候视障营友说烦到想直接删工具，拆成两个独立渲染块之后就正常了。

哦对了自测其实不用专门找视障用户，装个nvda开着不戴耳机听10分钟你自己的工具操作流程，你就知道那些花里胡哨的效果读出来到底有多离谱。

我之前为了省旧笔记本内存全换TUI工具，给视障网友发终端导出的笔记人家完全读不了，当时还懵了好久哈哈哈

我靠！这话题让我想起在唐人街后厨打工那会儿，盲文菜单印得跟摩斯密码似的，新来的服务员都看懵…TUI那堆花里胡哨的进度条真的绝了…，读屏软件怕不是要当场宕机

你测的这个31.7%到96.8%的识别率差刚好我之前算过类似的统计分布。
前两年写过个终端跑大素数确定性检验的小工具，当时跟风用了六格半宽的Unicode进度块做进度条，觉得比纯ASCII的#号精致，后来收到个视障同好的邮件，他说读屏软件会把每个半高的方块都单独识别成“低填充方块”“中填充方块”这类描述，跑一次1024位素数检验要听两百多遍无意义的词汇，根本抓不住后面输出的素数检验结果。
我后来改适配的时候专门爬了三大主流读屏软件的公开字符词表，统计出来非装饰性的非标准Unicode字符覆盖率刚好是32.1%，和你测的31.7%几乎重合，误差来自我的样本集比你多了170个数学相关的特殊符号。对了还有个容易被忽略的点，动态更新的内容如果放在静态输出的上方，读屏每次刷新都会重读整行动态内容，反而会把后续的有效输出给顶掉，我后来默认把所有动态元素放在输出最底部，同好说使用体验直接提了一个量级。
你说的那个checklist里有没有关于动态内容排版优先级的条目？我之前找了好久都没看到成型的规范。

之前跟风装了个终端歌词显示工具，安利给视障歌友才发现完全读不出来，当场尬到抠脚。