Web 2.0应用程序最佳实践-web应用程序

随着Web 2.0的日渐普及，Web 2.0应用程序的可访问性对开发者提出了越来越高的要求，应用程序可访问性是指为残障人士扫除使用障碍。在使用电脑时，有些用户也许无法看见或无法移动鼠标，或者会面临很多其他困难。

IBM在产品的可访问性方面有着悠久的历史；让应用程序能够被最广泛的客户群使用具有良好的商业意义。因此，IBM承诺将支持世界级规范和标准的技术带给残障人士。

附加测试，也称为可访问性验证测试（AccessibilityVerificationTesting，下文简称为AVT），被用于确保产品符合这些可访问性标准。AVTChecklist是一个检查点列表，支持可访问性的产品需要遵守这个列表。该列表是根据世界级可访问性标准生成的，如USsection508和W3CWebContentAccessibilityGuidelines（下文简称WCAG）。在本文中，我们将通过一些简单的例子来解释检查列表中一些基本的、重要的项目。我们将分享如何对一个Web 2.0产品规划和执行AVT的最佳实践。

背景

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

关于AVT的例子及信息都基于我们对Web 2.0应用程序的测试，支持Firefox3浏览器和JAWS10，因为有些属性，例如WAI-ARIA标记，只有使用特定的组件组合才能看到。

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

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

◆输入方式可选择：键盘、鼠标、语音，以及用于残障人士的设备；
◆输出方式可选择：显示、声音、打印，以及将图像提示转换成声音的用户界面元素；
◆一致性和灵活性：与颜色、字体等用户设置保持一致。

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

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

有些浏览器不支持图片，因此一些视力受损的用户看不到图片。因而为所有的图片提供替代文本就尤为重要，这能使所有用户都了解其信息。有了替代文本后，屏幕阅读器之类的辅助技术就可以以另一种方式传达图片的内容，根据WCAGSC1.1.1指南描述，所有非文本内容都应有alt文本属性。冗余的图片可将alt值设置为空，但有意义的图片应用有意义的语句设置。替代文本应当准确、简明。如下所示：

图1.非功能图片

1.1 非功能图片的alt内容为空

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

清单1.非功能图片的代码

<imgclassimgclass="lconnSpritelconnSprite-iconPriorityMedium16" 
alt=""src="/activities/javascript/dojo-ibm/dojo/resources/blank.gif"/>

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

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

图2.重要的图片

清单2.功能图片的代码示例

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

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

图3.功能图片

清单3.另一个功能图片的代码示例

<imgclassimgclass="lconnSpritelconnSprite-iconActivities16"dojoattachpoint="icon_AP"  
src="/activities/javascript/dojo-ibm/dojo/resources/blank.gif" 
alt="NormalPriority(Default)"/>

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

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

图4.多媒体的文字记录 #p#

2.适应性

通过UI呈现给用户的网站结构应该有一套替代方法来满足盲人用户的需求，通过UI展现给用户的信息、结构和元素关系应该能由程序控制或有替代文本。以下两个例子描述了确认UI上的表单之间的关系的方法。

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

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

图5.表单旁边有一个标签

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

<div> 
<labelforlabelfor="user">Username:</label> 
<inputidinputid="user"class="lotusText"type="text"name="j_username"/> 
</rdiv><div> 
<labelforlabelfor="password">Password:</label><inputidinputid="password" 
class="lotusText"type="password"name="j_password"/> 
</div>

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

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

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

清单5.使用“title”属性

<selecttitleselecttitle="AddRelatedActivity"style="width:530px;"size="5" 
name="target"dojoattachpoint="targetSelect_AP"/>

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

3.颜色

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

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

图7.颜色的不合理使用

图8.颜色的合理使用

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

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

4.键盘

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

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

WCAGSC2.1.1指出用户应当能用键盘导航到所有内容和功能，图10显示了一个关于键盘问题的例子。如果鼠标移动到用户名处，下方将会弹出一张卡片。用户单击弹出信息将打开整个名片。这整个操作过程都应当有为键盘用户设计的替代方法。这种情况下，快捷键就是一个不错的选择。例如，按下Ctrl+Enter将打开用户的名片。

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

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

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

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

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

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

图12.焦点的键盘问题

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

图13.下拉列表的键盘陷阱

5.高对比模式

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

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

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

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

<atitleatitle="Playanaudiofilewiththepronunciationoftheperson'sname" 
id="pronunciation" 
href="/profiles/audio.do?key=4815d70b-680d-4bfb-ba05-f32ccedbbcb5  
&amp;lastMod=1248147056328"> 
<imgsrcimgsrc="/profiles/nav/common/styles/images/blank.gif"class="lconnSprite  
lconnSprite-iconAudio16"/> 
<spanclassspanclass="lotusAltText">Pronunciation</span> 
</a>

6.其它问题

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

6.1定时调整

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

图15.具有定时调整的消息

6.2导航特性

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

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

<!--ThefollowinglinesarerequiredforAccessibilityandareusedbyscreenreaders.  
Pleasedonotremove--> 
<ahrefahref="#mainContent"id="lotusAccessLinkMainContent"accesskey="S" 
class="lotusAccess"> 
<imgsrcimgsrc="/activities/nav/common/styles/images/blank.gif" 
alt="Skiptomaincontentlink.AccesskeyS"/> 
</a> 
<ahrefahref="#tabNavigation"id="lotusAccessLinkTabNavigation"accesskey="1" 
class="lotusAccess"> 
<imgsrcimgsrc="/activities/nav/common/styles/images/blank.gif" 
alt="Skiptotabnavigationlink.Accesskey1"/> 
</a> 
<ahrefahref="#subNavigation"id="lotusAccessLinkSubNavigation"accesskey="2" 
class="lotusAccess"> 
<imgsrcimgsrc="/activities/nav/common/styles/images/blank.gif"alt="Skipto  
subnavigation.Accesskey2"/>

#p#
可访问性认证测试

现在您已经了解到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都会生成“hidedetails”按钮。每个按钮都加个数字作后缀来实现惟一的ID。

图16.重复ID示例

清单8.为动态生成的代码设置惟一ID的代码

<aidaid="showMore_1"class="lotusActionlotusNowrap"href="#" 
onclick="showDetails('1');returnfalse;" 
style="display:none;">showdetails</a> 
<aidaid="hideMore_1"class="lotusActionlotusNowrap"style="" 
href="#"onclick="hideDetails('1');returnfalse;"> 
hidedetails</a>

ALT文字和标签—表单关系设置

这些问题经常会发生，这就是第一步要执行WebKing的原因。在这个阶段，要检查所有图片的alt属性是否设置、对象间的关系是否设置。如果还没设置的话，您将收到警告，并且您应该在进入下一阶段前修复这些问题。

并不是所有违背现象都会成为真正的问题。以重复ID为例，有些隐藏对象不会显示给用户，只是供分析脚本使用。这种类型的问题可在WebKing中设置为禁止报告或看作报告中的例外。

屏幕阅读器—JAWS

屏幕阅读器主要针对视力受损的用户。它能帮助用户使用耳朵而不是眼睛来导航整个页面。它还能帮助识别用户界面中的所有元素及其关系。当使用JAWS听取UI内容时，有一些快捷键可用来打开“Linklist”、“headlinelist”等内容。另外，还可以对JAWS设置阅读配置，如是否读出链接的上下文、标题或alt内容等。如果要进行设置，打开JAWS主面板，选择Utilities>ConfigurationManager>SetOptions>HTMLOptions。图17显示的是设置面板。

图17.JAWS设置

JAWS10可用于FirefoxVersion3或Microsft®InternetExplorer8来读取UI内容，因为二者都支持WAI-ARIA技术。用户能听到UI上的更多内容，如页面结构或对象关系，JAWS有两种模式可供用户听取UI内容。一种是VirtualPC光标模式，另一种是Forms模式。有时候这两种模式被简称为打开VirtualPC光标模式或关闭VirtualPC光标模式。当运行JAWS听取内容时，这两种模式的效果截然不同。VirtualPC光标模式为用户逐行读取文档或使用快捷方式读取。Forms模式让用户与控件交互并在可编辑控件中输入信息。这两种模式可用Insert+Z组合键切换。在VirtualPC光标模式下，用户无法在可编辑字段中输入任何信息，必须切换到另一模式才可以。

测试方法

对Web 2.0应用程序的AVT测试并不经常进行。但对于使程序符合W3CWeb检查列表却十分重要。以下是AVT方法的最佳实践。

◆AVT应当在所有的主要UI更改完成后进行，因为大的UI变更会引入新的元素或更新已有元素的属性。

◆AVT应当在UI冻结（freeze）前完成。在该阶段发现的问题会导致UI更改，这将造成元素属性改变，应当确保在不出意外的情况下修复问题。如果项目对UI更改的签入有最后期限，应该在最后期限之前完成AVT。

◆Webking被更多地作为单元测试工具使用，而不是在AVT阶段使用的工具，特别是用于静态扫描。应当在完成WebKing静态扫描并修复问题后再进行其他测试。

◆JAWS是个灵敏的工具。不同版本的JAWS对UI元素会读出不同的内容。这不仅出现在主要版本变更中，例如JAWS9和JAWS10，也出现在小的补丁包变化中，如JAWS10.0.512和JAWS10.0.1142。早期版本可能在读取ARIA属性方面存在bug，后期版本则没有。因此，识别JAWS版本也是一项重要工作。

◆ARIA是用于Web 2.0应用程序的一项很好的技术。该技术定义了很多属性帮助用户识别UI中元素的结构和含义。该工具还可为您节省大量工作，例如，在aria-sort属性中，您可以使用很长的一句话来设置排序链接的标题，告诉用户是降序还是升序排列。使用aria-sort属性，用户可以用一个常用单词来设置标题，或添加aria-sort=ascending/descending来确定排序的模式。

◆有时测试人员很难确定alt文本是否需要或能否设置为空。原则是如果有一种替代方法能让用户知道图片传达的信息，alt就可以设置为空。否则，应填入有意义的文字。

结束语

AVT是产品生命周期中一个重要阶段。每个产品都有其不同的实现方法并且都应符合WCAG检查列表。本文描述了一些基本而重要的检查点以及测试工具。请现在就学会这些技巧并运用到您的测试过程中吧。

【编辑推荐】