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

　　后台数据每五分钟刷一次，群里@我的消息弹得比饮水机换桶还勤——你记不记得去年春晚那个活动页？就是那个要兼顾视障开发者无障碍访问的破项目，当时我原以为变量命名这种小事，随便按公司规范来就行，结果差点被产品经理骂到自闭。

文章配图，仅供参考

　　但真正让我破防的是复盘会。运营小王举着手机说：“我们AB测试了两组变量名，A组用‘userData’这种缩写，B组用‘userInformationData’这种完整词，结果视障用户的复访率B组高了12%。”我插嘴：“可完整词不是更长吗？读屏软件读起来不更慢？”他白了我一眼：“你试试用NVDA读‘userData’和‘userInformationData’——前者会读成‘用户 数据’，后者是‘用户 信息 数据’，后者能直接理解这是用户相关的信息集合，前者还得猜。”

　　饮水机突然“咕咚”一声，我抬头看见设计组的小李抱着物料箱经过，纸箱角蹭掉了墙上那张手写排期表——那是上周我熬到两点写的，现在被茶水浸得字迹模糊。我低头继续看数据：B组变量名的活动页，视障用户的转化漏斗在“理解变量含义”这一步，流失率比A组低了8%。这他妈哪是无障碍？这是优胜劣汰啊！

　　可最气的是，我们组那帮后端开发还觉得这是“过度设计”。上周三晨会，张工拍着键盘说：“变量名不就是给机器看的？视障开发者用读屏软件，那也是机器在转译，我们管它怎么读干嘛？”我差点把咖啡泼他屏幕上：“去年双十一投诉我们的视障用户，有37%是因为变量名歧义导致脚本报错——你觉得这是机器的问题还是人的问题？”他撇撇嘴：“那也是前端的事，后端变量名关我们屁事。”

　　结果第二天，测试又甩过来一份报告：后端接口返回的JSON字段名，如果用“user_name”这种蛇形命名，读屏软件会读成“用户 下划线 名字”；而用“userName”这种驼峰命名，能连读成“用户名”。更绝的是，如果字段名是“userAge”，读屏软件会读成“用户 年龄”，但如果是“user_age”，反而会读成“用户 下划线 年龄”——后者明显更难理解。我拿着报告冲进后端办公室，张工正对着屏幕发呆，手机电量显示17%。

　　他抬头看了我一眼：“所以呢？”我晃了晃报告：“测试说，视障开发者用我们的接口时，驼峰命名的字段理解正确率比蛇形高21%。”他挠挠头：“可我们公司规范一直用蛇形啊。”我冷笑：“去年双十一被投诉的时候，公司规范也没说要考虑视障用户啊。”他沉默了三秒，突然说：“那你们前端改接口文档吧，我们后端配合。”

　　那天下午，我盯着后台数据看了一小时——活动页上线后，视障用户的转化率比预期高了5%。运营小王在群里发了个“牛”的表情包，产品经理私聊我：“这次变量名改得值，下次活动页继续按这个标准来。”我回了个“哦”，心里却有点发虚——这标准是我们自己试出来的，可要是下次换个场景，比如移动端H5，读屏软件的解析规则会不会又不一样？

　　会议室一直被占着，我蹲在楼梯间给测试发消息：“下次能不能提前把读屏软件的解析规则文档发我们？”她回：“NVDA、JAWS、VoiceOver的规则都不一样，而且不同版本还有差异，我们也是边测边改。”我叹了口气，手机电量掉到12%——今天出门忘带充电宝了。

　　现在回头看，变量命名这事儿，说小也小，说大也大。小到只是几个字母的排列组合，大到能决定一个群体能不能顺畅使用你的产品。我原以为“无障碍”就是加几个alt标签、调调字体大小，结果发现连变量名这种底层细节，都得跟着优胜劣汰的规则来。可问题是，这种“优胜劣汰”的标准，到底该由谁定？是读屏软件的开发者？是视障用户？还是我们这些写代码的人？

　　上周五，我在工位上看到设计组新来的实习生在改图标——他把“搜索”图标从放大镜换成了“放大镜+文字”的组合。我问他为什么，他说：“测试说视障用户用读屏软件时，单独的放大镜图标可能被读成‘图片’，加上文字后能直接读成‘搜索’。”我点点头，突然想起去年春晚那个活动页——如果当时我们没改变量名，现在被投诉的，可能就不只是转化率了。

　　但话说回来，这种“优胜劣汰”的优化，到底能覆盖多少场景？移动端、PC端、小程序，每个平台的读屏软件解析规则都不一样；NVDA、JAWS、VoiceOver，每个软件的版本更新都可能改变规则。我们这些写代码的，难道要跟着读屏软件的更新节奏，天天改变量名？这成本也太高了吧？

　　手机突然震动，是产品经理的消息：“下周的活动页，视障无障碍的需求文档已经发你了，记得优先处理。”我回了个“好”，抬头看见张工从后端办公室出来，手里拿着充电宝——他大概也意识到，变量名这事儿，不是“关我们屁事”那么简单了。

（编辑：草根网）

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