设计无障碍读屏体验
你知道盲人是如何使用手机的吗？受益于无障碍读屏，盲人能在看不到屏幕的情况下，让手机读出屏幕上的每项内容。结合简易的手势、语音输入，盲人也能和明眼人（即视觉无碍的人）一样自由地享受科技。
无障碍读屏体验的重要性主要体现在以下 3 个方面:
满足用户需求
我们坚信，每个人都应该能平等地使用数字产品、服务，而不受视觉能力的限制。通过考虑视障群体的诉求，我们可以打破数字世界中的障碍，使他们能够与其他用户一样获得信息和参与交互。
提升产品竞争力
优良的无障碍读屏体验可以增加产品的吸引力、竞争力。若视障群体能轻松使用产品，他们会感受到关注、尊重。这种积极的用户体验将增加他们对产品的满意度，并提升他们继续使用、推荐产品的可能。
推动科技向善
推行无障碍读屏体验符合联合国《残疾人权利公约》的精神，该公约呼吁各方关注并消除残疾人面临的障碍，以促进社会的包容、可持续发展。通过为视障群体提供更好的用户体验，我们也在推动科技的持续向善。
可见，无障碍读屏体验是不可忽视的。因此，我们建议将无障碍读屏体验纳入到日常设计的考量范围内。
参考 WCAG 2.2，无障碍读屏体验的设计原则有以下 3 点：
Perceivable 能和明眼人一样在应用中获取信息。
Operable
能完成和明眼人几乎一样多的操作。
Understandable
对应用内的信息，能达到和明眼人接近的理解效果。
目前，市面上有诸多读屏应用。其中，最为常见的的系统级读屏应用主要有以下 3 个：
尽管本文的内容更侧重于触摸屏环境中的 VoiceOver 和 TalkBack，但整体设计思想是通用的。
无障碍读屏体验中，主要有以下 3 种交互模式：
Linear Navigation 读屏应用是以线性的顺序（sequentially）探索、朗读屏幕上的 UI 元素的。以 iOS 端的 VoiceOver 为例：向右轻扫选择下一项，向左轻扫选择上一项，焦点所在元素的内容会被朗读，双击即可触发元素。
Direct Command
和明眼人一样，视障用户同样可以通过语音助手、捷径（shortcuts）、快捷键（keyboard shortcuts）等功能实现更为直接、高效的交互。
关于快捷键，建议搭配阅读我们之前发布的《设计快捷键》一文。
Explore by Touch
视障用户也可以直接将手指按在屏幕的特定位置，以让焦点直接抵达此位置，而无需通过 linear navigation 的顺序一步步导航至此。
可见：
1. 保证可交互元素的响应热区足够大，也有利于无障碍读屏体验。
2. 若能保持 UI 元素位置稳定，视障用户也能通过形成肌肉记忆来提升无障碍读屏效率。
此外，用户还可以可通过盲文阅读器（braille display）等外接设备进行无障碍读屏。
Accessibility attributes 指的是 UI 元素被读屏应用朗读的内容。
为 UI 元素设计其 accessibility attributes 是无障碍读屏体验中至关重要的一环。因为，读屏应用朗读的内容几乎就是视障用户能获取到的所有信息。
通常，读屏应用会为各个元素按以下顺序朗读 accessibility attributes：
Label
Value
Traits
Hints
Label 指的是用于描述 UI 元素的文本。
默认情况下，label 的值等于 UI 元素在屏幕上展示的文本。若 UI 元素不含文本，则需手动为其填写 label。
举几个例子：
一个 button 的 label 是「添加」，和它在屏幕上展示的文本一致；
一个 icon 的 label 是「播放」，尽管在屏幕上它并没有文本标签。
Value 指的是 UI 元素当前的值、内容、已选项。
Value 是非必填项。只有当元素的 label 无法清晰描述其当前值或内容时，才需添加 value。
举几个例子：
一个 slider 的 label 是「屏幕亮度」，其当前的 value 是「60%」。
一个 pull-down button 的 label 是「性别」，其当前的 value 是「女」。
Traits 指的是用于描述 UI 元素的状态（state）、行为（behavior）、用途（usage）的文本。
每个元素都至少要有 1 个 trait。因为，操作系统需根据元素的 traits 来赋予其不同的交互特性。
举几个例子：
虚拟键盘中的按钮的 traits 为「Keyboard Key」。
音乐播放器中的播放按钮的 traits 为「Button, Starts Media Session」。
Hints 指的是用于描述 UI 元素执行结果的文本。
Hints 是非必填项。只有当元素的 label 无法清晰描述其执行结果时，才需添加 hints。
Hints 不一定会被朗读，因为用户可以在设置中选择是否让读屏应用朗读 hints。可见，我们可以将 hints 理解为是为「非熟练用户」提供的内容。
举几个例子：
一个 butoon 的 label 是「收藏」，其 hints 可以是「收藏内容更新时会提醒你」。
一个 icon 的 label 是「一键三连」，其 hints 可以是「轻点两下来同时点赞、收藏、关注」。
Rotor（转子）是 VoiceOver 中的一种工具，用于在触摸屏环境下提供各种快捷设置、实用功能。在不同的页面、场景，rotor 提供的选项会有所不同。
其使用方法为：
在屏幕上转动双指，即可唤出 rotor。
继续转动手指可以听取更多选项。
听到想要的选项时，停止转动手指，然后用手指在屏幕上上下轻扫就可以使用、更改选项了。
举几个例子：
在电子书应用中，可以唤出 rotor 并选取「语速」选项。接着，上下轻扫即可更改朗读语速。
在文档应用中，可以唤出 rotor 并选取「标题」选项。接着，上下轻扫即可使用「只读标题」的功能。
可见，rotor 能提供更快、更灵活的页面访问方式。
以下是常见的 rotor 选项及其效果：
| Rotor 选项 | 效果 |
|---|---|
| Character | 移至下一个/上一个字符 |
| Word | 移至下一个/上一个单词 |
| Line | 移至下一/上一行 |
| Speech Rate | 提高/降低语速 |
| Volume | 提高/降低音量 |
| Container | 将焦点从一个容器移至另一个容器 |
Item chooser（项目选取器）是 VoiceOver 中的一种工具，用于快速选择特定 UI 元素。其特别适用于页面中有大量元素的场景。
其使用方法为：
在屏幕上用两根手指轻点三下屏幕，即可唤出 item chooser。
接着，可以通过索引或搜索来选择特定 UI 元素。
为体系化地设计无障碍读屏体验，我们建议采取以下设计流程：
确定读屏范围
定义读屏顺序
进行元素分组
设计朗读内容
设计朗读方式
并非页面上的所有信息都需要被读屏应用朗读。因为，对于视障用户来说，纯装饰性的、用于构建视觉层级的 UI 元素是不需要的。
举几个例子：
模块间的分割线；
构建卖场氛围的背景插画。
建议使 focus order 与明眼人的 visual order（视线流）一致，而不是使用的「从左到右、从上到下」的默认顺序。
这与为键盘导航设计 tab order 的思路是一致的。可见，稳健的键盘导航体系是无障碍读屏体验的坚实基础。关于键盘导航，建议搭配阅读我们之前发布的《设计键盘导航》一文。
这样做主要能为我们带来以下 2 方面的好处：
提供清晰的信息结构 更清晰的信息结构使得视障用户能够更好地理解页面的组织、导航方式，从而更有效地浏览内容。如：
将「飞行模式」文本和一个 switch 放在同一组中，读屏软件就能将其朗读为：「飞行模式，切换按钮，关闭，轻点两下来切换设置」。若不放在同一组中，我们就需听完「飞行模式」后向右轻扫，才能听到「切换按钮，关闭，轻点两下来切换设置」。况且，当下所听到的「切换按钮」具体应用的对象也是不清晰的。
大幅简化导航和操作
通过将相关元素分组，可以使视障用户更轻松地导航和操作页面。
举几个例子：
1. 将列表项及其侧滑出现的「标为未读」「不显示」「删除」放在同一组中，当读屏焦点抵达此列表项时，读屏应用会提示用户有 custom action 可用。用户不需要将读屏焦点离开此列表项，即可向上或向下轻扫来完成「标为未读」「不显示」「删除」。
2. 将瀑布流中的帖子及其「点赞」按钮放在同一组中，当读屏焦点抵达此帖子时，读屏应用会提示用户有 custom action 可用。用户不需要将读屏焦点离开此帖子，即可向上或向下轻扫完成「点赞」。
清晰、简洁、有条理的朗读内容是无障碍读屏体验的重点。
以下是面向 label、traits、hints 等 accessibility attributes 的设计指引。
力求简洁
简洁的 label 能带来更高的读屏效率。
举几个例子：
UI 元素的 label 还能用于语音控制、盲文阅读。因此，若标签不够简洁，语音控制和盲文阅读的交互成本将显著提升。
不含元素的类型信息
UI 元素的类型信息应体现于 traits 中，如：文件管理器中的删除按钮，其 label 应被写为「删除」，而不是「删除按钮」。
随 UI 更新
如：原 label 为「添加」的图标按钮，在完成添加操作后，其图标会变为垃圾桶的样式，其 label 也应更新为「删除」。
为含语义的动画添加 Label
如：表达加载的动画元素的 label 可以写为「正在加载」。
为含语义的图片添加 Label
含有文本的图片、表达特定信息的图片（如数据图、示意图等）都需要添加用来描述图片信息的 label。如：用来表达页面无内容的插画的 label 可以写为「暂无内容」。
本地化
支持系统的首选语言。
1. 音乐播放器中的 3 个主按钮，其 label 应被写为「上一首」「下一首」「播放」，而不是「上一首歌曲」「下一首歌曲」「播放这首歌曲」。
2. 文件管理器中的删除按钮，其 label 应被写为「删除」，而不是「把文件从当前文件夹删除并放入回收站」。
只有当 UI 元素的 label 无法清晰描述其当前值或内容时，才需添加 value。
随意为元素添加 value 可能会导致读屏应用的朗读内容过于冗长或不合逻辑。
以 VoiceOver 为例，其提供以下 3 类 traits 选用：
| 类型 | Trait |
|---|---|
| State | Selected |
| State | Not Enabled |
| Behavior | Adjustable |
| Behavior | Update Frequently |
| Behavior | Causes Page Turn |
| Behavior | Play Sound |
| Behavior | Starts Media Session |
| Behavior | Allows Direct Interaction |
| Behavior | Modal |
| Usage | Button |
| Usage | Link |
| Usage | Tab Bar |
| Usage | Toggle |
| Usage | Search Field |
| Usage | Keyboard Key |
| Usage | Summary Element |
| Usage | Header |
| Usage | Image |
| Usage | Static Text |
以下是针对部分 traits 的设计指引。
Selected
用于表明 UI 元素是当前选定的项目。如：tab、segmented control 上被选定的项目等。
Not Enabled
用于表明 UI 元素是不可交互的。
Adjustable
用于表明 UI 元素的 value 可以被更改。如：slider、pull-down button 等。
读屏应用会告知用户可以在此元素上垂直滑动以更改 value。
Update Frequently
用于表明 UI 元素的 label 或 value 会变化。
这会让设备定期轮询此元素以获取更新。因此，为不必要的元素添加此 trait 会降低设备的性能和电池寿命。
Causes Page Turn
用于表明 UI 元素用于翻页。如：在电子书中用于翻页的 button 等。
Play Sound
用于表明 UI 元素一旦被激活就会播放声音。
Starts Media Session
用于表明 UI 元素一旦被激活就会开始播放或录制媒体。
Allows Direct Interaction
用于表明 UI 元素允许直接进行触摸交互（即明眼人操作手机的常规形式）。
此 trait 适用于直接触摸交互是合理形式的场景，如：
1. 在 GarageBand 中使弹钢琴；
2. 在图片编辑器中绘画。
Modal
用于表明 UI 元素是以模态的形式呈现的。
这会让读屏应用暂时忽略模态视图以外的内容。
Link
一般情况下，用于表明 UI 元素能导航到特定网页或拨打电话。
按惯例，用于在应用内导航的元素应使用 button 这一 trait。
Search Field
用于表明 UI 元素允许输入字符串以执行搜索。
Summary Element
用于表明 UI 元素提供当前页面内容的概览。如：iOS 原生天气应用顶部的摘要部分。
这会让读屏应用一进入此页面的时候就开始朗读此元素（无论此元素在视图层次结构中的位置如何），但导航顺序不会受到影响。
Header
用于表明 UI 元素是分隔内容的标题。如 navigation bar title、table section header 等。
借助前面提到的 rotor，我们可以让读屏应用跳过大段内容并仅朗读这类元素。对于视障群体来说，这应是一项基本技术。因为，他们无法直观地浏览屏幕以快速了解、定位信息。
每个页面都至少有一个这类元素。
Image
用于表明 UI 元素是含语义的图片。纯装饰性的图片则无需添加此 trait。
一般来说，此 trait 不应用于图像按钮，但可用于可以点击以获得更大版本的图片。
Static Text
用于表明 UI 元素是用户无法更改或很少更改的静态文本。
一般来说，此 trait 不应用于图像按钮，但可用于可以点击以获得更大版本的图片。
简明扼要地描述执行结果
尽管很少有 UI 元素需要 hints，但还是需尽可能让 hints 保持简短，以减少用户在使用该元素之前必须花费的时间。
省略主语，并以动词开头
在撰写 hint 时，可以想象我们是在向朋友描述如何使用此元素。如：我们会说「你轻点两下来这个按钮就可以播放音乐了」，所以此元素的 hint 就可以写为「轻点两下来播放歌曲」。
不含元素的类型信息
UI 元素的类型信息应体现于 traits 中
因此，诸如「轻点两下按钮来播放歌曲」「轻点两下链接来购买礼包」「轻点两下按钮来删除项目」都是不理想的 hints，更优的写法是「轻点两下来播放歌曲」「轻点两下来购买礼包」「轻点两下来删除项目」。
在英语环境下，用动词的第三人称单数形式
如：使用第三人称单数形式「Plays」，而不是命令式的「Play」。因为，命令式的表达会让 hints 听起来像命令。「Plays」传达的是「Tapping this control plays the song」，而「Play」更像是在传达「You must to play the song」。
在英语环境下，以大写单词开头，以句号结尾
尽管 hint 是一个短语，而不是一个句子，但以句号结束提示有助于读屏应用以适当的语调来朗读。
本地化
支持系统的首选语言。
4.5 用 Design Token 管理 Accessibility Attributes
我们建议从 component 层面开始设计朗读内容：将 label、value、traits、hints 作为 design token 的 property，以实现更为科学、高效的设计管理。
关于 design token，建议搭配阅读我们之前发布的《给设计师的 design token 指南》系列文章。
贴合逻辑、符合语境、富有情感的朗读形式能提升无障碍读屏的体验。
为向读屏应用指明该以什么样的形式、语气来朗读，我们可以使用以下属性：
Language
Spell Out
Punctuation
Phonetic Notation
用于指定使用何种形式来朗读数字。如：
对于电话号码「10086」，可指定朗读为「一零零八六」，而不是「一万零八十六」。
对于订单号「266 900 828」（为方便识别，此订单号采用每三个数字为一组的形式），可指定朗读为「二六六 九零零 八二八」，而不是「二百六十六 九百 八百二十八」或「二亿六千六百九十万零八百二十八」。
对于时间「2023/08/23 16:00」，可指定朗读为「二零二三年八月二十三号 十六点整」，而不是「二千零二十三，斜杠，八，斜杠，二十三，斜杠，十六比零」
用于指定对特定字词的口音、音高、语气等。如：
对于「番禺」，可指定朗读为「pān yú」，而不是「fān yú」；
对于「下个路口左转」，对于明眼人来说，能看到「左转」被加粗强调，所以应让读屏应用在朗读「左转」时提升音高（pitch）以起到等效的强调效果。
在英语环境下，我们还可以指定是否将缩写（abbreviation）以全称形式朗读。如：对于「BG」「FG」，可分别指定朗读为「Foreground Color」「Background Color」。
此外，在 visionOS 中，我们还可以运用 Spacial Audio 来构建更为丰富的发声模式。
对于一些信息较多的 UI 元素（特别是由多个子元素组合构成的复杂元素），我们可以让读屏应用默认只读其关键信息，而其他信息则需用户通过激活 rotor 中的「more content」选项才会被朗读。
由此，用户可以在他们需要或感兴趣的情况下才去听更多信息，而无需被大量信息所淹没。这是「Progressive Disclosure」设计模式的一种。
举几个例子：
在理财产品售卖页，每个列表项均有很多信息。若让读屏应用挨个阅读，效率势必差强人意。因此，我们可以将诸如「风险等级」「成立以来最大回撤」等附加信息指定为「more content」。这样一来，只有当用户想进一步了解此产品的信息时，才需通过 rotor 选择「more content」选项，并通过向上或向下轻扫的手势来依次听取这些附加信息
在机票售卖列表页，我们也可以将诸如「航空公司」「餐食」「机上 Wi-Fi」等附加信息指定为「more content」。
对于一些信息较多的页面，我们可以将页面的元素进行分类，以支持用户可以通过 rotor 来实现只在某类元素间进行导航的效果。
由此，用户可以只在感兴趣的类目下导航。这是「筛选」设计模式的一种。
如：在地图应用中，有非常多的 POI。若我们的目的是找某个公园，则可以通过 rotor 选择「parks」选项，即可只在公园的 POI 间导航，从而更快找到心仪的公园。
以下是常用的用于简化导航流程的 rotor 选项：
| Rotor 选项 | 效果 |
|---|---|
| Heading | 移至下一个/上一个标题 |
| Button | 移至下一个/上一个按钮 |
| Form Control | 移至下一个/上一个表单控件（如 checkbox、radio button) |
| Text Fields | 移至下一个/上一个输入框 |
| Search Fields | 移至下一个/上一个搜索框 |
| Links | 移至下一个/上一个链接 |
| Visited Links | 移至下一个/上一个已访问过的链接 |
| Unvisited links | 移至下一个/上一个未访问过的链接 |
| Images | 移至下一个/上一个图像 |
| Landmark | 移至下一个/上一个已访问过的 landmark（如 banner、navigation、main、complementary) |
| Same element | 移至下一个/上一个同类元素 |
我们可以通过 audio graph 来「朗读」数据图的整体轮廓。
在 audio graph 中，每个轴的数据都会被转化为声音。通常，我们会将 y 轴转化为音高（pitch），x 轴转化为时间。
我们还需提供方便的音频播放控制功能，如播放、暂停、停止和调整音量等。由此，用户可以根据自己的需要灵活地控制 audio graph 音频的播放。
我们可以将每个数据点都创建成可访问的元素，以支持用户访问数据图中特定点的数据。但有时，会出现数据点太多的问题。
正如前面我们提到的「元素分组」，面对这样的情况，我们建议将图表分成合理的区间，以方面用户在大量数据点间导航。
若页面发生的变化并不在焦点所处的元素上，视障用户就无法像明眼人一样用边缘视觉（peripheral vision）察觉到变化了。
因此，当页面中的 UI 元素发生变化、有 UI 元素出现或消失时，我们需通过 accessibility notification 来进行告知，即自动朗读变化信息。有时，还可以自动将焦点移动到发生变化的元素上。
举几个例子：
在计算器中，输入完「1+2」后点击「=」，读屏应用会自动朗读「Result，3」，而无需用户导航到结果区域才能听取结果。
在微信存储空间页，当「微信已用空间」计算完毕时，读屏应用会自动播报「微信已用空间」的具体数据。
对于 Apple 设备，可用 Xcode 中的 Accessibility Inspector 来帮助搜寻问题；
对于 Android 设备，可用 Accessibility Scanner 来帮助搜寻问题。
下面，我们将重点介绍使用 Accessibility Inspector 来进行验收的方式。
Accessibility Inspector 是 Xcode 自带的无障碍检查工具。我们可以在 Xcode 的中通过「Xcode > Open Developer Tool > Accessibility Inspector」打开，也可以直接通过 Spotlight 搜索来打开。
若需验收的应用非 macOS 应用，我们需先在应用所安装的设备上打开「Developer Mode」。
点击 Accessibility Inspector 窗口右上方的「Inspection Pointer」toggle button 。
点击想要检查的 UI 元素。
在 Accessibility Inspector 窗口的「Inspection Detail」区，查看此元素的各项 accessibility attributes，并检查其完整性、正确性。
我们也可以利用 Accessibility Inspector 一键检查应用特定页面的所有 UI 元素。
打开需检查的特定页面。
在 Accessibility Inspector 窗口左上角的「Device Target」pop-up button 中，选择所需检查的应用。
点击 Accessibility Inspector 窗口右上角的「Audit」。
点击 Accessibility Inspector 窗口中的「Run Audit」，即可看到搜寻到的所有无障碍问题。
在列表中，可以查看问题描述、截图、修复建议。
在 iOS 中，我们可以打开「连按三次电源键以快速打开和关闭 VoiceOver」的选项。这不仅能让每次启动或禁用 VoiceOver 更快，也能在不确定要使用哪个手势时轻松禁用旁白。
为了能更贴近视障用户的感受，我们还可以在使用 VoiceOver 的过程中打开 Screen Curtain（屏幕帘）。当 Screen Curtain 打开时，设备屏幕将始终处于关闭状态。
| Checklist | 相关概念 |
|---|---|
| 可交互元素的响应热区足够大 | 交互模式 / Explore by Touch |
| 导航顺序合乎逻辑、符合预期 | 交互模式 / Linear Navigation |
| 导航路径不会过于冗长 | 进行元素分组、用 Rotor 简化导航流程 |
| 朗读的内容合理、清晰 | 设计朗读内容 |
| 朗读的内容简明扼要，更多信息按需探索 | 用 Rotor 简化朗读信息 |
| 朗读的效果自然、准确 | 设计朗读方式 |
| 数据图也能轻松访问 | Audio Graph |
| UI 中变化的信息也能被朗读 | 创建 Accessibility Notifications |
| 支持多语言 | Label、Hints 的本地化 |
语音控制指的是用语音命令来执行各种操作的能力，如：打开应用、更改设置、浏览文件等。
语音控制与无障碍读屏的关系在于：
视障群体也可以通过语音控制实现无障碍读屏的 direct command，而无需通使用触屏手势。
无障碍读屏设计中的 label，也可以作为语音控制的口令。因此，简短的 label 能让语音口令更易于记忆和说出。
借助切换控制，用户可以使用多种自适应设备 (如 switch、joystick、键盘空格键或触控板) 操作 app：逐个扫描 UI 元素，到达所需的 UI 元素后，使用设备执行适当的操作。
切换控制与无障碍读屏的关系在于：
视障用户也可以用切换控制的设备来进行操作，而无需使用触屏手势。
无障碍读屏的导航顺序、元素分组也同样适用于切换控制。
键盘导航指的是使用键盘进行页面导航的能力。
键盘导航与无障碍读屏的关系在于：
在 PC 端，两者往往是配合使用的（通过键盘导航来移动焦点、操作）。
键盘导航的 tab order、focus group 等设计理念同样适用于无障碍读屏。
无障碍读屏设计不仅对视障群体有意义，对于明眼人来说也同样具有重要意义。
足够大的响应热区，稳定的界面布局，对于明眼人和盲人都同样重要。明眼人可以从中学习如何更好地设计用户界面，以提供更清晰、简洁和易于理解的信息。
无障碍读屏设计中的 label，有利于对页面进行检索。对于网页来说，其对 SEO 更是大有裨益。
无障碍读屏设计本身可以可以帮助更多人理解残障人士的需求和难处，促进社会平等和包容性的提高。
小确幸之光