简单了解下无障碍设计模式

无障碍

无障碍设计使任何人（无论什么能力）都能成功地浏览、理解和使用您的应用。

原则

一款设计良好的产品可供所有能力的用户使用，包括视力低下、失明、听力障碍、认知障碍或运动障碍的用户。改进产品的无障碍功能可以增强所有用户的可用性，这是非常值得做的事情。

Material design 的内置的无障碍功能将帮助你的应用适应所有用户。本节内容主要适用于移动端 UI 设计。有关设计和开发完全无障碍的产品的详情，请访问Google 无障碍网站。

明确的

通过使用清晰的布局设计、功能明确的操作，来帮助用户浏览你的应用。每添加一个按钮、图片或一行文本都会使界面变得更加复杂，可以通过以下方式简化你的应用：

• 清晰可见的元素
• 足够的对比度和尺寸
• 明确的重要性级别
• 使主要信息一目了然

健全的

使你的应用能适应各种用户。用户可能只有短暂的注意力，对你的产品不熟悉，或使用纯文本屏幕阅读器（使用语音合成器朗读文本或使用盲文显示器产生触觉）。你的应用应该方便每位用户来：

• 浏览：使用户清楚的知道他们现在在应用中的哪个位置，以及哪些是重要内容
• 了解重要任务：通过多个视觉和文本提示来强化重要信息。使用颜色、形状、文本和动效来传达正在发生的事情
• 访问你的应用：包含适当的内容标签，以适应那些使用纯文字版本的用户

具体的

支持特定平台的辅助技术，就像支持触摸、键盘和鼠标的输入方式一样。例如，确保您的 Android 应用可以和 Google 的屏幕阅读器 “TalkBack” 配合使用。

辅助技术通过屏幕阅读器、放大设备、轮椅、助听器或记忆辅助设备等设备帮助增强、维持或改善残疾人的能力。

颜色和对比度

使用颜色和对比度来帮助用户查看和解读应用的内容，与正确的元素交互，并理解操作。

无障碍调色板

为应用选择支持可用性的主色、辅助色和强调色。确保元素之间有足够的颜色对比度，以便视力低下的用户也可以使用你的应用。

对比度

基于亮度或发光强度，颜色和它的背景色的对比度范围为 1 - 21，和万维网联盟（W3C）一致。

对比度表示两种颜色之间的差异程度，通常写为 1:1 或 21:1。两个数之间的比值越高，颜色之间的相对亮度就越大。

W3C 推荐在正文文本和图片中使用以下对比度：

• 小文本和它的背景色之间至少有 4.5:1 的对比度
• 大文本（加粗的14pt/普通的18pt及以上）和它的背景色之间至少有 3:1 的对比度

正确示例

这些文本遵循颜色对比度建议，和它们的背景色之间有清晰的对比。

错误示例

这些文本没有遵循合颜色对比度建议，在它们的背景色中很难进行阅读。

图标或其他关键元素也应使用上述推荐的对比度。

正确示例

这些图标遵循颜色对比度建议，和它们的背景色之间有清晰的对比。

错误示例

这些图标没有遵循颜色对比度建议，在它们的背景色中很难进行阅读。

Logo 和装饰性的元素

虽然装饰性元素（例如 Logo 和插图）不需要满足对比度建议，但如果它们有比较重要的功能，那么它们应该有一定的辨识度。

正确示例

有辨识度的装饰性元素不需要满足对比度建议。

错误示例

没有必要扭曲你的 Logo 来满足对比度建议。

其他视觉提示

对于色盲或看不到颜色差异的用户，除了颜色外还增加了设计元素，以确保他们能接收到和正常人等量的信息。

色盲症分不同的类型（包括红绿色盲、蓝黄色盲和单色色盲）。对于重要的状态，可以同时使用多个视觉提示。使用下划线、指示符、图案或文本等元素来描述操作和内容。

正确示例

文本字段的错误状态使用了多个提示来传达：标题颜色、文本字段下划线、字段下面的错误提示。

错误示例

这个文本字段的错误状态仅使用了彩色下划线，可能会被色弱的用户忽略。

声音和动效

声音

给视觉元素添加声音作为替代方案，反之亦然。添加可隐藏的字幕，或其他视觉元素来作为重要声音元素和声音警报的替代方案。

通过在 UI 元素上添加描述性的标签，使用户可以通过声音在应用中导航。当使用屏幕阅读器（如 “TalkBack” ），并通过触摸板导航时，在用户指尖触摸到 UI 元素时，会大声读出标签上的文本。

应避免使用以下声音：

• 通过屏幕阅读器播放不必要的声音，例如打开网页时自动播放的背景音乐。如果有背景音乐，请确保用户可以安全的暂停或停止背景音乐。
• 添加到原生元素上的额外的声音（屏幕阅读器能够正确的翻译原生元素）

标记用户界面元素

给输入控件和其他元素添加描述，供屏幕阅读器等设备可以进行朗读

动效

Material design 使用动效来引导视图之间的焦点，以避免用户分心。把表面转换为焦点以供用户跟踪，并移除不重要的元素。

为了使具有运动和视觉敏感性的用户能舒适地使用界面，请遵循 Material Design 运动规范，该规范支持 W3C 的以下运动指南：

• 如果内容持续移动、滚动或闪烁的时间超过 5 秒，则会暂停、停止或隐藏
• 在 1 秒内，内容的闪烁次数限制为 3 次，以满足闪烁和红色闪烁的阈值
• 避免闪烁屏幕中较大的中心区域

定时控件

应用中的控件可以设置为在一定时间后消失。例如，播放视频 5 秒后，播放按钮控件可能会从屏幕上淡出。

高优先级的控件 避免在有高优先级功能的控件上使用定时器，因为如果这些控件消失的太快，用户可能不会注意到这些控件。例如，当焦点聚焦到控件上时， TalkBack 会大声朗读出控件，如果为其加上了定时器，可能会阻止控件完成某些任务。

对于有其他重要功能的控件，请确保用户可以再次启用控件、或可以通过其他途径执行相同的功能，在层次和焦点中了解更多。

自动朗读文本

阅读关于在活跃区域放置文本的信息。

样式

布局

Material Design 的触摸目标指南使那些无法看到屏幕、或者运动不灵活的用户能够点击应用中的元素。

触摸目标

触摸目标是屏幕中响应用户输入的部分。它们向外延伸，并超过元素的视觉边界。例如，图标可能显示为 24 x 24 dp，但是加上图标周围的边距，则构成了 48 x 48 dp 的触摸目标。

触摸目标应该至少为 48 x 48 dp。不管屏幕有多大，这种尺寸的触摸目标都相当于大约 9mm 的物理尺寸。推荐的触摸目标的尺寸为 7-10mm。可能需要使用更大的触摸目标来适配更大范围的用户，例如运动能力还在发展中的儿童。

触摸目标间距

在大多数情况下，触摸目标应该以 8dp 或更大的间距进行分隔，以确保均衡的信息密度和可用性。

头像：40dp 图标：24dp 两者的触摸目标：48dp

触摸目标示例

触摸目标高度：48dp 按钮高度：36dp

触摸目标和按钮示例

分组项目

把相关的项目放在一起，对那些视力低下或者在屏幕上聚焦困难的用户是有帮助的。

正确示例

滑块值和滑块控件非常接近。

错误示例

滑块值和滑块控件之间的距离太远。对于放大了屏幕的用户，如果不在滑块和值之间来回浏览的话，可能不能同时看到滑块和值。

字体

为了提高可读性，用户可能会增加字体大小。移动设备或浏览器有调整系统字体大小的功能。要在 Android 中使用系统字体大小，使用可缩放像素（sp）来标记文本极其关联容器。

确保为大型字体和外语字体分配了足够的空间。有关推荐的外语字体大小的信息，请参阅行高。

层次和焦点

应用应该给用户反馈，并使用户了解他们在应用中的位置。导航控件应该便于定位，且书写清晰易懂。视觉反馈（如标签、颜色和图标）和触摸反馈向用户显示了可用的 UI。

导航应该具有清晰的任务流程，和最少的步骤。在频繁使用的任务上，应该实现聚焦控制、或控制键盘和读取焦点的功能。

启用焦点导航

使用焦点控制导航

屏幕阅读器

屏幕阅读器为用户提供了多种屏幕导航的方法，包括：

• 屏幕阅读器的触摸界面允许用户在屏幕上移动手指，以听到手指正下方的内容。这使用户能快速了解整个界面。或者用户可以凭借肌肉记忆快速移动到指定 UI 元素。在 TalkBack 中，此功能被称为 “通过触摸浏览” 。用户必须双击才能选择一个项目。
• 用户也可以在屏幕上向前或向后滑动来移动焦点，来从上到下线性地阅读页面。这允许用户在某些元素上进行训练。在 TalkBack 中，这称为线性导航。

用户可以在 “通过触摸浏览” 和 “线性导航” 模式之间切换。当页面使用合适的语义化标签时，一些无障碍技术允许用户在页面的这些标记（例如标题）之间导航。

硬件或软件方向控制器（例如 D-pad、轨迹球或键盘）允许用户以线性的方式从一个选择的元素跳到另一个元素。

层次

根据项目的相对重要性，将项目放置在屏幕上。

• 重要操作：将重要操作放在屏幕的顶部或底部（使用快捷方式即可访问）
• 相关项目：将相似层级的相关项目放在彼此相邻的位置

正确示例

通过把重要的操作放在屏幕顶部，使它们在层次结构中显得更重要。

错误示例

当把重要的操作嵌入到其他内容中时，就不清楚什么是页面中最重要的元素。

焦点顺序

输入焦点应该按照视觉布局的顺序排列，从屏幕顶部到底部。它应该从最重要的项目到最不重要的项目进行遍历。确定以下的焦点和移动方式：

• 元素接收焦点的顺序
• 元素分组的方式
• 拥有焦点的元素消失时，焦点移动到哪里

通过视觉指示器和辅助文本的组合，来阐明焦点的位置。

分组

在标题下对类似项目进行分组，以告诉用户这个分组代表什么。这些分组会在空间上组织内容。

过渡

屏幕和任务之间的焦点遍历应尽可能保持连续。

如果一个任务中断了，然后又恢复，请将焦点放在之前聚焦的元素上。

绿色圆圈表示屏幕中的元素接收焦点的顺序。

实施

通过使用标准的平台控件，你的应用将自动包含与平台无障碍技术协同工作所需的标记和代码。调整你的应用，以兼容每个平台的无障碍功能标准和无障碍技术（包括快捷方式和结构），为用户提供更高效的体验。

正确示例

此屏幕使用了标准平台的对话框。

错误示例

此屏幕使用非标准平台的对话框来执行一个标准的对话框任务。这种实现会需要额外的编码和测试，以使这种非标准控件和无障碍技术相兼容。

在打开平台无障碍功能的情况下，测试你的设计（实施期间和之后）。

其他设计的注意事项：

• 使用可缩放文字和一个宽敞的布局，来适应那些可能开启大文字、颜色矫正、放大或其他无障碍功能的用户
• 键盘/鼠标界面可以仅通过键盘就能访问所有任务和所有悬浮信息
• 触摸界面应允许屏幕阅读器和其他无障碍设备读取界面中的所有内容。朗读的文本应该是有意义的和有帮助的。

正确示例

这个 UI 已经过缩放，能很好的和放大倍数的界面以及大文字适配。

错误示例

这个 UI 没有经过缩放，不能和放大倍数的界面以及大文字适配。部分内容被重叠或截断。

使 UI 元素的标签可视化

屏幕阅读器用户需要知道屏幕中哪些元素是可以点击的。要使屏幕阅读器大声朗读出组件的名称，请向组件（如按钮、图标、仅含图标不含可见文本的 Tab 选项卡）添加 contentDescription 属性。

标签化 UI 元素

1. 标记搜索图标 2. 标记麦克风图标

1. 标记编辑图标 2. 标记聊天图标

帮助文档

任何具有特殊无障碍功能的功能都应包含在帮助文档中。确保帮助文档的相关性、可访问性和可发现性。例如，查看本指南，了解如何在 Google Drive 中使用屏幕阅读器。

测试和研究

遵循这些无障碍指南有助于提升应用的可访问性，但不能保证拥有一个完全可访问的体验。建议你也：

• 在打开各种无障碍技术的情况下，测试应用从开始到结束的完整的任务流程。例如，在 TalkBack 中打开 “通过触摸浏览” ，并改变大声说出文本的速度。
• 让有障碍的用户测试你的应用
• 考虑单个元素怎么才能可访问，同时把它连接到一个连贯的用户流中
• 确保你希望用户完成的主要任务，能适应每一个人

与你的用户交流，特别是那些使用辅助技术的用户，了解他们的需求，他们想从你的应用中获得什么，它们使用什么工具，以及如何使用这些工具。开始熟悉这些工具，然后你可以给他们最好的用户体验。

人们以不同的方式使用无障碍技术。

书写

清晰且有帮助的无障碍文本是使 UI 更易访问的主要方法之一。视力低下或没有视力的用户会从清晰易懂的文字描述中受益。无障碍文本是指供屏幕阅读器软件使用的文本，例如 Android 上的 TalkBack、iOS 上的 VoiceOver、桌面端的 JAWS。屏幕阅读器会大声朗读屏幕上所有的文本，包括可见和不可见的替代文本。

无障碍文本包括可见文本（包括 UI 元素中的标签、按钮中的文字、链接和表单）和不可见的描述（没有文本标签的按钮的替代文字）。有时，可以使用无障碍文本覆盖屏幕中的标签，来为用户提供更多信息。

可见和不可见的文本都应该是有用的描述性的词，并且都有独自的含义，因为有些用户会使用页面中的标题和链接进行导航。使用屏幕阅读器测试你的应用，以确定那些缺失无障碍文本、或需要更好的无障碍文本的区域。

保持简洁

保持内容和无障碍文本简短、并切中主题。屏幕阅读器用户会听到每个 UI 元素的朗读。文本越短，屏幕阅读器用户导航速度越快。

切换到 heyfromjonathan@gmail.com

正确示例

书写明确和简短的无障碍文本。

账户切换器。切换到账户 heyfromjonathan@gmail.com

错误示例

不要写太长的无障碍文本。

避免在文本中包含控件类型和状态

屏幕阅读器会通过声音、或通过在无障碍文本前后说出控件名称，来自动声明控件的类型和状态。

搜索

正确示例

使用简短的说明。

搜索字段

错误示例

不要写控件类型。

开发人员注释：如果控件类型和状态没有被正确读取，则可能是控件的无障碍角色设置不正确，或者是一个自定义控件。网站上的每个元素都应该有一个相关的无障碍角色，或者通过代码为其声明一个角色。这意味着按钮应该设置成按钮、复选框应该设置成复选框，以便将控件的类型和状态正确传达给用户。如果一个元素是从一个原生的 UI 元素上扩展或继承的，他会获得父元素的角色。如果不是，你可以在每个平台上为无障碍重写这些信息（用于 Web 的 ARIA，用于 Android 的 AccessibilityNodeInfo）。

在 Android，将控件的 AccessibilityNodeInfo 类名字段设置为 “android.widget.Button”。

构建无障碍的自定义视图

仅用过 Wi-Fi 下载

正确示例

使用简短的说明。

已选择通过 Wi-Fi 下载

错误示例

不要写出状态。

指示元素的作用

使用动作动词来指明一个元素或链接的作用，而不是一个元素的外观，以便视觉障碍用户能够理解。链接文本应该是：

• 指明点击链接后将执行的任务
• 避免使用模糊的描述，例如 “点击此处”

确保所有用到该元素的地方，该元素的描述都保持一致。

正确示例

朗读的描述指明了由图标表示的操作。

错误示例

描述图标的外观无法清楚的表明操作的作用。

正确示例

导航菜单的无障碍文本可以是 “显示/隐藏导航菜单” （首选）或者 “显示/隐藏主菜单” （可接受）。

错误示例

朗读时，文本 “侧面抽屉” 无法指明会发生什么操作。

状态可以变化的元素

对于可以在值和状态之间切换的图标，根据向用户呈现内容来确定使用什么类型的图标。

• 如果图标是一个项目的属性，则将其设置为复选框，以便屏幕阅读器能读出当前状态，例如 “打开” 或 “关闭”
• 如果图标是一个操作，使用文本标签来指明选中图标后会发生的操作，例如 “添加到心愿单”

元素的使用方式会影响它们的显示方式。例如星形图标表示添加到心愿单的操作，则应用应该说出 “添加到心愿单” 或 “从心愿单中移除”。

不要提及确切的手势和交互

不要告诉用户如何与控件进行身体上的交互，因为它们可能使用键盘或其他设备进行导航，而不是用手指或鼠标进行导航。无障碍软件会为用户描述正确的交互方式。

正确示例

此命令 “语音搜索” 描述和用户输入法（语音）相匹配的任务（搜索）。

错误示例

此命令 “点击” 是不准确的，因为这不是激活此控件的唯一方式（它也可以通过按下键盘、开关切换或盲文显示来激活）。由于本例中用户的主要任务是搜索，所以操作应该使用如上文所提到的文字，而不应该使用 “说话”。

确认操作

使用对话框、toasts、或 snackbars（Android）来确认或确知具有破坏性的用户操作（例如 “删除” 或 “移除”），或者提示用户此操作不能撤销。

对于通过视觉方式确认的操作（例如，在删除一个项目时重新排列网格的布局），不需要 toast。在这些情况下，添加无障碍文本以提供确认。

提供提示语音

提示语音为不明确的操作提供额外的信息。例如，Android 的 “双击以选择” 功能提示用户在选择一个项目时需要点击两次。Android 的 TalkBack 也会提醒和元素相关联的任何自定义操作。谨慎使用提示语音，确保只在复杂的 UI 上使用提示语音。