`

使用 Dojo 开发支持 Accessibility 的 Web 应用

阅读更多
简介

Accessibility,又经常被缩写为 a11y,指的是软件产品的可访问性、易用性,特别是指对于诸如视力低下等残障人士的使用上的无障碍性。Web 应用,越来越多的作为软件产品的发布形式。而且随着互联网应用的飞速发展,Web 程序的易用性(Accessibility)显得尤为突出。

developerWorks Ajax 资源中心
请访问 Ajax 资源中心,这里几乎囊括了关于 Ajax 编程模型的所有信息,包括各种文章、教程、论坛、blog、wikis、活动和新闻。

一个好的 Web 应用程序,必然需要支持 accessibility(a11y)。这主要是要考虑到世界各地的具有伤残障碍的残障人士比例都不小,他们不能像正常人一样进行识别、阅读、操作 Web 网页,从而形成不公平的障碍。目前,很多发达国家,比如美国、欧洲、日本等国家都针对 a11y 立法,不符合 a11y 的软件程序很多都不在政府机关等的采购范围内。所以说 Web 应用程序对于 a11y 的支持是一个基本上不可或缺的功能。

目前越来越多的开发者加入 a11y 的阵营,来关注残障人士,为其 Web 程序增加 accessibility 的支持。Dojo 作为一个 JavaScript/Ajax 类库,附带了一些含有 a11y 支持的 UI 小组件,并且提供了一些简便的方法来帮助开发者更容易便捷的将自己的 Web 网页提升一个层次,支持 a11y。






回页首




页面样式和字体选择

一般而言,对于残障人士,尤其是视力不好的用户,大的字体,间隔分明的布局体系有利于他们阅读 Web 网页。他们也通常会利用浏览器自带的放大缩小字体的功能来为自己设置最为合适的字体。不同的浏览器放缩字体的方法不尽相同,在 Firefox 浏览器中可以使用“Ctrl +”快捷键来放大字体,“Ctrl -”快捷键来缩小,而 IE 浏览器则而可以使用菜单上的字体缩放来调整。

字体的使用,应该尽量使用比较规范的印刷体字体,而不要使用一些不常见的手写体形式。字体的大小可以在层叠样式表 CSS 中定义以百分比,或者以 em 等为单位设置字体大小,从而支持动态缩放。这样的字体单位属于相对单位,各种浏览器都能较好的支持。同样,也可以在 JavaScript 中使用 Dojo 为页面上的某些节点动态方便的设置字体大小,这主要用于一些 Ajax 的应用程序中:

dojo.query(".big").style("fontSize","150%");
// 将页面上所有具有 big 这种 css 类的节点的字体大小设置成 150%;



当然不使用 CSS 而去使用 JavaScript 定义字体大小是不常见的,但是对于某些对浏览器应用不熟悉的视力有问题的用户来说,我们可以在网页的显眼位置设置增大、缩小文字的按钮,用户通过点击这两个按钮,而不需要掌握浏览器伸缩字体的方式,就能够放大、缩小网页上的字,很显然,这种按钮的背后就是上面使用 Dojo 的例子那样的 JavaScript 在起作用。

而更加人性化,完备的解决方案则是多样式表的提供,比如说专门为视力弱小的人群提供 a11y 形式的 CSS, 用户可以自主的选择这种样式为整个网页换肤,并且,浏览器通过 cookies 记录下来用户的偏好样式,以后每当该用户重新访问该网页的时候,就使用之前用户选择的 a11y 的 CSS 进行呈现,下面是一个使用 Dojo 动态替换样式表的例子:

在 HTML 文件中指定了默认的 CSS 样式文件 <link id="theme" type="text/css" rel="stylesheet" href="default.css"/>



用户点击 changeThemeButton 切换到 a11y 的 CSS, 使用 Dojo 可以很方便的做到: dojo.require("dojo.cookie");
var changeThemeButton = dojo.byId("changeThemeButton");
function changeTheme(){
        var styleObj = dojo.byId("theme");
        var src= "a11y.css";
        dojo.attr(styleObj, "href", src); //设置新的样式
        dojo.cookie("style", src); //设置 cookies
}
//使用 dojo 的 event connect 机制,用户点击 changeThemeButton,将触发 changeTheme 方法
dojo.connect(changeThemeButton, "onclick", changeTheme);








回页首




页面导航和键盘支持

用户在浏览网页的时候,经常需要与网页进行一系列的交互操作,比如,点击链接,输入表单信息,点击按钮等等。大部分的用户相当依赖于鼠标来进行这些工作,鼠标能够精确定位页面上任意一处地方,并且通过点击左键、中键、右键等来触发相应的操作。但是这些鼠标的操作对于某些残障人士来说是很困难的,他们很大程度上更加依赖于键盘的操作,尤其是 Tab、Enter、方向键等键值。其中最重要的可能是 Tab 键了,Tab 键主要用来进行页面元素的导航。

使用 Tab 键导航

用户可以使用 Tab 键(或者 Shift+Tab 键)来定位到页面上的元素,获得该节点的焦点,继而可以使用 Enter 回车键或者 Space 空格键来触发点击事件。这是最为普遍常见的键盘导航的应用。

在一个 HTML 网页中,一般意义上可以获取焦点的元素,也就是能够 Tab 到的元素主要是链接 <a> 标记,表单输入域(<input>, <textarea> 标记等等),按钮等需要用户进行交互的元素。如果网页中不特别规定元素的导航顺序,用户使用 Tab 键,将依次按页面的顺序从左至右,由上而下(某些中东国家使用从右至左的文字顺序)的访问,Shift+Tab 组合键则是倒序的访问。

当然软件开发人员可以设定元素的 TabIndex 属性,来自行规定访问的顺序。比如说 a,b,c 三个元素,tabIndex 依次是2,3,1。 那么使用 Tab 键导航将依次访问到 c, a, b。这些都是普通 Web 程序为了增强 a11y 的常用方法。

而针对 Ajax 形式的 Web 应用程序,由于内容的动态性,访问的次序以及焦点的设置都有可能发生变化。比如说:用户通过点击某个按钮激活了一个利用 JavaScript 技术模拟的模态的对话框 Dialog,那么这个时候用户的页面焦点则应该被设定到这个 Dialog 中,并且用户再使用 Tab 键导航, 则不应该跳出这个模拟的模态 Dialog 的范围。直到 Dialog 被销毁。

而这样的需求,很显然,只是简简单单的使用 HTML 语言规范中的 TabIndex 属性是做不到这一点的。我们必须拦截用户的键盘事件,来判断用户按的键值,并且根据不同的键值做出不一样的响应。

不幸的是,不同的浏览器对于用户按键的捕捉,键值的属性等等都各有差异,很难做到支持各种主流的浏览器,不过 Dojo 针对键盘事件的处理,尤其是在各种键值在浏览器中的属性的不一样,事件机制也有差异的情况下,进行了规范化,屏蔽了浏览器之间的差异性,用户可以在同一个 API 下面进行编程,大大提高了方便程度。

下面是一个简单的利用 Dojo 捕捉键盘事件,处理 Tab 导航的例子:

function onkey(evt){
        var key = evt.keyCode;
        if(key == dojo.keys.SHIFT_TAB)
        {
                dojo.stopEvent();
                // 阻止事件的往上发布
                // 定位到上一个需要定位的元素 prev
                prev.focus();

        }
        else if(key == dojo.keys. TAB)
        {
                dojo.stopEvent();
                // 阻止事件的往上发布
                // 定位到下一个需要定位的元素 next
                next.focus();
        }
}
//利用dojo的事件挂接方法来处理键盘事件,用户按下任意键值,都将出发onKeyPress方法
dojo.connect(document, "onkeydown", "onkey");







回页首




使用其他键值进行辅助、快捷的操作

如果您使用过 Google Reader,一个在线的 RSS 内容阅读 Web 应用程序,您可能知道使用 "j" 键来打开下一条 RSS 的 Feed 内容,或者使用 "k" 键来打开上一条内容等等。这些键值不同于 Tab 键,Enter 回车键等 HTML 网页中具有某些默认行为的键值,他们是自定义的,换言之,不同的 Web 站点可能有不同的操作规范,但是不管怎么样,他们提供了除鼠标操作之外的另外一个方便快捷的途径,大大提高了 Web 应用程序的易用性。

而对这些键盘操作的支持,同样需要利用 JavaScript 捕获键盘事件,并针对不同的键值进行不同的操作,实际上,跟上面的例子基本上一模一样,我们只需要再加上对其他键值的判断和对应的处理方法就可以基本上实现了。

function onkey(evt){
        var key = evt.keyCode;
        if(key == dojo.keys.SHIFT_TAB)
        {
                // navigate to prev item
        }
        else if(key == dojo.keys.TAB)
        {
                // navigate to next item
        }
        ...
        else if(key == 42)
        {
                // user pressed "j"
                // do something .
        }
}
dojo.connect(document, "onkeydown", "onKeyPress");



很简单,不是吗,网站的易用性实际上不需要开发者编写很繁琐的代码,每增加一点支持,网站就能更加的平易近人。






回页首




读屏软件的支持

读屏软件是一种专门为视力低下甚至完全眼盲的人士开发的辅助性软件,它能跟踪当前页面上的焦点,并且通过语音发声的形式告诉用户当前是什么信息。目前较为流行、用户范围较广的软件主要是 JAWS, Windows-Eyes 等。

支持基本的读屏操作

目前,读屏软件阅读网页的能力主要来自网页中 HTML 元素给出的相应信息。比如链接 a 标记的 title 信息,图片的 alt 替代文字说明等等。这就要求我们在 编写易用性网页的时候,需要为这些相关的信息元素加上这些辅助的信息,尽管这些信息在大多数时候看起来好像是毫无用处的,但是正是有了这样的信息,读屏软件才能较为正常的帮助这些弱视的群体辨别当前的内容。

对于 Ajax 形式的 Web 程序,这个可能尤为重要,因为内容可能时时都在发生变化。对于动态生成的内容,我们也不应该为读屏软件的工作设置障碍,主动设置好这些辅助信息是一个好习惯。

支持 ARIA

基本的读屏支持是通过读屏软件阅读 HTML 元素给出的 title,label,标准表单元素的选中(checked, unchecked)信息来实现的,而目前富因特网应用越来越多的使用一些自定义的,模拟桌面 GUI 程序的 Web widget 小组件来增强 Web 应用程序的交互,例如 dojo 自带的对话框 Dialog 模态对话框, 以及模拟桌面程序的下拉菜单等等。由于这些带有某种模拟性质的页面节点,读屏软件是不能了解其真正的含义的,读屏软件还是只能去阅读其中的一些诸如 title,label 等信息,很难让弱视的用户获得和普通用户一致的感受。

ARIA 是为了解决类似以上这种问题的标准协议:它的全称是“W3C Web Accessibility Initiative Accessible Rich Internet Applications (WAI-ARIA) Roadmap”,目前应该说还在完善中。并且诸如 IE 这样的浏览器还是不支持的,Firefox 浏览器支持的比较好。它定义了一系列附加的属性(角色 Roles 和状态 State),来支持描述页面上的这类事物。通过为 HTML 的 DOM 节点,比如一个 div 标记设置角色以及状态的信息,然后通过读屏软件的支持,来阅读出当前所访问的是什么东西,并且它处于什么样的状态,从而达到 Accessibility。比如对话框 Dialog,通过设置在 div 上的角色信息,用户能够知道当前访问的是一个对话框,并且能通过设置在 div 上的状态信息,得知这个对话框目前的状态等等。

Dojo 提供的 widget 均已内建 ARIA 的支持。比如说对话框控件, Dialog:在标示 titleBar 的 div 节点上定义了 waiRole = "dialog"; 如果使用 Firefox 以及读屏软件比如 Windows-Eyes 的用户就能明白当前是一个对话框。

<div class="dijitDialog">
  <div dojoAttachPoint="titleBar" class="dijitDialogTitleBar" tabindex="0"
    waiRole="dialog">
    <span dojoAttachPoint="titleNode" class="dijitDialogTitle">${title}</span>
    <span dojoAttachPoint="closeButtonNode" class="dijitDialogCloseIcon"
  dojoAttachEvent="onclick: hide">
      <span dojoAttachPoint="closeText" class="closeText">x</span>
    </span>
  </div>
  <div dojoAttachPoint="containerNode" class="dijitDialogPaneContent"></div>
  <span dojoAttachPoint="tabEnd" dojoAttachEvent="onfocus:_cycleFocus" tabindex="0">
  </span>
</div>



这些都是 Dojo 的组件的内建功能,但是如果想利用 Dojo 开发自己的支持 ARIA 的小组件,Dojo 依然提供了帮助。最简单的:

您可以使用 dijit.wai.setWaiRole 来为某个 DOM 节点设置角色信息。
您也可以使用 dijit.wai.setWaiState 来为某个 DOM 节点设置状态信息。
当然您还需要阅读一下 WAR-ARIA 的规范说明,除此之外您无须担心其他,Dojo 会为您搞定其他,包括 Firefox 高低版本浏览器对 ARIA 支持的差异,名称空间等等。






回页首




支持高对比度的显示模式

某些弱视的群体,可能是色盲患者,经常需要调整操作系统的颜色设置来达到高对比度的效果。

而在 Web 程序中,由于大量使用了图片元素传达信息,这些用户可能对识别这些图片颜色感到困难,所以也可能选择关闭这些图片的显示,而仅仅依赖于图片的提示说明文字 (比如说图片 <image> 标记的 alt 属性)。但是在 Web 程序中,由于图片之前占据了页面中的某些个位置,禁用这些图片将导致网页信息不完整,用户得不到相关的信息。

Dojo 的 widget,由于使用 JavaScript 来侦测浏览器是否处于这个高对比度 a11y 模式,而进行不同的输出(针对一般模式,输出背景图片,而针对高对比度的 a11y 模式,使用可代替的文字占位符等代替图片),保留了信息的完整性,从而避免了这些弱视用户的信息获取的不完整。

比方说,Dojo 的“下拉选择输入框“组件,一般情况下,使用一个向下指的箭头图片来进行下拉框选择,而在高对比度 a11y 模式下面,则会选用“▼”这样一个特殊的字符来代替,通过这样的设计,则基本上不会影响用户的操作和组件的功能性。

而利用 Dojo 这一功能,我们只需要在背景图片的节点上放置一个隐藏的区域来提供高对比度的模式下显示的文字下就可以了,并且设置一定的 CSS 就可以支持这种高对比的模式了。举例来说:

某个 widget 的某个背景图片区域的 DOM 节点是这样的:

<div class="imgNode"><div class="altText">Logo</div></div>



而我们的 CSS 样式表是这样的:

.imgNode{background-image:url(logo.png)}
.altText{display:none}
.dijit_a11y .altText {display:inline}



那么在正常模式下,imgNode 这个元素将显示背景图片 logo.png,而其中的替代文字 "Logo" 将不会显示,因为它的 display 属性是 none 。但是在高对比度模式下,由于 Dojo 的自动探测功能,Dojo 会在 HTML 网页的根节点标记上自动加上了.dijit_a11y 这样一个 CSS 类。 那么替代文字 "Logo" 将会显示出来,代替之前的图片。不影响用户对信息的理解。






回页首




结束语

事实上,a11y 还有其他的内容,不过以上提到的文字大小,布局样式,读屏发声,高对比等的支持,可以认为是一个支持 a11y 的 Web 程序的主要部分。虽然大多数 人是不需要这样的信息的,但是为了让我们的用户能更加广泛、多元化,更公平的参与网络给我们带来的信息世界,a11y 的重要性是不言而喻的。

分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics