我已经实现了一个弹出式窗口,该弹出式窗口是通过网页上的按钮触发的.该弹出窗口几乎填满整个屏幕,并阻止用户与网页上的任何内容进行交互,直到该弹出窗口消失为止.这对于有视力的用户来说效果很好,但是在Mac上使用VoiceOver时,您仍然可以浏览基础网页的内容,而盲人用户根本不知道会出现弹出窗口.
如何防止VoiceOver导航页面上除一个div(以及该div中的每个元素)之外的所有元素？
我知道可以使用aria-hidden =“ true”将其隐藏在屏幕阅读器中,而且我知道可以强制将重点放在某个元素上,但是我不确定如何最好地实现这一点.我是否需要遍历整个DOM并本质上隐藏所有内容,然后在关闭时取消隐藏所有内容？还是有更好的方法,也许有一些定义了这种元素类型的ARIA属性？
表现出所需行为的网站是Piazza.当您激活“登录”按钮时,它会显示一个弹出模式对话框并要求聚焦,并且您必须先退出该弹出窗口,才能离开它.
解决方法:
正确实现可访问的模式对话框必须是Web可访问性的棘手方面之一,因为除了屏幕阅读器和浏览器兼容性以及遵守规范的常见问题之外,还有很多事情需要注意.这是一个摘要(！),多少基于个人经验this article from Smashing Magazine on accessible Modal dialogs、WAI-ARIA 1.0 Authoring Best Practices和this slideshow on the same topic.
(请注意,您会在这些建议之间发现一些冲突的建议；这在某种程度上是由于屏幕阅读器/浏览器与规范之间在行为上存在差异,并且不同的作者在是否遵循规范还是与实际用户实际使用的屏幕阅读器配合使用方面存在不同的立场)
>告诉屏幕阅读器它是一个对话框：将role =“ dialog”添加到父DIV,然后将aria-labelledby设置为指向标题的ID.
首先,这会使屏幕阅读器将用户界面识别为对话框.当用户通过导航或由于焦点移入其中而进入浏览器时,屏幕阅读器将宣布用户现在处于对话框中,并且可能还会宣布标题. (在某些屏幕阅读器/浏览器组合上-特别是VoiceOver Safari,它也可能会影响屏幕阅读器导航的工作方式.)但是,这本身并不能“隐藏”页面上的任何其他UI.
>添加基本的键盘支持
对于在屏幕阅读器用户和使用键盘用户的非屏幕阅读器用户来说,有很多事情要做.这里的两个关键问题是将焦点移到对话框最初出现时的适当位置,而当对话框关闭时,将焦点恢复到对话框最初出现时的位置.
>使它成为屏幕阅读器用户和键盘用户的模式
对话框有两种形式：模态(不允许用户在存在时与任何其他UI交互)和无模(可让用户离开对话框并稍后返回)-示例可能是某些文本中的“查找文本”对话框编辑. role =“ dialog”不会区分这两种情况,并且使用ARIA不会对浏览器行为产生任何影响,因此,如果您的对话框是模式对话框,则您必须自己做一些额外的工作才能使其成为模式对话框.这有两个方面：
>就像模态对话框使用灰色稀松布或模糊效果在视觉上向视力不佳的用户隐藏不活动的背景一样,我们也希望对屏幕阅读器用户隐藏此内容：否则,他们仍然可以从对话框中导航到背景,或者使用其他热键可以列出页面中的链接或标题或其他控件,并且可以从页面的背景部分和对话框中看到这两项.使用aria-hidden =“ true”是执行此操作的最佳工具(并确保在完成操作后将其删除).如果页面结构允许,这里最简单的方法是将所有主页面内容放在一个div下,因此您可以将aria-hidden应用于该一个div.否则,您必须将其应用于除对话框之外的所有*div.
>对于屏幕阅读器用户和不使用屏幕阅读器的键盘用户,您还都需要使键盘行为具有模式性：从对话框中最后一项击中选项卡时,应包装到对话框顶部,而将shift-tab行为与之相反.如果您不这样做,则键盘-和屏幕阅读器-用户可以直接从对话框中跳出标签,进入页面背景.有不同的方法来执行此操作,大多数方法是在身体级别上跟踪焦点或类似焦点,如果焦点“逃脱”,则将焦点强制回到对话框中.
>其他调整/修复/黑客
基于Windows的屏幕阅读器(例如NVDA和JAWS)在进入对话框时会进入“应用程序模式”：它们的Web导航热键不再起作用,并且将对话框的内容视为表单而不是富网页.很好,因为对话框内容是仅包含字段,标签和按钮的经典形式,但是如果对话框包含带有文本,超链接等的Web内容,则不合适.在这种情况下,您可能需要放置< div role =“ document”> …< / div>在您的role =“ dialog”中,但包装了主要内容.
>确保对话框内容本身可访问
应该不言而喻,但是以上所有内容都不算什么,除非对话框中的内容本身可访问.
>最重要的是：首先了解为什么要使对话框可访问,并进行适当的测试.
不幸的是,此刻(2015年1月！),不同的屏幕阅读器之间的行为仍然存在很大差异(还取决于所使用的浏览器).这几乎就像十年前(！)的浏览器使用CSS的方式一样.值得理解的原因是,为什么要使您的UI易于访问,弄清楚大多数用户的位置以及针对要使用的屏幕阅读器进行适当的测试.从the most recent (Jan 2014) WebAim Screenreader survey开始,Windows阅读器(尤其是JAWS和NVDA)占据了大部分市场,而VoiceOver则位居第三.
这是要考虑的一种可能策略：
>如果您只想进行基本的“尽职调查”,则仅使用VoiceOver进行测试就可以了.在其他屏幕阅读器上的体验可能不尽如人意,但是如果VO可以运行某些功能,则在其他屏幕阅读器上可能不会被完全破坏.
>进一步升级是获得(免费,但可以免费捐赠)基于Windows的NVDA屏幕阅读器的副本,并在Mac上的VM中运行它(假设您在此处使用Mac). NVDA和JAWS往往在行为方面非常接近.
>如果可访问性是您职位描述的一部分,则您或您的公司可能需要获得JAWS(800美元！)的副本,因为这似乎是*和教育机构的首选屏幕阅读器. (这可能是使用IE较低版本进行测试的可访问性模拟！)