由 dawei 视障开发者依赖屏幕阅读器理解代码，而变量命名是他们获取语义的关键入口。模糊的缩写、含混的简写或过度依赖上下文的名称，会显著增加认知负荷，甚至导致逻辑误读。例如，screenReaderStatus 和 srs 在阅读器中均被逐字母朗读，后者无法传达任何业务含义。
命名应优先采用完整、具象、可发音的英文单词组合。avoidBlindUser 优于 abu，toggleNav 优于 tn——前者明确指向“避免影响视障用户”，后者需回溯上下文才知指代导航栏。可发音性直接影响听觉处理效率：isFocused 能被自然读作 /ɪz ˈfoʊ.kəst/，而 isFcd 则被迫拆解为 i-s-F-c-d，打断思维流。
避免依赖视觉隐喻的词汇，如 “redFlag”、“blackList”、“whiteSpace”。这些术语对非视觉用户缺乏直观意义，且可能触发不适联想。改用功能导向表达更稳妥：“validationWarning”、“blockedUsers”、“whitespaceCharacters”——每个词都承载独立、中立、可验证的语义。
一致性比创新更重要。项目中统一使用 camelCase 或 PascalCase，并严格约定前缀含义：如用 “aria” 开头标识与无障碍直接相关的状态（ariaIsLiveRegion），用 “has” 表达布尔属性（hasKeyboardFocus）。这种可预测的模式，让屏幕阅读器用户无需反复确认命名逻辑。
不要牺牲清晰度换取简洁。count 不如 itemCount，data 不如 userData ——多出的两三个字符，换来的是即时可理解性。对视障开发者而言，节省的不是打字时间，而是每次停顿、回溯、猜测所消耗的认知资源。
AI生成图像，仅供参考
变量名不是给编译器看的，而是给人——尤其是那些不靠眼睛编程的人——传递意图的最小信息单元。当命名本身成为无障碍支持的一部分，代码就不仅可运行，更可感知、可信赖、可协作。