可理解性
本文提供了关于如何编写 Web 内容的实用建议,使之符合 Web 内容无障碍指南 (WCAG) 2.0 和 2.1 中概述的可理解性原则中的成功标准。可理解性指出信息和用户界面操作必须易于理解。
注意:要阅读 W3C 对可理解性及其指南和成功标准的定义,请参阅 原则 3:可理解性 — 信息和用户界面操作必须易于理解。
指南 3.1 — 可读性:使文本内容可读且易于理解
本指南侧重于使文本内容尽可能易于理解。
成功标准 | 如何符合标准 | 实用资源 |
---|---|---|
3.1.1 页面语言 (A) | 每个网页的默认人类语言应通过代码可检测。这对于确保读者已访问到适合其语言的网页等目的至关重要。实现此目的的最简单方法是在页面的 lang 属性上设置 <html> 元素,使其值等于最能代表页面所用语言的语言代码。 |
请参阅 设置文档的主要语言。 |
3.1.2 部分语言 (AA) |
在页面内容包含与主要语言不同的语言的单词或短语的情况下,请使用 lang 属性在围绕所述术语的元素(例如,如果不存在语义元素,则为 对于无论语言如何都相同的单词或短语(例如专有名词、不属于特定语言的技术术语),您无需设置不同的语言。 |
|
3.1.3 罕见词语 (AAA) | 使用技术术语、行话或习语/俚语时,应为这些短语/词语提供定义。您的网站应提供包含这些单词/术语定义的词汇表,然后您可以在这些单词/术语出现时链接到词汇表,或者至少在周围文本中提供定义,或者在页面底部的 描述列表 中提供定义。 | |
3.1.4 缩略语 (AAA) |
使用缩略语时,应提供其扩展或定义(视情况而定)。 通常认为, |
请参阅 缩略语。 |
3.1.5 阅读水平 (AAA) |
如果提供的文本需要高于初中水平的阅读水平(通常为 11-14 岁的儿童),请提供补充解释材料来帮助无法阅读的人,或者提供以初中水平编写的替代版本。 这并不意味着所有主题都应该被所有人理解,而是指写作风格应该对所有人来说都是无障碍的。最好将所有内容都以初中水平编写,即使是编程教程等技术文档,除非有充分的理由不这样做(例如,出于诗歌效果而使用其他风格),或者必须采用严格的风格(例如 W3C 规范)。 |
|
3.1.6 发音 (AAA) |
应提供一种机制,以便用户可以访问需要理解内容才能完全理解内容的单词的发音。 HTML |
请查看 视频和音频内容 以及 英语词典发音指南。 |
注意: 同时请查看 WCAG 对 指南 3.1 可读性:使文本内容可读易懂 的描述。
指南 3.2 — 可预测性:使网页以可预测的方式显示和操作
该指南侧重于使用户界面直观易懂。
成功标准 | 如何符合标准 | 实用资源 |
---|---|---|
3.2.1 获取焦点 (A) |
当控件或其他页面功能获取焦点时,不应以可能混淆或使用户感到困惑的方式改变上下文。 这是一个合理的的设计问题 - 人们不希望界面让他们感到意外;他们希望界面直观并按预期运行。例如,聚焦导航菜单选项不应改变显示的页面 - 应在显示改变之前激活它。 |
Element 的 focus 事件包含一些有用的信息。同时请查看 构建键盘辅助功能 获取一些有用的实现思路。 |
3.2.2 输入 (A) |
当数据输入控件或更改设置时,上下文不应意外更改。在更改发生之前,应警告/告知用户即将发生的更改。 同样,应实施合理的设计。例如,如果按下按钮会导致应用程序退出当前视图,则应询问用户是否确认此操作,并在适当的情况下保存其工作等。 |
input 事件在此处很有用。 |
3.2.3 导航一致性 (AA) |
导航菜单/控件的样式和位置应在网页的不同页面或视图之间保持一致,并且现有项目应以相同的顺序出现,即使例如添加了新项目。如果用户启动了更改,例如选择导航的不同配色方案或位置,则应在所有页面上尊重他们的选择。 同样,合理的设计 - 使所有页面或视图上的导航控件相同。 |
请查看 页面布局 获取有关现代布局标记的信息。同时请查看 将链接样式化为按钮 获取一个有用的可访问导航菜单示例。 |
3.2.4 标识一致性 (AA) |
具有相同功能的控件或组件应在不同页面或视图中以相同的方式标识。例如,出现在世界旅行网站每个页面上的货币转换器应该在语义上和标签方面完全相同。 同样,合理的设计! |
“标签”可以指文本内容中的描述性信息或 HTML 表单标签。请查看 有意义的文本标签 获取更多信息。 |
3.2.5 按需更改 (AAA) |
可能导致用户混淆或迷失方向的上下文更改仅应在用户请求时发生,或者用户应该能够关闭它们。 如果你需要做一些会显着改变当前视图(例如内容或控件)的事情,让用户控制他们希望何时发生这种改变(例如,显示哪个页面,何时前进到图库中的下一张照片...)。 如果你需要在页面上使用像轮播这样的功能,提供一个选项来停止它自动前进。如果可能,最好避免使用这种功能。 |
|
3.2.6 帮助一致性 (A) |
包含帮助机制的网页(包括自助选项和人工联系方式),这些机制在多个网页上重复,需要将这些机制以相同的顺序放置在所有页面上,除非用户启动更改。 |
查看 一致性帮助文档 了解有关此标准的更多信息。 |
注意: 同时请查看 WCAG 对 指南 3.2 可预测性:使网页以可预测的方式出现和运行 的描述。
指南 3.3 — 输入辅助:帮助用户避免和纠正错误
该指南围绕着帮助用户以最少的错误输入必要的信息。
成功标准 | 如何符合标准 | 实用资源 |
---|---|---|
3.3.1 错误识别 (A) |
当用户填写表单或在选项之间进行选择时,应向用户清楚地报告检测到的任何错误,以及与错误相关的表单控件。 建议通过 HTML 表单验证功能和/或 JavaScript 实施客户端错误检测和处理,无论哪种方法最适合你的情况。当检测到错误时,应该在有错误的表单输入旁边显示直观的错误消息,以帮助用户更正其输入。对于屏幕阅读器用户,你可以使用 aria 实时区域来提醒用户页面上的更改。 注意: 服务器端验证应始终与客户端验证一起使用。客户端验证很容易被关闭或绕过,因此不能单独依赖它。 |
请查看 表单数据验证 获取全面的验证信息,以及 WAI-ARIA:动态内容更新 获取有关实时区域的信息。 |
3.3.2 标签或说明 (A) |
在需要数据输入时,应提供清晰的说明。当需要简单的说明或提示时,你可以使用 如果需要更复杂的解释,你也可以始终包含解释性段落,或者你可能需要尝试使你的表单更直观。 |
|
3.3.3 错误建议 (AA) |
当检测到错误并且已知更正建议时,向用户提供这些建议(例如,当用户选择已存在的用户名时,建议替代方案),除非这样做会导致安全问题(例如输入密码)或上下文问题(例如,他们试图回答测验应用程序中的问题)。 在这种情况下,如果合适,你可能需要使用 JavaScript 和服务器端功能的组合来检查输入是否正确,如果输入不正确,可以向用户提供哪些可行的建议。这些建议应该在上下文中以有用的方式显示,就像错误消息一样(参见 3.3.1)。 |
还没有教程建议。 |
3.3.4 错误预防(法律、财务、数据)(AA) |
在涉及敏感数据输入的表单(例如法律协议、电子商务交易或个人数据)的情况下,以下至少一项应为真
|
可逆 - 对于任何可以输入数据的视图,提供一个等效的视图,允许你根据需要编辑或删除条目(例如,请查看 Django Web 框架)。 检查数据 - 如 3.3.1 中所述,应使用客户端和服务器端验证的组合来检测错误并向用户显示有用的消息,以允许他们更正其输入。 确认和更正 - 在适当的情况下,在填写一系列表单字段以执行任务(例如购买产品)后,应向用户显示一个确认屏幕,让他们可以在其中查看其输入并更正任何看起来不对的地方。这种模式通常用在亚马逊等电子商务网站上。 |
3.3.5 可用上下文敏感帮助 (AAA) | 在上下文中提供说明和其他适当的提示,以帮助完成和提交表单。 | 这实际上只是在 3.3.1 和其他类似标准的基础上,需要更全面的上下文帮助信息和服务,例如,在每个页面上提供一个指向帮助页面或服务的专用链接,提供成功完成应该是什么样子的示例。 |
3.3.6 错误预防(所有)(AAA) | 这一原则是在 3.3.4 的基础上,将其要求扩展到所有用户输入情况,而不仅仅是涉及敏感数据的用户输入情况。 | 同样,请查看 3.3.4。 |
3.3.7 重复输入 (A) | 在相同流程或用户流程中,用户之前已输入或提供的必要信息,要么自动填充,要么从选项列表中提供给用户选择,除非重新输入信息对于安全原因至关重要或必不可少,或者信息已失效。 | 查看 了解重复输入 了解更多信息。 |
3.3.8 可访问身份验证(最低)(AA) | 除非提供替代方案,例如物体或个人内容(例如图像、视频和音频)识别,或辅助机制(例如复制和粘贴以及自动保存密码),否则任何身份验证流程中的任何步骤都不需要认知功能测试,例如记住密码。 | 查看 可访问身份验证文档 了解有关此标准的更多信息。 |
3.3.9 可访问身份验证(增强)(AAA) | 任何身份验证流程中的任何步骤都不需要认知功能测试,例如记住密码,除非提供不依赖于认知功能测试或提供机制来帮助用户完成认知功能测试的替代方案。允许需要用户识别物体或识别用户提供给网站的非文本内容的身份验证测试。 | 查看 增强型可访问身份验证文档 (AAA) 了解更多信息。 |
注意: 同时请查看 WCAG 对 指南 3.3 输入辅助:帮助用户避免和更正错误 的描述。