我已经实现了一个弹出窗口,该弹出窗口是从我网页上的按钮触发的。此弹出窗口几乎填满整个屏幕,并阻止用户与网页上的任何内容交互,直到弹出窗口被取消。这适用于有视力的用户,但在Mac上使用VoiceOver时,您仍然可以浏览基础网页内容,而盲人用户则不知道弹出窗口是否已呈现。
如何阻止VoiceOver导航页面上的每个元素,只有一个div
(以及div
中的每个元素)?
我知道可以使用aria-hidden="true"
将其隐藏在屏幕阅读器中,我知道可以强制关注元素,但我不确定如何最好地实现这一点。我是否需要遍历整个DOM并基本上隐藏所有内容然后关闭取消隐藏所有内容?或者是否有一种更好的方法,一些ARIA属性可以定义这种类型的元素?
展示所需行为的网站是Piazza。当您激活“登录”按钮时,它会显示一个弹出模式对话框并要求对焦,在您关闭弹出窗口之前,您无法离开它。
答案 0 :(得分:3)
正确实现可访问的模式对话框必须成为Web可访问性的一个棘手的方面,因为除了通常的问题之外,还需要注意这么多的事情。屏幕阅读器和浏览器兼容并遵守规范。这是一个摘要(!),有些基于个人经验,this article from Smashing Magazine on accessible Modal dialogs,WAI-ARIA 1.0 Authoring Best Practices和this slideshow on the same topic。
(请注意,您会在这些之间找到一些相互矛盾的建议;这在某种程度上是由于屏幕阅读器/浏览器和规范之间的行为差异,以及不同的作者在是否坚持规范与使用屏幕阅读器的工作方面有不同的立场真正的用户实际使用。)
告诉屏幕阅读器它是一个对话框:添加角色="对话框"到父DIV,并设置aria-labelledby指向标题的ID。
这使得屏幕阅读器首先将UI片段识别为对话框;当用户导航到其中时,无论是通过导航还是因为焦点移动到其中,屏幕阅读器将宣布用户现在处于对话中,并且可能还会宣布标题。 (在某些屏幕阅读器/浏览器组合上 - 特别是VoiceOver + Safari,它也可能影响屏幕阅读器导航的工作方式。)仅此一项并不能隐藏'但是,页面上的任何其他UI都是。
添加基本键盘支持
这里有许多事情要做,这对屏幕阅读器用户和使用键盘用户的非屏幕阅读器都很重要。这里的两个关键问题是在最初出现时将焦点移动到对话框中适当的位置,当对话框被解除时,将焦点恢复到对话框最初出现时的位置。
为屏幕阅读器用户和键盘用户设置模态
对话有两种形式:modal,它不允许用户在出现时与任何其他UI交互,并且无模式,让用户离开对话框并稍后返回 - 示例可能是&#34 ;查找文字"一些文本编辑器中的对话框。角色="对话框"没有区分这两种情况,并且使用ARIA也不会对浏览器行为产生任何影响,所以如果你的对话是模态的,你必须自己做额外的工作,使其表现为模态。这有两个方面:
正如模态对话框使用灰色稀松布或模糊效果直观地隐藏有视觉用户的非活动背景一样,我们也希望从屏幕阅读器用户隐藏此内容:否则他们仍然可以导航出对话框到后台,或使用其他热键列出页面中的链接或标题或其他控件,并将从页面的背景部分和对话框中看到这两个项目。使用aria-hidden =" true"是用来执行此操作的最佳工具(并确保在完成后将其删除)。如果您的页面结构允许,最简单的方法是将所有主要页面内容放在一个div下,这样您就可以将aria-hidden应用于该div;否则你必须将它应用于除对话框之外的所有顶级div。
对于屏幕阅读器用户和使用非屏幕阅读器的键盘用户,您还需要进行键盘行为模式:从对话框中的最后一项中击中标签应该换行到对话框的顶部,并且shift-tab的行为。如果你不这样做,键盘和屏幕阅读器 - 用户可以直接从对话框中选择进入页面背景。有这样做的不同方法,大多数涉及在身体水平跟踪焦点或类似物,并且如果它逃脱"逃避"
其他调整/修正/黑客
基于Windows的屏幕阅读器(如NVDA和JAWS)进入&#34;应用模式&#34;当他们进入对话框时:他们的网络导航热键不再有效,他们将对话框的内容视为表单而不是丰富的网页。这很好,对话框内容是一个只包含字段,标签和按钮的经典形式,但如果对话框包含带有文本,超链接等的Web内容,则不适合。在这种情况下,您可能希望在您的角色=&#34;对话框中放置<div role="document">...</div>
&#34;但包装主要内容。
确保对话框内容本身可以访问
不言而喻,除非对话框中的内容本身可以访问,否则以上所有内容都是无关紧要的。
最重要的是:了解您为什么要首先访问对话框,并进行适当的测试。
不幸的是,目前(2015年1月!),不同的屏幕阅读器之间的行为仍有很多变化(也取决于使用的浏览器);它几乎就像浏览器使用CSS一样十年(!)左右。值得理解的是,为什么要使用户界面可访问,找出大多数用户的位置,并根据他们将要使用的屏幕阅读器进行适当的测试。来自the most recent (Jan 2014) WebAim Screenreader survey的Windows阅读器 - 尤其是JAWS和NVDA - 占据了市场的大部分,而VoiceOver则排名第三。
这是一个可以考虑的策略:
答案 1 :(得分:1)
您应该遍历所有顶级项目,并在这些项目上设置aria-hidden = true。这是一个例子:
<!doctype html>
<html>
<head>
<title>aria-hidden examples</title>
</head>
<body>
<a aria-hidden="true" href="#">Link at top</a>
<p aria-hidden="true">Lots of text content</p>
<form aria-hidden="true">
<label for="input">Label</label>
<input id="input" type="text" />
<button>Submit</button>
</form>
<div>
<label for="dialogInput">Nother Label</label>
<input id="dialogInput" type="text"/>
</div>
<form aria-hidden="true">
<label for="input2">Label 2</label>
<input id="input2" type="text" />
<button>Submit 2</button>
</form>
<a aria-hidden="true" href="#">Link at bottom</a>
</body>
</html>
问题是,这会导致通知保留在&#34;对话框中,但是如果按Tab键,焦点可以移出对话框而不会被宣布。这意味着如果对话框外部存在交互元素,则用户最终可能会与错误的元素进行交互。其他浏览器也会做类似的事情。
因此,如果您的页面包含其他可自由聚焦的元素(如上例所示),则需要使用Javascript事件处理程序将焦点捕获到对话框中以处理您的TAB键。
答案 2 :(得分:0)
WAI-ARIA提供dialog和alertdialog角色来定义对话框。当希望用户提供数据时使用对话框角色,并使用alertdialog角色向用户宣告对话框的内容。
提醒对话框
<div role="alertdialog"
aria-labelledby="dlgtitle"
aria-describedby="instructions">
<h1 id="dlgtitle">Shutdown instructions</h1>
<ol id="instructions">
<li>Open timesheet</li>
<li>Enter time for today</li>
<li>Close all open applications</li>
<li>Shut down system</li>
</ol>
<div>
<input type="button" value="OK">
</div>
</div>
<强>对话强>
<div role="dialog" aria-labelledby="dlgtitle">
<h1 id="dlgtitle">Sign up to Newsletter</h1>
<ol id="instructions">
<li>Enter email address</li>
<li>Press the 'Sign up' button</li>
<li>You're all signed up!</li>
</ol>
<div>
<label for="email">Email: </label>
<input type="text"
id="email"
name="email"
aria-describedby="instructions">
<input type="button" value="Sign up">
</div>
</div>
WAI-ARIA Authoring practice design pattern for a modal dialog