无障碍编程不是附加功能，而是尊重每位开发者认知方式的基本承诺。视障开发者依赖屏幕阅读器将代码转为语音或盲文，而变量命名恰恰是他们理解逻辑流的第一道门槛。
模糊缩写是隐形障碍。当屏幕阅读器念出“usr”“tmp”“idx”，它无法传递语义——这不像视觉者能靠上下文快速推测。更糟的是，“usr”可能被读作“user”或“U-S-R”，歧义迫使开发者反复停顿、回溯、验证，打断思维连续性。用完整单词如“currentUser”“temporaryFile”“elementIndex”，让语音输出本身就能承载意义。
驼峰命名中的大小写边界对屏幕阅读器至关重要。良好的命名会主动强化语音切分：例如“isUserActive”会被自然读作“is user active”，而“AllUsers”可能被误读为“all users”或“a l l users”。避免全大写缩写（如“XMLData”），优先采用“xmlRequest”这类小写连写，确保语音引擎稳定识别词根。
本图由AI生成，仅供参考
类型暗示需谨慎。虽有“strName”“intCount”等匈牙利命名法，但现代语言已支持类型标注，且屏幕阅读器对前缀的发音常不一致（如“str”读作“string”还是“S-T-R”？）。直接使用“userName”“itemCount”更可靠——名称本身说明用途，类型由语言和工具链保障。
环境上下文应融入命名，而非省略。在用户管理模块中，不用“name”，而用“userName”；在日志模块中，避免孤立的“time”，改用“logTimestamp”。这对视觉者是冗余，对听觉处理者却是关键锚点——它减少跨文件跳转确认的次数，把认知负担从记忆转移到表达。
最终，好名字不是写给人看的，而是写给人听、让人想、让人安心重构的。每一次敲下清晰的变量名，都是在代码里铺一条语音可辨识的小路——它不增加字符数，却为视障同行省去数十秒的停顿、一次困惑的重复聆听、或一次放弃调试的念头。包容，就藏在每个被认真拼写的单词里。
