Mac VoiceOver 是否会限制其在 Chrome/Firefox 上的功能？

Question

我正在我公司的网站上进行一些可访问性测试。我一直在使用 Mac 的 VoiceOver 工具和 Chrome 进行大部分屏幕阅读器测试。在大多数情况下，它已经起作用了，但是，今天我向自定义元素（主要使用 div 构建）添加了一些 ARIA 标签和角色，并且它似乎只在 Safari 中有效......

有没有其他人遇到过这个问题？关于是否有修复或解决方法的任何想法，以便它可以在任何浏览器上运行？

如果我的场景不够清楚，请告诉我，我会提供更多信息/细节。谢谢！

Answer 1

答案更有可能与您提出问题的方式相反。

Mac VoiceOver 是否会限制其在 Chrome/Firefox 上的功能？

一般来说，没有。Web 开发人员通常认为屏幕阅读器是问题所在，但通常缺少 Web 浏览器的实现。当 HTML 和 ARIA 语义在使用相同操作系统和屏幕阅读器的一个浏览器中按预期传达时，而不是在另一个浏览器中传达时，这通常表明浏览器的实现存在差异。

屏幕阅读器不直接阅读网页。相反，屏幕阅读器（和其他辅助技术）通过操作系统提供的可访问性 API 与 Web 浏览器（和其他本机应用程序）进行通信。屏幕阅读器只能报告 Web 浏览器告诉它的内容。Web 浏览器需要将可访问性元数据传递给操作系统，而操作系统又可供屏幕阅读器使用。Firefox 尤其不适用于 macOS 辅助功能 API。

WCAG 使用术语“支持无障碍”来描述这一点。基本上，这些鸭子必须排成一排：

• 网页开发人员正确使用 HTML 和 ARIA。请注意，ARIA 有一个内容模型；某些角色/属性应与其他属性和子级角色结合使用。
• Web 浏览器正确实现 HTML 和 ARIA 语义，并将其公开给主机操作系统上的可访问性 API，并具有正确的映射。
• 主机操作系统提供的可访问性 API 也必须建模相同的信息。
• 辅助技术（屏幕阅读器等）使用它来通知用户屏幕上的内容，并沿相反的路线将他们的交互传回。关于如何最好地呈现这一点，屏幕阅读器有不同的设计理念：它们提供用户偏好来控制诸如冗长和标点符号之类的东西；和用于检查文档结构或列表链接的工具。

也就是说，一些屏幕阅读器（如 JAWS）可以直接挂接到浏览器进程中，因为在开发可访问性 API 之前，这在历史上是最好的处理方式。我听说一些辅助技术可能会使用自定义行为作为浏览器错误的解决方法，但我无法提供一个很好的例子的引用。展望未来，正确的方法是使用操作系统级别的可访问性 API，操作系统供应商可能会在某个时候强制执行。屏幕阅读器确实具有用户脚本功能，并且一些供应商分发脚本（黑客）来增强特定网站。

更多信息：

• Accessibility APIs: A Key To Web Accessibility是对该主题的一个很好的介绍。
• WhatSock 的辅助功能树培训指南更深入。
• PowerMapper 已发布大量屏幕阅读器可靠性信息。详细的测试结果比较了浏览器、操作系统和屏幕阅读器的多种组合。
• 浏览器开发工具现在提供了一种检查可访问性树的方法（Firefox、Chrome）。这显示了浏览器向操作系统级可访问性 API 发送的内容。
• 要在通过操作系统级辅助功能 API 时检查辅助功能信息，您可以使用aViewer (Windows) 或 XCode Accessiblity Inspector (macOS)。
• 将 Web 内容映射到操作系统级可访问性 API 的预期行为在各种 W3C 文档中进行了描述：核心可访问性 API 映射、HTML 可访问性 API 映射、SVG 可访问性 API 映射、可访问性名称和描述计算。浏览器供应商有望实现这些。
• 各种屏幕阅读器软件的错误跟踪器通常提供有关特定怪癖是由浏览器还是屏幕阅读器引起的洞察力。