无障碍编程：变量命名如何无声包容视障开发者

　　我原以为变量命名这事，就是个 lint 规则跑两遍、CI 卡一卡的事。结果上个月在帮盲人同事调一个 k8s operator 的 configmap 注入逻辑时，发现他用的屏幕阅读器——NVDA 读到 env: "DB_HOST" 直接念成“D B 空格 H O S T”，停顿三秒，再重读，“D B……HOST”，然后他就摘了耳机，手指在键盘上悬着，没敲下去。

　　提交工单的时候孩子在我膝盖上揪我耳机线；桌上的黄焖鸡盖饭凉透了，汤浮着一层半凝固的油；窗外雨一直下，不是那种唰唰声，是水管接缝漏的那种滴答——滴、嗒、滴、嗒，比 Jenkins 构建失败的铃还准。

　　工单发出去那刻我按了三次“发送”按钮：第一次点歪了，弹出个“确认退出编辑”的浮层；第二次光标卡在最后一行，Ctrl+Enter 没反应；第三次才发成功。等回复等了三天，客服回的第一句是：“亲，我们这边核实到您账号实名信息未完全同步，请优先完成人脸核验。”——可我实名早过审了，连阿里云备案都过了，这个厂商连我自己工单里的“张伟（已实名）”都读不全，还谈什么变量名读得清？

　　他们文档里写“推荐使用驼峰式”，可没说 NVDA 默认把 camelCase 拆成 cam el Case；写“避免缩写”，却放任 teamMembers 写成 tMem；写“语义清晰”，但有个 service 名叫 uo12，我问运维老李，他说是“用户中心二期上线版12号快照”。这玩意儿读出来就是“U O 一二”，连我这种看屏都能懵两秒，更别说靠耳朵听代码的人了。

　　上周五，盲人同事林薇——就是那个三年前在 DevOps 中国峰会用语音调试 Prometheus alert 路由的人——发来一段 log：“pod is stuck in ContainerCreating”，她念给我听，声音很平，但尾音发虚：“张工，你帮我看看，yaml 里那个 fieldRef 是不是拼错了？” 我扫一眼就发现了：env.valueFrom.fieldRef.fieldPath 写成了 fieldPah。她用语音指令让屏幕阅读器逐字朗读，读到“fieldPah”时机器顿了一下，接着读：“field P A H”，她就没往下听了。她不是不会查，是没法靠发音猜错别字。这不是能力问题，是命名在主动拒人门外。

文章配图，仅供参考

　　我原以为这是个小修小补——加几个 lint 规则，推个内部 checklist 就完事。结果昨天翻他们去年的 CVE 修复日志，发现有个关键漏洞补丁（CVE-2023-xxxxx）的 patch commit 里，变量名叫 _tmp_a1。三个字母，两个下划线，一个数字，读出来是“下划线 下划线 T M P 空格 A 一”。没人提。没人改。没人念。它就在那儿，活得好好的，跟那个跑了三年还没被干掉的僵尸 pod 一样安稳。

　　我桌上鼠标垫起边了，右下角卷起来一块，每次拖鼠标到边缘就会卡一下——就跟他们那个“无障碍命名自查工具”一样，前端界面渲染正常，但一旦传进 screen reader 的 aria-label 就变成 undefined。上次测试时，林薇问我：“这个按钮说的是‘提交’还是‘交 提’？” 我说“是‘提交’”。她说：“可它读出来是‘交 提’。” 我查 DOM，发现是 React 的 fragment 在 render 时漏掉了 key。这种细节，跟超售时容器 runtime 偷摸复用 cgroups 是一个德行：表面一切如常，实际早已失焦。

　　早年我在万网买空间，用的是最便宜那种 Linux 共享主机。客服说“无限流量”，我信了；后来被限速，工单回：“检测到您的站点存在异常高并发请求”，我截图 show -c 10000 访问日志发过去，对方说“您这属于爬虫行为”。现在想想，那会儿连域名解析都要手敲 dig +trace，谁管你眼睛看得见看不见？可那时至少没人把“语义清晰”当 KPI 写进 PR 模板里，更没人把“读得清”当验收项——倒显得诚实。

　　他们新出的“无障碍开发白皮书”，第7页写着：“变量命名应体现意图而非结构”。很好。但第12页附录的样例里，service account name 叫 sa-devops-cicd-prd-nvda-test。我数了数，大小写混、中英文混、带环境标识、带角色标识、带测试用途，最后还加了个 nvda——真够贴心，生怕屏幕阅读器不知道它为谁而生。结果念出来是：“S A 连字符 D E V O P S 连字符 C I C D 连字符 P R D 连字符 N V D A 连字符 T E S T”。它不是在帮助阅读，是在发起一场发音耐力赛。

　　还有一次，代理商小陈微信我：“张哥，你们要不要试试我们新上的变量命名智能校验插件？” 我说：“读得清吗？” 他回：“支持 ESLint 和 SonarQube 接口。” 我又问：“NVDA 或 VoiceOver 测试过没？” 他顿了四分钟，发来一张截图，上面是 Chrome DevTools 里 AXE 插件扫出来的“无高风险无障碍问题”。我说：“那是对 DOM，不是对变量名。” 他没回。第二天发来一条语音：“张哥，我们技术总监说，这个不属于 WCAG 2.1 的强制要求范畴……”

　　所以你看，这事根本不是技术能不能做到，是愿不愿意认——认变量名不是写给 IDE 看的，是写给人听的；不是为 grep 留线索，是为耳朵留喘息。优胜劣汰？对。但汰掉的不该是读代码的人，该是那些把“可访问性”塞进年度 OKR 第三行、然后三年没动过一行 linter 配置的厂商。

　　明年到期就迁走。不选大厂，也不选新锐，就找一家官网 footer 里写明“所有 API 响应字段名均经 NVDA + JAWS 双引擎验证”的。找不到？那就自己写个 pre-commit hook，强制替换掉所有 a1、b2、tmpX、val、dataX、res。哪怕只跑在本地，至少——至少我的终端能听懂我写的每一行，而不是假装听懂。

（编辑：站长网）

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