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

　　去年十月那会儿，我正被变量命名这事儿折磨得焦头烂额——不是普通命名，是得让视障开发者能“听”明白的命名。那天下午三点，测试组的小林戴着助听器，屏幕阅读器“咔嗒咔嗒”读着代码，突然拍桌子：“这变量名‘tempData’读出来是‘腾普戴特’？我原以为你们至少会避开缩写，结果连‘temporary’都懒得写全？”他边说边把键盘敲得震天响，桌上那杯凉透的奶茶晃出半圈涟漪。

　　这事儿得从需求评审说起。老板拍板要“无障碍适配”，产品经理老齐甩了句“按国际标准来”，转头就去盯DAU了。我翻着WCAG 2.1文档，发现变量命名居然也算“无障碍”——比如别用“i”“j”这种单字母（屏幕阅读器会读成“爱”“杰”，分不清是循环变量还是其他），别用“btn”这种缩写（得写全“button”），甚至颜色变量不能只写“red”（得是“errorRed”或“warningRed”）。我当时想，这不就是“命名规范”的加强版吗？结果小林第一次测试就翻车：他用的屏幕阅读器读“getUserInfo”是“给特尤斯因佛”，但“fetchUserProfile”读出来是“费驰尤斯普若法尔”，后者明显更清晰——可这俩变量名，开发组觉得“前者更短，符合代码简洁原则”。

　　会议室里吵成一锅粥。测试主管老陈叼着烟，烟灰弹进外卖盒里：“你们懂个屁，视障开发者靠听觉抓逻辑，变量名就是代码里的路标。‘temp’这种词，读出来是‘腾普’，谁知道它是临时的还是永久的？‘data’更扯，读出来是‘戴特’，和‘date’（日期）一个音，容易混淆。”他边说边用笔在白板上画圈，“我原以为你们会按‘语义明确+避免歧义’来，结果还在纠结‘少打几个字母’——省那两秒，人家可能要多听十遍才能理清逻辑。”

　　那天晚上加班，我盯着代码里的“getUserList”和“fetchUserArray”，突然想起小林说的一句话：“屏幕阅读器读代码，和你们看代码是两码事。你们扫一眼就知道‘List’是列表，‘Array’是数组，但我们得靠读音区分——‘李斯特’和‘阿瑞’，哪个更清楚？”我试了试用手机语音助手读这两个词，果然“李斯特”更顺口。第二天我就把变量名全改了，结果开发组炸锅：“这得改多少地方？PRD里可没写这么细！”老齐接了个电话，回来就说：“先这样吧，上线要紧。”

文章配图，仅供参考

　　可最让我后怕的是，这些规则不是“额外要求”，而是“基础能力”。上周五，测试组的小林又发现个问题：有个变量叫“colorCode”，屏幕阅读器读成“卡乐扣得”，但视障开发者小张说：“我听到‘卡乐’就知道是颜色，但‘扣得’是什么？代码里还有‘statusCode’（状态码），读成‘斯戴特扣得’，这两个‘扣得’容易混。”最后我们改成“colorHex”和“statusNum”，小张试了试：“‘卡乐海克斯’和‘斯戴特纳姆’，这下清楚了。”

　　现在回头看，变量命名的无障碍适配，根本不是“照顾少数人”，而是“让代码更健壮”。那些“缩写”“单字母”“模糊词”，在普通开发里可能只是“小问题”，但在无障碍场景里，就是“逻辑断点”。我原以为“优胜劣汰”是市场选择，结果发现，在代码可读性这件事上，清晰永远比简洁更“优”——毕竟，代码是给人读的，哪怕那个人用耳朵读。

　　当然，这事儿还没完。上周老齐又甩了个需求：“把无障碍适配做成可配置的，有些客户可能不需要。”我盯着他，没说话——他可能不知道，有些“需求”，一旦开了头，就回不去了。就像变量命名，一旦用过“fetchUserProfile”，谁还愿意回到“getUserInfo”？

（编辑：站长网）

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