无障碍与可访问性不是“发布前补作业”，而是贯穿需求、设计、开发与验收的基础质量项。下面这份清单按常见工作流整理：先用自动化扫描快速抓大问题，再用对比度与色觉模拟复核视觉层面，最后用 ARIA 模式与屏幕阅读器做关键路径验证。每个工具都附上定位点，方便你把问题转成可执行的修复任务。
工具地址：https://developer.chrome.com/docs/lighthouse/
免费商用：Chrome 内置的质量审计工具，适合做第一轮可访问性体检。它能快速提示对比度、按钮命名、表单标签、ARIA 属性等常见问题，并把问题映射到具体 DOM 节点。建议对关键页面建立固定审计基线，改版前后对比得分与问题数量，避免可访问性回归。
工具地址：https://www.deque.com/axe/devtools/
需看协议：业内使用广泛的 a11y 扫描与调试套件，浏览器扩展对开发联调非常友好。它的报告通常更可修，会明确说明违反了什么规则、常见成因、以及修复后如何验证。适合在组件开发、自测与发布前冒烟阶段使用。
需看协议：可视化标注型检查工具，优点是看得见哪里不对。它会在页面上直接标记缺少替代文本、结构层级不合理、表单缺少标签、对比度风险等问题。适合设计与前端一起走查时共享屏幕讨论，把规范落到具体位置与组件。
工具地址：https://accessibilityinsights.io/
免费商用：微软开源的检查工具，覆盖快速扫描与手动检查清单。它的手动流程会引导你逐项验证键盘可达性、焦点顺序、语义结构、名称与角色等关键点。适合做发布前验收式复核，也适合把检查项整理成团队统一的 QA 清单。
工具地址：https://webaim.org/resources/contrastchecker/
免费商用：常用的对比度计算器之一，输入前景与背景色即可判断是否满足 WCAG AA 或 AAA。建议把品牌色、状态色与文本颜色组合都跑一遍，并把通过的配色对写进设计 Token，减少每次临时算色与争论成本。
需看协议：设计侧非常实用的无障碍工具，常见形态是 Figma 插件或浏览器插件。它能做对比度检查、色觉缺陷模拟、可访问性评审提示等。适合在设计阶段就把明显风险提前消掉，减少开发后返工，并更容易形成团队共识。
工具地址：https://accessible-colors.com/
免费商用：帮助你在接近原色的前提下找到合规的替代颜色。它会给出可用的色阶范围与推荐值，适合做品牌色微调、状态色体系补齐，以及为深色模式设计可用的文本与背景组合。
免费商用：桌面端色觉缺陷模拟器，可在系统层面模拟不同类型的色盲或色弱效果。适合在最终视觉稿或线上页面上做整体复核，确认信息不是只靠颜色传达，告警与成功状态仍可区分，图表是否需要纹理或标注辅助。
工具地址：https://www.nvaccess.org/
免费商用：Windows 平台常用的免费屏幕阅读器。建议挑选核心任务链路做验证，重点听控件名称是否可理解、提示信息是否会被读出、错误定位是否明确、弹窗是否会抢焦点。读屏验证能暴露很多仅靠自动化扫描发现不了的问题。
工具地址：https://support.apple.com/zh-cn/guide/voiceover/
免费商用：macOS 与 iOS 内置屏幕阅读器。移动端产品建议至少用 VoiceOver 走一遍关键页面，关注滑动浏览顺序、可点击区域是否有清晰标签、控件状态是否会被读出、以及弹窗与底部栏切换时的焦点落点是否合理。
工具地址：https://www.w3.org/WAI/ARIA/apg/
免费商用：官方的组件交互与 ARIA 模式参考，适合在做自研组件库或复杂交互控件时按图施工。当你不确定某个控件应该用什么 role、aria 属性、以及键盘交互时，优先对照这里的模式，能显著降低可访问性返工风险。
工具地址：https://inclusive-components.design/
免费商用：偏实践的组件设计与实现参考，强调从可访问性出发做交互。它会解释为什么某些看似方便的写法会伤害键盘用户或读屏用户，并给出更稳妥的实现思路。适合设计与前端一起读，用来统一对按钮、菜单、提示、表单错误等细节的标准。
小提示：自动化工具能发现很多问题，但无法替代真实的键盘与读屏验证。建议把扫描、对比度复核、键盘走查与读屏关键路径固定成发布前四步，形成团队可复用的检查节奏。
