无障碍编程：变量命名中的无声包容

　　“无障碍编程：变量命名中的无声包容”——这是我去年暑假在为视障同事李哲适配前端SDK时，突然卡在console.log()里一个变量名上，盯着屏幕停了四分三十七秒后打出来的标题。

　　那会儿我正改写一个表单校验模块，原命名是validateUserInput，李哲说他用NVDA读到“validate”就跳过后面，“user”又和“users”“username”听感太近，得靠上下文硬猜。我把命名改成checkIfEmailFormatIsCorrectForThisField，他试了三遍才确认能听清每个词边界——但新问题来了：VS Code的自动补全直接崩了，输入chec…弹出27个以check开头的变量，其中11个来自我三年前写的旧工具包。我当场删掉6个重复校验函数，不是因为逻辑冗余，是因为它们的命名全带check，像一串同音糖葫芦——甜，但噎人。

文章配图，仅供参考

　　去年暑假第19天，我拿团队2021年上线的电商风控模块做命名审计：全项目1387个变量，含“usr”缩写42处、“tmp”59处、“val”33处；用VoiceOver+Xcode模拟朗读测试，平均每分钟出现2.3次歧义停顿——最惨的是那个叫“actn”的变量（action缩写），李哲第一次听成“action”，第三次听成“a ction”，第五次问我“是不是有个ct字符被吞了”。后来我们加了下划线强制切分：act_n，延迟降了17%，但补全效率跌回2018年水平。这事让我想起2021年深圳残联发的《语音交互编码指南（试行）》第4.2条——它压根没提下划线方案，因为当时主流IDE根本不支持音节感知补全。

　　失败案例真有。今年三月，我给某银行做无障碍重构，把所有“accnt”改成“accountNumber”，结果ATM机具固件里的JAWS脚本报错：老版本只认3字母缩写，多一个字母就拒绝加载TTS引擎。最后被迫回滚并加了个兼容层，用Object.defineProperty在运行时动态挂载同义名——这活儿干得我手抖，因为那行defineProperty代码本身，命名是tempAliasForLegacyATM，连我自己都不敢读出来。

　　变量名不是标签纸，是声波路径上的第一个路标。去年暑假我在杭州西溪湿地边调试小程序时发现，把data_user_id改成userProfileIdentifier，语音引擎识别准确率从81%升到94%，但微信开发者工具里编译耗时多了83毫秒——这83毫秒里，有42毫秒花在AST节点重解析上。技术栈越老，命名越不能“正确”，而要“可容忍”。比如Node.js 14的v8引擎，对超过23字符的变量名会悄悄启用不同的哈希算法，这事儿文档没写，是我调v8源码debug三天发现的——但它解释了为什么我们在某次灰度中，视障用户投诉“列表加载变慢了0.5秒”，而健全用户完全无感。

　　我不信“最佳实践”这个词。

　　去年暑假结束前，我把所有带“is”前缀的布尔变量改成了describes…或enables…结构（比如isEligible → enablesPromoCodeApplication），测试组6人里，4位视障用户反馈节奏更稳，但两位用Dragon NaturallySpeaking的老年测试员说“听着像在念政府公文”。我立刻加了白名单配置项：允许按用户语音引擎型号返回不同命名变体。这事还没推上线——因为我不知道该不该让一个变量名，变成需要配置的feature flag。

　　现在我正在拆解TypeScript的DeclarationMap生成逻辑，想试试能不能让tsc在emit .d.ts时，把@accessibleName注释自动注入JSDoc，再由VS Code插件转成语音友好型提示……但这玩意儿得等TS 5.6 beta发布才敢测，毕竟5.5里type-only import的source map生成还是乱的。

（编辑：站长网）

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