可访问性是跨团队协作的硬性约束，必须通过HTMLHint在CI中强制拦截基础规则：attr-req-aria-role、attr-req-aria-attrs、attr-no-duplication、head-title-only-in-head，并推动语义化标签替代div+role模式。
可访问性标准不一致，不是“要不要做”的问题，而是“不做就直接阻断协作”的硬伤——aria-label漏写、role乱用、tabindex随意设，会导致下游团队的自动化测试失败、无障碍扫描器报错、甚至 JS 逻辑因焦点状态异常而崩溃。
为什么可访问性在跨团队里特别容易失控
前端写完一个按钮，用 div onclick + aria-hidden="true" 模拟交互；产品改文案时删掉 aria-label 还以为“只是文字变了”；测试同学跑 axe 时发现整个导航区不可键盘操作，但没人知道是哪次提交引入的。根本原因在于：可访问性不是单点校验，它依赖标签语义、属性组合、DOM 结构、JS 行为四者协同生效，任意一环脱节，整条链就断。
用 htmlhint 锁死基础可访问性规则
别等 PR 阶段才扫 axe，那已经晚了。把最易出错的 4 条规则塞进 .htmlhintrc，CI 直接拦截：
-
"attr-req-aria-role": true—— 凡含role属性，必须配对应aria-*（如role="button"要有aria-label或aria-labelledby） -
"attr-req-aria-attrs": ["button", "a", "input"]—— 对这些交互元素强制要求aria-label或alt等描述属性 -
"attr-no-duplication": true—— 防止aria-hidden="true" aria-hidden="false"这种冲突写法 -
"head-title-only-in-head": true——title不在head里，屏幕阅读器根本读不到页面标题
把可访问性检查下沉到编辑器和提交前
非前端成员（比如运营改 landing page）不可能天天看 axe 文档。要让他们“无感合规”：
立即学习“前端免费学习笔记（深入）”；
- VS Code 安装
HTMLHint插件，保存即标红错误行，提示具体修复方式（例如：“缺少 aria-label，请补全或改用button标签”） - 用
husky+lint-staged在pre-commit钩子里跑htmlhint --fix，自动补alt、转小写、修引号，但绝不碰语义逻辑 - 禁用所有耗时检查（如 axe 全量扫描）放在本地钩子——它该在 CI 里跑，不是卡住提交
用语义化标签代替手动加 ARIA
90% 的可访问性问题，根源是用 div + role 模拟原生控件。这不是“高级技巧”，是技术债源头：
- 把
<div role="button" tabindex="0" onclick="..."></div>改成<button type="button">...</button>—— 原生支持键盘交互、焦点管理、屏幕阅读器识别 - 导航区不用
<div id="nav"> + <code>role="navigation"，直接用<nav></nav>—— 下游团队写nav a选择器不会失效 - 表单控件必须用
<label for="id"></label>关联<input id="id">，禁用aria-labelledby替代 —— 后者在部分旧版 JAWS 中不触发自动聚焦
真正难的不是写对某一行 aria-* ，而是让所有人默认信任语义化标签的隐式可访问性保障。一旦团队开始习惯写 <main></main> 而不是 <div class="main-content">，可访问性就从“额外工作”变成了“不写反而更费劲”的自然结果。</div>
