基于Web的企业网和互联网的信息和应用( 1194.22 )

基于Web的企业网和互联网的信息和应用( 1194.22 )

原文更新日期: 2001年6月21日
原文地址: http://www.access-board.gov/sec508/guide/1194.22.htm

这些标准的规范由美国*提出的制作网页必须遵循的要求。除非这样做会增加过分的负担,否则必须适用这些规定。

符合规范的关键就是严格遵守这些条文。许多机构购买了辅助软件去测试他们的网页。这将有助于人们更加了解这些工具和不同的编码技术之间是如何互相影响的。然而,我们应该始终小心这些 辅助科技,如屏幕阅读器,它们是复杂的程序,而且需要花很大的精力才能掌握。因此,新用户可能会得到一个不准确的结果,而这个结果可以很容易导致挫折感,并且让人确信网页不符合规范。举例来说,所有屏幕阅读程序都是通过使用特定的按键组合去读取特有的编码表。如果使用它们的新手不知道有这些命令,不管编码表的格式多么标准,它们也将永远不会被适当的读取。如果一个网站符合1194.22 章节的第(a)至(p) 条款,它将符合508标准。注意,该文档中为符合某些特定条文讨论的提示与技术,并不是唯一遵守508规范的方式。在大多情况下,由董事会、教育部、司法部开发的技术,已被用户用广泛应用的屏幕阅读软件测试过了。随着技术的演变,其他技术可能变得很实用,甚至更出色 。


(a) 为每个非文本元素提供等同文字(例如,通过"alt","longdesc",或者在元素内容里)。

等同文字指什么?

等同文字是指增加文字去表现非文本元素的内容。这一条款规定,当一个图片暗示一个导航行为,如"移动到下一个屏幕"或"返回页面顶部",图像必须配有实际文本以表明它的 意图。该条款还要求,当图片被用来代表网页内容,图片必须配有文字描述来说明其意义。

HTML源代码:<img src="art/logo-green.gif" alt="Access Board Logo">

http://www.access-board.gov/

在等同文本中实际需要多少信息?

在可能的情况下,与非文本元素关联的文字信息应该传达与其关联元素的相同信息。例如,当一个图片指示一个动作,这个动作必须加以文字说明。真正需要文字描述的非 文本元素仅限于一些用于提供帮助理解内容的信息或者用于方便导航的元素。网页作者往往利用透明图片来获取空间。为它们增加的文字说明,将给屏幕阅读器的用户带来不必要的 困扰。对于这样的图片,空的ALT属性是有益的。

源代码示例: <IMG src="transparent.gif" alt="">

就本条款而言,非文本元素是指什么?

非文本元素是图片、图形、音频剪辑,或其他通过图片或声音传达意义的特性,包括按钮、复选框、图片和嵌入式或流式音频或视频。

HTML源代码: <img src="art/logo-green.gif" alt="Access Board Logo">

http://www.access-board.gov/

如何对待音频演示?

这一条款规定,当音频演示在一个多媒体网页里是有效的情况下,音频部分必须配以文字。音频是一个非文本元素,所以如果音频是多媒体演示的一部分,多媒体包括音频和视频,必须提供音频的等同文字。如果演示品就是音频 本身,文字记录将满足这一要求。

有什么方式可以把文字分配给元素?

有几种方法可以提供文字信息,以便其能够被辅助科技设备识别。例如,<IMG>标签可以接受“alt”属性让网页设计师可以直接在<IMG>标签内包含图片的文字描述信息。

HTML源代码: <img src=”image/ab_logo1.gif” alt=”The Architectural and Transportation Barriers Compliance Board emblem-Go to Access Board website”>

链接: http://www.section508.gov/

同样, Java的<APPLET>标签也有“alt”属性,但这仅适用于支持Java的浏览器。通常情况下,网速慢的用户会关闭Java applet。提供文字说明的一个更好的选择是简单地在<APPLET>或<OBJECT>标签之内引入替代 文字。例如,如果web设计者希望在网页中引入名为MyCoolApplet的applet,并且还包括一个关于该applet显示许多股票当前价格的描述,设计者将使用下面的HTML代码,例如:

<APPLET CODE="MyCoolApplet.class" WIDTH="200", HEIGHT="100">

这个程序会为许多流行的股票显示当前股票价格。

</APPLET>

最后,还用另一种方式来提供文字说明,就是把它列入网页的上下文中:

Below is a picture of me during my great vacation!
<p>
<IMG src="pictureofme.jpg">

Back


(b) 等同替代品应与多媒体同步展示

把什么视为等同替代品?

可把音频部分的字幕和多媒体演示的视觉信息的音频描述视为等同替代品。这一条款规定,当一个多媒体产品的音频部分配有字幕,基于( a )条的规定,字幕必须与音频同步。需要同步字幕,这样看字幕的人也可以看发言者和配合演讲的肢体语言。

如果一个网站提供的音频文件没有视频,一定要配上字幕?

不用,因为它不是多媒体。然而,由于音频是一种非文字的东西,必须有可用的等同文字,如笔录。同样,(无声的)网络幻灯片演示并不需要配有一个音频描述,但确实需要图形对应的替代文字。

如果一个联邦机构官员进行一个现场的音频和视频的直播演讲,需要字幕么?

当然,它具有一个多媒体演示的资格,并需要给演讲配上字幕。

例如:

美国人文基金会
www.neh.gov/media/scottcaptions.ram

National Center for Accessible Media (NCAM)
http://main.wgbh.org/wgbh/access/dvs/lion.ram

Back


(c) 网页应该被设计成,所有信息,有色彩可以传达,没有色彩也可以传达,例如通过上下文或标记。

为什么会出现这样的规定,有必要吗?

基于Web的企业网和互联网的信息和应用( 1194.22 )

在颜色被用来作为识别屏幕元素或控件的核心方式的时候,色盲患者、盲人以及低视力人群可能会不能使用网页。

这是否意味着所有的网页都必须显示成黑白的?

不,这个规定并没有禁止使用颜色去突出显示一些重要特性。但是,它要求必须有其他的识别方法联合颜色一起使用,如文字标签。这一规定不仅涉及用颜色强调文字的问题,而且还 涉及用颜色指示动作。例如,引导用户“按绿色按钮启动”的网页应该不单单使用颜色去标识那个绿色的按钮,还应该用一些其他的方式。

有没有什么方法可以快速地检查网页,以确保它遵守这一规定?

确定符合该规范,有两个简单的方法测试网页:在黑白显示器上浏览网页,或用黑白打印机把网页打印出来。这两种方法会很迅速地显示去除颜色是否会影响网页的可用性。

Back


(d) 应很好地组织文档,以便在没有关联的样式表的情况下也可以读取。

样式表造成什么样的潜在的问题?

样式表可以使用户定制特定的视图偏好以适应他们的生理缺陷。例如,低视力的用户可创建自己的样式表,这样,不管他们访问什么网页,所有的文字都会以一种超大的白色字体显示在黑色背景上。如果设计师建立自己的网页去覆盖用户定义的样式表,生理缺陷人士可能无法使用这些网页。因此,为了良好的访问性,设计师确保他们的网页不干扰用户定义的样式表是至关重要的。

一般来说, 最“安全”和最有用的样式表的形式,是“外部”样式表,它的风格规则建立在一个单独的文件里。 外部样式表的一个例子:

源代码示例: <link rel=stylesheet type="text / css" href="section508.css>

Back


(e) 应该为服务器端影像地图的每个活动提供冗余的文本链接。

“影像地图”是如何工作的?

一个“影像地图”是一张在网页上的图片(通常是实际地图),它根据用户点在图片的哪里,提供到相应网页的“链接”。有两个基本类型的影像地图: “客户端影像地图”和“服务器端影像地图”。对于客户端图像 
地图,在图片中,每一个“活动的地区”可以指派它自己的“链接” (所谓的URL或“Uniform Resource Locator统一资源定位器” ),在图片的一部分被选中时,该链接指定去加载什么网页。HTML允许每个活动区域有自己的替代文字,就像一个图片可以有替代文字一样(见§ 1194.22 ( a )项)。 相比之下,点击服务器端影像地图的一个位置仅仅指定了在图像内的鼠标按下时的坐标。链接或URL的最终选择必须可以由运行网页的电脑解释。

为什么会出现这样的规定,有必要吗?

当一个网页把服务器端影像地图作为可选的方式给用户展示的时候,浏览器无法给用户指明地区地图所激活的网址。因此,冗余的文字链接,为那些无法看到或者无法准确地点击在地图上的人们 ,提供对那个网页的访问,是必要的。

Back


(f) 应该提供客户端的影像地图而不是服务器端的影像地图,除非那些不能用几何图形来标识的地区。

为什么客户端的影像地图更具有可访问性?

不像服务器端的影像地图, 客户端的影像地图允许作者去为每个影像地图的“热点”添加文字。这个特性意味着用屏幕阅读器的人可以轻松识别并激活地图的区域。说明如何构建这些影像地图,将有助于弄清这个问题。

创建一个基本的客户端影像地图需要这几个步骤:

  • 为地图确定一张图片。首先,在客户端影像地图中必须使用一张图片。用<img>标签标识该图片,用“usemap”属性把它指定为地图。
  • 对地图内的“地区”使用<MAP>标签。<MAP>标签是一个容器标签,含有一系列用于确定图片具体部分的<AREA>标签。
  • 用<AREA>标签来识别地图区域。要在地图范围内确定区域,只需在<MAP>容器标签内使用<AREA>标签。使这个客户端影像地图具有可访问性,可简单的描述:在每个<AREA>标签内简单地引用“ALT”属性以及对区域描述的文字。
  • 以下HTML演示如何创建客户端影像地图:

<img src="navbar.gif" border="0" usemap="#Map">
<map name="Map">
<area shape="rect" coords="0,2,64,19" href="general.html" alt="information about us" >
<area shape="rect" coords="65,2,166,20" href="jobs.html" alt="job opportunities" >
<area shape="rect" coords="167,2,212,19" href="faq.html" alt="Frequently Asked Questions" >
<area shape="rect" coords="214,2,318,21" href="location.html" alt="How to find us" >
<area shape="rect" coords="319,2,399,23" href="contact.html" alt="How to contact us" >
</map>

Back


(g) 数据表的行标题和列标题应该被标识出来。

(h) 对于有两个及两个以上的逻辑行标题或列标题的数据表,应该用记号将数据单元格和标题单元格关联起来。

为什么需要这两个规定?

( g )和( h )允许使用表,但要求该表的代码符合用于创建表的标记语言的规则。如果一个人使用非可视化的方式访问网页,可能很难理解表里的大量数据。因为屏幕阅读器正在阅读的特定单元格 也许不能与相应的列标题和行标题关联起来,所以屏幕阅读器的用户可以很容易“迷失”在表里面。举例来说,假设工资表包括联邦雇员的各个级别和阶段的工资。表中的每一行代表一个级别和每一列代表了一个阶段。因此,要找第9级别,第5阶段的工资需要找在第九行和第五列的单元格。对于第15级、第10阶段的工作图表,表将有至少150个单元格。如果没有一个关联标题和各个单元格的方法,不难想象 辅助科技的用户将遇到的障碍。

1194.22章节的 ( g )和( h )指出,当以表格的形式来展示信息的时候,应使用适当的表格标签而不是用“<pre>”标签关联的预格式化的表 ,列出信息。网页作者还需要用一种方法来提供标题及其相关信息的联系。

HTML表格怎样才能被辅助科技读取?

在表里使用"Scope"属性 – 使用"scope"属性是使网页符合规范的最有效的一种方法,同时也是实现起来最简单的方法。在表头或数据单元格使用“colspan”或“rowspan”属性的表里,"scope"属性也与一些(但不是所有) 辅助科技合作愉快。

使用"Scope"属性 – 每个表的第一行应含有列的标题。典型的,尽管<TD> 标签也可以用,但是列的标题是放在<TH> 标签之间的。每列顶部的这些标签应包括以下属性:

scope="col"

通过这样简单的步骤,该单元格里的文字就和这列的每个单元格关联起来了。不像其他的方法(特别是“ ID ”和“headers” ),没有必要在每一个表的单元格里面包含特殊属性。同样,各表的第一列应包括识别的表中各行的标识信息。第1栏的每个单元格是由<TH>或<TD>标签创建的。这些单元格应包括以下属性:

scope="row"

通过简单的添加这个属性,在那个单元格的文本就和那行的每个单元格关联起来了。这个技术显著地提高了网页的使用性,同时,使用scope属性不会对不支持该属性的浏览器产生任何影响。

源码实例 – 下面的简表列出了三位员工的工作计划,并展示了scope的规则。

<table>
<tr>
<th>&nbsp;</th>
<th scope="col" >Spring</th> <th scope="col" >Summer</th> <th scope="col" >Autumn</th> <th scope="col" >Winter</th> </tr>
<tr> <td scope="row" >Betty</td> <td>9-5</td> <td>10-6</td> <td>8-4</td><td>7-3</td>
</tr>
<tr> <td scope="row" >Wilma</td> <td>10-6</td> <td>10-6</td> <td>9-5</td> <td>9-5</td>
</tr>
<tr> <td scope="row" >Fred</td> <td>10-6</td> <td>10-6</td> <td>10-6</td> <td>10-6</td>
</tr>
</table>

该表显示效果如下:

  Spring Summer Autumn Winter
Betty 9-5 10-6 8-4 7-3
Wilma 10-6 10-6 9-5 9-5
Fred 10-6 10-6 10-6 10-6

在非常大的表中用scope属性的效果是非常明显的。例如,如果一个机构用一个20行、20列的表,就有400个数据单元格。如果不用scope属性, 为了让该表符合该规范,将需要在400个数据单元格中写代码,再加上40个列标题和行标题。相比之下,用scope属性则只需要40个列标题和行标题。

在表中使用"ID" 和"Headers" 属性

不像使用"scope"属性,使用“id”和“headers”属性需要在表中的每个数据单元格指定要关联的属性。尽管浏览器支持的scope属性可能降低了它们在访问性方面的 优势,“id”和“headers”属性仍然非常有用而且为小表提供了一个有效的访问方法。

下表比前面的例子要复杂得多,先演示“id”和“headers”属性的使用,然后是scope属性。这两种方法都提供了满足网页中的数据表的要求的手段。在这个例子中,表包括两名员工的工作时间。每个员工有一个随冬季或夏季而变化的上午和下午的工作时间。每个“Summer”或“Winter”栏包括两个标示为“Morning”和“Afternoon” 的区域。因此,在每个单元格里明确着工作时间,用户需要知道雇员的姓名(Wilma 或 Fred),季节(夏季或冬季),以及时段(上午或下午)。

<table>
<tr>
<th>&nbsp;</th>
<th colspan="2" id="winter" >Winter</th>
<th colspan="2" id="summer" >Summer</th>
</tr>
<tr>
<th>&nbsp;</th>
<th id="am1" >Morning</th>
<th id="pm1" >Afternoon</th>
<th id="am2" >Morning</th>
<th id="pm2" >Afternoon</th>
</tr>
<tr>
<td id="wilma" >Wilma</td>
<td headers="wilma am1 winter" >9-11</td>
<td headers="wilma pm1 winter" >12-6</td>
<td headers="wilma am2 summer" >7-11</td>
<td headers="wilma pm2 summer" >12-3</td>
</tr>
<tr>
<td id="fred" >Fred</td>
<td headers="fred am1 winter" >10-11</td>
<td headers="fred pm1 winter" >12-6</td>
<td headers="fred am2 summer" >9-11</td>
<td headers="fred pm2 summer" >12-5</td>
</tr>
</table>

该表效果如下所示:

  Winter Summer
  Morning Afternoon Morning Afternoon
Wilma 9-11 12-6 7-11 12-3
Fred 10-11 12-6 9-11 12-5

为此表的单元格的“id”和“headers”属性的是要比使用“scope”属性复杂得多,如下所示:

<table>
<tr>
<th>&nbsp;</th>
<th colspan="2" scope="col" >Winter</th>
<th colspan="2" scope="col" >Summer</th>
</tr>
<tr>
<th>&nbsp;</th>
<th scope="col" >Morning</th>
<th scope="col" >Afternoon</th>
<th scope="col" >Morning</th>
<th scope="col" >Afternoon</th>
</tr>
<tr>
<td scope="row" >Wilma</td>
<td>9-11</td>
<td>12-6</td>
<td>7-11</td>
<td>12-3</td>
</tr>
<tr>
<td scope="row" >Fred</td>
<td>10-11</td>
<td>12-6</td>
<td>9-11</td>
<td>12-5</td>
</tr>
</table>

该表效果如下所示:

  Winter Summer
  Morning Afternoon Morning Afternoon
Wilma 9-11 12-6 7-11 12-3
Fred 10-11 12-6 9-11 12-5

summary属性是可选的?

虽然一些网页设计者极力推荐它成为一种总结表的内容的方式,但是TABLE标签的“summary”属性没有得到主要辅助科技制造商的充分的支持,不值得推荐。因此,那些对总结性表有兴趣的Web开发员,应考虑用Caption之类的标签将表的描述放在表的旁边或表的正文中。在任何情况下,Web开发员都不应该把总结性表当作能使表内容符合上文所述的一个选择。

Back


(i) 框架应配以文本标题,以便于框架的识别和导航。

为什么会出现这样的规定,有必要吗?

框架提供了一种方法,使计算机屏幕上直观地分裂成不同的可改写的区域。不幸的是,当这些框架不容易被辅助科技识别的时候,它们可能会残疾用户带来障碍。例如,框架的一种流行的使用方法是在屏幕的一个固定位置上创建“导航栏”,可以通过激活其中的一个导航按钮来获取网站内容。新的内容显示在屏幕的另一个区域上。由于导航栏不变,它为用户提供了稳定的“框架的引用”,使导航变得更加容易。然而,如果两个框架之间的区别不是很明显的话,残疾用户可能会迷失其中。

识别框架的最好的方法是什么?

满足这个需求的最明显的方法是在各自的框架主体区域内引入文本去明显的标识他们。例如,在导航栏的例子,Web开发员应该考虑在框架内容开始的地方放一些类似“导航链接”的词,让所有用户知道这个框架里面是导航链接。像这样在各自框架的内容顶部提供标题可以满足这些需求。机构应该考虑的一项补充措施是在<frame>标签的“title”属性中添加有意义的文字。尽管现在大部分辅助科技的厂商还不支持,“title”属性是HTML4.0规范的一部分,目的是让Web开发员在双引号内添加一个框架的描述。演示“title”属性的用法需要对框架如何构建有个基本的了解。当框架被用于网页中,加载的第一个页面必须含有<frameset>标签用以勾勒出网页的基本格局。在<frameset>标签内,<frame>标签指定各个独立框架的名字、初始内容、以及外观。因此,以下示例使用“title”属性 标识第一个框架“导航链接框架” ,以及第二个框架“内容框架”。

Example: ADA Technical Assistance Program - The use of frames with “No Frames Link”例如:反倾销协定的技术援助计划-使用框架与“无框架链接”

<frameset cols="30%, 60%">
<frame src="navlinks.html" name="navlinks" title="Navigational Links Frame">
<frame src="geninfo.html" name="contents_page" title="Contents Frame">
</frame>

虽然辅助科技还没有广泛支持“title”属性,我们建议在使用框架的网页中包括此属性。

例如: ADA Technical Assistance Program -框架“No Frames Link”的使用
www.adata.org

Back


(j) 网页应避免造成荧光屏在2赫兹与55赫兹之间的频段闪烁。

为什么会出现这样的规定,有必要吗?

这一规定是必要的,因为如果显示器忽明忽暗、闪光或闪烁不定,特别是在特定的频率范围内闪烁很强烈的话,患有光敏性癫痫的人可能会病发。2赫兹的限制被选为符合对ADA可访问性指南的建议修订版本,作为回报,该指南正与国际编码委员会( ICC )/ ANSI A117标准保持一致,“可访问的和可使用的建筑物和设施” ,ICC/ANSI A117.1 - 1998年引用了2赫兹限制。上限被确定为55赫兹。

如何鉴别闪光的或闪烁的元素?

闪烁的元素通常是通过,诸如动画GIF,Java applet,或第三方插件或应用程序之类的技术添加到网页中的。可以通过<APPLET>或<OBJECT>标签的存在与否来鉴别Java applet和第三方插件。动画GIF是一个图像文件中(像普通图像文件一样),但具有在很短的时间内变化的内容。然而,像其他的图片一样,它们通常包含于<IMG>标签中。

Back


(k) 当不能以任何其他方式遵守这些标准的规定的时候,应提供具有同等信息或功能的纯文本网页以符合规范。无论什么时候只要基本网页变化了,纯文本网页的内容应该更新。

为了符合该规范,纯文本网页必须含有什么东西?

纯文字的网页中必须包含基本网页的同等信息或功能。 此外,一旦基本网页变化了,纯文本网页就应该更新。

例如: Disability.gov在首页显示一个纯文本的网页

HTML 源代码: <div ID=”textonly”> <p><a HREF=”../textonly/default.asp”>Text Only</a> </p></div> 
链接: http://www.disability.gov/

Back


(l) 当网页利用脚本语言来显示内容或创造界面元素时,脚本所提供的信息应该用功能性的文字标出来,这样辅助科技就可以阅读。

脚本可以引发什么样的访问障碍?

网页作者有责任用一种方式提供脚本信息以便辅助科技能够阅读。 如果作者不把功能性文字和脚本放在一起,屏幕阅读器通常会阅读那些毫无意义的混乱的数字和字母的脚本源代码。尽管这种混乱的东西是文本,但是它不能被解释或使用。

Web开发人员如何能够遵守这一规定?

用JavaScript的Web开发员经常使用所谓的JavaScript URL的一种简单的方法来调用JavaScript函数。通常情况下,这项技术被用作<a>锚链接的一部分。例如,下面的链接调用名为myFunction的JavaScript函数:

<a href="javascript:myFunction();">Start myFunction</a>

对辅助科技而言,该技术不会造成访问性问题。如果开发者在没有提供关于图片的有意义的信息或者锚链接的效果的前提下就利用图片内部的JavaScript URL,那么更棘手的问题就产生了。例如,下面的链接同样也调用的JavaScript函数myFunction ,但是却要求用户点击一个图片而不是文字串“启动myFunction”:

<a href="javascript:myFunction();"><img src="myFunction.gif"></a>

上面所写的这种类型的链接带来了巨大的访问性问题,但这些问题可以很容易地得到纠正。 <img>标签,当然啦,支持“alt”属性,它可以用来描述的图片和点击链接的效果。因此,下面的修改补救了前面的例子所造成的访问性问题:

<a href="javascript:myFunction();"><img src="myFunction.gif" alt="picture link for starting myFunction"></a>

一些开发员所倡导的另一种方法是使用<a>标签的“title”属性。 例如,下面的例子在“title”属性里包括一个有意义的描述:

<a title="this link starts myFunction" href="javascript:myFunction();"><img src="myFunction.gif"></a>

并非所有辅助科技都支持这个标签。因此,尽管它是HTML 4.0的规范,作者应该在封闭的Image标签中使用“alt”标签。

最后,浏览器的状态栏(在屏幕的底部)通常显示任何鼠标当前指向的链接的网址。 例如,如果点击锚点链接,页面会迁移到http://www.usdoj.gov;如果用户的鼠标停留在锚点链接的上方,该URL就会显示在状态栏。在JavaScript URL的案例中,状态栏可能会充满无意义的脚本片断。为了防止这种影响,有些web开发人员会通过特殊的“event handlers” ,如onmouseover和onmouseout,用定制的消息覆盖状态栏的内容。例如,下面的链接将用“明智的选择”取代状态栏的内容。

<a href="javascript:myFcn();" onmouseover="status='Nice Choice'; return true;" onmouseout="status='';"><img src="pix.gif"></a>

屏幕阅读器难以或无法检测到被改写到状态栏里面的文字。 尽管改写状态栏不干扰JavaScript URL的访问性,web开发人员应确保所有在状态栏里的重要的信息也可以像上面那样通过“alt”属性来传达。

JavaScript把所谓的“event handlers”当作某种要发生的动作或功能的触发器。 例如,一个web开发者出于安全和完整性的考虑,可以在网页中嵌入JavaScript函数去自动检查表单的内容。将一个事件处理程序与一个“提交”按钮关联起来,这样在表单正式提交给服务器进行处理之前触发检查功能。对*机构而言,它的优点就是节省了*资源,因为不用*的服务器做初步检查。对计算机用户而言,其优点是几乎瞬间得到错误信息的反馈,因为在提交互联网之前用户就得到了错误信息。

在决定在他们的网页里应用哪些事件处理器时候,Web开发人员必须谨慎,因为不同的屏幕阅读器对不同的事件处理器支持程度不一样。 下表列出了一些关于许多比较流行的事件处理器使用的建议:

  • onClick – onClick事件在用户单击某一特定元素时触发。通常用于链接和按钮元素,并用于和这些元素的连接。它和屏幕阅读器配合得很好。如果点击带有OnClick事件的元素从而触发了一个函数或执行了其他一些行动,开发员应确保上下文能让所有用户明白会发生这样的事情。注意,除非绝对必要的,否则不要把OnClick事件用在有数个选项的表单元素上(例如,选择列表,单选按钮,复选框)。
  • onDblClick – onDblClick事件在用户双击某一元素时触发。除了它产生的访问性问题外,它很容易让用户困惑,应该避免使用。
  • onMouseDown 和 onMouseUp – onMouseDown事件和onMouseUp事件各处理一半的鼠标点击过程-(a)按下鼠标按钮和 ( b )释放鼠标按钮。像onDblClick一样 ,Web开发人员应当有节制地使用该标签,是否真的需要它,因为它是相当混乱。在大多数情况下,开发员应选择OnClick事件而不是onMouseDown事件。
  • onMouseOver 和 onMouseOut – 这两个事件在许多网站上非常流行。例如,所谓的翻滚图片,就是在鼠标经过图像时切换网页上的图像,通常两个事件一起用。 这些事件处理既不可以用鼠标访问也不干涉访问性-屏幕阅读器彻底地无视了他们。 因此,用他们的Web设计员应注意由这些事件通过其他方式提供的重复的信息(如果有的话)。
  • onLoad 和 onUnload – 这两个事件是网页已经完成装载或卸载时被用来执行特定功能。因为网页上的元素的任何用户接口都不能触发其中任何一个事件,所以他们不存在 访问障碍。
  • onChange – 在<select>标签的内部选项被选中时,经常用这个事件来调用Javascipt函数。意外的是,对屏幕阅读器而言,它存在巨大的访问性问题,应该避免发生。相应的,开发员应该用onClick事件(与在<select>标签旁边的链接或按钮关联起来的)去完成同样的功能。
  • onBlur和onFocus – 这些事件在网页中不常用。虽然他们不一定会带来访问性问题,但是他们的行为足以让网页访客困惑,应该避免使用。

Back


(m) 当网页需要applet、插件或者其他应用程序存在于客户端系统来解释网页内容时,页面必须提供它们的链接以符合§1194.22的第(a)至(l) 条款。

为什么这个条款是必要的?

虽然大多数Web浏览器可以轻松地阅读HTML和展示给用户,一些私人公司已经开发的专有文件格式,用于传输和显示特殊的内容,如多媒体或非常精确的定义的文件。 由于这些文件格式是私有, Web浏览器不能正常显示出来。 为了让这些文件能被Web浏览器阅读,加载项程序或“插件”可下载并安装在用户的计算机上,将使他们的Web浏览器有可能显示或播放文件的内容。这一条款规定,含有诸如Real Audio或PDF文件( Adobe Acrobat公司便携式文件格式)的网页提供一个链接到插件,以满足软件的规定。 对网页来说为插件提供链接是非常常见的。 例如,网页含有Real Audio文件的同时几乎总是有一个必须的播放器资源库的链接。这一条款规定网页作者有责任在需要插件之前知道存在一个兼容的程序。

如何才能让插件和Applet被检测到?

通常可以通过检查一个网页的HTML里是否存在一个<OBJECT>标签监测到插件。然而,一些插件生产商可能需要使用专有的标签。也可以像插件一样通过HTML源代码 中<OBJECT>标签的存在性来识别Applet。 此外,<APPLET>标签也意味着在网页里引用了一个applet。

Back


(n) 把电子表格设计成在线完成的时候,表单应该允许人们使用辅助科技来访问信息、域元素以及表单的完成和提交状态的功能性需求,包括所有向导和提示。

为什么对于屏幕阅读器而言,电子表单代表障碍?

目前,表单控件与屏幕阅读器之间的相互作用是不可预测的,这取决于包含这些控件的网页的设计。当Web开发人员将表单元素及其相关标签或标题分开的时候,HTML表单就暴露出 访问障碍。例如,如果一个输入框是用来接收用户的姓名,那么web开发人员就必须小心那些“last name” (或类似的分开的文字)出现在输入框附近,或者以某种方式和输入框关联起来了。虽然这可能看起来像是一个明显的要求,却非常容易犯错误。因为表单元素视觉上很近并且标题也不能保证什么,以至于屏幕阅读器会将“last name”或者“name”与输入框关联起来,而这种关联对一个辅助科技的用户而言将是家常便饭。

下面的表单演示了这些问题。视觉上,这个表单是表的一部分,而且每个域被很小心的放在了他们相应的Label旁边的单元格里面(注意,用表格格式化的表单并不意味着这是表现表单固有的 访问障碍的唯一的形式;表只是清晰地演示了问题)。

虽然从可视化审查来说"First Name"或者"Last Name"标题和他们各自的输入框之间的关系是显而易见的,但是这个关系对于屏幕阅读器来说是不明显的。相反,当遇到各自的输入框的时候,屏幕阅读器可能单纯的宣布"输入框"。通过审查这个表格的HTML代码就会发现这些 障碍的原因。下面的代码是这个表格的简单版本。。

<FORM>
<TABLE>
<TR>
<TD><B>FIRST NAME: </B></TD>
<TD><INPUT TYPE="TEXT" NAME="FIRSTNAME"> </TD>
</TR>
<TR>
<TD><B>LAST NAME: </B></TD>
<TD><INPUT TYPE="TEXT" NAME="LASTNAME"> </TD>
</TR>
</TABLE>
<P>
<INPUT TYPE="SUBMIT" VALUE="SUBMIT">
</FORM>

这两对表单元素用粗体标示在上面了。由表格内部的表单元素排列产生的问题现在就清楚了-表格的格式化指令将表单元素和他们的Label标签给分开了。

开发者如何提供无障碍HTML表单?

第一个原则是把标签Label放到输入框旁边,而不是放到独立的表格的单元格里。HTML 4.0规范为不希望将表单元素紧邻其相应的标题的Web开发者提供了<LABEL> 标签,可以让Web开发者标示指定内容为“标签” ,然后把那个标签和表单元素关联起来。通常有两种方法使用LABEL标签:显式标签和隐式标签。

“显式标签" 效果明显
经验表明,显式标签与所有流行的辅助科技配合得异常出色,并建议在所有非常简单的表格中使用。我们建议,所有机构确保他们的网页开发人员都熟悉这些重要概念。使用“显式"标签包括明显的两步:

  • 使用<LABEL>标签并且设置"FOR"属性。换言之,明确标单的Label词句并用<LABEL>标签把它们括起来。用“FOR”属性唯一识别那个元素。
  • 在相关的表单元素中使用“ID”属性。每个表单元素都支持“ID”属性。通过设置此属性去标识中使用“FOR”属性关联的<LABEL>标签,你“捆住”那个表单元素及其相关的标签。举例来说,我们已经重写了form-inside-a-table的HTML源代码,包括显式标签如下。新的显式标签的HTML代码用粗体表示了:

<FORM>
<TABLE>
<TR>
<TD><B><LABEL FOR="first"> FIRST NAME:</LABEL> </B></TD>
<TD><INPUT TYPE="TEXT" NAME="FIRSTNAME" ID="first" ></TD>
</TR>
<TR>
<TD><B><LABEL FOR="last"> LAST NAME:</LABEL> </B></TD>
<TD><INPUT TYPE="TEXT" NAME="LASTNAME" ID="last" ></TD>
</TR>
</TABLE>
<P>
<INPUT TYPE="SUBMIT" VALUE="SUBMIT">
</FORM>

简而言之,这就是使HTML表单元素可访问的辅助科技。经验表明这项技术在非常复杂的、比较绕的表单里面表现非常出色,并且它也应该在所有机构的HTML表单中表现出色。

避免使用“隐式标签”
“隐式”标签,表单元素与其关联的标签是被包括在<LABEL> 开始标签和</LABEL>关闭标签之间。例如,在上表可以看出,一个隐式的标签把“First Name”与其输入单元格关联起来,我们可以像下面这样使用一个隐式的标签:

<LABEL>
<TR>
<TD><B>FIRST NAME:</B></TD>
<TD><INPUT TYPE="TEXT" NAME="FIRSTNAME"></TD>
</TR>
</LABEL>

经验表明,应避免隐式的标签,原因有两个。第一,许多屏幕读取器对隐式标签支持得不好,特别是,如果在同一网页上大量使用隐式标签的话,效果也不好。通常,输出可能非常不准确而且让人困惑。第二,如果任何文字 将标签和它关联的表单元素分开的话,隐式的标签就变得不切实际而且让人困惑,因为标签本身和表单元素已不再容易分辨。。

Back


(o) 应该为用户提供一种方法去跳过重复的导航链接。

为什么对于屏幕阅读器和其它类型的辅助科技来说,导航链接代表障碍?

本条款提供了一个方法,以促进易于跟踪网页的内容,为用户提供的辅助科技选择跳过重复的导航链接。Web开发者经常放置大量的日常导航链接于标准位置-通常布满上方、下方、或网页的一侧。如果非残疾用户返回一个网页,而且知道他或她想要查看特定页面的内容,不是选择一个导航链接转到另一个网页,取而代之,他或她可能只是看历史链接,并开始阅读所需的文字的位置在哪里。对于那些使用屏幕阅读器或其他类型的辅助科技的人,但是,它可能是一个乏味费时的苦差事去等待辅助科技检查并宣布每个标准导航链接在到达预定位置之前。为了缓解这一问题,508规范规定,当重复导航链接的使用,必须有一个机制,让用户跳过重复的导航链接。

例如:美国农业部目标中心和劳工部的网站使用跳过重复导航链接。

http://www.usda.gov/oo/target.htm

http://www.dol.gov/dol/odep/

Back


(p) 当响应时间是必要的时候,应提醒用户并给予足够的时间来提示需要更多的时间。

为什么对于残疾的网络用户来说,响应时间代表麻烦?

可以用脚本来设计网页,这样,如果在一定时间内没有接到响应的话,网页就消失或者“过期”。有时这个技术是为了安全或减少提供Web服务的计算机的需求。某些人的残疾可以直接影响他或她在阅读, 移动,或填写网页表单时的速度。例如,视力非常低的人的阅读速度可能会低于正常人。在他能够看完前,页面可能就“超时”了。很多表单,当他们“超时”的时候,同时也会自动删除填写的任何数据。结果那些输入比较慢的残疾的人士不能够完成那个表单。出于这个原因,当响应时间是必要的时候,应通过确认框提醒用户并给予足够的时间来提示是否需要更多的时间。

例如:节俭储蓄计划
www.tsp.gov

上一篇:mysql 导出数据导致锁表


下一篇:mysql多线程插入速度与不同数据库之间的比较