无障碍（A11y）不是“多做一点点美化”，而是确保更多用户能完成任务。下面整理了一组常用的无障碍与可用性测试工具：从设计阶段的对比度与色盲模拟，到开发阶段的规则扫描与审计报告，再到验收阶段的读屏与键盘真实走查。你可以把它当作评审清单：先用自动化工具抓大头问题，再用读屏+键盘把关键路径跑通，最后把结果沉淀成可复用的规范与组件基线。
免费商用：最经典的对比度计算器之一，适合在设计评审时快速判断文字与背景是否满足 WCAG AA/AAA。建议把常用字号（正文/小字/按钮）和品牌主色、辅助色都过一遍，形成“可用色板”。它也很适合在改版时做回归检查，避免因为换肤导致可读性下降。
需看协议：Stark 提供对比度检查、色盲模拟、焦点顺序等能力，适合把无障碍检查前移到设计阶段。对团队来说，它的价值在于“把问题暴露在画稿里”：组件一旦在设计稿就不达标，后面开发修复成本会更高。使用前建议明确你们的目标级别（例如 WCAG 2.1 AA）。
需看协议：业界常用的无障碍扫描器，浏览器扩展即可对页面进行规则检查并生成可追踪的问题列表。它很适合在研发自测或测试验收阶段做“基础合规”：ARIA 属性、表单标签、对比度、可聚焦元素等。建议把高频规则写入 CI（例如跑在 PR 上），让问题尽早被拦截。
免费商用：Chrome DevTools 自带的审计工具，包含 Accessibility 评分与可解释的修复建议。它适合做“上线前的快照式体检”：同一页面在迭代前后跑一次，能直观看到分数和问题变化。注意 Lighthouse 更偏规则覆盖与统计，并不能替代真实读屏与键盘走查，但很适合作为门槛与趋势指标。
免费商用：WAVE 的优势在于“可视化标注”：它会把结构信息与潜在问题直接叠加在页面上，适合设计师与产品一起看。比如缺失的表单标签、标题层级不合理、低对比度区域等，都能在视觉层面快速定位。对于复杂页面，建议结合 WAVE 的 Outline/Structure 视图检查信息层级是否符合预期。
免费商用：NVDA 是常用的免费读屏软件之一，适合在验收阶段做“真实体验验证”。建议固定一套走查脚本：从导航到主内容、表单填写、弹窗关闭、错误提示读取、按钮状态变化等。许多“自动化扫描器抓不到”的问题（例如读屏顺序混乱、状态不播报、焦点丢失）都需要 NVDA 这类工具来发现。
免费商用：如果你的用户包含 iPhone/iPad/macOS 用户，VoiceOver 是必须覆盖的真实场景。它能帮助你验证：组件是否有可理解的可访问名称（Accessible Name）、控件角色是否正确、滑动/转子操作是否顺畅。建议在关键路径（注册/登录/支付/提交）至少做一遍 VoiceOver 走查，并记录“读到的内容”和“预期应该读到的内容”。
免费商用：色盲模拟工具可以帮助你检查“信息是否只靠颜色传达”。例如状态只用红绿区分、图表只靠颜色区分系列、选中态缺乏形状/文字提示等。建议在设计阶段就用它快速扫一遍关键页面，确保即使在色觉差异情况下，用户仍能理解层级与状态。
免费商用：这类工具适合做“反推式配色”：给定品牌主色后，计算出可用的文字色/背景色组合，并提供 AA/AAA 的对比度结果。它特别适合做设计系统：把按钮、标签、提示条等组件的前景/背景组合预先验证，形成可直接复用的 token 组合，减少每次出图都重新判断的成本。
免费商用：tota11y 以“教学式的叠加层”帮助你理解页面无障碍问题：标题结构、对比度、可访问名称等。它适合做团队内部的培训与共识建立，让非工程同学也能直观看到问题类别与影响。建议把它作为入门工具，配合更严格的扫描器（如 axe）一起使用。
免费商用：严格来说它是规范与模式库，但在落地无障碍时非常“工具化”。当你要做复杂组件（菜单、对话框、Tabs、Combobox）时，APG 给出了推荐交互、键盘行为与 ARIA 属性组合。建议把 APG 作为组件库的验收标准之一：只要组件行为偏离模式，就容易出现键盘不可达或读屏误读。
免费商用：提供 FastPass（快速扫描）与 Assessment（更系统的检查清单），还支持生成报告与跟踪修复。它适合把“无障碍问题”纳入常规缺陷管理：每次版本发布前跑 FastPass 做门槛检查，遇到关键页面再用 Assessment 深入走查。对跨端团队来说，它的检查流程更结构化，便于统一执行。
