济南盈讯科技有限公司

26. 可访问性测试

序言

web 可访问性测试是易用性测试的子集之一，这种测试是针对那些使用互联网的方式受到残障影响的用户的。对于易用性和可访问性两者而言，最终目标都是探求人们怎样才能轻松利用网站以及反馈那些可以改进设计和实施的信息。

可访问性评估通常比易用性测试更为正式。法律和公众舆论倾向于不歧视残障人，为了公平对待所有公民，政府和其它一些组织致力于遵循各种网站的可访问性标准，如美国联邦政府制订的 Section 508 法案和 W3C 的 Web 内容可访问性指南（WCAG）。

然而，重要的是区分符合标准和最大化网站可访问性之间的差别。在最理想的情况下，两者是一致的，但是任何给定的标准仍可能无法做到：

 

• 满足所有残障人士的需求
• 平衡不同残障人士的需求
• 用最佳技术与那些需求相匹配
• 使用明确的语言表达需求或技术

这些弱点可能会导致有些人带着美好愿望却误入歧途，并且可能被追求官样文章而忽略产品可用性的人所利用。

此外，互联网可访问性是一个目标，而不是一个是/否的设置，这是一种人类需求和技术之间的关系。正如我们了解人类需求的演变，以及技术对这些需求的不断适应，可访问性的环境要求也将改变，现行标准也会过时。不同的网站，不同的网页，采用不同的技术服务于不同的需求。像 Skype 这种语音聊天方式对盲人来说是极好的，而 video 视频聊天则是手语用户的一种福利。

在解决一种产品如何轻松使用的问题时，残障人士是一个特殊的问题，这是因为他们在用户和评估者之间引入了额外的经验差距。可访问性评估必须考虑在不同的情况下对网络的体验会如何，这些不同的情况包括不同的感官意识和认知能力，以及为了使网络更贴近人们特别是残障人士而采用的各种独特的配置选项和专业软件。

在你试图评估网站的易用性或可访问性时，把自己设想为正使用网站的青少年电影爱好者或是 50 岁的银行经理都有困难，更别提把自己设想成残障人士了。但是，要是青少年电影爱好者正好是个聋哑人并且需要观看电影的字幕时该怎么办？如果那位 50 岁的银行经理正好是盲人，而且他为了与自己的桌面环境和网络浏览器交互，正在使用对于评估者来说是陌生的特殊技术（如屏幕阅读器）时又该怎么办？

可访问性的指导方针和工具有助于弥合这些经验的差距。然而，由于需要传神的想象力、创新的技术以及同用户交谈，这些指导方针和工具也只能作为一种补充，而不是替代品。

本文中，我将从建立正规的一致性和使可访问性最大化两方面来讨论网页可访问性的评估办法。本文的结构如下：

• 测试应当在什么时候进行?
• 了解你的要求
  • 外部需求
  • 一致性细节
  • 超出预期
  • 用户界面的重要性
  • 残障人士角色
  • 选择一种可访问性标准
  • 法律的精神
• 应该由谁来测试?
• 专家测试
  • 半自动化可访问性检查工具
  • 结构检查
  • 检查和使用终端用户辅助技术
  • 详细检查
    • 可感知性
    • 可操作性
    • 可理解性
    • 健壮性
• 用户测试
  • 招募测试者
  • 实际的考虑
  • 选择任务
  • 解释结果
• 对可访问性测试结果进行沟通
• 总结
• 练习题

测试应当在什么时候进行？

一位资深软件工程师说过：“尽早测试，经常测试”。在开发过程结束后跟踪测试结果存在两种风险：

1. 项目往往是既超时又超过预算的。由于这些压力，常常使测试变得既仓促、又大意，或者直接被忽略掉。
2. 在一次开发过程中，修复后来才发现的问题与从一开始就把事情做对相比，需要更多的工作量。

因此，要确保质量和节省时间与金钱，可访问性评估应该从最初设计产品时就启动，并且延续到随后的反复开发过程之中直到最后交货。

了解你的要求

在你开始评估一个可访问性项目之前，你需要确定在既定环境、意向受众和资源的情况下，对于该项目来说有哪些关键要求。有些要求将由第三方如政府和客户来设置；还有一些你可以自己来选择。

外部需求

通常需求都来源于外部，例如：

• 政府。这类需求通常采取立法的形式来禁止歧视残障人士，而并非通过规定某种特定标准或列举出详细的一致性要求。一个重要的例外是当法律强制公共部门执行某一标准时的情况。例如，Section 508 是美国联邦立法条款之一，该法案规定了为联邦机构制作的网站必须符合至少一套具体定义的要求。WAI 的关于 Web 可访问性的政策页面提供了一份类似法案的不完整清单。但是，如果想得到一份关于你司法责任的权威声明，请咨询律师。
• 客户政策。例如，壳牌公司目前正在努力确保他们的网站符合 WCAG 1.0 的 “AA” 一致性级别，所以如果你正在为其开发一个网站，你就需要（至少）满足相同的标准。
• 营销工具。符合特定的标准，如 Section 508 法案，可能有助于向那些关注可访问性的顾客销售一个项目。
• 你所在机构的内部可访问性政策。例如，英国广播公司（BBC）制作的项目需要遵守 BBC 的可访问性指南 v1.3 标准。

一致性细节

获取尽可能明确的外部需求是很重要的。一些可访问性标准可能有一个以上的一致性级别或类型，所以敲定哪个是必需满足的级别就显得尤为重要了。例如，WCAG 1.0 有三个一致性级别：

1. 对未通过“A”级的 HTML 文档来说，残障人士“将无法访问信息”。
2. 对未通过“AA”级的 HTML 文档来说，残障人士“将难于访问信息”。
3. 对未通过“AAA”级的 HTML 文档来说，残障人士“将稍微有点难于访问信息”。

WCAG 2.0 草案也有三个级别，但一致性的可能情况变得更加复杂。但凡某种资源是某个过程（例如一个在线商店的产品查找、产品选择、结账以及购买确认）中一系列资源的其中之一时，该系列中所有资源的一致性级别就是级别最低的那个资源的级别。

一致性要求必须建立在“支持可访问性”的内容技术基础之上。作为一种支持可访问性的内容技术，这种技术必须满足以下条件：

• 已经被证实可以与用户的辅助技术一同工作。
• 具备可与用户辅助技术一同工作的用户代理（浏览器、插件等），并可为残障用户提供与无残障用户相同费用的服务。

请注意，在内联网环境中，你可以保证所有用户都将获得这些用户代理，但你无法保证同样的情况能发生在互联网上。例如，某个应用程序可能在无任何商业技术的条件下仍然可用，但却只能被含有某个商业插件的屏幕阅读器所读取，使用该插件需要一个针对某个机构的企业内部授权。当该应用程序部署在该机构的内联网之中时，它可能符合 WCAG 2.0，但当其部署在公共网站之上时则无法符合 WCAG 2.0。

WCAG 2.0 还承认受限的一致性声明。如果提供了一种可访问的替代品，某种原本不可访问的资源就能够符合可访问性的规定。如果页面内容是由其它来源所综合得到的，发行商则可以发表一项部分一致性的声明。

超出预期

确定外部需求只是可访问性测试的开始；外部需求应被视为最低要求的集合，应当在此集合的基础上添加进一步的目标，以使可访问性最大化。作为可访问性的评估者，你的职责就是要引起更多对可访问性的关注，因为你是这个领域的专家。

在提交最终报告时，你可能需要区分两种情况。例如，某家网上超市的忠实客户可能会提到，他们想要一家对盲人用户来说可访问的商店。考虑到目标人群，你还应该评估该商店对其它残障人士是否也可访问。

请注意，遵守特定标准的外部需求不一定非得禁止从其它现行标准中获得最佳的实践指南。例如，你可能会为某联邦机构对一个为老年市民服务的网站进行评估，并且还要求该网站遵守 Section 508 法案。Section 508 法案规定了：

§ 1194.22 (c) 网页内容设计若使用颜色来传递信息，也应同时提供不使用颜色来传递信息的方式，例如从上下文或标记中获得信息。

这一条款可帮助那些知道如何定制网页内容外观的用户，但并没有在建议的颜色之间确保具足够的对比度，从而为目标受众提供可访问性最大化的默认外观内容。幸运的是，并没有什么东西能够阻止一个网站履行这一要求，并且同时符合来 WCAG 2.0草案中的以下条款：

1.4.3 对比度（最小值）：文字和文字图片的色彩对比度应至少在 5:1 以上，除了以下几项：（AA级别）

• 大型印记：大型文字和文字图片的色彩对比度应至少在3:1以上；
• 附带的内容：对那些无效的用户界面组件的文字或文字图片没有最小对比度要求，因为那是纯粹的装饰，是附带的图片内文字，或者说任何人都无法看到的。

注：可以通过在网页上或从页面内控制对比度而满足 1.4.3 和 1.4.6 条款。

1.4.6 对比度（增强型）：文字和文字图片其色彩对比度至少在 7:1 以上，除了以下几项：（AAA级别）

• 大型印记：大规模文字和文字图片的色彩对比度应至少在 5:1 以上；
• 附带的内容：对那些无效的用户界面组件的文字或文字图片没有最小对比度要求，因为那是纯粹的装饰，是附带的图片内文字，或者说任何人都无法看到的。

注：可以通过在网页上或从页面内控制对比度而满足 1.4.3 和 1.4.6 条款。

通过对比度限制，该标准意在说明你应该提供一种提高颜色对比度的办法。

WCAG 2.0 正在设计之中，它将会具有对其它标准（特别是 WCAG 1.0 和 Section 508 法案）的高度向后兼容性。

用户界面的重要性

想想看，使一个网站的用户界面易于访问有多重要。即使内容无法以合适的形式来访问，一种可访问的用户界面也可以帮助用户确定感兴趣的内容，并通过一些外部帮助使其转换为他们能使用的形式。例如，一个听觉有障碍的人可能会提出，某个视频共享网站的视频讲座没有字幕。然而，由于 URL 是该视频的唯一标识，而且他们使用播放器观看视频，所以他们可将其提交给第三方，如免费的 readOn 项目服务，来制作字幕。

残障人士角色

一个理想的办法是在项目中将关键残障人士正确创建到其它用户角色中：在考虑那些特殊类型的用户如何使用一个网站时，采用虚构的用户作为原型。假设你正在评估某个视频共享网站的设计原型，其中的角色包括：

• 23 岁的 James Smith，一位足球迷，特别想与朋友分享体育要闻。
• 34 岁的 Sarah Maddison 是一位职业母亲，她可能一般没有时间进入视频共享网站。但是她 3 岁的女儿很热衷于观看视频，并且莎拉想坐下来帮她女儿找到她想要观看的合适影片。

你可以采用这些角色并将残障人士纳入其中，包括（例如）：

• 视力受损人士。
• 色盲人士。
• 失明者。
• 耳聋者。
• 听力障碍者。
• 聋盲者。
• 癫痫。
• 阅读障碍者。

举例来说，你可能会决定，James 同时也是聋哑人，并希望将比赛录像的评论做成字幕，Sarah 视力低下，她阅读花式字体和微小文字很费力。这些角色会指导你拒绝那些在无字幕条件下，视频播放器就无法提供服务的设计原型，或那些在需要图片的地方使用复杂的文本标题的设计原型。

WAI 的残障人士如何使用网页和 Shawn Lawton Henry 的试问：如何在整个设计中整合可访问性的理念包含了更多受残障影响的角色的例子，可以让你轻松上路。

虽然没必要说明，但我们不能假定残障人士是可以互换角色的。残障的表现形式非常多，并且，除了残障之外，残障人士也具有无残障人士所有的各种差异，（例如）不同的性别、年龄、兴趣、价值观念和技能（也许与他们的计算机操作技能最相关）。

同样，与可访问性指南相对比，产品可以帮助填补角色所没有涉及到的空白。例如，也许你正遵循 WCAG 2.0 来创建视频共享网站，但角色中未包含一位癫痫用户。然而，你可以通过阅读指南2.3（“癫痫发作：不要设计那些众所周知会引起癫痫发作的内容”）来决定该系统必须能够在视频显示前防止其闪烁。

选择一个可访问性标准

如果你需要选择某个可访问性标准以引起整个团队对可访问性的关注，或仅仅是需要一个可访问性标准以在测试时指导操作，我想建议你看一看 WCAG 2.0，因为它：

• 是围绕着适用于除 HTML 和 CSS之外技术（如 Flash）的人类核心需求所设计的。
• 详细列出了每个一致性标准的原因。
• 为了满足一致性标准，提出了用当前技术实现的实际技巧。
• 确保了每一条款均可测试。
• 包含了比目前替代品更新的研究。
• 其设计广泛符合现有的可访问性标准。
• 将是一个国际标准。

你可以援引 WCAG 2.0 的某个特定草案；然而，出于市场营销的目的，最好也使其符合已完善的标准，如 Section 508 法案和 WCAG 1.0。

法律的精神

在依照指南进行测试时，重要的是要领会所有具体技术指导意见的基本原理：必须遵守法律的精神，而不仅仅是法律的文字。

下面是一个警示故事。Section 508 法案（§ 1194.22）包括一项规定，即：“任何非纯文本元素均应提供相同意义的文字说明（例如：通过在元素内容中使用 alt，longdesc）”。同样的，WCAG 1.0 也包括了如下的检查点：

为每个非纯文本元素提供一个相同意义的文字说明（例如：通过 alt，longdesc，或元素内容）。这包括：图片、图形化表示的文字（包括符号）、图像映射区域、动画（例如：动画 GIF），小应用程序和程序性对象、ASCII艺术字符、框架、脚本、用作列表项目符号的图片、空白、图形按钮、声音（通过或不通过用户交互播放）、独立的音频文件、视频的音轨，以及视频。

可惜的是，许多阅读指南的人误解了该条款，而把修饰性元素与真正的文本等同起来，因而产生了类似这样的标记：

<img alt="fancy border" src="/fancy-border.gif" border="0">

事实上，由于这些图片不传递任何新的信息，也不具有功能，对于这些图片来说，等效的文本应该是空的字符串（alt=""），这样屏幕阅读器就会直接跳过 alt 属性，而不必读出来。不得不听着阅读器一遍又一遍地朗读 “fancy border” 这样的文字对于一个屏幕阅读器用户来说是非常郁闷的，因为这样的文本并不能为他们提供任何有用的信息。

WCAG 2.0 试图定义得更明晰一些。等同准则中规定：“除以下所列情况，任何非纯文本内容均应提供一个等同的备选文字信息。”这些情况之一是：“修饰、格式化、不可见的：如果是纯粹的装饰，或只用于视觉格式化，或如果它不会显示给用户，那么它可以以一种会被辅助技术忽略的方式来实施。”同样重要的是，WCAG 2.0 试图详细说明该准则背后的原因：

本准则的目的是确保所有非文本内容的文本也同样可以以文本方式获得。“文本”是指电子文本，而并非一个文字图片。电子文本具有独特的优势，即它在外观上是中立的。也就是说，它可以渲染成视觉上、听觉上、触觉上或其任何感官组合上的形式。因此，电子文字信息可以采用任何能最好地满足用户需求的形式来提交给用户。它也可以很方便地被放大，或者以一种易于理解的语音读出来，或被渲染成可以最好地满足用户需求的任何触觉形式。

应该由谁来测试？

进行测试的人基本可以分为两组：专家和用户。

专家测试是很重要的，因为专家懂得基本的网络技术是如何互相作用的，可以担当关于不同用户群的知识的采播中心的任务，并且愿意学习专用的测试工具。

用户测试是至关重要的，因为用户在其自身能力和自身辅助技术方面是真正的专家。用户测试还可以揭示不同技术水平的用户之间、熟悉当前网站的人（如专家测试者本身）和不熟悉当前网站的人（新用户）之间的可用性的差距。

知道如何使用屏幕阅读器的网页开发人员不可能与一般的屏幕阅读器用户一样；对于会编写自己的脚本程序的屏幕阅读器用户来说，他们也不可能与那些仅仅利用计算机来做象写邮件这类的普通任务的屏幕阅读器用户一样。

用户测试过程中获得的知识可在下一次测试中反馈到专家测试流程中（无论是在同一项目上的另一次测试，还是一个完全不同的项目）。用户测试还有一个更微妙的优势。通过使最终用户与开发员会面，可以增加创建可访问性网站的动力。

专家测试

专家测试有四个组成部分：

• 工具引导评估：指的是运用工具寻找可访问性问题并将其提交给评估者（这包括可访问性校验工具和代码检查工具）。
• 筛检：在这一部分中专家将模拟最终用户的网站体验。通常你不需要进行深入钻研来发现可访问性问题。你可能只需要在浏览器中打开网页，就会注意到某些文字非常难于阅读。
• 以工具为基础的检查：在这一部分中，评估者将使用某种工具来调查网站的各个部分如何共同工作。
• 代码检查：在这一部分里，评估者将直接查看代码和网站资源以查找问题。

虽然初学者可能特别依赖于工具引导评估，但是，各种经验水平的评估者都可以从每一个组成部分中获益。甚至于初学者也可以在 HTML 标记内发现缺少同义文字说明的 img 元素，而当你获得更多的经验时，在你进展到更严格的测试之前，就可以更快的发现问题。对于从事更大项目的专家们来说，手动审查所有的客户端代码或检查网站的所有部份可能是不可行的，但是工具引导的评价却能够找到值得进一步研究的特殊问题区域。此外，人类评估者可能会忽略掉机器所发现的问题。

不幸的是，虽然有很多的可访问性工具，但其中大多数是存在这样那样的缺陷的。例如，一种在 HTML 文件中列出标题的工具犯了未在 img 元素中包含 alt 属性的错误。正如你应该牢牢记住法律的精神和标准一致性，你也应该记得工具是有缺陷的。在向某人抱怨某项可访问性问题之前，先确定这是一个真正的问题而不是一个工具错误。

半自动化可访问性校验工具

一旦已经修复了第一次看到的问题，下一步就是将该网页扔给一个半自动化可访问性校验工具。如果你正在评估与特定标准的一致性，你可能会想要选择一个专门为你所使用的标准所设计的半自动化可访问性校验工具。

如果你正在评估与 Section 508 法案或 WCAG 1.0 的一致性，Cynthia Says 是一个不错的选择。如果你正在针对德国 BITV 1.0 Level2、意大利 Stanca 法或 WCAG 2.0 草案进行测试，目前唯一的选择是测试版的 ATRC Web Acc 可访问性校验工具。

这些工具有很大的局限性。没有类似于全自动化的可访问性测试。例如，鉴于目前人工智能的原始性质，计算机程序对一些文本是否真正的与上下文中的一张照片等同没有最后的发言权。即使那些理论上可以完全自动化的区域，校验工具程序员也可能会在诠释可访问性指南时犯错误，或是丢失法律文字下所代表的精神。

良好的工具会检查网页的可访问性问题，并生成一份它认为是错误的列表，以及另一份它认为值得人们去研究的问题。例如，如果 Cynthia Says 发现 img 元素带有 alt=""，就会发出警告（而不是发出一个错误！），指示用户“确认此图片只用于补白或设计，或不具有意义。”如果与那张图片等同的正确文本是一个空字符串，你就可以继续查看下一错误或警告。

也许可访问性校验工具的最大优势是，如果你选择了一个工具，比如说 TAW 3，该工具可以同时检测多个 URL，你就有可能找到需要进一步检查的网页大集合。

结构检查工具

许多检查工具的设计目的是探测网页内容的结构。结构，简单来说，就是界定一个网站有哪些组成部分，以及它们之间的相互关系如何。例如，在 HTML 文档对象模型（DOM）中，文字可以通过 label 元素被指定为一个表单域的标签。浏览器将 HTML 解析成一个文档对象模型。该浏览器会将各种行为与特定的组成部分联系起来。例如，如果你按一下复选框的标签，通常它们就会被勾选。

桌面环境和应用程序通过支持屏幕阅读器、语音识别软件及其他辅助性技术，来提供与可视情况下相同的结构与内容。在 Windows 环境下，主要结构系统称之为微软主动式辅助（MSAA）或 Vista 上的用户界面自动化。例如，一个对话框上含有一系列相关的子元素，如对话框的标题、区域、按钮和它们的标签等。

典型的辅助技术主要是从这些结构系统的角度来处理浏览器和插件对网页内容的表示的，而并非直接处理网页文件对象模型。

有些检查工具既可检查桌面级别的结构又可检查网页级别的对象模型。在桌面级别方面，OS X 配备了可访问性检查工具和可访问性核查工具。Microsoft 提供了 Microsoft Active Accessibility 2.0 和 Microsoft Active Accessibility 1.3 的检查工具。Accerciser 工具可用于 GNOME 辅助技术－SPI API。

查看（X）HTML 文档对象模型的工具，包括在 Opera Dragonfly 和 Firebug 中的 DOM 检查，和可访问性工具包，如专用于网络浏览器和 Opera 的 Web 可访问性工具栏以及 ICITA Firefox 可访问性工具栏。

DOM 检查工具显示了构造（X）HTML 的元素和属性以及文本树，而 web 可访问性检查工具则提取特定的组成部分或关系，并将其列表说明。例如，它可能会列出所有的表单域及其标签，或全部的标题，或是全部的链接。

如果你认为某种浏览器将正确的（X）HTML 结构向辅助技术描述得不够正确，那么你也可能会想要调查这一层次，但是通常对于（X）HTML 来说，挖掘可访问性模型不是必要的。相反，通常你会直接检查（X）HTML 结构。

并非所有的内容都可以用 DOM 或 Web 可访问性检查工具来检查。检查那些内容插件（媒体播放器、Flash 内容和 Java 小应用程序）所使用的可访问性辅助技术也是非常重要的。

一般情况下，你应该检查是否所有的控件都在模型之内扮演适当的角色（举例来说就是，文本框就是文本框，按钮就是按钮）并具有必要的属性。

调查和使用最终用户辅助技术

调查涉及在测试时模拟残障人士的体验。这种调查可能使用辅助技术与一个网站交互，或试图以某种方式限制一个人的能力。例如：

• 当测试键盘可访问性时，使用一个口含棒来按键。
• 采用色盲模拟工具来（Vischeck simulator）观看网页，该工具会显示出那些带有不同形式色盲的人士所看到的网页和其中所包含的图片。
• 关闭显示器，同时配合浏览器使用屏幕读取器。

调查可以帮助开发人员创建对残障人士需求的评定，还可以揭示基本的设计缺陷。使用辅助技术可以消除某些关于支持或不支持 web 交互标准的误解。举例来说，流行的屏幕阅读器没有用为 aural 或 braille CSS 媒体类型所推荐的样式，而是试图去描述可视化浏览器所显示的 screen 类型。

使用辅助技术不是一项可以掉以轻心的任务，因为如果要很好地了解如何使用该系统，就需要某种程度的投入和培训。此外，还存在一种制造新误解的严重风险。开发人员可能会努力地想要对某种屏幕阅读器进行一些处理，并且臆断该屏幕阅读器在某方面还有不足，但这其实反映了他们对这种工具缺乏专业知识。他们可能会尝试以错误的方式使用工具，例如尝试按顺序读取一个网页，而这种情况下，一个真正的屏幕阅读器用户会利用标题和其他元素跳来跳去地寻找自己感兴趣的内容。换句话说，他们也可能无法正确阅读屏幕。使用屏幕阅读器仔细阅读一个你可以用肉眼看见或很了解的网页，同探索一个你无法看见的全新网站是有很大差异的。

辅助技术的使用需要依据用户在日常生活中运用该技术的经验，并且由此获得的经验总结理想情况下应该通过专家用户所确认。整体说来，初学者最好将辅助技术的使用留给用户测试者处理。

细节检查

一旦所有由你选定的检查工具所确定的真实问题已得到修复，你就可以进入手动测试、探索并回顾该项目阶段了。

WCAG 2.0 将其最佳实践标准分为四个原则。网页内容和功能必须是：

• 可感知的（例如，图像应该有文本对应体）。
• 可操作的（例如，用户应该可以不用鼠标也能与某个网站进行交互，并且可以通过屏幕阅读器来进行导航）。
• 可理解的（例如，正文不应该比它需要的更加复杂，且网站应以可预测的方式来运行）。
• 健壮性（例如，不同的用户代理能够一起使用网站，且导航应该是一致的）。

在这一节中，我将提出一些实例，说明测试专家可以怎样对网页内容与上述原则的一致性进行评估。请注意本节并不能代替对 WCAG 及其技术的综述。

可感知性

可感知性问题的子集之一是围绕着对各种类型的媒体提供替代内容而展开的。你可以通过在浏览器中关闭图像和多媒体技术并查看网页来测试文本对应体。但是，你需要特别关注 img 和 input 元素。通常情况下，建议你将所有纯粹装饰性图像的 alt 属性设置成空白（alt=""），从而使屏幕阅读器直接跳过它们。然而，在下述情况下：

• 图像是链接的唯一内容
• 表单按钮

如果给这些因素设定 alt="" 属性的话，屏幕阅读器通常就会按照 alt="" 属性缺失的情况来对图像或按钮进行处理，并会试图提供一个属性值（例如，通过读出图像的网址）。

因此，在这些特殊情况下，你应当确保链接或按钮内的图像具有 alt 属性，以说明链接的目标或按钮的动作，即使这样做有点啰嗦。

对与多媒体同步的替代内容的测试，如字幕和音频描述，可以通过对媒体播放器参数进行挖掘，从而显示出可访问性设置而达成。

另一组可感知性问题涉及到对网页进行样式化。这里有三个需要调查的方面：

• 该页面的建议外观的可访问性很高吗？举例来说，是否有足够的色彩对比度？文本大小是否看着比较舒服？除了自己一个人对着网页眯眼，你可以使用诸如 Juicy Studio CSS 分析器之类的工具，这些工具可以依照某些度量易读性的公式来检查背景色和前景色的组合。
• 发布者提出的外观建议能否切实地与普通用户的参数相结合？这些参数旨在使页面内容更易读，比如增加字体大小、放大和使用各种缺省颜色。试着通过约 2-5 个步骤来增加文字大小;不必担心结果在像素上是不是完美的，而应关心布局是否被破坏了，从而导致内容难以阅读。试着改变你的颜色参数，看看会发生什么。如果发行商的 CSS 设置了颜色，它应该是将背景和前景色一起显式地指定的，以确保独特的用户偏好和发行商样式的结合不会导致无法阅读或出现不可见的文本。流行的浏览器允许用户实施他们自己的色彩偏好，并关闭 CSS 背景图像。如果你自己如此尝试的话，就会发现错误的 CSS 图像置换技术使得文本不显示在屏幕上，因为虽然图像不会被载入，但文字仍会看不见。
• 如果发布者的外观建议被弃置不用，那么所有由该建议表达的信息是由用户代理的默认样式还是由用户自定义样式来显示的？不妨尝试关闭 CSS，并检查文档对象模型，校验标题是否标记为标题，表格是否被用于没有布局的表格化数据。

可操作性

虽然很少被考虑到，但对于提高网站的可操作性来说，健康和安全是至关重要的一部分。闪烁性内容具有触发光敏性癫痫的风险。你可以对正在使用中的网站进行屏幕捕捉，并将其提交给跟踪中心光敏性癫痫分析工具（PEAT）以测试该页面是否具有可能对用户造成危险的闪烁内容。显然，如果你要创建一个视频共享网站，这是一个特别值得关注的问题。在产品设计阶段，你可能得在网站中包含一个自动化的上传筛选程序。

除此之外，提高一个测试网站可操作性的最好办法，就是去观察你是否能够使用不同设备访问所有的基本内容和功能：

• 试着只用键盘使用你的网站。当前的焦点总是清楚地指示出来了吗？所有的功能都可以通过键盘获取吗？
• 试着以触摸屏设备使用你的网站。
• 试着通过 Windows 版的 Opera 及其语音附加组件，或 Windows Vista 语音识别及 IE，用语音命令对网页进行导航（注：商业的语音识别软件最近已经以 MacSpeech Dictate 的形式引入到 Mac OS X 中，但目前在免费的 *nix 平台上还没有对应产品）。

屏幕阅读器和其它辅助技术可以充分利用 （X）HTML 语义结构来正确地关联内容，并启用内容导航。例如，屏幕阅读器可以让用户跳转到下一个出现的标题或其它元素类型，也可以列出某一特定类型发生的所有事件。正确使用 label 和 legend 元素可以让辅助技术将标签关联到正确的表单域上；正确使用 th 元素和 header、scope 和 axis 可以让辅助技术把表格标题和表格数据单元格关联起来。语义结构可以用 Opera Dragonfly 中的文档对象模型（DOM）检查工具来进行评估。像 Firefox 可访问性扩展之类的可访问性检查工具可以使工作变得更容易，例如，可以通过列出网页上的标题，或列出表单域的属性（快速地显示出哪些缺失了相关标签）来实现。具体示例参见图 1。

图1 ：BBC 新主页的 Firefox 可访问性扩展信息的屏幕截图。

可理解性

评估可理解性比评估易读性更加主观。除非评价者对一个项目不熟悉或是一个专业校订者，否则其他人也许不是评估正文可理解性的最佳人选。然而，你可以使用 Juicy Studio 易读性测试工具来得到网站的正文有多简单的一个粗略概念。

不过，客观说来，有些方面是高度客观可测试的，例如内容是否具有语言元数据，以使（例如）屏幕阅读器和语音浏览器用正确发音将页面内容读出来。对于 HTML，你可以使用一个 DOM 检查工具检查某份文档中的 lang 属性是否存在以及每一种语言的变化。

留意网站中不一致的地方，无论从内部一致性角度还是从来自于互联网公共惯例的可预测角度都可以。每次只能看到一页中部分内容的屏幕放大镜用户极大地依赖于这种一致性，这样他们才能知道在哪里可以找到特定的内容和功能。

健壮性

测试页面内容是否健壮涉及到检查技术的使用是否正确。在非常基础的水平上，你可以用下面这些工具来检测标记和代码，如：

• 启用了警告的 WDG HTML 验证器
• W3C 的 CSS 验证器
• JSLint 的 JavaScript linter

接下来，你可以对代码进行深入检查，以检验功能是否得到了正确使用。例如，你可以检验是否用的是 HTML 原装控件，而不是那些含有无意义元素和 JavaScript 的伪造控件，并且你还可检验 JavaScript 是否在可能范围内尽量使用了特征检测而不是浏览器嗅探法。

然后，你就可以在多个用户代理和辅助技术情况下进行测试，检验该网站是否是可感知的，可操作的，并且是可理解的，无论发布者 CSS，JavaScript 和插件的组合是怎样的，也不管这种组合是启用还是禁用的。

最常见的问题可能是生硬的 JavaScript，比如，网页中的锚记和按钮实际上却要依赖于 JavaScript 才有效。还有更微妙的问题，这些问题产生于 JavaScript 与技术堆栈中其他层次过于紧密的耦合。例如，JavaScript 可能应用 CSS 的 display：none; 来隐藏内容，但在没有应用发行商 CSS 的情况下，又会发生什么呢？

另一个例子是就多媒体控件。通常，当插件内容被包含在内时，该插件的原始用户界面会被禁用，并且该插件会由脚本化的 HTML 窗口小部件所控制。只有经过基于 JavaScript 的插件检测后，插件的内容通过 JavaScript 得以添加时，它才会运转正常。但有时插件的内容包含在预制脚本状态的页面内。在这种情况下，就不仅要检验以确保该网站包含了一种防止正在进行处理的插件无法使用的备选方案，还要检验以确保该插件的原始用户界面在 JavaScript 被禁用的情况下依然可运行。如果前者的情况并非如此，那么用户根本不会看到备选方案的内容；如果后者不为真，那么用户将可以看到该插件，但却无法控制它。

用户测试

开发员的检查和筛选再多，都无法取代用户和网站的原始冲突。由于难于了解 web 内容和辅助技术之间的所有微妙的相互作用，而且难以准确地估计残疾人用户的体验，用户测试对于残障用户来说就更重要了。如果可能的话，你应该让真正的残障用户来测试你的网站。规模庞大而昂贵的用户测试可以做到这一点，但也不要低估小规模用户测试所能带来的好处。

招募测试者

测试者通常可以象你寻找易用性测试候选人一样的办法去寻找（例如通过广告和中介机构）。当地的残障人士组织应该可以推荐适当的论坛以招募测试对象。

测试实际上也是工作，因此最好能提供报酬。对用户测试而言，大约 70 美元一个小时的报酬是很常见的。

你可能可以找到愿意免费对小型项目进行测试的人员。在你的朋友、亲戚和同事之中会有一些残障人士。此外，还有一些致力于软件的可访问性问题的在线讨论小组，如：

• WebAIM Accessibility Discussion List。
• Web Accessibility Initative Interest Group Mailing List：一个讨论 Web 可访问性相关问题的论坛。
• British Computer Association of the Blind mailing list：讨论视障人群的信息通讯技术（ICT）。
• Magnifiers Yahoo! Group.
• 该Email地址已收到反垃圾邮件插件保护。要显示它您需要在浏览器中启用JavaScript。 :一份针对 JAWS 屏幕阅读器用户的邮件发送列表。
• GW-Info:一份针对 GW Micro Window-Eyes 屏幕阅读器用户的邮件发送列表。
• Dolphin software users Yahoo! Group.
• NVDA users mailing list.
• Thunder users mailing list.
• 该Email地址已收到反垃圾邮件插件保护。要显示它您需要在浏览器中启用JavaScript。 ：使用 OS X 的盲人名单。
• 该Email地址已收到反垃圾邮件插件保护。要显示它您需要在浏览器中启用JavaScript。 ：苹果 VoiceOver 用户.
• Blinux-list：使用 Linux 的盲人和视障人士用户论坛名单。
• GNOME Orca users.
• Ai Squared Forums:包括流行的扩视放大镜的用户。
• Deaf-Macs Yahoo! Group:专门针对聋人、听觉障碍者及其教员或聋盲人的 Mac 用户。
• deaf-uk-technology Yahoo! Group ：聋人相关技术讨论

这些小组通常都欢迎来自于 web 开发员关于他们网站的可访问性或特定技术的提问。

实际的考虑

请记住，测试环境本身也应该是可访问的。例如，如果你正准备笔试材料，你必须同时准备提供这些笔试材料的替代品。在常规的测试区域中，复现用户浏览环境的后勤工作非常复杂，所以在用户的家中测试可能更切合实际。如果做不到这一点，远程测试也是极有用的。

对于用户所熟悉的技术的特殊考虑，可能对残障用户来说，比其他用户更为重要。辅助技术能给他们的计算机体验添加多层次的复杂性，从而在新手计算机用户和老手计算机用户之间产生大的分歧，并将用户划分成不同的团体，这些团体可能对他们自己的配置非常熟练，而对不熟悉的技术则会十分困惑。（想想那些没有残障以影响到自己对计算机的使用的用户在 Mac 和 PC 之间切换是多为难啊！）

如果你找到一个长期使用 Window-Eyes 屏幕阅读器的用户，而让他坐在一台安装了对他来说很陌生的 JAWS 屏幕阅读器的机器前，并请他来测试一个网站，那么，到底是他对 JAWS 的使用有问题还是对网站的使用有问题，将会变得非常难于区分。即便你提供了 Window-Eyes，由于版本之间存在着显著的差异，以及用户可能会自定义设置，这些情况仍可能使区分问题变得很困难。有鉴于此，除非你正好在专门测试网站的可访问性在陌生的设置（例如在图书馆内或朋友的电脑上）下能有多好，否则最好还是允许用户采用他们自己的设置进行测试，或者尽可能接近这种设置。

同样，除非你要专门测试新手用户或专家用户，否则你就应该选择那些对使用自己的当前设置访问网络大约有一年经验的用户。不管是辅助技术还是网络自身的协议都是不容易学会的。选择新手用户，你将不知道问题是出自于你的网站还是学习过程中的固有问题，专家们则可能有其他人所没有的技巧。

选择任务

即使是对用户探索某个网站时进行观察，也可以得到令人难以置信的启发。正如其它任何的用户测试一样：

• 尝试为用户设置一些具体的需要完成的任务。
• 询问他们的想法，倾听他们的发言。
• 关注他们所做的事情，因为这可能有别于他们所说的话：偏好陈述是行动的最差指南。

在设计网站时，你需要把重点放在那些用户希望要于完成的事务上，而不是他们所需要使用的特殊控件上。同样，在进行可访问性测试时，你所制定的任务应该（至少在开头的时候）反映出使用网站的访问者的真实目的，而不是专注于他们与特殊控件之间的交互。这些事务对于有或没有残障的人来说通常是类似的。

例如，如果你正在测试一个视频共享网站的可访问性，不要在一开始时就询问他们是否可以使用特殊控件（“这是音量滑块。你可以调整音量吗？”）。相反，给他们一些情景，并请他们完成关键用户任务。例如：

• 浏览视频并选择一个去播放。
• 搜索视频。
• 上传视频。
• 暂停视频、播放视频、使视频静音、取消视频静音、快退和再次播放视频。
• 评估视频。
• 与朋友分享视频。

以这种方式，你很可能会发现很多预料之外的问题。例如，屏幕阅读器用户可能无法找到搜索框或视频控件。相反，用户可能已经有导航策略来处理甚至连你都不知道的网页。

解释结果

在理想的环境下，我们可以测试各种可能的组合，并且从每个人身上得到反馈。但在现实中，时间和金钱会限制用户测试。有鉴于此，反馈可能是一把双刃剑。虽然它可以教会你很多，但也存在着过于重视某个人的看法的危险，某个人的看法可能对更多的目标受众不具有代表性。例如，某些屏幕阅读器用户倾向于寻找一个为盲人用户简化了的体验；另一些则急于知道有关他们的非盲人朋友和同事所看到的网站的一切。

这就是像 WCAG 这样的可访问性标准真正获得承认的原因。通过遵循这样的指南，你就比较可能创建出即使那些无法测试到的用户群也可以得到满足的基本可访问性。

当你在观察问题，分析问题产生的原因时。例如，你的视频共享网站包含一个显示热门影片数据表的网页，各栏包括定格画面、标题、上传日期、上次播放日期、总体评价，并以视频目录的形式排列在横排组内。在用户测试方面，屏幕阅读器用户可能无法使用数据表。这可能反映了：

• 网站代码有问题。举例来说，也许是开发人员用的是毫无意义的 div 元素来创建数据表，而不是使用正确的数据表标记。在这里，适当的做法是对表格重新编码。
• 对于部分用户缺乏专门知识。例如，JAWS 用户可能不熟悉 JAWS 的浏览和阅读数据表的特性。这里适当的做法是对不那么专业的用户提供补充文件或提示。如果专家用户也不能完成理想的测试目标，他们则可以成为很好的顾问。
• 用户代理有问题。例如，Safari 向 Apple 可访问性模型显示数据表时，是以一系列布局框的形式，而不是以一组数据关系的形式。在这方面适当的做法包括向用户代理发行商或开发商报告漏洞，研究一种能在该用户代理中起作用的技术，或注意文件方面的限制，并提供一些建议，告诉人们哪些用户代理的替代品能够正确浏览你的网站。
• 屏幕阅读器有问题。例如，开发者可能会使用 abbr 属性缩短表头长度，但屏幕阅读器可能无法阅读缩短后的版本。在这方面适当的做法包括向屏幕阅读器发行商或开发商报告漏洞，也可以是寻求一种能在该屏幕阅读器上起作用的技术，或注意到文件方面的限制，并提供一些建议，告诉人们哪些替代工具或导航策略能够正确浏览你的网站。

对可访问性测试结果进行沟通

在就可访问性评估的结果进行沟通时，应当精确地记录所评估的内容。如果你针对某个特定标准的一致性进行了测试，那么你就应该具体说明一致性在哪些方面做得好，在哪些方面做得不好。在提出问题的时候，请先用实在的，人性化的术语提问，并说明该问题可能会怎样对用户产生不利的影响。还要描述出如何重现问题并测试其是否已经解决的办法。还应当为实现一致性或改善可访问性推荐实用技术。

例如，你可能会像以下这样报告视频共享网站存在的某个问题：

• 问题：不使用鼠标悬停在菜单项目的顶部时，下拉菜单就无法打开，并且当你通过 TAB 键移动菜单时，键盘焦点会消失于屏幕之外。
• 如何重现：在浏览器内打开网页，并尽力试着仅使用键盘访问某个菜单的子项目。
• 说明：网站导航应独立于设备，因此，使用除鼠标之外设备的用户，如盲人用户或运动残障人用户，也可以访问内容和功能。目前，此类用户无法访问项目的子菜单，并且，当聚焦指示器出现时，使用键盘的非盲人用户可能会混淆。
• 一致性含义：键盘操作性是 WCAG 1.0 和 WCAG 2.0 一致性的“A”级的要求（见 WCAG 1.0 指南 9 和 WCAG 2.0 指南 2.1）。
• 建议的补救措施：当 JavaScript 无法使用时，可使用一简单的链接列表将导航的每个子列表链接到子页面上。并在这些子页面上，显示出带子列表的主导航栏。当 JavaScript 可用时，从 DOM 中删除子列表并为每个菜单项的子列表添加 click 事件，该事件可同样地由键盘、鼠标、语音识别和触摸屏所触发。

总结

并非每个网页都能得到专家们或付费测试者的可访问性评估。但是，任何网页开发人员都可以学习可访问性的原则，在代码中尽力贯彻这些准则，并通过邮件列表向用户发布其劳动成果，以了解进一步的问题，从而为未来的开发获取新知识。

练习题

• 试着不用鼠标来对你选择的某个复杂的网站进行导航。你遇到什么困难么？网站开发人员如何才能帮助你呢？
• 关闭 CSS，然后进行你每天的网页浏览。你遇到了什么问题？
• 关闭 JavaScript，然后进行你每天的网页浏览。你遇到了什么问题？
• 选择一个最喜欢的网站，为该网站设计一些角色，然后作为一个专家测试者来评估其是否满足 WCAG 1.0 和常规的可访问性。为一个网站设计一个用户测试计划，包括征募需求和任务以进行测试。写一份关于如何改善其可访问性的报告。

• < 上页
• 下页 >