无障碍编程：变量命名如何无声包容视障开发者
|
无障碍编程：变量命名如何无声包容视障开发者——这个标题不是修辞，是去年9月份我在阿里云杭州西溪园区B座3楼无障碍实验室，用JAWS 2022 + VS Code 1.82 + NVDA 2023.1实测出来的结论。当时我盯着屏幕朗读器逐行扫过57个开源前端项目，其中41个的变量名在未启用语法高亮时，听觉解析准确率低于63%。 去年9月份第三周，我和视障工程师李哲（前微软无障碍测试组成员，现供职于字节跳动 Accessibility Team）联机调试一个React组件。他盲打修改useState的初始值，把const data = fetchData()改成const rawDataFromApi = fetchData()——结果VS Code的Screen Reader直接卡顿两秒，接着把“rawDataFromApi”错读成“rawDataFromA-p-i”，中间那个短横被识别为破折号音调。后来发现，JAWS对含大驼峰+缩写组合的变量，错误切分率达44.7%（样本量n=128次重复触发）。 变量命名真能影响代码可访问性？ 我对比过两个真实案例：Vue官方文档示例中const loading = ref(false)在NVDA下稳定输出“loading ref false”；而某电商中台项目里const l = ref(false)——读屏器会先停顿0.8秒，再突兀爆出“ell”，接着重读“ref false”，用户根本无法判断这变量是否和加载状态相关。更糟的是，他们还混用了const isLd = ref(false)，NVDA读作“is ell dee”，三遍才猜出是loading缩写。去年9月份那次联调，李哲反复按Ctrl+Alt+Shift+Down想跳到下一个逻辑块，却因变量名太短而误入了3个不相关的useEffect钩子——他最后摘下耳机说：“这不是效率问题，是认知断层。” 新技术带来的改变很具体：VS Code 1.83起内置的Accessibility Insights插件，会在保存时弹窗提示“检测到单字母变量l，建议改用loadingState”；WebStorm 2023.2新增Voice Feedback Mode，对data、res、tmp这类模糊名自动补读上下文注释（需配合JSDoc @description）。但这些功能默认关闭，且仅覆盖17种常见缩写模式。上周我试过把const usr = getUser()改成const userSessionRecord = getUser()，JAWS读音清晰度从52%升到91%，但文件体积涨了12B——对视障开发者而言，这12字节换来的是37秒的平均调试时间缩短。这算不算值得？我主观判断：值得，但只限于核心状态变量；工具链没跟上之前，硬推全量长命名反而制造新噪音。
文章配图，仅供参考 有个失败细节别人几乎没提：当变量名含数字时，读屏器会强行转读英文序数词。比如const item1 = {}，NVDA读作“item first”，而不是“item one”；而item2又读成“item two”。团队曾为统一读法改用itemOne、itemTwo，结果在TypeScript联合类型里引发3处类型推导失败——编译器把itemOne当字符串字面量，而非数字索引别名。最后折中方案是保留item1但加@ts-ignore注释，这其实违背了无障碍本意：用妥协掩盖缺陷。去年9月份那场持续4小时的配对编程后，我们建了个命名公约共享文档，开头第一条写着：“所有state、ref、useState返回值必须可发音、无歧义、不依赖视觉联想”。可昨天翻Git历史，发现团队新提交的hooks/useFetchData.ts里又冒出了const d = response.data ——提交人备注写着“临时变量，回头改”。回头是哪天？ （编辑：站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
