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

　　去年12月份那场代码重构，差点让我在团队里背了黑锅——起因是前端组新来的视障开发者小周，对着变量名“imgSrc”在屏幕阅读器里卡了整整十八分钟。他敲着盲文键盘说：“这变量名念出来是‘艾姆吉艾斯阿儿西’，鬼知道是图片路径还是图片尺寸？”当时我站在他工位后边，凉掉的茶在保温杯里晃出波纹，突然想起自己三年前在V2EX上和人吵过的那句“变量名就该用拼音缩写，省事儿”。

　　后来复盘才发现，我们自以为“行业惯例”的命名方式，对视障开发者简直是场无声的灾难。比如“btnSubmit”在屏幕阅读器里会被拆成“比提恩艾斯优比提艾姆艾特”，小周说这就像让盲人用摩斯密码写情书——明明有更包容的方式，偏要搞成密码学。我原以为“优胜劣汰”是技术圈的铁律，结果这次重构让我彻底改了主意：所谓“优胜”，得先让所有人能站在同一起跑线上。

　　那天下午我翻出站长平台里存了半年的截图——全是竞对站改标题的记录，突然意识到变量命名这事儿，和SEO优化有点像：你得先让机器（或者屏幕阅读器）能“读懂”，才能谈效率。比如“submitButton”虽然比“btnSubmit”多敲四个字母，但小周说屏幕阅读器念出来是“萨布米特巴顿”，他一听就知道是提交按钮，不用再翻文档确认。这种“冗余”不是浪费，是给特殊开发者留的“无障碍通道”。

　　可团队里反对声也不小。后端老张拍着桌子说：“我二十年前就这么写代码，现在让我改？那变量名得写多长？”我指着他屏幕上的“userInfo”反问：“这变量名你念得顺吗？屏幕阅读器念出来是‘优瑟因佛’，小周得猜半天是用户信息还是用户状态。”他撇撇嘴：“那直接写‘userInformation’？”我摇头：“太长，‘userData’更好——‘优瑟戴塔’，屏幕阅读器念得快，意思也清楚。”他沉默了半分钟，突然冒出一句：“我女儿学英语时，老师也说别用缩写。”

　　后来我们定了个“三秒原则”：变量名念出来，屏幕阅读器得在三秒内让开发者明白意思。比如“imgWidth”不行，得是“imageWidth”；“urlLink”不行，得是“websiteUrl”。小周说这规则像给代码加了“语音注释”，虽然要多敲几个字母，但省了他翻文档的时间——对他来说，翻文档得用盲文点显器，一次操作要十几秒。我算过，一个项目里如果有一百个变量名不符合规范，他每天得多花半小时在“猜变量”上。

　　当然，这事儿也有翻车的时候。有次前端小李把“loginButton”写成了“logInButton”，屏幕阅读器念出来是“罗格因巴顿”，小周以为是个日志按钮，差点把登录功能改成了日志记录。后来我们加了条硬规定：涉及动作的变量名，动词必须用现在分词（比如“submitting”而不是“submit”），名词必须用单数（比如“button”而不是“buttons”）。小周说这规则像给代码上了“语法课”，虽然严格，但至少不会猜错意思。

文章配图，仅供参考

　　对了，昨天凌晨刷后台时，发现小周提交的代码里有个变量叫“errorMsgForScreenReader”——专门给屏幕阅读器准备的错误提示。我笑着给他点了赞，他回了个盲文表情：“这才叫真正的‘包容性设计’。”

　　现在团队里还有人嘀咕：“这么改会不会影响开发效率？”我不好说死，但至少小周的代码提交速度比上个月快了15%——他说是因为不用再猜变量名了。至于这算不算“优胜劣汰”，我说不准，但至少这次，我们没让“劣”的规则淘汰掉“优”的开发者。

　　下一步我打算把这套规则写成文档，塞进团队的代码规范里——虽然肯定有人嫌麻烦，但至少以后不用再为变量名吵架了。至于竞对站会不会跟进？管他呢，先把自己的代码写得“能读”，比什么都强。

（编辑：站长网）

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