无障碍（Accessibility / a11y）不是上线前的最后一步，而是一套贯穿设计与开发的质量标准。下面这份清单把常见的可访问性检查拆成几个可操作的环节：自动化扫描用来快速发现高频问题（缺少标签、对比度不足、结构不合理等），辅助技术用来验证真实体验（屏幕阅读器、键盘导航、焦点顺序），最后把结果写回组件规范与设计系统，减少反复返工。
需看协议：WebAIM 提供的网页无障碍快速检查工具，适合做首轮体检。用它标记结构性问题后，再结合人工判断是否影响真实用户。
工具地址：https://www.deque.com/axe/devtools/
需看协议：浏览器扩展/开发者工具形态，适合开发侧在本地与 CI 前进行扫描。输出的规则与修复建议较清晰，便于团队形成统一口径。
工具地址：https://developer.chrome.com/docs/lighthouse/overview/
需看协议：Chrome 内置审计能力，上手成本低，适合做持续的“基线”检查。注意分数不等于合规，重点看具体问题条目。
工具地址：https://accessibilityinsights.io/
需看协议：提供 FastPass + 流程化检查清单，适合团队按步骤做系统排查。把检查结果截图/记录下来，作为评审与返工的依据。
工具地址：https://www.tpgi.com/arc-platform/arc-toolkit/
需看协议：另一套常用的浏览器辅助检查工具，适合与其他扫描结果交叉验证。对一些交互/结构问题的提示比较直观。
工具地址：https://www.tpgi.com/color-contrast-checker/
需看协议：桌面端对比度检测工具，适合设计阶段快速验证文本/图标与背景的对比度是否满足 WCAG。建议把常用颜色组合沉淀成设计 Token。
需看协议：把无障碍检查前置到设计工具里，支持对比度检查与色觉模拟等。适合设计师在交付前先做一轮自检，减少开发返工。
需看协议：跨平台色觉缺陷模拟工具，用来验证信息传达是否过度依赖颜色。建议把关键状态信息同时用形状/文本/图标冗余表达。
工具地址：https://www.nvaccess.org/
需看协议：常用的屏幕阅读器之一，适合做真实读屏体验测试。重点检查：可读顺序、按钮名称、表单提示、弹窗焦点与键盘可达性。
工具地址：https://support.apple.com/guide/voiceover/welcome/mac
需看协议：Apple 生态自带读屏工具，覆盖 macOS/iOS。设计评审时可用它快速验证 App/Web 在真实设备上的可操作性。
工具地址：https://support.google.com/accessibility/android/answer/6283677
需看协议：Android 端读屏工具，适合移动端交互测试。关注滑动探索、焦点顺序、可点击区域与辅助文本是否准确。
工具地址：https://pa11y.org/
需看协议：适合接入 CI 的自动化扫描工具，可把关键页面的无障碍问题变成可追踪的质量门禁。建议从少量核心路径开始，逐步扩大覆盖范围。
