辅助功能测试（Accessibility Testing）是验证数字产品能否被残障用户有效使用的系统性过程。其目标是确保视觉、听觉、运动或认知障碍人群能平等获取信息与功能。测试覆盖网页、移动应用及桌面软件，依据国际标准如WCAG 2.1（Web Content Accessibility Guidelines）执行。不符合辅助功能要求的产品不仅排除特定用户群体，还可能违反法律（如美国ADA、欧盟EN 301 549）。
测试需结合自动化工具与人工验证。自动化工具（如axe、WAVE、Lighthouse）可快速识别约30%-40%的可访问性问题，包括缺失alt文本、颜色对比度不足、无效ARIA属性等。但工具无法判断语义结构合理性、焦点管理逻辑或屏幕阅读器下的实际体验。因此，人工测试不可或缺，尤其涉及复杂交互组件（如下拉菜单、模态框、动态内容更新）。
核心测试维度包括：
- 键盘导航：所有功能必须仅通过键盘操作完成，焦点顺序应逻辑清晰，可见焦点指示器不得缺失。
- 屏幕阅读器兼容性：使用NVDA（Windows）、VoiceOver（macOS/iOS）、TalkBack（Android）验证元素语义是否正确传达，如按钮是否被识别为可操作项，表单错误是否有明确提示。
- 视觉可访问性：文本与背景对比度至少达到WCAG AA级（4.5:1），支持浏览器缩放至200%无内容溢出或功能失效。
- 语义结构：HTML标签使用符合语义（如nav、main、button），避免div模拟交互元素；ARIA属性仅在原生语义不足时补充，且需验证其有效性。
测试流程应嵌入开发生命周期。需求阶段明确辅助功能验收标准；设计阶段提供高对比度方案与焦点状态规范；开发阶段采用语义化编码并集成自动化检查；测试阶段执行完整用例覆盖。关键点：不要依赖后期修复，早期介入可降低70%以上修复成本。例如，在组件库层面统一实现可访问的按钮、表单控件，比逐页面修正更高效。
常见错误包括：隐藏内容未对辅助技术屏蔽（如display:none仍被读屏器读取）、动态内容更新未触发aria-live通知、表单错误信息仅靠颜色区分。解决方法：使用CSS clip-path替代display:none隐藏非必要内容；对实时更新区域添加aria-live="polite"；错误提示需包含文本标识并关联对应字段（通过aria-describedby）。
团队需建立可复现的测试环境。配置多平台屏幕阅读器组合（如Windows+NVDA+Firefox，iOS+VoiceOver+Safari），记录具体设备、OS版本、浏览器及辅助工具版本。测试用例应包含真实用户场景：例如，视障用户如何完成注册流程，运动障碍用户如何提交长表单。最终输出应包含问题描述、违反的WCAG条款（如1.1.1 Non-text Content）、修复建议及验证方法。
