Linux无障碍环境搭建：13年工程师实战指南

　　去年五月那会儿，我原以为给Linux搭无障碍环境就是个配置文件改改的事儿——结果被屏幕阅读器坑得差点摔键盘。那天下午测试机充电线不够长，我蹲在工位底下插电源，听见隔壁开发喊‘你这Orca怎么念着念着突然卡成电子音了？’我抬头一看，他屏幕上那行‘正在加载配置’卡了快两分钟，键盘上那个空格键还按下去不回弹，得用指甲抠才能弹起来。

　　说真的，这行干了十三年，最烦的就是‘无障碍’这种虚头巴脑的需求。产品经理总说‘要覆盖所有残疾用户场景’，可他们连盲人怎么用键盘都不知道——上次有个测试用例写‘验证语音提示音量可调节’，结果开发直接把系统音量接口绑死，盲人用户得先调系统音量再调应用音量，这算哪门子无障碍？但这次不一样，客户是残联的定点机构，需求文档里连‘屏幕阅读器兼容性测试矩阵’都列了二十多条，优先级标的是P0，不搞定连灰度都上不了。

　　我原以为Orca和NVDA差不多，装上就能用——结果在Ubuntu 22.04上跑起来，光是启动就报三个错。第一个是PulseAudio音频服务冲突，屏幕阅读器抢不过系统音效；第二个是GTK主题不兼容，焦点框显示不全；第三个最离谱，输入法切换快捷键和Orca的快捷键撞车，盲人用户连输入框都进不去。那天下午测试机用例管理工具一直在转圈，我一边等加载一边翻日志，发现Ubuntu自带的Orca版本是三年前的，而NVDA最新版已经支持Wayland了——这他妈能兼容才怪。

文章配图，仅供参考

　　但最坑的还是硬件兼容。客户那边有个盲人测试员，用的是老式点显器，通过串口连接Linux。我们按文档装了Brltty驱动，结果点显器只亮灯不显示字符。开发查了半天说‘串口被系统占用了’，让我关掉串口终端服务——可关掉后系统又报错，说‘无法访问/dev/ttyS0’。我蹲在机房里折腾了两小时，最后发现是Ubuntu的udev规则没写对，得手动给/dev/ttyS0加权限。那天测试机摆了三台，一台跑Orca，一台连点显器，一台挂着用例管理工具，白板上的测试进度只写了‘50%’，数字还擦了一半，看起来像‘5%’。

　　后来我算是明白了，Linux无障碍环境搭建这玩意儿，跟其他功能测试完全不一样——它不是‘能跑就行’，而是‘所有细节都得抠’。比如屏幕阅读器的快捷键，得避开系统快捷键和输入法快捷键；比如高对比度主题，得保证所有图标和文字都清晰可见；比如语音提示的语速，得让盲人用户能听懂但又不嫌慢。这些需求没有明确的‘完成标准’，全靠实际用——就像我们测试时发现，Orca在Firefox里读网页没问题，但在Chrome里会漏读部分标签，最后发现是Chrome的ARIA支持没做好，得降级用旧版Chromium。

　　说回‘优胜劣汰’——这十三年里，我见过太多功能因为‘不好用’被砍掉，但无障碍不一样。它不像性能优化那样能靠跑分证明价值，也不像新功能那样能吸引眼球，但它有个最狠的筛选条件：真实用户会用。残联那个项目上线后，客户反馈说‘盲人用户终于能用Linux办公了’，而之前他们只能用Windows——因为Windows的无障碍支持更成熟，第三方工具更多。这就是优胜劣汰：不是靠吹嘘，而是靠实际能不能解决问题。我们后来把所有无障碍相关的配置和脚本都打包成了一个安装包，新版本直接集成进去，再也不用每次部署都手动改配置了——虽然开发还是抱怨‘又多了一层依赖’，但至少线上没再出过无障碍相关的阻塞问题。

　　不过话说回来，这行干了这么久，我还是怕一种情况：需求变来变去。比如残联项目中期，客户突然说‘要支持手语翻译’，可我们连手语翻译的接口标准都没摸过，最后只能推到下个迭代。还有测试资源不够的时候，无障碍测试经常被排到最后——上次灰度前一天，开发说‘无障碍用例先跳过吧，时间来不及了’，我直接拍桌子说‘这是P0需求，跳过就上不了线’，他才不情不愿地加了班。所以啊，无障碍环境搭建这事儿，光有技术不行，还得够硬气——毕竟，残疾用户的体验，容不得半点含糊。

　　现在回头看，去年五月那两周的折腾，值。至少现在再遇到无障碍需求，我知道该从哪儿下手了——先查系统版本，再测硬件兼容，最后抠交互细节。至于那些说‘无障碍是小众需求’的人，我只想说：等哪天你眼睛看不见了，就知道这需求有多重要了。当然，我也承认局限——比如我们只测了Orca和NVDA，没测Orca在Wayland下的表现；比如点显器的驱动只支持Ubuntu，其他发行版还得自己适配。但至少，我们迈出了第一步——而这一步，比任何漂亮的测试报告都实在。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!