【Web】Web内容可访问性指南 1.0
译文：Web内容可访问性指南 1.0
http://www.junchenwu.com/WAI/wai-pageauth.html原文：Web Content Accessibility Guidelines 1.0
http://www.w3.org/TR/WAI-WEBCONTENT注意：
本文档的英文版为唯一正式版本
本文档为中文翻译版，译者尽量与原著保持一致，错误和不妥之处欢迎指正
著作权声明：http://www.w3.org/Consortium/Legal/copyright-documents.html
译者： 吴隽辰（Junchen WU）[ [email protected] ]时间：初次定稿 2006-02-02 / 最后更新 2006-02-05
[目录] [检验点]
Web内容可访问性指南 1.0
W3C推荐标准 1999年5月5日
当前版本: http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505( 纯文本, PostScript版本, PDF版本, HTML版tar/gzip压缩包, HTML版zip压缩包)最新版本: http://www.w3.org/TR/WAI-WEBCONTENT上一版本: http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990324编者:Wendy Chisholm, Trace R & D Center, University of Wisconsin -- Madison
Gregg Vanderheiden, Trace R & D Center, University of Wisconsin -- Madison
Ian Jacobs, W3C
Copyright © 1999 W3C (MIT, INRIA, Keio), 版权所有. W3C 免责条款, 商标, 文档使用许可和软件使用许可都适用于本文档。
摘要
本文档介绍了如何使Web内容对于残疾人也具有可访问性。适合所有网站开发人员(页面架构和网站设计师)以及编辑器开发者阅读。本文档的主要目的是促进可访问性的发展，并且，遵循这些指南可以使Web内容对所有人更加有用，无论使用什么用户代理(例如：桌面浏览器、语音浏览器、移动电话、车载个人电脑等等。)或者在条件限制的情况下使用(例如：嘈杂的环境、过暗或过亮的房间、或者是免提情况等等。)。遵循本指南也可以帮助人们更快的找到他们想要的信息。这些指南并非建议开发者不使用图片、视频等，而是解释如何让多媒体内容更加具备可访问性，并且有更多的使用者。
本文档可以作为可访问性法则和设计的参考文档，文中谈到的一些策略也涉及到互联网国际化和移动访问。但是本文专注于可访问性，无法完全将其他相关的W3C内容都叙述出来。请参考W3C移动访问主页和W3C国际化主页来获得更多信息。
本文档作为稳定版本，并没有提供各种浏览器支持情况等详细信息，因为它们更新地太快。不过，Web可访问性倡议(WAI)网站上提供这些信息(请参考[WAI-UA-SUPPORT])。
本文另附一份文档，按主题和优先权列出了所有的检验点。这些检验点都链接到本文档内部各自的定义。附录中涉及到主题包括图像、多媒体、表格、帧、表单以及脚本。包括一份检验点全表和一份检验点简表。
“Web内容可访问性指南 1.0 技术部分”([TECHNIQUES])是一份单独的文档，用来阐明如何贯彻各个检验点，详细讨论了每一个检验点，并且提供了很多例子，运用了超文本标记语言(HTML)、层叠样式表(CSS)、同步多媒体集成语言(SMIL)和数学标记语言(MathML)等相关技术。该文档也包含文档验证和测试的技术，以及一份HTML元素和属性的索引（技术上需要的）。该技术文档用来追踪技术的变化，所以更新比本文要快的多。注意，并不是所有的浏览器或多媒体工具都支持本文谈到的一些特性，尤其是HTML 4.0或CSS 1或CSS 2里的一些新特性。
“Web内容可访问性指南 1.0”是可访问性指南系列的一部分，都是由WAI发布的。该系列还包括“用户代理可访问性指南”([WAI-USERAGENT])和“编辑工具可访问性指南”([WAI-AUTOOLS]).
本文档的状态
本文档已被W3C成员及其他相关方面审阅，并已被W3C理事（W3C Director）批准为W3C推荐标准。这已经是稳定版本，可以被其他文档引用或者作为正式的参考材料。W3C制定推荐标准的任务是使之受到关注，并促使其被广泛应用。这将增强Web的功能性与互操作性。
本文档的英文版本是唯一正式版本，其他语言翻译版本请见http://www.w3.org/WAI/GL/WAI-WEBCONTENT-TRANSLATIONS。
本文档的一些已知错误请见http://www.w3.org/WAI/GL/WAI-WEBCONTENT-ERRATA。报告错误请发送邮件至：[email protected]。
W3C当前推荐标准和其他技术文档请查询http://www.w3.org/TR。
本文档是W3CWeb可访问性倡议的一部份。Web内容指南工作组的工作目标在工作组章程里可以找到。
目录
摘要
本文档的状态
1. 简介
2. 可访问性设计的主题
2.1 确保内容的良好呈现
2.2 使内容易理解与可导航
3. 本指南的组织形式
3.1 文档约定
4. 优先级
5. 一致性
6. Web内容可访问性指南
1. 为视听的内容提供同等的文字替代
2. 不要仅依靠色彩来提供信息
3. 适当使用标记语言和样式表
4. 阐明自然语言的使用
5. 创建编排良好的表格
6. 确保页面能够在新技术下良好呈现
7. 确保使用者能处理时间敏感内容的改变
8. 确保嵌入式用户界面具有直接的可访问性
9. 设备无关的设计
10. 使用过渡的解决方案
11. 使用W3C推荐的技术和规范
12. 提供内容引导信息
13. 提供清晰的内容导航机制
14. 确保文档内容的清晰与简单
附录 A. -- 验证
附录 B. -- 术语表
鸣谢
参考资料
另附检验点全表和检验点简表。
1. 简介
对于那些不熟悉网页设计可访问性问题的人，要考虑到许多用户可能有与自己非常不同的操作习惯:
他们可能无法容易地，或者根本不能看见，听到，拖动或处理某些类型的信息。
他们可能在阅读或理解原文上有困难。
他们可能没有或者无法使用键盘或鼠标。
他们可能只有纯文本的屏幕，小屏幕，或低速网络连接。
他们可能并不会说或不能通畅理解文档所用的自然语言。
他们可能眼睛，耳朵或手正忙碌或受某些事物的干扰（比如在开车上班途中，在一个喧闹的环境下工作，等等）。
可能使用早期的浏览器，完全不同的浏览器，语音浏览器，或不同的操作系统。
内容开发者必须考虑到页面设计过程中这些不同的情形。当要考虑若干种情况时，每种可访问性设计的选择通常使一些疾病类型的残疾病人立刻受益并融入整个网络。例如，通过使用样式表控制字体，废弃FONT元素，HTML作者对页面的控制将加强，页面对视力障碍的人群更具可访问性，通过共享样式表，还将减少所有使用者的页面下载时间。
本指南讨论了可访问性问题并提供可访问设计解决方案。每一条都针对特定的场合、特定的残疾（和字体样式的例子类似）可能产生的问题来解答。例如，第一条解释了内容开发者如何使图像具备可访问性。有些用户可能无法看到图像。有些可能使用基于文本，不支持图像的浏览器，有些可能关闭了图像支持（例如由于低速网络连接问题）。 并不是说要避免使用图像来提高可访问性。相反的，解释了为什么替代文字将使使图像具备可访问性。
替代文字是如何提高图像的可访问性的？替代文字中每个字都是重要的：
文本内容可能会被呈现为合成语音、盲文、和视觉播放文本。这三种机制每种都利用不同的感觉——合成语音利用听觉，盲文利用触觉，视觉播放文本利用视觉——使得信息对于那些存在各种感官或其他残疾的人们没有访问障碍。
为了有效，替代文本必须能传达图片同样的功能或目的。比如一张从外太空观察地球的拍摄图片的替代文字，如果图片的目的主要是为了装饰，那么“从外太空看到的地球照片”这样的文字就可以实现所需要的功能；如果照片的功能是为了举例说明世界地理的特殊信息，那么替代文字应当传达这种信息。如果设计这个照片是为了告诉用户通过选择图片（比如点击它）来获得关于地球的信息，那么替代文字应当是“关于地球的信息”。因此，如果这段文字为残疾人传达的功能或目的，与图片给其他用户提供的功能目的相同，那么就可将其视为同等的替代文字。
要注意的是，除了使残疾人用户受益之外，同等的替代文字可以帮助所有用户更快地找到页面，因为当索引页面时搜索引擎机器人可以利用这些文字。
网络内容开发者必须提供图片和其他多媒体内容的同等替代文字，相应的，用户代理（比如浏览器和诸如屏幕阅读器，盲文显示等的辅助功能）有责任为用户表达这些信息。
文字的非文字等同替代（例如，图标，预先录制的语音或者将文字翻译为手语的视频）能使那些访问文字有困难的人可以访问文档，这些人包括许多存在认知残疾，学习残疾的个体和聋人。文字的非文字等同替代对于无法阅读的人也有帮助。听觉描述就是视觉信息非文字等同替代的一个例子。多媒体演示的听觉描述可以使得不能获得视觉信息的人从中受益。
2. 可访问性设计的主题
本指南主要处理以下两个主题：保证内容良好呈现，使内容易理解与可导航。
2.1 保证内容良好呈现
通过遵循这些指南，内容开发者可以制作出内容良好呈现的页面。简介中提到的任何情况，包括身体上的、感觉上的和认知上的残疾，工作限制，和技术壁垒，这些页面都具有良好的可访问性。以下是保证页面设计良好呈现的几个关键因素：
将结构与表现分离（请参考内容，结构与表现之间的区别）。
提供文字（包括同等的文字）。文字可以被绝大部分浏览设备渲染，并且对几乎所有用户都具有良好的可访问性。
提供同等的信息（如音频、视频或其他感觉辅助功能）服务于盲人或聋人，这并不意味着需要为盲人事先录制一个网站的音频版本来提高可访问性。盲人可以使用屏幕阅读器来阅读整个页面的文字信息。
不依赖于一种硬件平台。页面应该在任何情况下工作，比如没有鼠标、小屏幕、低分辨率、单色屏幕甚至无屏幕、只有语音或文字输出的条件等。
指南第1至11条处理本主题。
2.2 使内容易理解与可导航
内容开发者应该使内容易于理解并且可导航的。这并不仅仅要求语言上的清晰与简单，而还需提供易于理解的页面导航机制。提供导航工具和位置信息能够极大的提高可访问性和易用性。并不是所有人都能使用图片映射(image map)、成比例的滚动条、框架页，或者是用来引导桌面图形浏览器用户的图片。有些人可能只能逐词阅读（如语音合成或盲文显示），或者一次只能看到一部分内容（如小的显示区域或放大显示），他们可能很容易就失去了上下文的联系信息。没有位置信息，用户可能难以理解巨大的表格、列表、菜单等等。
指南第12至14条处理本主题。
3. 本指南的组织形式
本文档包含十四条方针，或者说是可访问性设计的基本原理。每条包括：
序号。
综述。
导航链接。包含下一条方针（向右箭头）、上一条方针（向左箭头）和当然方针在目录中的位置（向上箭头）。
基本原理和谁受益于此。
检验点定义列表。
每条方针后的检验点定义解释了在特定情况下方针的应用情况。每个检验点定义包括：
序号。
综述。
优先级。[优先级 1]已经通过样式表高亮显示。
其他资料信息，例子和其他相关方针或检验点的链接。
技术文档([TECHNIQUES])的链接，进一步讨论检验点的执行和例子。
每个检验点都试图解释的非常清楚，这样访问者可以明确页面或网站是否达到该检验点。
3.1 文档约定
本文档遵循以下约定：
元素名都为大写字母
属性名为引号小写字母
定义链接用样式表高亮显示
4. 优先级
W3C工作组按照检验点对可访问性的重要程度，赋予每个检验点一个优先级。
[优先级 1]Web内容开发者 必须满足该检验点。否则部分人或团体将无法获取文档中的信息。该检验点是使得部分人或团体能访问web文档的最基本要求。 [优先级 2]Web内容开发者 应该满足该检验点。否则部分人或团体将对获取文档中的信息感到困难。达到该检验点可以扫清相当数量访问web文档的障碍。 [优先级 3]Web内容开发者 可以采纳该检验点的要求。否则部分人或团体有可能对获取文档中的信息感到困难。满足该检验点可以提高web文档的可访问性。
一些检验点在某些（已指明）情况下，可能会改变优先级。
5. 一致性
本部分定义了一致性的三个级别：
一致性级别"A"： 所有优先级1的检验点都满足；
一致性级别"AA"： 所有优先级1和优先级2的检验点都满足；
一致性级别"AAA"： 所有优先级1、优先级2和优先级3的检验点都满足；
注意：一致性级别被呈现为可读，以便于理解。
文档的一致性声明必须使用以下两种形式之一。
形式 1：指明：
指南的标题: "Web Content Accessibility Guidelines 1.0"
指南的URI: http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505
达到的一致性级别："A"，"AA"或"AAA".
声明的范围（如页面、网站或者指定的部分）。
例子 1：
本页面遵循W3C的“Web Content Accessibility Guidelines 1.0”,URI: http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505, 一致性级别“AA”。
形式 2：在一致性声明页面上包含3个W3C图标之一，并且链接到该图标所代表的声明页面。关于图标的使用请参考[WCAG-ICONS].
6. Web内容可访问性指南
第一条. 为视觉和听觉的内容提供等义的替代
一切呈现给用户的内容，包括视觉上和听觉上的，都需要提供功能上或目的上等义的替代。
虽然部分人无法使用诸如图像、电影、声音、Applets程序等技术，但是他们还是可以访问那些提供了等义替代内容的页面来获取信息。比如，一个链接到目录索引的向上箭头图片可以添加“返回目录”这样的替代文字。一些情况下，替代内容还需描述视觉内容（比如复杂的图表、布告板或示意图）或者听觉内容（比如用于教育的音频样例文件）。
本原则强调了为非文本内容（图片、预录制的音频、视频）提供等义文本替代的重要性。利用等义文本替代的好处，就在于它可以被绝大部分技术或工具通过不同方式呈现给具有各种障碍的残疾人。文字可以被合成语音或者被翻译为盲文，或者在屏幕、纸上以不同尺寸显示。合成语音对于盲人，阅读障碍，理解和学习障碍，以及聋人非常重要。而盲文也利于那些失去听觉和视觉的人，以及盲人理解内容。并且文字显示对于聋人和绝大部分web使用者都非常友好。
为文字内容提供非文本内容的替代（比如图片、视频和预先录制的音频），同样有益，特别是对那些没有阅读器或者有阅读障碍的人来说。在视觉呈现或者视频里，可视化动作（比如肢体语言、手语等）可能没有足够的声音信息来传达同样的内容。除非也提供口头描述，不然那些看不到视觉内容的人将无法获取其中的信息。
检验点:
1.1 对于所有的非文本元素，提供具有相同意义的同等的替代文字（如用"alt"、"longdesc"属性，或者在元素内容中提供）。 这些非文本元素包括: 图片，图片形式的文字（包括符号），图像映射（image map）区域，动画（如GIF动画），applet小程序和一些程序性的对象，ASCII图案，框架，脚本，列表的指示图片（list bullets），用来调整间距的对象（spacer），图形按钮，，声音（无论是否通过使用者互动来播放），单独的音频文件，视频文件的音轨以及视频。 [优先级 1]HTML中的例子：
为IMG，INPUT和APPLET元素提供"alt"属性替代文字，或者在OBJECT和APPLET元素里提供同等的替代文字。
对于较复杂的、"alt"属性无法完整描述的替代内容，比如图表，可以使用附加的描述。如利用IMG或FRAME元素的"longdesc"属性或者在OBJECT元素中加入链接，或者是增加一个描述链接。
对于图像映射，既可以使用在AREA上加alt属性，也可以在MAP元素中加入A元素（或其他文字）作为内容的一部分。
请参考检验点 9.1和检验点 13.10.
1.1 技术部分 1.2 对于服务器端的图像影射的每个有效区域，均提供额外的文字链接。 [优先级 1]请参考 检验点 1.5和 检验点 9.1. 1.2 技术部分 1.3 除非用户代理能自动地将视频信息的同等替代文字朗读出来，否则就应该提供听觉上的描述内容，以表达视频或多媒体呈现的重点信息。 [优先级 1]根据 检查点1.4为 听觉描述提供同步音轨。 关于视觉信息的文字替代请参考 检查点 1.1。 1.3 技术部分 1.4 对于任何时间性的多媒体内容（如电影或动画），都应该将等价的替代对象（例如字幕或视频的听觉性描述）与媒体播放同步化。 [优先级 1] 1.4 技术部分 1.5 除非用户代理能绘制出客户端图像映射链接的等义文字，否则就应该要为每个客户端图像映射的有效区域提供额外的文字链接。 [优先级 3]请参考 检验点 1.2和 检验点 9.1。 1.5 技术部分
第二条. 不要仅依靠色彩来提供信息
确保没有颜色的情况下，文字和图像都易于理解。
如果仅通过颜色来传达信息，那么无法辨别颜色的人和使用单色的或非可视发的显示装置的用户将无法获取信息。当前景色和背景色色调比较接近，使用单色显示器用户可能无法提供足够的对比度来显示它们，有颜色视觉缺陷的人也将无法获取信息。
检验点：
2.1 确保所有通过颜色传递的信息在无色情况下也可用。比如通过前后文或者标示理解。 [优先级 1] 2.1 技术部分 2.2 确保前景色与背景色的搭配组合，即使在色盲患者的眼中，或在黑白屏幕里，都具有充足的对比。[对于图片为优先级 2，对于文字为优先级 3]. 2.2 技术部分
第三条. 适当使用标记语言和样式表
使用结构化元素来标记整个文档。使用样式表来控制表现，而非表现层元素和属性。
使用标记不合理——没有按照规范——阻碍了可访问性。滥用表现层的标记（如使用表格来布局或者用标题h1-h6来增大字号等）会给用特定软件访问的用户造成理解和导航上的困难。此外，使用表现层的标记的文档结构也会使得其他设备理解困难。（参考内容、结构与表现之间的区别）。
内容开发者可能会为了适应某些旧的浏览器，而使用（或滥用）一些标记来达到某种想要的设计格式或特效。但是这样做可能会造成可访问性方面的问题，要考虑清楚这样子的页面设计是否比保证所有人获取文档信息还重要。
另一方面，内容开发者也不要因为有一部分浏览器和辅助技术无法正确处理，而把这些标签给供奉起来。比如说，在HTML里，对于表格状信息应该使用TABLE元素来标记，即使还有一些旧的屏幕阅读器无法正确处理那些相邻的文本。（参考检验点 10.3）。正确并且合适的使用TABLE来创建表格，使一些软件能够正确呈现这些表格而不仅仅是二维格子。（参考第五条）
检验点：
3.1 如果有合适的标记语言，就应该用标记来传递信息，而不是用图片。 [优先级 2]比如使用MathML来标记数学公式，用 样式表来格式化文字和布局。同样还要避免用图片来替代文字，尽量使用文字和样式表。参考 第六条和 第十一条. 3.1 技术部分 3.2 使用已发布发布的正式语法来创建文档。 [优先级 2]比如，在一个文档开始部分常包含一个已发布的文档类型声明DTD（如strict HTML 4.0 DTD）。 3.2 技术部分 3.3 使用样式表来控制布局和表现。 [优先级 2]比如用CSS的font来替代HTML中的FONT元素来控制字体、字号等。 3.3 技术部分 3.4 在标记语言的属性值和样式表的属性值中，尽量使用相对的单位 [优先级 2]比如，在CSS中，尽量使用'em'或者百分比单位，而不是'pt'或'cm'这样的绝对单位。如果已使用绝对单位，验证并确保呈现的内容正常有效。（请参考 验证一节）。 3.4 技术部分 3.5 根据规范使用标题（headings）来呈现文档结构。 [优先级 2]比如在HTML中，使用H2来表示以下内容为H1的子内容。不要使用标题来控制字号等效果。 3.5 技术部分 3.6 适当的标记列表及列表项目。 [优先级 2]比如在HTML中，可以合适的嵌套OL/UL/DL。 3.6 技术部分 3.7 标记引用语，不得利用引用语标记来制造缩排等排版效果。 [优先级 2]比如在HTML中，使用Q和BLOCKQUOTE元素来分别标记短的和大段的引用。 3.7 技术部分
第四条. 阐明自然语言的使用
Use markup that facilitates pronunciation or interpretation of abbreviated or foreign text.
当内容开发者为文档中的自然语言变换作了标记，语音合成器和盲文设备会自动切换至新的语言，使文档对于多语言使用者具有可访问性。内容开发者应该将文档内容的主要自然语言标记在HTTP头中，也需要为缩写和简称提供解释说明。
除了有利于辅助技术，自然语言标记也使得搜索引擎可以更好的获取指定语言的关键字。自然语言标记同样为所有人促进了可读性，包括有学习障碍和认知障碍的人群，和聋人。
当缩写或者自然语言的更改没有被指名，阅读机器或者盲文显示可能无法辨认内容。
检验点：
4.1 文档中任何文字或 等义文字（如表格标题说明）所使用的自然语言更换时，予以明确地识别。 [优先级 1]比如在HTML里使用"lang"属性，在XML里，使用"xml:lang"。 4.1 技术部分 4.2 文档中缩写词或简称第一次出现时，应当注明其全称。 [优先级 3]比如在HTML中，为ABBR和ACRONYM使用"title"属性。在正文中提供这样的解释有利于提高文档的可用性。 4.2 技术部分 4.3 指名文档所使用的主要自然语言。 [优先级 3]比如在HTML中，在HTML元素上标明"lang"属性，在XML中使用"xml:lang"。系统操作人员应当合理配置服务器以利用内容判断（content negotiation）机制( [RFC2068], section 14.13)，这样客户端可以自动找到首选语言版本的文档。 4.3 技术部分
第五条. 创建编排良好的表格
确保表格具备良好的结构标签使浏览器和其他用户代理可以良好呈现。
表格应该用来组织表格状信息（“数据表格”）。内容开发者应当避免使用表格来布局（“布局表格”）。不管怎样，表格在屏幕阅读器里总是呈现很多问题（参考检验点 10.3），尤其是布局表格。
除非是在表格的标签与结构正确的情况下，一些用户代理才呈现良好。（参考第三条）
以下的检验点直接关系到用户通过听觉访问表格（比如屏幕阅读器或车载设备），或者用户一次只浏览一步分页面情况下（比如盲人或者有视觉障碍的用户通过语音输出或盲文显示，或其他小屏幕设备等等）的情况：
检验点：
5.1 对于数据表格，指名行和列标题。 [优先级 1]比如在HTML中，使用TD来表示数据单元格，用TH来表明标题。 5.1 技术部分 5.2 对于具有两层或多层行列逻辑关系的表格，合理使用标签联系单元格与标题的关系。 [优先级 1]比如在HTML中，使用THEAD，TFOOT，和TBODY来为行分组，使用COL和COLGROUP来为列分组，使用"axis"，"scope"，和"headers"属性来描述数据间的复杂关系。 5.2 技术部分 5.3 不要使用表格来布局，除非该表格线性化后仍有意义。如果表格并不具有意义的话，就该提供等义的替代对象（这可能是 线性化后的版本）。 [优先级 2] 【注】 只要用户代理支持使用样式表定位，就不应该用表格来布局。 参考检验点 3.3. 5.3 技术部分 5.4 如果已经使用表格来布局，就不该再使用其它的结构性标记来处理视觉格式效果。 [优先级 2]比如在HTML中，不要使用TH元素来使文字（非表格标题）居中和加粗。 5.4 技术部分 5.5 提供表格的摘要信息。 [优先级 3]比如在HTML中，使用"summary"为TABLE添加摘要信息。 5.5 技术部分 5.6 为表格标题提供缩写。 [优先级 3]比如在HTML中，使用"abbr"为TH添加缩写信息。 5.6 技术部分
请参考检验点 10.3。
第六条. 确保页面能够在新技术下良好呈现
保证页面可访问，即使不支持新技术或者效果被关闭。
虽然鼓励内容开发者使用新技术来解决问题，但应当保证运用新技术的页面在旧浏览器和被关闭效果的浏览器中同样有效。
检验点：
6.1 组织文档，使其在没有样式表的情况下也能加以阅读。举例来说，当一个HTML文件没有按照关联的样式表来呈现时，一定要还是能阅读其内容。 [优先级 1]当内容是按照逻辑组织的，即使样式表被关闭或不支持 ，这些内容也会按照逻辑显示。 6.1 技术部分 6.2 确保动态内容的等义替代文字在动态内容更新时也能一并更新。 [优先级 1] 6.2 技术部分 6.3 确保在脚本，小应用程序或其它程序型对象在被关闭或不支持的情况下，网页仍可使用。如果实在不可能办到的话，应该提供等义的替代信息或其它具可访问性的网页。 [优先级 1]比如，保证触发脚本的链接在校本被关闭或不支持的情况下也可用（即不要使用"javascript:"作为链接目标），如果这不能办到，则在NOSCRIPT元素中提供等义的文字替代，或者使用服务器端脚本来实现功能，或者提供替代的可访问页面，如 检验点 11.4所述。 同样参考第一条。 6.3 技术部分 6.4 对于脚本及小应用程序来说, 都应确保事件处理程序应与输入接口及设备无关。 [优先级 2]参考 设备无关的定义。 6.4 技术部分 6.5 确保动态内容也具可访问性，否则就该提供等义的替代内容或网页。 [优先级 2]比如在HTML中，在框架页的最后使用NOFRAMES。在一些应用中，服务器端脚本比客户端脚本更具可用性。 6.5 技术部分
请参考检验点 11.4.
第七条. 确保使用者能处理时间敏感内容的改变
保证用户可以暂停或者停止移动的、闪烁的、自动更新的对象或者页面。
认知障碍和视觉障碍患者可能不能阅读移动的文字。移动同样会造成对其他内容阅读和理解的分心。屏幕阅读器并不能阅读移动的文字。肢体残疾的用户也无法快速跟踪移动的对象，从而产生理解上的困难。
【注】 以下检验点包括一些内容开发者需要承担的义务，直到用户代理提供足够的控制机制。
检验点：
7.1 除非用户代理 支持用户控制闪烁的对象，否则应尽量避免屏幕闪烁。 [优先级 1] 【注】 当屏幕闪烁在4至59每秒及峰值灵敏度20Hz的情况下（如从暗变亮，类似于闪光灯），感光性癫痫症患者可能会发作。 7.1 技术部分 7.2 除非用户代理支持用户控制闪光，否则应尽量避免内容闪烁（比如从有到无，或类似于消失后马上出现的情形）。 [优先级 2] 7.2 技术部分 7.3 除非用户代理支持用户停止移动内容，否则应尽量避免页面内出现移动内容。 [优先级 2]当页面包含移动内容时，应当提供脚本或小程序让用户关闭移动或者更新。使用脚本和样式表来让用户可以自由关闭一些特效。 参考第八条. Techniques for checkpoint 7.3 7.4 除非用户代理支持用户停止页面刷新，否则应尽量不要创建周期性自动刷新的页面。 [优先级 2]比如在HTML中，不要使用"HTTP-EQUIV=refresh"，除非用户代理支持用户关闭此功能。 7.4 技术部分 7.5 除非用户代理 支持用户停止自动重定向，否则应尽量避免页面自动重定向。而通过服务器来实现重定向。 [优先级 2] 7.5 技术部分
【注】BLINK和MARQUEE元素在W3C HTML标准中从来没有定义过，并不推荐使用。参考第十一条。
第八条. 确保嵌入式用户界面具有直接的可访问性
确保用户界面遵循可访问性设计原则：对功能操作设备无关，可以键盘操作及自动发音等。
当一个嵌入式对象具备“自己的界面”，和浏览器的界面类似，那对于用户来说比较易用。如果嵌入式的这个界面不能达到此要求，那么最好有一个可替代的无障碍方案。
【注】 更多关于用户界面易用性的，请参考用户代理可访问性指南（[WAI-USERAGENT]）以及编辑工具可访问性指南（[WAI-AUTOOL]）。
检验点：
8.1 让程序型元素如脚本和小应用程序等，能够直接被一些辅助技术使用，或者与之兼容[如果功能很 重要而且不在其它地方出现的话， 优先级为1，否则优先级为 2。]。 参考第六条。 8.1 技术部分
第九条. 设备无关的设计
确保通过多种不同的输入设备都可以激活或触发页面上的元素。
设备无关性意味着用户可以使用一些喜好的输入（或输出）设备——如鼠标、键盘、语音、肢体棒等——来和用户代理或者文档交互，如果，举个例子，表单控制只能通过鼠标或者其他指示设备来触发，那么当一些具有视力障碍或者使用语音输入和键盘的人就无法使用。
【注】 为图像映射或图像链接提供等义替代文字，可以使没有指点设备的用户正常交互。参考第一条.
通常来说，支持键盘交互的页面同时也支持语音和命令行操作。
检验点：
9.1 除非无法用有效的多边型形状来定义，否则应该提供使用者端的图像映射，而非服务器端。 [优先级 1]请参考 检验点 1.1, 检验点 1.2, 和 检验点 1.5。 9.1 技术部分 9.2 确保任何具有自身操作界面的元素，其操作方式都与使用者的设备无关。 [优先级 2]请参考 设备无关性的定义。 同样请参考第八条。 9.2 技术部分 9.3 对于脚本来说，应指定逻辑上的事件处理，而不应该指定特定装置的事件处理。 [优先级 2] 9.3 技术部分 9.4 在链接、表单控制及对象间，提供合乎逻辑的Tab条约顺序。 [优先级 3]比如在HTML里，可以通过"tabindex"属性来制定tab顺序，确保页面设计的逻辑性。 9.4 程序部分 9.5 为重要链接提供键盘快捷键（包括 客户端图像映射、表单控制、表单控制群组）。 [优先级 3]比如在HTML里，可以使用"accesskey"来指明键盘快捷键。 9.5 技术部分
第十条. 使用过渡的解决方案
使用过渡的可访问性解决方案可以使辅助技术以及旧的浏览器很好的支持。
比如，旧的浏览器不允许用户操纵空的编辑框；旧的屏幕阅读器把连续的链接列表理解为一个链接；这些活动元素访问起来就比较困难或者难以访问。改变当前窗口内容或者弹出新窗口则会使一些用户感到迷惑。
【注】 以下检验点仅在用户代理支持时有效（包括辅助技术）。这些检验点都被标为“过渡”的，这意味着Web内容指南工作小组认为它们在本文档发布时是有效和需要的。但并不保证在将来，Web技术也可能会加入一些预期的功能和特色。
检验点：
10.1 除非用户代理支持用户关闭新开的窗口，否则应尽量避免使用弹出式窗口或其他类似窗口，也不该在未通知用户的情况下就变更当前窗口。 [优先级 2]比如在HTML中应避免在某个框架页上使用链接目标为新窗口。 10.1 技术部分 10.2 除非用户代理支持处理label和表单控制元素间的关联，否则对于所有的表单控制元素和不明确的lable来说，都应当确保这些label位于合适的位置。 [优先级 2]label必须出现在它所联系的控制元素之前（包括一行内具有多个的情况），或者是上一行。 请参考检验点 12.4. 10.2 技术部分 10.3 除非用户代理 （包括辅助技术）能够正确地绘制出平行的文字, 否则就应该为 所有使用平行文字或折行表列的表格（在同一页或其它页面中）提供线性的等义替代文字。 [优先级 3] 【注】 请参考 线性化表格的定义。 本检验点主要考虑那些使用不支持平行文字块的 用户代理（比如一些 屏幕阅读器）的用户；本检验点并非阻止开发者使用表格表现 表格状数据。 10.3 技术部分 10.4 除非用户代理能够正确处理空白的控制元素，否则就应该要在编辑框及文字区域中，预先放置占位字符。 [优先级 3]比如在HTML中，TEXTAREA和INPUT元素应当如此。 10.4 技术部分 10.5 除非用户代理（包括辅助技术）能够清楚地显示紧靠的两个链接，否则应当在两个链接间插入不属于链接又可被打印的字符（并以空格隔开）。 [优先级 3] 10.5 技术部分
第十一条. 使用W3C推荐的技术和规范
使用W3C技术（根据规范）并且遵循可访问性指南。如果使用W3C技术有困难，或者可能会造成内容呈现上的问题，那么可以提供一个现有内容的可访问性替代版本。
本指南推荐W3C技术（如HTML和CSS等）有以下原因：
W3C技术本身遵循可访问性规范。
使用W3C技术可以保证可访问性问题在设计阶段就考虑到。
W3C标准和规范的制定是开放、一致并且严格的。
很多非W3C格式（如PDF，Shockwave，等）必须安装插件或者独立的应用程序来浏览。通常情况下这些格式不能被标准的用户代理（包括相关辅助技术）阅读和导航。避免使用非W3C推荐和非标准的功能（私有的元素、属性和扩展），这样可以使更多的人使用多种软硬件访问。当一些页面必须使用有访问障碍的技术时，必须提供等价的替代页面。
使用W3C技术也必须遵循可访问性指南，当使用了新的技术，确保它们能够良好的呈现出来。（参考第六条。）。
【注】 从PDF、PostScript、RTF等形式转换成W3C标签语言（如HTML、XML）所得的文档可能不具有良好的可访问性。所以转换完成后须检验每个页面的可访问性和可用性（参考验证一节）。如果转换比较困难，那么可以通过修订原文档来确保良好呈现，或者提供一个HTML或纯文本版本。
检验点：
11.1 尽可能并且合理的使用W3C技术，尽可能使用被支持的最新的W3C技术。 [优先级 2]最新W3C标准和规范请查阅 参考文献部分，最新的关于用户代理（UA）支持方面的W3C技术信息请参考 [WAI-UA-SUPPORT]。 11.1 技术部分 11.2 避免使用W3C不赞成的废弃的功能。 [优先级 2]如在HTML中，请勿使用 不推荐的FONT元素；而使用样式表（如CSS里的font属性）。 11.2 技术部分 11.3 提供相关的信息，让使用者能够按照其偏好 （语言, 内容类型等）来获取文档。 [优先级 3] 【注】 尽可能的使用内容判断（content negotiation）机制。 11.3 技术部分 11.4 如果 竭尽所能仍无法建立具 可访问性的网页, 那么应另外提供网页，该网页应使用W3C推荐的技术，具备可访问性，并且提供 等义的替代信息 （或功能），并且与那个不具可访问性（原来的）网页保持同步更新。 [优先级 1] 11.4 技术部分
【注】 当其他措施都无效的时候，内容开发者才应该提供可访问性替代版本，因为这些替代版本可能更新比“主”页面慢。这样如果用户访问主页信息有障碍，而替代版本又是过期的，可能会造成挫折。自动生成替代版本也许是好主意，但是要确保这些页面正确并且可以通过链接导航。在采取替代页面方案前，再考虑一遍原页面的设计，毕竟提高原页面的可访问性对于所有用户都有好处。
第十二条. 提供内容引导信息
提供上下文和位置信息以帮助用户理解复杂的页面或元素。
提供相关页面间和相关元素间联系信息，可以帮助所有的用户理解。一些页面间复杂的联系可能会造成认知障碍人士和视觉障碍人士访问上的不便。
检验点：
12.1 为每一个框架添加标题，以促进框架的辨认与导航。 [优先级 1]比如在HTML里在FRAME元素上使用"title"属性。 12.1 技术部分 12.2 如果框架标题不够明确，就应该描述每一个框架的目的，以及当前框架与其他框架间的联系。 [优先级 2]比如说在HTML里面，使用"longdesc"属性或者是 描述链接。 12.2 技术部分 12.3 自然适当的将大块的信息分隔为易于管理的小部分。 [优先级 2]例如在HTML里；使用OPTGROUP来群组SELECT里相关的OPTION元素；用FIELDSET和LEGEND来分隔表单控制；适当的使用嵌套的列表；使用标题（headings）来结构化文档，等等。 请参考第三条。 12.3 技术部分 12.4 明确地将LABEL与其所关联的表单元素联系在一起。 [优先级 2]例如在HTML里使用LABEL元素和"for"属性。 12.4 技术部分
第十三条. 提供清晰的内容导航机制
提供清晰并且一致的导航机制——位置信息、导航条、网站地图，等等——如此可使使用者在网站上快速而精确地找到特定信息。
清晰并且一致的导航机制对于具有认知障碍、视力障碍的人非常重要，并且对于所有人都有益。
检验点:
13.1 能够明确的知道每个链接的目标。 [优先级 2] 链接文字应该意义清楚，无论是单独理解或者是放入上下文。链接文字也必须是扼要的。比如，在HTML里，写“4.3版本信息”而不是“点击这里”。为了使链接文字清楚，内容开发者必须利用信息提示（在HTML里，即"title"属性）指明链接的目标。 13.1 技术部分 13.2 利用原数据（metadata）为页面和网站加入语义化信息。 [优先级 2]比如，使用资源描述框架（RDF）( [RDF])来表明文档的作者、内容的类型等等。 注意：一些HTML 用户代理 可以通过HTML的LINK元素和"rel"或"rev"属性来创建导航。（如：rel="next"，rel="previous"，rel="index"，等等。） 参照检验点 13.5. 13.2 技术部分 13.3 提供网站结构规划方面的信息（如网站地图或者目录索引）。 [优先级 2]在描述网站结构的时候，涉及到可访问性的内容可以高亮显示并加以解释说明。 13.3 技术部分 13.4 提供一致的导航机制。 [优先级 2] 13.4 技术部分 13.5 提供导航条，强调并让使用者导航机制。 [优先级 3] 13.5 技术部分 13.6 将相关的链接聚集一起，并且(为用户代理)指明， 除非用户代理可以处理，否则还应该提供跳过该链接群的方法。 [优先级 3] 13.6 技术部分 13.7 如果提供了搜索功能，可以设计不同的网页内容搜索方式，以提供不同经验与喜好者搜寻选用。 [优先级 3] 13.7 技术部分 13.8 在网页标题、段落、列表等的开始部分放置区分信息。 [优先级 3] 注意： 这通常被称作“预加载”并且非常有利于利用串行设备（如合成语音）的人获取信息。 13.8 技术部分 13.9 为文档辑（包含众多页面）提供信息。 [优先级 3]例如，利用HTML的LINK元素和"rel"和"rev"属性可以帮助建立文档辑。另外一种方法就是制作存档（如利用zip，tar和gzip，stuffit等等。）。 注意：离线浏览可以为一些动作不便、缓慢的人节省下不少费用。 13.9 技术部分 13.10 提供一个跳过多行ASCII图形的方法。 [优先级 3]参考 检验点 1.1和 术语表中ASCII图形的例子。 13.10 技术部分
第十四条. 确保文档内容的清晰与简单
确保文档内容的清晰与简单，以便于人们理解。
一致的页面布局，可辨认的图片以及易于理解的文字可以让所有人受益。特别是可以帮助具有认知障碍和阅读障碍的人访问。（为盲人、视力障碍者或关闭图片显示的用户提供图片的替代文字，请参照第一条。）
使用清晰简单的文字可以提高信息的传达效率。较书面的文字会给认知障碍和学习障碍者造成理解上的困难。使用清晰和简单的问题同样可以使那些母语并非网页语言的访问者易于理解，还包括那些主要使用手语的人。
检验点：
14.1 使用最清晰最简单的文字表达网站的内容。 [优先级 1] 14.1 技术部分 14.2 提供图片、音频表达的文字补充说明，便于增强页面内容的易理解性。 [优先级 3] 参照第一条 14.2 技术部分 14.3 统一页面之间的表现样式。 [优先级 3] 14.3 技术部分
附录 A. -- 验证
可以通过自动工具或者人工验证可访问性。自动的验证工具可以非常便捷的得出结果，但是并不能覆盖所有的可访问性问题。人工验证可以保证语言文字和导航信息的清晰与易用。
尽量在开发初期就重视验证可访问性问题，发现的越早则越容易解决和避免。
以下是一些重要的验证方法，在技术文档 - 验证部分中有详细的介绍。
使用自动化的工具和浏览器验证工具，请注意使用软件工具并不会提示所有的可访问性问题，比如链接文字的意义、替代文字是否合适等等。
语法检验（如：HTML，XML等）。
样式表检验（如：CSS）。
使用纯文本浏览器或模拟器。
使用多媒体图形浏览器，并且：
加载声音和图片，
关闭图片显示，
禁止声音播放，
不使用鼠标，
关闭框架、脚本、样式表和applets
使用多个浏览器，旧的和新的。
使用能自我发音的浏览器、屏幕阅读器、放大软件或小面积显示等等。
使用拼写和语法检查器。拼写错误可能导致使用语音合成器的浏览者误解词语的意思。减少语法上的问题可以提高可理解度。
检查文档的清晰度和简洁性。通过一些字处理软件统计阅读信息，对于文档的清晰度和简洁性有指示作用。最好的办法就是邀请有经验的作家来协助撰写内容。通过编辑人员的，也可以提高文档的可用性。
邀请一些残疾人来评论，他们都会认真地提供关于可访问性或使用性的有价值的反馈信息。
附录 B. -- 术语表
Accessible 可访问的，无障碍的当内容对于残疾人来说可以正常使用与理解，即具备可访问性。 Applet Java应用小程序某种嵌入Web页面的程序。 Assistive technology 辅助技术特别设计用来辅助残疾人完成日常活动的软硬件。辅助技术包括轮椅，阅读机器，抓握装置等。在web可访问性领域，常用的基于软件的辅助技术包括屏幕阅读器，屏幕放大器，语音合成器，语音输入软件，通常与桌面图形浏览器（以及其他 用户代理）联合操作。硬件辅助技术包括特制键盘和定点设备。 ASCII art ASCII图案ASCII图案使用文本字符来组合创造图像。例如， ";-)"是表示微笑。下面是一个ascii图案，表现了闪动频率与病人睁眼、眨眼的光敏反映。[ 跳过ascii图案或参考本 图案描述]：
% __ __ __ __ __ __ __ __ __ __ __ __ __ __ 100 | * | 90 | * * | 80 | * * | 70 | @ * | 60 | @ * | 50 | * @ * | 40 | @ * | 30 | * @ @ @ * | 20 | | 10 | @ @ @ @ @ | 0 5 10 15 20 25 30 35 40 45 50 55 60 65 70 Flash frequency (Hertz)
Authoring tool 创作工具HTML编辑器，文档转化工具，以及由数据库产生web内容的工具都是创作工具。查阅“创作工具可操作性指南”（ [WAI-AUTOOLS]）关于开发这些工具的相关信息。 Backward compatible 向后兼容即设计在早期版本的语言、程序中都兼容。 Braille 布莱叶盲文布莱叶盲文用六个不同式样的突起点来表达字母和数字，供盲人用指尖来阅读。布莱叶盲文中“Accessible”（可访问性）一词表示如下： 盲文显示器，通常也叫做“动态盲文显示器”，由一个电子装置——通常是计算机——发出命令，提升或降低点的样式。结果是出现一行可以迅速改变的盲文。当前通用的动态盲文显示器在尺寸上从一单元（六至八点）延伸至八十单元行，大多数每行有十二至二十单元。 Content developer 内容开发者创建Web页面或是设计、规划网站的人。 Deprecated 不赞成、弃用的弃用元素或属性是已经由更新的所替代，已经过时的元素或属性。弃用元素在将来HTML的版本中变的陈旧。 技术文档中HTML元素和属性的索引显示了在HTML 4.0中不主张使用的元素和属性。开发者应当避免使用弃用元素和属性。但由于向后兼容的原因，用户代理应继续支持。 Device independent 设备无关的用户必须使用由他们选择的、被支持的输入输出设备，依照他们的需求，与用户代理（以及它呈现的文档）交互。输入设备可以包括定点设备、键盘、盲文设备、肢体棒，麦克风和其他设备。输出设备可以包括显示器、语音合成器和盲文设备。请注意，“与设备无关的支持”不是说用户代理必须支持每一种输入或输出设备。用户代理应当为支持的设备提供众多输入和输出机制。举个例子，如果一个用户代理支持键盘和鼠标输入，用户应当可以仅使用键盘、仅使用鼠标或两者完成所有交互。 Content,Structure, and Presentation 文档内容、结构与表现文档的内容即文档通过自然语言，图像，声音，电影，动画等呈现给用户的东西。文档的结构就是指文档在逻辑上是如何组织的（例如，通过章节，引言，目录等等）。详细表明文档结构的 元素 （例如HTML中的P, STRONG, BLOCKQUOTE）称作 结构元素。文档的表现是指文档是怎样呈现的（例如，打印，二维图像表示，纯文本表示，合成语音，盲文等）。详细表明文档表现的 元素（例如B, FONT, CENTER）称作 表现元素。例如一个文档标题，标题的内容就是标题所说的（例如“帆船”）；在HTML中，标题就是被标出的结构元素，例如，H2。最后，标题的表现形式可能是粗印刷体文字并具外补丁，占据一行并居中的文字，标题由某种声音（例如一种听觉字体）说出，等等。 Dynamic HTML (DHTML)DHTML是一个营销术语，应用于包括HTML， 样式表，文档对象模型 [DOM1]，脚本在内的各种标准的混合。然而并没有正式定义DHTML的W3C标准。大多数指南适用于DHTML的应用，但本文档下列原则集中讨论同脚本和样式表相关的问题： 第一条, 第三条, 第六条, 第七条, 和 第九条。 Element 元素本文档用“元素”这一术语既表示严格的SGML含义（元素是一个语法组成部分），也通常用来表示内容的类型（例如视频或语音）或逻辑结构（例如标题或列表）。后一种含义强调，一个HTML格式的指南可以毫不费力的应用于另一种标记语言。注意一些（SGML）元素有其显示的内容（例如P, LI, 或TABLE），一些为外部内容所取代（例如IMG），一些影响处理过程（例如STYLE和SCRIPT使信息被样式表或脚本引擎处理）。使文字字符成为文档内容的元素称为 文字元素。 Equivalent 等价的、同等的、可替代的当一部分内容与其他内容一样都能基本实现对用户的表达相同功能或目的时，可称其为等价。在本文档中，就像基本内容为健全人士所提供的功能一样，等价必须为残疾人基本实现同样的功能（至少是在考虑到残疾人的本性与技术状态下的可行范围内）。例如，文字“满月”在表示给用户时，可以传递与满月图像同样的信息。注意，等价信息是用来完成 同样的功能。如果图像是链接的一部分，且理解图像对猜测链接目标有至关重要的作用时，等价也必须给予用户链接目标的概念。为可访问性内容提供等价信息是开发人员使残疾人访问文档的一种主要的途径。作为完成内容相同功能的一部分，等价可以包括对内容的描述（也就是内容的外表特征和语音特征）。例如，为使用户了解一个复杂图表所传达的信息，作者应当描述图表中的视觉信息。由于文本内容可以以合成语音，盲文和可视化播放文字的形式呈现给用户，因此本文档也要求图像和音频信息的 等义文字替代。必须编写同等的替代文字以便传达所有基本内容。非文字替代（例如一个视觉表示的听觉描述；一个用手语讲故事的视频，作为一个书面故事的等价；等等）同样提高了那些不能访问视觉信息与书面文字的人的可访问性，这类人包括盲人，有认知障碍的人，有学习障碍的人和聋人。等价信息可以以许多种方式提供，包括：通过属性（例如一个在HTML和SMIL中”alt“属性”的属性值）；作为元素内容的一部分（例如HTML中的OBJECT）；作为文档内容的一部分；通过一个链接的文档（例如在HTML中指定为"longdesc"属性或 描述链接(d-link)）。由于同等可替代内容的复杂性，需要结合技术（例如对较复杂的信息使用"longdesc"，益于第一次使用的用户；除此之外，较简短的则使用"alt"，对回访的用户有益）。至于如何提供及何时提供等价信息， 技术文档中有详细资料。 文字副本（text transcript） 是音频信息的等义替代，音频信息包括语音和非语音，例如音响效果。 字幕（caption）就是一种文字副本，它与音频视频同步。字幕通常在叠加在视频上表示，以利于那些聋人，有听觉困难和听不到声音的人（例如在一个嘈杂的房间内）。 按序文字副本（collated text transcript ）将（按序）字幕同视觉信息的文字表达（动作表达，身体语言，图像和视觉追踪的情景变化）相结合。这些等义的替代文字使聋人、盲人以及不能播放电影、动画的人等都可以访问。同时，也使信息可用于搜索引擎。非文字等同的一个例子就是一些关键视觉元素的 听觉描述（auditory description ）。这个描述既可以是一个预先录制的人声也可以是一段合成的声音。听觉描述与是视频同步的，通常在自然停顿的时候播放。听觉描述包括动作，肢体语言，图像和情景变化等信息。 Image 图像一种图形化呈现。 Image map 图像映射图像映射是指图像上被划分的与链接相关联的作用区。点击任一作用区可以触发操作。当一个用户点击一个 客户端图像映射的作用区时，用户代理计算点击在哪个区发生并进行与那个区相关的链接。点击一个 服务器端的图像映射的作用区，会使点击的相应指令被传送到服务器，随即执行一些操作。内容开发者可以使用客户端图像映射来创建与设备无关的访问。客户端图像映射允许用户代理提供用户直接反馈，以便得知用户指示（如鼠标）是否移动至一个作用区上。 Important 重要对理解文档有至关重要作用的那部分信息。 Linearized table 线形表格是指按照段落显示的方式显示表格单元格的一种呈现方式。这些段落将以单元被在源文件中被定义的同样顺序显示。当按顺序阅读时单元格应当有意义并包含 结构化元素（创建段落，标题，列表等）以便页面线性化后有意义。 Link text 链接文字一个链接内部呈现的文字内容。 Natural Language 自然语言口语，书面语或有符号的人们所使用语言，如法语，日语，美式手语，盲文等。自然语言的内容可以利用HTML（ [HTML40]，第8.1节）中“lang”属性，和XML（ [XML]，第2.12节）中"xml:lang"属性指明。 Navigation Mechanism 导航机制导航机制是用户进行页面或站点导航使用的任何手段。一些典型的导航机制包括：
navigation bars 导航栏导航栏是一份文档或整个站点大多数重要部分的链接的集合。 site maps 站点地图站点地图是整个页面或站点结构的全局视图。 tables of contents 目录目录通常是一份文档大多数重要部分的列表（及相应链接）。 Personal Digital Assistant (PDA) 个人数字助理，PDAPDA是一种小型可携带的电脑设备。大多数PDA用于记录个人数据，比如日历，联系和电子邮件。PDA通常是一个有小屏幕的手持设备，可以通过多种资源输入。 Screen magnifier 屏幕放大器是一种放大屏幕比例以便更方便观看的软件程序。屏幕放大器主要为弱视个体所使用。 Screen reader 屏幕阅读器一种将屏幕内容大声朗读给用户听的软件程序。屏幕阅读器主要为盲人所使用。屏幕阅读器通常仅能阅读屏幕的印刷体文字而不能阅读图片文字。 Style sheets 样式表样式表是文档表现的详细描述。样式表可以有三种不同的来源：可由内容提供者编写，可由用户创建，或由用户代理商立。在CSS ( [CSS2])中，内容提供者，用户和用户代理样式表的交互称为层叠。 Presentation markup 表现层标记是用来完成格式上（而非结构上）效果的标记，例如HTML中的B或I元素。注意STRONG和EM元素不作为表现层标记是因为它们传达与特定字体样式无关的信息。 Tabular information 表格式信息当表格用于表达数据文字，数字，图像等中的逻辑关系时，信息被称作“表格式信息”，表格被称为“数据表格”。由表格表示的关系可以在视觉上表示出来（通常在一个二维的格子上），在听觉上表示（通常是最前面的有标题信息单元），或以其他形式表示。 Until user agents ... 直至用户代理...在大多数检验点中，要求内容开发者保证他们的页面和站点具有可访问性。然而，还有很多可访问性需求需要 用户代理（包括 辅助技术）支持。至本文发表时，不是所有的用户代理或辅助技术提供访问控制用户要求（例如，一些用户代理不允许用户关闭闪烁内容，或一些屏幕阅读器不能较好的处理表格）。包含“直到用户代理商……”的检验点要求内容开发者为可访问性提供额外支持，直到大多数用户代理可被其用户容易地利用，包括必需的可访问性功能。 However, there are accessibility needs that would be more appropriately met by user agents (including assistive technologies). 注意，W3C无障碍网络倡议网站（参见 [WAI-UA-SUPPORT]）提供了关于用户代理支持可访问性功能的信息。建议内容开发者适当地参考这个页面的最新信息。 User agent 用户代理访问web内容的软件，包括桌面图像浏览器，文字浏览器，语音浏览器，移动电话，多媒体播放器，插件程序，以及一些用来与浏览器联结的软件辅助技术，比如屏幕阅读器，屏幕放大器，语音识别软件等。
鸣谢
Web内容可访问性工作组联合主席： Chuck Letourneau, Starling Access Services Gregg Vanderheiden, Trace Research and DevelopmentW3C小组联系人： Judy Brewer and Daniel Dardailler感谢以下所有曾经帮助修正本文档的朋友：Harvey Bingham, Kevin Carey, Chetz Colwell, Neal Ewers, Geoff Freed, Al Gilman, Larry Goldberg, Jon Gunderson, Eric Hansen, Phill Jenkins, Leonard Kasday, George Kerscher, Marja-Riitta Koivunen, Josh Krieger, Scott Luebking, William Loughborough, Murray Maloney, Charles McCathieNevile, MegaZone (Livingston Enterprises), Masafumi Nakane, Mark Novak, Charles Oppermann, Mike Paciello, David Pawson, Michael Pieper, Greg Rosmaita, Liam Quinn, Dave Raggett, T.V. Raman, Robert Savellis, Jutta Treviranus, Steve Tyler, Jaap van Lelieveld, and Jason White
本文档的原始草案基于由Trace R & D Center at the University of Wisconsin编译的“网站可访问性指南统一标准（The Unified Web Site Accessibility Guidelines）”([UWSAG])，该文档包含另外的贡献者名单。
参考文献
任何最新版本W3C标准及规范，请查阅W3C技术报告。
[CSS1]"CSS, level 1 Recommendation", B. Bos, H. Wium Lie, eds., 17 December 1996, revised 11 January 1999. The CSS1 Recommendation is: http://www.w3.org/TR/1999/REC-CSS1-19990111.
The latest version of CSS1 is available at: http://www.w3.org/TR/REC-CSS1. [CSS2]"CSS, level 2 Recommendation", B. Bos, H. Wium Lie, C. Lilley, and I. Jacobs, eds., 12 May 1998. The CSS2 Recommendation is: http://www.w3.org/TR/1998/REC-CSS2-19980512.
The latest version of CSS2 is available at: http://www.w3.org/TR/REC-CSS2. [DOM1]"Document Object Model (DOM) Level 1 Specification", V. Apparao, S. Byrne, M. Champion, S. Isaacs, I. Jacobs, A. Le Hors, G. Nicol, J. Robie, R. Sutor, C. Wilson, and L. Wood, eds., 1 October 1998. The DOM Level 1 Recommendation is: http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001.
The latest version of DOM Level 1 is available at: http://www.w3.org/TR/REC-DOM-Level-1 [HTML40]"HTML 4.0 Recommendation", D. Raggett, A. Le Hors, and I. Jacobs, eds., 17 December 1997, revised 24 April 1998. The HTML 4.0 Recommendation is: http://www.w3.org/TR/1998/REC-html40-19980424.
The latest version of HTML 4.0 is available at: http://www.w3.org/TR/REC-html40. [HTML32]"HTML 3.2 Recommendation", D. Raggett, ed., 14 January 1997. The latest version of HTML 3.2 is available at: http://www.w3.org/TR/REC-html32. [MATHML]"Mathematical Markup Language", P. Ion and R. Miner, eds., 7 April 1998. The MathML 1.0 Recommendation is: http://www.w3.org/TR/1998/REC-MathML-19980407.
The latest version of MathML 1.0 is available at: http://www.w3.org/TRREC-MathML. [PNG]"PNG (Portable Network Graphics) Specification", T. Boutell, ed., T. Lane, contributing ed., 1 October 1996. The latest version of PNG 1.0 is: http://www.w3.org/TR/REC-png. [RDF]"Resource Description Framework (RDF) Model and Syntax Specification", O. Lassila, R. Swick, eds., 22 February 1999. The RDF Recommendation is: http://www.w3.org/TR/1999/REC-rdf-syntax-19990222.
The latest version of RDF 1.0 is available at: http://www.w3.org/TR/REC-rdf-syntax [RFC2068] "HTTP Version 1.1", R. Fielding, J. Gettys, J. Mogul, H. Frystyk Nielsen, and T. Berners-Lee, January 1997. [SMIL]"Synchronized Multimedia Integration Language (SMIL) 1.0 Specification", P. Hoschka, ed., 15 June 1998. The SMIL 1.0 Recommendation is: http://www.w3.org/TR/1998/REC-smil-19980615
The latest version of SMIL 1.0 is available at: http://www.w3.org/TR/REC-smil [TECHNIQUES]"Techniques for Web Content Accessibility Guidelines 1.0", W. Chisholm, G. Vanderheiden, I. Jacobs, eds. This document explains how to implement the checkpoints defined in "Web Content Accessibility Guidelines 1.0". The latest draft of the techniques is available at: http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/ [WAI-AUTOOLS]"Authoring Tool Accessibility Guidelines", J. Treviranus, J. Richards, I. Jacobs, C. McCathieNevile, eds. The latest Working Draft of these guidelines for designing accessible authoring tools is available at: http://www.w3.org/TR/WAI-AUTOOLS/ [WAI-UA-SUPPORT]This page documents known support by user agents (including assistive technologies) of some accessibility features listed in this document. The page is available at: http://www.w3.org/WAI/Resources/WAI-UA-Support [WAI-USERAGENT]"User Agent Accessibility Guidelines", J. Gunderson and I. Jacobs, eds. The latest Working Draft of these guidelines for designing accessible user agents is available at: http://www.w3.org/TR/WAI-USERAGENT/ [WCAG-ICONS]Information about conformance icons for this document and how to use them is available at http://www.w3.org/WAI/WCAG1-Conformance.html [UWSAG]"The Unified Web Site Accessibility Guidelines", G. Vanderheiden, W. Chisholm, eds. The Unified Web Site Guidelines were compiled by the Trace R & D Center at the University of Wisconsin under funding from the National Institute on Disability and Rehabilitation Research (NIDRR), U.S. Dept. of Education. This document is available at: http://www.tracecenter.org/docs/html_guidelines/version8.htm [XML]"Extensible Markup Language (XML) 1.0.", T. Bray, J. Paoli, C.M. Sperberg-McQueen, eds., 10 February 1998. The XML 1.0 Recommendation is: http://www.w3.org/TR/1998/REC-xml-19980210.
The latest version of XML 1.0 is available at: http://www.w3.org/TR/REC-xml
[ 目录] [ 检验点]
感谢以下朋友对本翻译提供的帮助：
欧石南，一个藏袍