可访问性测试从检查静态HTML页面演变为解决复杂的JavaScript驱动的应用程序。早期的网页可访问性关注于语义标记和图片的替代文本。现代单页面应用程序（SPAs）带来了动态更新内容而无需页面重新加载的挑战，这使得屏幕阅读器难以检测变化。
核心问题涉及动态界面中的ARIA实时区域和焦点管理。当实时数据流更新DOM时，像NVDA或JAWS这样的屏幕阅读器可能无法宣布关键更改，或者更糟的是，通过非必要的更新中断用户。模态对话框则通过不正确地限制焦点或在关闭时未能将焦点返回到触发元素而使情况更加复杂，违反了WCAG 2.1成功标准1.3.1和2.4.3。
实施一个系统的手动测试方案，结合键盘导航测试、屏幕阅读器验证和认知流分析。首先，验证所有交互元素是否可以通过Tab键导航到达，而无需依赖鼠标。其次，使用实际的屏幕阅读器进行测试，以验证实时区域使用适当的礼貌设置（aria-live="polite"与"assertive"）。第三，使用浏览器开发者工具记录焦点顺序，以确保逻辑顺序与视觉布局相匹配。
我被指定负责测试一个使用React构建的金融交易仪表板，该仪表板显示实时加密货币价格更新，并允许用户通过模态对话框执行交易。该应用程序针对因视觉障碍而依赖屏幕阅读器的专业交易员，要求即时通知价格警报，同时保持工作流程的连续性。由于错过警报可能导致用户重大财务损失，风险很高。
在初步测试中，我们发现价格下降警报未能向屏幕阅读器用户宣布，导致他们错失重要的交易机会。此外，在打开交易确认模态时，焦点仍停留在背景元素上，使得用户在使用Tab键导航时意外触发交易。模态关闭按钮也未能将焦点返回到触发元素，使得用户不得不从页面顶部重新开始导航。
我们考虑使用像axe DevTools和Lighthouse这样的自动化可访问性扫描仪快速捕捉违规行为。这些工具有效地识别缺失的alt属性和不足的颜色对比率。然而，它们完全忽视了实时区域公告的时机问题以及特定于模态React Portal实现的焦点管理问题。静态分析无法验证屏幕阅读器是否在正确的时刻真正宣布内容，或者焦点陷阱是否与实际辅助技术配合使用。
第二种方法涉及在Windows上使用NVDA和在macOS上使用VoiceOver进行纯手动测试，无需结构化测试用例。虽然这种方法捕捉到了特定的焦点限制问题，但不一致且耗时。不同的测试人员根据其屏幕阅读器的熟练程度报告出冲突的结果。这种方法也未能为开发人员建立可重复的步骤来修复问题，因为轶事观察在测试会话之间有所不同。
我们实施了一种混合的方法，结合了结构化测试方案与针对辅助技术的验证。我创建了详细的测试用例，专门用于“屏幕阅读器兼容性”，使用NVDA配合Firefox和VoiceOver配合Safari作为主要组合。每个测试用例包括验证实时区域礼貌级别的具体步骤，记录通过模态的确切Tab导航顺序，以及使用屏幕阅读器语音查看器记录公告行为。该方法在彻底性和可重复性之间实现了平衡。
我们选择了混合结构的方法，因为它为开发人员提供了具体的、可重复的缺陷报告，包括特定的ARIA属性配置错误。这种方法消除了即兴测试的不一致性，同时捕捉了自动扫描仪遗漏的问题。结构化格式还使知识转移给不熟悉可访问性测试的初级QA工程师成为可能。
这种方法确定了开发团队为所有价格更新实现了aria-live="assertive"，导致了不断的干扰。我们建议将关键警报更改为**"assertive"，将标准更新更改为"polite"。对于模态，我们使用react-focus-lock**库实现了焦点限制，并确保焦点返回到触发元素。修复后的验证显示，100%的受测屏幕阅读器用户能够成功完成交易工作流，而没有错过警报或失去导航上下文。
您如何验证模态对话框关闭时焦点管理是否正常？
许多候选人建议简单检查模态是否在视觉上消失。正确的方法需要理解WCAG 2.1成功标准2.4.3（焦点顺序）。您必须验证当模态通过Escape键或关闭按钮关闭时，焦点是否返回到最初打开模态的元素，而不是DOM的顶部。通过打开模态、关闭它，然后按一次Tab来测试，以验证焦点是否移动到触发后的下一个逻辑元素。此外，在模态可见期间，Tab导航必须仅在模态元素内循环（焦点限制），以防止意外的背景交互。
礼貌和果断实时区域之间有什么区别，您如何测试屏幕阅读器的行为？
候选人通常会混淆这些ARIA属性或暗示它们功能相同。Aria-live="polite"在屏幕阅读器完成当前语音之前列队公告，适用于非关键更新，如自动保存确认。Aria-live="assertive"立即打断用户，仅保留给诸如事务失败等关键错误。要测试，请使用实际的屏幕阅读器（NVDA、JAWS或VoiceOver）而不是浏览器工具，创建在屏幕阅读器说其他内容的同时更新两种区域类型的场景。许多测试人员错过了aria-atomic和aria-relevant属性进一步控制公告行为的问题，当只有部分实时区域发生变化时。
您如何处理在像React Router这样的框架中进行路由更改的可访问性测试，无需完全重新加载页面？
大多数初级测试人员检查视觉URL变化，却忽视屏幕阅读器依赖页面标题更新和焦点移位来宣布导航。由于SPAs不会触发传统的页面加载事件，辅助技术可能不会通知用户他们已经导航到新视图。解决方案需要验证路由更改是否以编程方式更新document.title，并通过JavaScript将焦点移动到H1标题或main标志。通过激活屏幕阅读器导航路由并确认其公告新的页面标题或标题内容进行测试。候选人经常忽视在SPAs中测试浏览器的后退按钮行为，其中必须维护焦点历史，以防止用户在导航堆栈中迷失。