隐藏屏幕阅读器中除一个 div 之外的所有元素？

Question

我已经实现了一个由我网页上的按钮触发的弹出窗口。这个弹出窗口几乎填满了整个屏幕，并阻止用户与网页上的任何内容进行交互，直到弹出窗口被关闭。这对视力正常的用户很有效，但是在 Mac 上使用 VoiceOver 时，您仍然可以导航底层网页内容，而盲人用户不会知道出现了一个弹出窗口。

如何防止 VoiceOver 导航页面上除一个div元素（以及其中的每个元素div）之外的每个元素？

我知道可以用aria-hidden="true"它来对屏幕阅读器隐藏它，并且我知道可以强制将焦点放在一个元素上，但我不确定如何最好地实现这一点。我是否需要遍历整个 DOM 并基本上隐藏所有内容，然后在关闭时取消隐藏所有内容？或者是否有更好的方法，一些定义可能呈现的此类元素的 ARIA 属性？

展示所需行为的网站是Piazza。当您激活登录按钮时，它会显示一个弹出式模式对话框并要求获得焦点，并且您无法离开它，直到您关闭弹出窗口。

Answer 1

正确实现可访问的模式对话框必须是 Web 可访问性的棘手方面之一，因为除了屏幕阅读器和浏览器兼容性以及遵守规范的常见问题之外，还有很多事情需要注意。这是一个总结（！），有点基于个人经验，这篇来自 Smashing Magazine 的关于可访问模态对话框的文章，WAI-ARIA 1.0 创作最佳实践和这个关于同一主题的幻灯片。

（请注意，您会发现这些建议之间存在一些相互矛盾的建议；这在某种程度上是由于屏幕阅读器/浏览器和规范之间的行为差​​异，以及不同的作者对于是否坚持规范与使用真实用户实际使用的屏幕阅读器的立场不同.)

• 告诉屏幕阅读器这是一个对话框：将 role="dialog" 添加到父 DIV，并将 aria-labelledby 设置为指向标题的 ID。

  这会导致屏幕阅读器首先将 UI 片段识别为对话框；当用户通过导航或焦点移入其中时，屏幕阅读器将宣布用户现在处于对话框中，并且可能还会宣布标题。（在某些屏幕阅读器/浏览器组合上——特别是 VoiceOver+Safari，它也可能影响屏幕阅读器导航的工作方式。）然而，这本身并不会“隐藏”页面上的任何其他 UI。

• 添加基本​​键盘支持

  这里有很多事情要做，对屏幕阅读器用户和使用键盘的非屏幕阅读器用户都很重要。这里的两个关键问题是在对话框最初出现时将焦点移到对话框中适当的位置，以及当对话框被关闭时，将焦点恢复到对话框最初出现时的位置。

• 使其成为屏幕阅读器用户和键盘用户的模态

  对话框有两种风格：模态的，它不允许用户在出现时与任何其他 UI 交互，以及无模式的，它允许用户离开对话框并稍后返回——示例可能是某些文本中的“查找文本”对话框编辑。role="dialog" 不区分这两种情况，并且使用 ARIA 也不会对浏览器行为产生任何影响，因此如果您的对话框是模态的，则您必须自己做额外的工作才能使其表现为模态。这有两个方面：

  • 正如模态对话框使用灰色纱布或模糊效果在视觉上对视力正常的用户隐藏非活动背景一样，我们也希望对屏幕阅读器用户隐藏此内容：否则他们仍然可以从对话框导航到背景，或者使用列出页面中的链接或标题或其他控件的其他热键，并且将从页面的背景部分和对话框中看到这两个项目。过去，将 aria-hidden="true" 放在所有其他顶级 DIV 上是用于执行此操作的最佳工具（有点繁琐 - 完成后记得将其删除！），但截至 2020 年，aria- modal="true"似乎得到了很好的支持，并且更容易实现。

  • 对于屏幕阅读器用户和非屏幕阅读器使用的键盘用户，您还需要使键盘行为模式化：从对话框中的最后一项点击 Tab 键应该换行到对话框的顶部，而 shift-tab 的相反行为。如果您不这样做，键盘和屏幕阅读器用户可以直接从对话框中跳到页面背景中。有不同的方法可以做到这一点，大多数涉及在身体级别跟踪 focusin 或类似的方法，并在它“逃脱”时强制将焦点返回到对话框中。

• 其他调整/修复/黑客

  基于 Windows 的屏幕阅读器（例如 NVDA 和 JAWS）在进入对话框时会进入“应用程序模式”：它们的 Web 导航热键不再起作用，并且它们将对话框的内容视为表单而不是丰富的网页。这很好，因为对话框内容是只有字段、标签和按钮的经典表单，但如果对话框包含带有文本、超链接等的 Web 内容，则不太适合。在这种情况下，您可能希望<div role="document">...</div>在您的 role="dialog" 中放置 a但包装主要内容。

• 确保对话内容本身是可访问的

  不言而喻，但除非对话框中的内容本身是可访问的，否则上述所有内容都毫无意义。

• 最重要的是：首先了解为什么要使对话框可访问，并进行适当的测试。

  不幸的是，目前（2015 年 1 月！）不同屏幕阅读器之间的行为仍然存在很多差异（也取决于所使用的浏览器）；这几乎就像浏览器在十年（！）左右之前使用 CSS 的方式一样。值得理解为什么要让 UI 易于访问，弄清楚大多数用户将在哪里，并根据他们将使用的屏幕阅读器进行适当的测试。从最近的（2014 年 1 月）WebAim Screenreader 调查来看，Windows 阅读器——尤其是 JAWS 和NVDA——占据了大部分市场，VoiceOver 位居第三。

  以下是一种可以考虑的可能策略：

  • 如果您只想进行基本的“尽职调查”，那么仅使用 VoiceOver 进行测试可能没问题。其他屏幕阅读器的体验可能不如其他屏幕阅读器，但如果某些功能适用于 VO，则可能不会在其他屏幕阅读器上完全损坏。

  • 下一个级别是获取（免费，但可以随意捐赠）基于NVDA Windows 的屏幕阅读器的副本，并在 Mac 上的 VM 中运行它（假设您在这里使用的是 Mac）。NVDA 和 JAWS 在行为方面往往非常接近。

  • 如果可访问性是您工作描述的一部分，那么您或您的公司可能需要获得一份JAWS（800 美元以上！），因为它似乎是政府和教育机构的首选屏幕阅读器。（这可能是使用低级版本的 IE 进行测试的可访问性模拟！）