我已经实现了一个弹出式窗口,该弹出式窗口是通过网页上的按钮触发的。该弹出窗口几乎填满了整个屏幕,并阻止用户与网页上的任何内容进行交互,直到关闭弹出窗口为止。这对于有视力的用户来说效果很好,但是在Mac上使用VoiceOver时,您仍然可以浏览基础网页的内容,而盲人用户根本不知道会出现弹出窗口。

如何防止VoiceOver导航页面上除一个div之外的所有元素(以及该div中的每个元素)?

我知道可以使用aria-hidden="true"将其隐藏在屏幕阅读器中,并且我知道可以强制将重点放在某个元素上,但是我不确定如何最好地实现这一点。我是否需要遍历整个DOM并本质上隐藏所有内容,然后在关闭时取消隐藏所有内容?还是有更好的方法,也许是定义了这种呈现的元素类型的一些ARIA属性?

表现出所需行为的网站是Piazza。当您激活“登录”按钮时,它会显示一个弹出模式对话框并要求焦点,并且您必须先退出该弹出窗口,才能离开它。

最佳答案

正确实现可访问的模式对话框必须成为Web可访问性的棘手方面之一,因为除了屏幕阅读器和浏览器的兼容性以及遵守规范的常见问题之外,还有很多事情需要注意。这是一个摘要(!),多少基于个人经验this article from Smashing Magazine on accessible Modal dialogsWAI-ARIA 1.0 Authoring Best Practicesthis slideshow on the same topic

(请注意,您会在这些建议之间发现一些冲突的建议;这在某种程度上是由于屏幕阅读器/浏览器与规范之间在行为上存在差异,并且不同的作者在是否遵循规范还是与实际用户实际使用的屏幕阅读器配合使用方面存在不同的立场)

  • 告诉屏幕阅读器它是一个对话框:将role =“dialog”添加到父DIV,然后将aria-labelledby设置为指向标题的ID。

    首先,这会使屏幕阅读器将用户界面识别为对话框。当用户通过导航或焦点移入其中时,屏幕阅读器将宣布用户现在处于对话框中,并且可能还会宣布标题。 (在某些屏幕阅读器/浏览器组合上-特别是VoiceOver + Safari,它也可能会影响屏幕阅读器导航的工作方式。)但是,这本身并不能“隐藏”页面上的任何其他UI。
  • 添加基本的键盘支持

    对于在屏幕阅读器用户和使用键盘用户的非屏幕阅读器用户来说,有很多事情要做。这里的两个关键问题是将焦点移到对话框最初出现时的适当位置,而当对话框关闭时,将焦点恢复到对话框最初出现时的位置。
  • 为屏幕阅读器用户和键盘用户设置模式

    对话框有两种形式:模态(不让用户在显示时与任何其他UI交互)和无模(无模),使用户离开对话框并稍后返回-示例可能是某些文本中的“查找文本”对话框编辑。 role =“dialog”不能区分这两种情况,并且使用ARIA不会对浏览器的行为产生任何影响,因此,如果对话框是模态的,则必须自己做一些额外的工作才能使其表现为模态。这有两个方面:
  • 就像模态对话框使用灰色稀松布或模糊效果在视觉上向视力不佳的用户隐藏不 Activity 的背景一样,我们还希望对屏幕阅读器用户隐藏此内容:否则,他们仍然可以从对话框中导航到背景,或者使用其他热键可以列出页面中的链接或标题或其他控件,并且可以从页面的背景部分和对话框中看到这两项。过去,将aria-hidden =“true”放在所有其他顶级DIV上是执行此操作的最佳工具(有点儿怪异-记住在完成后将其删除!),但是从2020年开始,aria-modal="true"出现了得到体面的支持,并且易于实现。
  • 对于屏幕阅读器用户和不使用屏幕阅读器的键盘用户,您还需要使键盘行为具有模式性:从对话框最后一项中击中选项卡应换行到对话框顶部,而将shift-tab用作反向行为。如果您不这样做,则键盘-和屏幕阅读器-用户可以直接在对话框中跳入页面背景。有不同的方法来执行此操作,大多数方法是在 body 级别上跟踪focusin或类似内容,如果焦点“退出”,则将焦点强制返回到对话框中。
  • 其他调整/修复/黑客

    基于Windows的屏幕阅读器(例如NVDA和JAWS)在进入对话框时会进入“应用程序模式”:它们的Web导航热键不再起作用,并且将对话框的内容视为表单而不是富网页。很好,因为对话框内容是仅包含字段,标签和按钮的经典形式,但是如果对话框包含带有文本,超链接等的Web内容,则不合适。在这种情况下,您可能想在角色=“对话框”中放置一个<div role="document">...</div>,但包装主要内容。
  • 确保对话框内容本身可访问

    应该不言而喻,但是以上所有内容都不算什么,除非对话框中的内容本身可访问。
  • 最重要的是:首先了解为什么要使对话框可访问,并进行适当的测试。

    不幸的是,此刻(2015年1月!),不同的屏幕阅读器之间的行为仍然存在很大差异(还取决于所使用的浏览器)。几乎就像十年前(!)的浏览器使用CSS一样。值得理解的是,为什么要使UI易于访问,弄清楚大多数用户的位置以及在给定将要使用的屏幕阅读器的情况下进行适当的测试。在the most recent (Jan 2014) WebAim Screenreader survey中,Windows阅读器(尤其是JAWS和NVDA)占据了大部分市场,而VoiceOver则位居第三。

    这是要考虑的一种可能策略:
  • 如果您只想进行基本的“尽职调查”,则仅使用VoiceOver进行测试就可以了。在其他屏幕阅读器上的体验可能不尽如人意,但是如果VO可以运行某些功能,则在其他屏幕阅读器上可能不会被完全破坏。
  • 下一步是获得NVDA基于Windows的屏幕阅读器(免费,但可以免费捐赠)的副本,并在Mac上的VM中运行它(假设您在此处使用Mac)。 NVDA和JAWS往往在行为方面非常接近。
  • 如果可访问性是您的职位描述的一部分,则您或您的公司可能需要获得JAWS($ 800 +!)的副本,因为这似乎是政府和教育机构的首选屏幕阅读器。 (这可能是使用较低版本的IE进行测试的可访问性模拟!)
  • 07-24 09:46
    查看更多