介绍

　　应用可访问性是指为残障人士扫除使用障碍在使用电脑时有些用户也许无法看见或无法移动鼠标或者会面临很多其他困难IBM® 在产品可访问性方面有着悠久历史；让应用能够被最广泛客户群使用具有良好商业意义因此IBM 承诺将支持世界级规范标准和标准技术带给残障人士

　　附加测试也称为可访问性验证测试(Accessibility Verication Testing下文简称为 AVT)被用于确保产品符合这些可访问性标准AVT Checklist 是个检查点列表支持可访问性产品需要遵守这个列表该列表是根据世界级可访问性标准生成如 US section 508 和 W3C Web Content Accessibility Guidelines(下文简称 WCAG)在本文中我们将通过些简单例子来解释检查列表中些基本、重要项目我们将分享如何对个 Web 2.0 产品规划和执行 AVT 最佳实战

　　背景

　　WAI- ARIA(下文简称 ARIA)即 Accessible Rich Internet Applications Suite开发出种方式使网络内容更易于残障人士访问它让 Asynchronous JavaScript + XML (Ajax)、JavaScript 或其它技术开发出动态内容尤其易于使用特别是WAI-ARIA 提供了个框架用于添加属性来识别用户交互特点、它们互相如何关联以及它们当前状态在以下例子中您将看到大多数属性是特定于 WAI-ARIA

　　有关 AVT 例子及信息都基于我们对 Web 2.0 应用测试支持 Firefox 3 浏览器和 JAWS 10有些属性例如 WAI-ARIA 标记只有使用特定组件组合才能看到

　　可访问性检查列表关键要素

　　那么究竟哪些技术被认为是和可访问性相关技术？可访问性检查列表有几条关键原则:

　　输入方式可选择:键盘、鼠标、语音以及用于残障人士设备

　　输出方式可选择:显示、声音、打印以及将图像提示转换成声音用户界面元素

　　致性和灵活性:和颜色、字体等用户设置保持致

　　这些原则是可访问性检查列表基础在本文中我们将重点放在 Web 2.0 应用可访问性因此我们讨论 Web 应用检查列表Web 应用应该符合检查列表以便残障人士能够使用这些例子将包含些基本要点以及经常出现问题方面

　　1. 替换文本:所有非文本内容均应有对应文本内容

　　有些浏览器不支持图片因此些视力受损用户看不到图片因而为所有图片提供替代文本就尤为重要这能使所有用户都了解其信息有了替代文本后屏幕阅读器的类辅助技术就可以以另种方式传达图片内容

　　根据 WCAG SC 1.1.1 指南描述所有非文本内容都应有 alt 文本属性冗余图片可将 alt 值设置为空但有意义图片应用有意义语句设置替代文本应当准确、简明如下所示:

　　1.1 非功能图片 alt 内容为空

　　图 1 显示是优先级设置在词语 “高优先级” 和 “中等优先级” 前红色和绿色标志图标其实和词语意思相同因此这些图标就是非功能性或者说是冗余如检查列表 1.1 指出您应当将图标 alt 属性设为空值清单 1 显示了相应 HTML 代码

图 1. 非功能图片


清单 1. 非功能图片代码

<img　="lconnSprite　lconnSprite-iconPriorityMedium16"　
alt=""　src="/activities/javascript/dojo-ibm/dojo/resources/blank.g"　/>　

　　1.2 功能性/重要图片 alt 包含有意义内容

　　图 2 显示是用户信息卡卡上照片是重要图片因此其 alt 属性应包含有意义描述清单 2 显示是 HTML 代码

图 2. 重要图片


清单 2. 功能图片代码举例

<img　height="35"　width="35"　alt="Profile　photo"　
　src="http://lc40.cn.ibm.com:9082/profiles/photo.do?userid=　
　CFDFB8C1-7082-428F-97EF-9E274BDE3F68"/>　

　　图 3 是另个有关功能图片例子“myactivity” 前面闪电图标代表活动优先级它旁边没有文字描述因此 alt 属性应被设为有意义文字以告诉用户该图片作用

图 3. 功能图片


图 3. 另个功能图片代码举例

<img　="lconnSprite　lconnSprite-iconActivities16"　dojoattachpo="icon_AP"　
　　src="/activities/javascript/dojo-ibm/dojo/resources/blank.g"　
alt="Normal　Priority　(Default)"/>　

　　1.3 对于多媒体应使用文字记录描述其内容

　　图 4 是视频文字记录例子Web 2.0 应用通常都会提供多媒体内容有些甚至可以和用户交互视力受损用户感觉不到这些信息因此应该有代替思路方法能使残障用户了解其内容在图 4 中内容下方有文字记录链接用户可以通过阅读文字记录了解视频信息

图 4. 多媒体文字记录


　　2. 适应性:通过 UI 呈现给用户网站WebSite结构应该有套替代思路方法来满足盲人用户需求

　　通过 UI 展现给用户信息、结构和元素关系应该能由控制或有替代文本以下两个例子描述了确认 UI 上表单的间关系思路方法

　　2.1 如果个表单旁边有标签可以使用 “for” 来确定标签和表单间关系

　　本例子可用于大多数典型表单结构即每个条目字段旁都有标签使用和相关数据条目元素 id 属性相匹配值为标签添加 for 属性如果 for 属性未设置仅当焦点位于输入表单时用户才会听到 “编辑器”然而如果为标签设置了 for 属性用户将会听到 “用户名列编辑器”这能帮助用户明确表单用处和应该输入什么清单 4 是这些标签代码

图 5. 表单旁边有个标签


清单 4. 表单中 “for” 参数使用方法

<div>　
<label　for="user">User　name:</label>　
<input　id="user"　="lotusText"　type="text"　name="j_username"/>　
</rdiv><div>　
<label　for="password">Password:</label><inputid　="password"　　
="lotusText"　type="password"　name="j_password"/>　
</div>　

　　2.2 如果个表单没有标签则为 “title” 、“aria_title” 或 “aria_labelledby” 设置参数

　　图 6 显示了个表单称为 “Add Related Activity”数据输入字段旁没有标签但有段长描述因此应当为此表单设置 title 属性

图 6. 表单数据输入字段旁没有标签


　　查看原图(大图)

清单 5. 使用 “title” 属性

<select　title="Add　Related　Activity"　style="width:　530px;"　size="5"　
name="target"　dojoattachpo="targetSelect_AP"/>　

　　此外设置另外两个属性也可以达到同样效果:aria_title 和 aria_labelledby可以通过 WAI-ARIA 技术来使用这两个属性我们将在本文中稍后讨论

　　3. 颜色

　　颜色是用户界面中个重要元素有时你宁愿使用颜色而不是意思相同文字来表示某些功能性含义这就违反了 WCAG SC 1.4.1它指出颜色只能用于装饰；功能性含义不能只用颜色标记以下两个例子就指出并解决了违反颜色相关规定情况

　　图 7 和 8 显示了个此类违背例子并提供了个可行解决方案如果用颜色来表示特定含义视力受损用户或使用高对比模式系统用户就无法了解只通过颜色传达信息图 7 中第个例子显示了个高对比屏幕所有条目颜色都消失了因此用户无法看到条目间区别图 8 显示了个解决方案只需添加些简单有意义文字如 [Requiring Approval] 或 [Draft]就可以区分区别类型条目

图 7. 颜色不合理使用


图 8. 颜色合理使用


　　查看原图(大图)

　　图 9 显示是另个颜色可用性问题普通模式下选项卡活动时会高亮显示但如果系统设置为高对比模式则无法确定哪个选项卡页是活动解决思路方法是在每个选项卡页上加上选项卡名称这样当用户进入某页时就能知道该页是活动

图 9. 高对比模式下颜色问题


　　查看原图(大图)

　　4. 键盘

　　键盘也是处理可访问性问题时应关注另领域

　　4.1 所有功能都能用键盘访问

　　WCAG SC 2.1.1 指出用户应当能用键盘导航到所有内容和功能

　　图 10 显示了个有关键盘问题例子如果鼠标移动到用户名处下方将会弹出张卡片用户单击弹出信息将打开整个名片这整个操作过程都应当有为键盘用户设计替代思路方法这种情况下快捷键就是个不错选择例如按下 Ctrl+Enter 将打开用户名片

图 10. 打开弹出信息时键盘问题


　　图 11 显示了另项复杂操作即拖放功能这是 Web 2.0 应用中常见特性允许用户在 UI 上动态拖拽小部件这项功能很难用键盘模拟因此应该用其他思路方法实现UI 中另个明显功能是向用户展示向哪里移动小部件

图 11. 有关拖放功能键盘问题


　　4.2 不应有键盘陷阱:焦点可以进入和退出当前 UI

　　当用户在当前窗口的上再打开个新窗口时可能会对焦点变化感到疑惑WCAG SC 2.1.1 指出不应有键盘陷阱如果打开个新窗口焦点应当移到新打开窗口第个可编辑元素中并且应该能通过关闭或按下键盘 ESC 键思路方法来退出新打开窗口

　　图 12 显示是 UI 中弹出新窗口例子当用户展开 More Actions 按钮并单击 Import Bookmarks 时屏幕显示焦点仍在 More Actions 按钮上而不是移到新窗口中这就是个键盘陷阱用户无法只用键盘就将焦点移到新窗口中键盘导航仍停留在原窗口中这种情况下应当添加些代码来专门将光标移到新打开窗口第个可编辑对象上

图 12. 焦点键盘问题


　　查看原图(大图)

　　图 13 显示是另个键盘陷阱问题单击 Prioritize 按钮后弹出个下拉列表如果用户不想选择任何项只是退出列表那么他们不管按下什么键都无法做到这是个键盘陷阱应该有退出思路方法如按 ESC 键

图 13. 下拉列表键盘陷阱


　　5. 高对比模式

　　高对比(下文简称 HC)模式是种特别显示模式在 HC 模式下所有背景设置无效包括图片和颜色因此应用中应有专门代码处理 HC 模式

　　图 14 显示是有关该检查点例子每条用户记录都有个按钮来读出名字但图片是背景图在 HC 模式下不会显示在 UI 中在图 14 中我们用替代文字来表示图标清单 6 显示了如何通过第 7 行中 <span> 指令来用 span 设置替代文字

图 14. 高对比模式下背景图


清单 6. 为 HC 用户生成替代文字

<a　title="Play　an　audio　file　with　the　pronunciation　of　the　person's　name"　
　id="pronunciation"　
　href="/profiles/audio.do?key=4815d70b-680d-4bfb-ba05-f32ccedbbcb5　
　　&amp;lastMod=1248147056328">　
　<img　src="/profiles/nav/common/styles/images/blank.g"　="lconnSprite　
　　　lconnSprite-iconAudio16"/>　
　<span　="lotusAltText">Pronunciation</span>　
　</a>　

　　6. 其它问题

　　还有其他些影响使用性情形它们不包含在以上类别中本节将介绍这些情形

　　6.1 定时调整

　　WCAG SC 2.2.1 指出应用中不应有无法禁用或调整时间限制图 15 显示是该检查点例子消息将在约 5 秒钟后消失而用户无法禁用这个有关时间限制配置这对于残障人士是无法接受尤其是视力受损用户解决思路方法是禁用时间限制或仅弹出个消息即可

图 15. 具有定时调整消息


　　6.2 导航特性

　　WCAG SC 2.4.1 指出所有 UI 都应有导航特性以帮助用户将焦点移到合适位置例如在包含空白图片 UI 顶部使用 “Skip to content” 标记当然个产品所有用户界面都应有导航特性清单 7 显示了该检查点有 3个标识供用户跳过他们不想听到内容

清单 7. 提供思路方法使用户跳过不希望听到内容

<!--The　following　lines　are　required　for　Accessibility　and　are　used　by　screen　readers.　
Please　do　not　remove　-->　
<a　href="#Content"　id="lotusAccessLinkMainContent"　accesskey="S"　
　="lotusAccess">　
　<img　src="/activities/nav/common/styles/images/blank.g"　
alt="Skip　to　　content　link.　Accesskey　S"　/>　
</a>　
<a　href="#tabNavigation"　id="lotusAccessLinkTabNavigation"　accesskey="1"　
　="lotusAccess">　
　<img　src="/activities/nav/common/styles/images/blank.g"　
　alt="Skip　to　tab　navigation　link.　Accesskey　1"　/>　
</a>　
<a　href="#subNavigation"　id="lotusAccessLinkSubNavigation"　accesskey="2"　
　="lotusAccess">　
　<img　src="/activities/nav/common/styles/images/blank.g"　alt="Skip　to　
　sub　navigation.　Accesskey　2"　/>　

　　可访问性认证测试

　　现在您已经了解到 Web 应用开发过程中会遇到各种问题那么现在来看下如何对这些问题进行测试

　　在可访问性验证测试中使用工具

　　按照以下步骤测试 Web 内容可访问性将会事半功倍

　　步骤 1:语法分析:WebKing

　　步骤 2:键盘导航和可视焦点

　　步骤 3:可视内容格式化和定时

　　步骤 4:音频和视频

　　步骤 5:高对比和大字体

　　步骤 6:禁用样式表

　　步骤 7:屏幕阅读器

　　每步都有相关辅助工具本文描述官方工具有:语法检查器和屏幕阅读器

　　Web 语法检查器 — WebKing

　　我们在第步就提到了 Web 语法检查器这其实主要供开发人员而不是测试人员使用它般在开发结束、正式 AVT 开始的前使用WebKing 是常用 Web 语法检查工具它可以直接检查 HTML 代码并帮助您在使用其他辅助技术的前修复可访问性问题

　　动态内容生成是 Web 2.0 应用项特性使用 Ajax 在 Web 上动态生成对象使页面在每次加载时都产生区别 HTML 代码WebKing 支持两种区别代码扫描思路方法:静态扫描和动态扫描静态扫描可用于开发人员在开发环境中直接扫描源代码动态扫描可用于测试人员在和交互并加载区别内容时操作

　　WebKing 扫描结果报告可用于分析区别违背现象原因和解决方案以下列举了几种常见违背现象

　　重复 ID

　　HTML 代码中所有元素都应有个 ID对于用来识别 HTML 页面上元素辅助技术来说ID 应该是惟否则就会产生混乱无法确定哪个才是正确元素对于 HTML 的类静态代码来说很容易遵守这点但对用 JavaScript 生成动态代码来说则会很困难在这种情况下必须用某种思路方法保证每次都产生区别 ID图 16 显示了种有关重复 ID 解决方案每次页面加载时JavaScript 都会生成 “hide details” 按钮每个按钮都加个数字作后缀来实现惟 ID