lighthouse和axe devtools是实用的可访问性自动化扫描工具：lighthouse在chrome devtools中一键运行，重点检查accessibility面板中的硬性违规项；axe devtools支持实时调试并定位dom节点给出修复建议；axe-core可集成进ci流水线，建议仅拦截critical和serious级别问题。
怎么用自动化工具扫描可访问性违规项
大型项目没法靠人工逐行检查，得靠工具批量发现硬伤。Lighthouse 和 axe DevTools 是目前最实用的两个入口，但它们只报“是什么”，不告诉你“为什么必须修”。
-
Lighthouse在 Chrome DevTools 里点一下就能跑，重点看Accessibility面板里的红色条目——比如Image elements do not have [alt] attributes或Buttons do not have an accessible name，这些是必须清零的硬性指标 -
axe DevTools更适合开发中实时调试，它能定位到具体 DOM 节点，并给出修复建议，比如把<div onclick="submit()">提交</div>改成<button type="button" onclick="submit()">提交</button> - 别把
axe-core直接集成进 CI 流水线当门禁——它默认会报所有级别问题（包括 minor），容易被忽略；建议只让 CI 拦住critical和serious级别，比如缺失lang、role错配、tabindex乱序等
怎么定义团队可落地的可访问性验收清单
指标不是越细越好，而是要和团队当前能力匹配。一个能执行的清单，必须满足：可验证、有明确责任人、能嵌入现有流程。
- 核心三项必须 100% 达标：
html[lang]存在且值合法；所有交互元素（button、a、input）都有可访问名称（aria-label/aria-labelledby/ 内部文本）；所有图片有非空alt（装饰图用alt=""） - 表单类组件单独列一条：每个
input必须显式绑定label（for属性或嵌套写法），错误状态必须用aria-invalid="true"+aria-describedby关联提示文案 - 禁止在 PR 描述里写“已测可访问性”——必须附上 Lighthouse 报告截图，且关键项为绿色；否则 QA 直接打回
怎么避免语义化标签被 CSS/JS 覆盖导致可访问性失效
很多问题不是没写对，而是后续改动悄悄破坏了语义。比如用 display: none 隐藏 legend，或给 nav 加了 tabindex="-1" 却忘了移除原生导航能力。
- 禁止对语义化容器（
header、nav、main、footer、section）设置tabindex——它们本就不该被键盘聚焦，加了反而干扰屏幕阅读器跳转逻辑 -
aria-hidden="true"只能用于纯装饰性内容，绝不能加在main或article上；如果某块区域需要动态隐藏，优先用hidden属性而非display: none - 所有自定义组件（如 Tabs、Accordion）必须提供
role+aria-属性的 JS 初始化逻辑，且在销毁时清除对应属性——漏掉清理会导致辅助技术读取残留状态
怎么让设计师和前端对齐可访问性实现细节
设计稿里“看起来一样”和“用起来一样”是两回事。最常见的断层是颜色对比度、焦点样式、动态内容通知。
- 设计交付物必须包含最小对比度标注：正文文字 ≥ 4.5:1（WCAG AA），小字号或背景图文字 ≥ 7:1；前端用
axe的 color-contrast 规则做回归校验 - 所有可交互元素的
:focus样式不能仅靠outline: none抹掉——必须提供等效的视觉焦点指示（如box-shadow或边框加粗），且尺寸 ≥ 2px - 涉及 AJAX 加载、表单提交、步骤切换的场景，必须加
aria-live="polite"区域，且更新内容要带语义（比如“第 3 步，共 5 步”而不是“step-3”）
aria-label，而是当新需求压过来时，没人愿意花 10 分钟去补一个 label for。指标定得再漂亮，如果没嵌进 daily standup 的 checklist 里，就只是文档里的装饰。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
