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

Question

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

还有其他人遇到过这个问题吗？关于是否有修复程序或变通办法以便可以在任何浏览器上使用的任何想法？

如果我的情况不够清楚，请告诉我，我将提供更多信息/详细信息。谢谢！

Answer 1

答案很可能与您对问题的措辞相反。

  

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

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

屏幕阅读器不会直接阅读网页。相反，屏幕阅读器（和其他辅助技术）通过操作系统提供的可访问性API与Web浏览器（和其他本机应用程序）进行通信。屏幕阅读器只能报告网络浏览器告诉您的内容。 Web浏览器需要将可访问性元数据传递给操作系统，然后屏幕阅读器可以使用该元数据。尤其是Firefox不能与macOS可访问性API一起很好地工作。

WCAG使用术语“ accessibility supported”来描述这一点。基本上，这些鸭子必须排成一排：

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

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

更多信息：

• Accessibility APIs: A Key To Web Accessibility是对该主题的很好介绍。
• WhatSock的Accessibility Tree Training Guide更加深入。
• PowerMapper已发布了广泛的Screen reader reliability信息。详细的测试结果比较了浏览器，操作系统和屏幕阅读器的许多组合。
• 浏览器开发工具现在提供了一种检查可访问性树（Firefox，Chrome）的方法。这显示了浏览器正在发送给操作系统级可访问性API的内容。
• 要检查通过操作系统级别可访问性API传递的可访问性信息，可以使用aViewer（Windows）或XCode Accessiblity Inspector（macOS）。
• 在各种W3C文档中描述了将Web内容映射到OS级可访问性API的预期行为：Core Accessibility API Mappings，HTML Accessibility API Mappings，SVG Accessibility API Mappings，Accessible Name and Description Computation。浏览器供应商应实施这些。
• 各种屏幕阅读器软件的错误跟踪器通常可以洞悉是浏览器还是屏幕阅读器引起了特定的问题。