标签归档:accessibility

创建无障碍的对话框

如今的web应用程序中,对话框如同在桌面应用程序中一样常见。我们使用较少的JavaScript和CSS就可以很容易的显示或隐藏一个元素,但很少会考虑对话框对可访问性的影响。多数情况下,它是可访问性的一个灾难。输入焦点未能正确处理以及屏幕阅读器无法感知内容变化。其实,使对话框可访问并非如此困难,你只需要理解几行代码的作用。

ARIA role

如果你想要屏幕阅读器用户感知到弹出了一个对话框,那么你需要学习一些ARIA role知识。ARIA role [1]为HTML元素提供了额外的语义,让浏览器与屏幕阅读器以更具描述性的方式进行沟通。ARIA定义了大量的角色,改变了屏幕阅读器感知页面中不同元素的方式。与对话框有关的角色有两个:dialog和alertdialog 。

在大多数情况下, 我们使用dialog。将一个元素的role属性设为此值,浏览器则会把该元素看作为一个对话框。

<div id="my-dialog" role="dialog">
    <-- Your dialog code here -->
</div>

当role属性值为dialog的元素可见时,浏览器会告知屏幕阅读器一个对话框已打开。这可以让屏幕阅读器用户意识到,他们已经不在页面的常规流中了。

对话框应有描述标签(label)。你可以使用aria-label属性来指明描述文本或者使用aria-labelledby属性来指明包含描述文字的元素的ID。示例如下:

<div id="my-dialog" role="dialog" aria-label="New Message">
    <-- Your dialog code here -->
</div>

<div id="my-dialog" role="dialog" aria-labelledby="dialog-title">
    <h3 id="dialog-title">New Message</h3>
    <-- Your dialog code here -->
</div>

在第一个例子中,aria-label属性用于指定一个仅用于屏幕阅读器的标签。当对话框的label无需可见时,你可以使用此方法。在第二个例子中,aria-labelledby属性用于指定包含对话框标签的元素的ID。由于对话框有一个可见的标签,关联复用比再重复一遍更妥。当对话框显示时,屏幕阅读器会报读对话框的标签。

alertdialog role是对话框的一种特殊类型,目的是为了吸引用户的注意力。你可以把它看作是当你尝试删除一些东西时弹出的确认对话框(confirmation dialog )。alertdialog的交互相比而言较少。它的主要目的是让用户感知到一个操作已执行。与此相比,dialog 可能是供用户输入信息的区域,比如写一封电子邮件或即时消息。

当一个alertdialog显示时,屏幕阅读器会查找描述文字来报读。建议使用aria-describedby来指定需要朗读的文本。这个属性与aria-labelledby 类似,其值是包含欲朗读内容的元素的ID。如果未指定aria-describedby,那么屏幕阅读器将试图找出能起描述作用的文本,往往会选择元素内第一段文本内容。例如:

<div id="my-dialog" role="alertdialog" aria-describedby="dialog-desc">
    <p id="dialog-desc">Are you sure you want to delete this message?</p>
    <-- Your dialog code here -->
</div>

此示例使用一个元素包含了描述文本。这样做可以确保在对话框显示时,会报读正确的文本。

即使你不设置这些额外的属性,仅对对话框设置适当的role,应用的可访问性也会得到极大地提高。

将焦点设置在对话框上

创建无障碍对话框的下一步就是管理焦点。当一个对话框出现时,焦点应在对话框内,这样用户才可以使用键盘继续浏览。焦点设置在对话框内的确切位置,在很大程度上取决于对话框本身的目的。如果确认对话框(confirmation dialog )内有一个“继续”按钮和一个“取消”按钮,那么你可以将焦点默认设置在“取消”按钮上。如果对话框是用来让用户输入文字的,那么你可以将焦点默认设置在文本输入框内。如果你实在不知道将焦点设在何处,将焦点设置在能代表对话框的元素上是个不错的选择。

由于多数情况下,我们使用<div>元素来表示一个对话框,那么可以将焦点默认设置在该<div>上。你需要将该元素的tabIndex属性设置为-1,这样这个元素才能获得焦点。这个属性值允许你使用JavaScript将焦点设置到该元素,但不会将该元素插入到正常的Tab键顺序中。也就是说用户将无法按TAB键将焦点设置在对话框上。直接在HTML中设置或通过JavaScript设置都可以。在HTML中设置:

<div id="my-dialog" role="dialog" tabindex="-1" aria-labelledby="dialog-title">
    <h3 id="dialog-title">New Message</h3>
    <-- Your dialog code here -->
</div>

通过JavaScript设置:

var div = document.getElementById("my-dialog");
div.tabIndex = -1;
div.focus();

一旦将tabIndex设置为-1,元素就可以调用focus(),就像任何其他的可聚焦元素一样。这样用户就可以按Tab键在对话框中导航了。

限制焦点(Trapping focus)

对话框的另一个可访问性问题是要确保焦点不能跳出对话框。一般来说,如果对话框是模态的,其焦点应无法逃脱对话框。当对话框打开时,如果按tab键将焦点设置到对话框背后的页面元素中,那么对于键盘用户来说将焦点重新返回到对话框内是相当困难的。因此,我们最好使用一些JavaScript以避免这种情况发生。

基本思路是使用事件捕获(event capturing)侦听focus事件,这种方法由Peter-Paul Koch[2]推广,如今已在JavaScript库中广泛使用。由于focus不冒泡(bubble),你无法在事件流的冒泡阶段捕捉到它。相反,你可以通过使用事件捕获方法捕获页面上的所有focus事件。之后,你只需确定获得焦点的元素是否在对话框中。如果没有,则将焦点设置在对话框上。代码是非常简单的:

document.addEventListener("focus", function(event) {

    var dialog = document.getElementById("my-dialog");

    if (dialogOpen && !dialog.contains(event.target)) {
        event.stopPropagation();
        dialog.focus();
    }

}, true);

代码监听document的focus事件,用以在目标元素接收到它们之前截获所有这类事件。假设对话框打开时,变量dialogOpen的值为true。当focus事件发生时,这个函数截获事件,并检查对话框是否是打开的,如果是的话,再检查接收焦点的元素是否在对话框内。如果两个条件都满足,则重新将焦点设置在对话框上。这样焦点就会在对话框的尾部和起始处循环。这就不会tab出对话框,键盘用户就很难再迷失方向。

如果你使用JavaScript库的话,focus事件委托的方法也可以实现同样的效果。如果不使用JavaScript库,同时需要支持Internet Explorer 8及更早的版本,可以使用focusin事件代替(译者注:focusin和focusout支持事件冒泡)。

恢复焦点(Restoring focus)

对话框的最后一个焦点难题:当对话框关闭时,将焦点返回至页面的主体部分。思路很简单:为了打开对话框,用户可能激活了一个链接或一个按钮。此时焦点转移到对话框中,用户完成一些任务后,然后退出对话框。焦点应该重新设回至为了打开对话框而点击的链接或按钮上,以便可以继续浏览网页。在Web应用程序中经常忽视这个问题,但效果是天壤之别。

与其他部分一样,少量代码即可实现效果。所有浏览器都支持document.activeElement ,返回当前具有焦点的元素。你只需获得这个值,然后显示对话框,关闭对话框时,将焦点返回到该元素。例如:

var lastFocus = document.activeElement,
    dialog = document.getElementById("my-dialog");

dialog.className = "show";
dialog.focus();

这段代码的重点是它记录了最后的焦点元素。这样一来,对话框被关闭时,将焦点设置在它上面:

lastFocus.focus()

总体而言,只会在你已有的对话框代码上增加几行代码即可实现。

退出对话框

最后一个问题是要为用户提供一个快速简便的方法来退出对话框。最好的办法是使用Esc键关闭对话框。这是对话框在桌面应用程序中的退出方式,所以用户非常熟悉这种方式。只需监听Esc键是否被按下,然后退出对话框,如:

document.addEventListener("keydown", function(event) {
    if (dialogOpen && event.keyCode == 27) {
        // close the dialog
    }
}, true);

Esc键的keyCode值是27,所以你只需在keydown事件中查找它。一旦监听到,关闭对话框并将焦点设置回之前的焦点元素上。

总结

从本文可以明显发现,创建一个可被屏幕阅读器和键盘用户轻松访问的对话框并不需要大量额外的代码。只需少量几行代码,你带给用户的不再是无尽的沮丧,而是令人难以置信的快乐。有很多Web应用程序在使用弹出式对话框,但很少能够正确处理这些问题。希望这篇文章对你创建自己的无障碍对话框有所启迪。

参考文献

WAI-ARIA (W3C)
focus和blur事件委托 by Peter-Paul Koch(Quirksmode)

本文译自Nicholas C. Zakas的新作《Making an accessible dialog box》,《JavaScript高级程序设计》就是他的作品。

视觉隐藏内容

组内做的一个分享,主题是“视觉隐藏内容”,主要关注隐藏的方式、方法及每种方法对可访问性的影响,并着重分析了a & label元素的可访问性,介绍了使用clip来做视觉隐藏。内容有点散,但主题明确,其他组的几个同事来要PPT,现在传至slideshare,错误之处,请指正。

View more presentations from Lee Jace.

表单显式label和隐式label对屏幕阅读器用户的影响–更新

增强网站可访问性的25种方法一文,其实讲的是影响网站可访问性的25个重要方面,第十部分讲的是表单。其中讲到使用label元素将标签和特定表单控件联结起来,具体写法有两种:显式label 和隐式label,大猫同学问到两种写法对盲人有何影响,于是测试了一番。

显式label

  • 也就是说为label元素添加for属性,其属性值与表单控件的id属性值一致。
  • 重置和提交按钮(<input type="reset"/><input type="submit"/>), 图片按钮(<input type="img"/>)以及脚本按钮 (<button></button>)不用使用显式label,因为它们已经有了隐式标签,如value 和 alt 属性值,button元素的内容。
<label for="firstname">First name:</label><input type="text" name="firstname" id="firstname" tabindex="1" />

隐式label

  • 根据HTML 4.01 规范, 通过label 元素包裹 表单控件和label文本可创建”隐式label”。
  • 由于一些浏览器(IE6)不支持隐式label,WCAG2.0不建议使用。
<label>First name: <input type="text" name="firstname" /></label>

另外一种写法,即上面两种方法的结合:

<label for="firstname">First name:
<input type="text" name="firstname" id="firstname" tabindex="1" /></label>

两者的区别

使用屏幕阅读器NVDA和IE9测试发现,屏幕阅读器用户听到的提示内容是不同的:

  • 显式label写法:“fFirst name: 编辑框 空白(或内容)”
  • 隐式label写法:“First name: 文本 First name: 编辑框 空白(或内容)”–两种方法一致,不过最后一种写法在所有浏览器下点击label都无法激活表单控件(笔者demo手误,已更改),强烈不推荐这种写法。

可以看出,nvda会重复label文本内容,屏幕阅读器用户更容易理解显式label写法的提示

查看demo

更新:今日看到 HTML5 Accessibility Chops: form control labeling 一文做了同样的测试,作者测试了更多的浏览器和屏幕阅读器,查看测试demo页和结果页,得到了同样的结论:使用for 和 id 并且表单控件不放在label元素内是最健壮的方法。

更多阅读:Form labels: visible and hidden

增强网站可访问性的25种方法

随着web使用量的增加和人们网络意识的增强,可访问性(或“通用设计”)变得更加重要。可访问性不仅取决于一个网站的代码,还受网站设计和内容的影响,这就是为什么可访问性、标准和可用性关系如此紧密。

网页无障碍是一个庞大的课题,已自成一个领域。 但不要被它吓到。无障碍并不是非常难以实施。它并不会像一些人想象的会有碍美观或影响交互。这是一种高明的(smart)设计和开发方式。

让我们来看看建立一个无障碍网站的25个重要技术。

1.一致的布局和结构

为了帮助用户快速和轻松地浏览您的网站,你应该提供一个一致的布局和结构。页面的主要元素——banner、navigation、sidebar侧栏,在整个网站中应该出现在的相同位置 。他们也应该标记一致,如使用同一标题结构(heading structure)。这有利于认知障碍者和使用屏幕阅读器(用来处理屏幕上的内容,并大声读出)的用户访问。 继续阅读增强网站可访问性的25种方法

WebAIM第三次屏幕阅读器用户调查报告

查看报告完整中文版 或 下载 PDF版本

2010年12月,WebAIM进行了第三次屏幕阅读器用户的偏好调查。2009年1月2009年10月,WebAIM先后进行了两次屏幕阅读器用户调查,这是前两次调查的跟进调查。本次调查共收到1245份有效调查结果(其中英语1049份,西班牙语101份,法语91份和葡萄牙语4份)。

虽然国内与国外的互联网环境、辅助技术、无障碍政策法规、视障群体的信息素养有差异,但该报告结果对我们了解视障群体的使用习惯和信息需求有一定帮助,为国内的信息无障碍优化提供事实依据,故笔者将此报告做了全文翻译,现将一些结论摘录于此:

在之前的屏幕阅读器用户调查中发现的结论仍然存在—— 没有典型的屏幕阅读器用户。这些结果突出显式了两年内的重大变化和趋势,我们希望这些结果能够推动网页无障碍有根据的实践。

值得注意的几个点:

  • JAWS仍然是主屏幕浏览器,但其使用量因为NVDA和VoiceOver使用量的显著增加而下降。
  • 实行免费或低收费的屏幕阅读器的看法正在改善。
  • 98.4%的受访者启用JavaScript。
  • 对网页可访问性的前景是乐观的。
  • 三分之二的受访者在移动设备上使用屏幕阅读器,两年前只用12%的人使用。
  • 大部分受访者认为longdesc有用。

 

确保DOM顺序与视觉顺序一致

C27: Making the DOM order match the visual order

适用性

CSS与HTML和XHTML使用

该技术涉及:

描述

该技术的目的是确保内容在源代码中的顺序与内容的视觉呈现顺序一致。作者通过改变css可以将同一源代码的内容呈现为多种视觉顺序。每种顺序本身可能有意义,但可能会导致辅助技术用户困惑。这可能是由于用户关闭了作者指定的展现形式,而是直接通过源代码访问内容(如屏幕阅读器),或者使用键盘与内容交互。如果一个使用屏幕阅读器跟踪源代码来阅读网页的盲人用户与通过视觉顺序阅读网页的明眼用户一起工作,当他们以不同的顺序获取信息时,他们可能会遇到困惑。使用屏幕放大镜和屏幕阅读器组合的低视力用户可能会感到困惑,当阅读顺序在屏幕上来回跳转时。当源代码顺序与视觉顺序不匹配时,键盘用户可能会在预测下一个焦点位置时遇到麻烦。

也有这种情况,视觉呈现顺序对页面的整体理解很重要,如果源代码顺序与展现的不同,它可能会更加难以理解。

当源代码顺序与视觉顺序匹配时,每个人会以同一(正确)的顺序阅读内容并与之交互。

注:tabindex属性有两个功能:其一是使元素可获取焦点,另一个是为元素分配在焦点序列中的位置。tabindex等于0可使元素聚焦,但是是以源元素的顺序添加到焦点序列中的。焦点的顺序依照tabindex正值的顺序。设置tabindex值导致元素的顺序与元素在DOM对象模型(DOM)中的顺序不一致,这意味着该顺序对辅助技术用户来说是不正确的。这主要是因为tabindex属性是在HTML或XHTML中定义的,而不是CSS指定。这可能会在未来的规范中改变,它也可能与视觉呈现顺序不一致。

from: Techniques for WCAG 2.0

键盘可访问性

一些思考

键盘辅助功能是残疾访问的一个重要方面。盲人通常不能使用鼠标,因为他们看不到点击的地方。他们几乎完全依靠键盘。(一些有有限残余视力的法定盲,在页面被放大和高对比度下可以使用鼠标。)(注:法定盲(legal blind)法律上对视觉障碍的界定。目的是为教育、福利或其他方面的工作提供统计标准和确定的依据。在美国为优眼最佳矫正视力在20/200以下,或中心视野直径在20°以下者。在中国则为优眼最佳矫正视力在0.5以下或视野半径小于10°者。大部分仍有一些残余视力,完全看不见的只占少部分。)

一些有神经肌肉障碍的用户也不能使用鼠标。震颤麻痹的用户不能很好的控制肌肉,还有一些很少或者从没使用过他们的双手,由于脊髓损伤、脑损伤或者其他一些原因。有些人根本就没有手,无论是由于出生缺陷、事故或截肢。总之,有很多种情况导致使用鼠标困难或者根本无法使用鼠标。

无法使用鼠标的人可能也不能使用键盘。一些人使用”puff and sip”(吹吸)设备,这种设备通过口腔气流来控制鼠标。(译者注:puff and sip设备是一种为有行动障碍的人提供辅助的计算机技术,是一种替代鼠标的头戴式设备,用户可以在不使用手的情况的下通过向管子内吹气来控制鼠标的指针移动。)

继续阅读键盘可访问性

实用技巧:Firefox下显示网页中的accesskey键盘快捷键

原文:http://www.ampercent.com/how-to-display-keyboard-shortcuts-on-a-web-page-in-firefox/6253/

翻译:Jace (有修改)

在打开的程序、对话框之间或者内部切换、访问菜单项,以及执行简单的任务(如复制、粘贴)时,使用键盘快捷键或热键可以节省你很多时间。

键盘快捷方式在浏览网页时同样也能派上用场。很多网页能够较好的展示出设置的快捷方式,同时也有很多网页的快捷键不被用户察觉。如果您使用的是Firefox,只需对与此类网页链接的CSS做小的修改即刻呈现出设置了的键盘快捷键。 继续阅读实用技巧:Firefox下显示网页中的accesskey键盘快捷键

WAI-ARIA实时区域( Live Regions)

———————————————————————-

注:这篇文章的内容已过时,请查看《WAI-ARIA Live Regions[更新]

———————————————————————-

原文:WAI-ARIA Live Regions

作者:Gez Lemon

摘要

使用WAI-ARIA的实时区域(live regions)将能够解决大多与ajax相关的无障碍问题。实时区域(live regions)能够将更新内容通知给辅助技术,如屏幕阅读器,而且不会失去他们在内容中的位置。

目录

  • 无障碍富互联网应用
  • Live Regions属性
    • atomic属性
    • controls属性
    • describedby属性
    • labelledby属性
    • live属性
    • relevant属性
  • 一致性
  • 未来

无障碍富互联网应用

今天的许多Web应用都将残疾人士排除在外,因为目前的技术在传达重要信息方面能力不足。富互联网应用(RIA)通常使用多种技术, HTML,CSS和javascript,但往往不能提供足够的语义,因此,web应用对残疾人士难以使用,或者完全不能访问。 继续阅读WAI-ARIA实时区域( Live Regions)