PDF设计系统是无障碍交付工具
使应用程序的无障碍支持具有可扩展性、生产力和一致性
Shahtab Wahid
多年来，设计系统在所有平台上构建软件方面发挥着关键作用。它们提供通用的构建模块集，设计师和开发人员可以使用这些模块为用户交付功能和价值。著名的例子包括 IBM 的 Carbon 设计系统2、谷歌的 Material Design7 和 Salesforce 的 Lightning Design System6。
虽然有不同的方法来描述设计系统的构成，但可以归纳为四个部分：4,5
- 基础 决定了整个系统中使用的视觉方面，例如颜色、间距和排版。
- 组件 利用基础来构建常用元素，例如按钮、复选框、输入字段和表格。
- 模式 说明了组件的组合如何布局和交互，以解决常见的用户界面工作流程。
- 指南 通过描述基础、组件和模式是什么以及应该如何使用它们，为所有这些提供了一个总体层。
设计系统是为应用程序的设计师和开发人员等消费者构建的基础设施。一个成功的设计系统允许组织中的消费者快速扩展跨应用程序的设计和开发，提高生产力并建立一致性。设计系统也是具有自身用户群的产品。它们必须成长、发展并满足构建应用程序的消费者的需求。如果设计系统变得停滞不前，并且未能兑现其在可扩展性、生产力和一致性方面的承诺，那么消费者的采用率将会降低。
包括多元化倡议、员工生产力、法规和收入影响在内的多种因素，可能会推动组织提供无障碍软件的需求。然而，许多消费者并未准备好为无障碍功能而构建。在这种情况下，组织能否使应用程序的无障碍支持具有可扩展性、生产力和一致性？
本文的中心论点是设计系统是向消费者交付无障碍支持的主要工具。 通过确保基础、组件、模式和指南都考虑了无障碍性，消费者可以“免费”采用这些优势，并使自己的应用程序更易于访问。设计系统构建和部署无障碍优势的方法极大地影响了无障碍性是否能够成为组织内可扩展、高效且一致的举措。为此，本文深入探讨了无障碍性及其与设计系统两个部分的关系：(1) 如何使设计系统组件无障碍； 以及 (2) 如何记录为设计系统消费者量身定制的无障碍指南。
第一个主题涵盖了需要在所有组件规范中定义的无障碍因素。第二个主题侧重于创建无障碍指南的策略。这两个讨论都以 Web 内容无障碍指南 (WCAG)9 和无障碍富 Internet 应用程序 (ARIA) 规范1 为出发点。
无障碍组件
设计系统，特别是为 Web 量身定制的设计系统，包含各种各样的组件。常见的组件有表单元素，例如输入字段、按钮和复选框；以及导航组件，例如选项卡和手风琴。更复杂的组件，例如表格、工具栏和标题也可能包含在内。表 1 显示了设计组件时需要定义的方面。
表 1：设计系统组件规范
| 组件方面 | 描述 |
|---|---|
| 状态 | 组件可以处于的所有条件，例如默认、悬停、聚焦、禁用、只读、选中/未选中、打开/关闭和错误。 |
| 布局和结构 | 标签、图标和交互元素等部分的排列，以及它们的尺寸和间距定义。 |
| 颜色 | 用于边框、背景、文本、图标和任何其他元素的颜色。 |
| 排版 | 用于组件中任何文本的文本样式。 |
| 交互 | 使用键盘、鼠标和触摸事件来激活组件并在状态之间转换。 |
| 变体 | 组件的替代配置，可以通过添加、删除或重新排列元素来更改布局、结构和交互。 |
WCAG 和 ARIA 文档描述了组件规范中需要包含哪些无障碍因素，1,9 以及示例。3 这里分享的因素并非旨在全面，而是为了突出最重要的 issues。它们适用于 Web 平台上的组件，但其中一些也将扩展到其他平台。
颜色对比度
WCAG 要求适当的颜色对比度，以确保前景中的内容可以与背景区分开来。例如，深灰色在黑色背景上不如浅灰色那么显眼。在定义组件在任何状态下的边框、背景、文本、图标和任何其他部分的颜色时，应牢记这一点。
字体大小更改
可能需要放大文本以支持阅读，而无需任何辅助技术——如 WCAG 所定义。浏览器通常提供可以在设置中更改的默认字体大小。组件需要支持显示其中完整文本的能力，以防用户选择放大字体大小。例如，当输入字段或表格列标题中的文本必须放大时，这可能需要组件的大小增长以适应文本。
键盘导航
所有功能都应通过键盘（绘图等例外情况）提供，这要求组件是键盘可访问的。ARIA 实践为要使用的键提供了示例1,3。在导航组件时，对某些键的行为有期望
- 箭头键 — 在项目列表（例如下拉菜单或菜单中）或二维空间（例如日历中的日期）中移动。
- Home 键和 End 键 — 跳转到列表中的第一个或最后一个项目。
- 空格键和 Enter 键 — 调用操作（例如按钮）或进行选择（例如复选框或下拉菜单项）。
- Esc 键 — 关闭（例如下拉菜单）或退出更复杂的组件（例如由多个更简单的组件组成的工具栏组件）。
- Tab 键 — 将焦点从一个组件移动到另一个组件。Tab 键不应用于在组件内移动焦点，因为期望它会根据页面的制表符顺序将焦点移动到下一个组件。
鼠标交互
WCAG 提到了从意外或错误的鼠标点击中恢复。使用点击触发的交互应在鼠标抬起时调用，允许用户在鼠标按下事件后移开以防止操作被调用。鼠标按下事件应仅用于不提交的操作，例如点击输入字段以将焦点移至其中进行键入。
屏幕阅读器支持
支持使用屏幕阅读器等辅助技术是关键。组件必须完全可以通过屏幕阅读器访问。在 Web 上，语义 HTML 实现了这一目标。当语义 HTML 可能不足时，ARIA 在提供无障碍支持方面发挥着重要作用。通过使用语义 HTML 或 ARIA，屏幕阅读器应该能够做到以下几点
- 识别组件的角色。 角色（例如按钮、复选框或表格）用于描述屏幕阅读器用户正在访问的组件类型。常见的 ARIA 角色包括 button、checkbox、listbox 和 table。
- 说出组件的标签。 许多组件（例如输入框、按钮、单选按钮和复选框）都有可见标签。如果不存在可见标签或未以编程方式将可见标签与组件关联，则屏幕阅读器仍必须能够读出标签。ARIA 提供了诸如
aria-label和aria-labeledby之类的属性来实现此目的。 - 指示组件的状态以及与其关联的任何消息。 组件可能具有展开/折叠或选中/未选中状态，可以使用 ARIA 的
aria-expanded和aria-checked等属性来描述。当输入字段处于错误状态时，屏幕阅读器应中继此状态以及描述错误的任何消息。 - 提供维度上下文。 对于下拉菜单或菜单，提供可用项目的总数并表达当前聚焦的项目，可以让用户了解他们所处的位置。对于表格，可以利用 ARIA 来提及总行数和列数，以及焦点单元格所属的行和列。
记录无障碍指南
本文的下一部分重点介绍如何记录设计系统的无障碍指南。许多消费者不了解构建无障碍软件必须做什么。必须仔细制定无障碍文档，以满足受众的需求。
当谈到无障碍文档时，WCAG 是规范。这些指南是全面的，需要有耐心的受众花费时间来消化。为了提供一些结构，它们基于四个不同的原则：可感知性、可操作性、可理解性 和 稳健性。理解这些原则是有价值的。不幸的是，已经表明，这些原则可能不够清楚，并且文档可能会引起许多问题。8 作为一种更简单的方法，有些人选择访问带有 WCAG 清单的网站，以了解有哪些要求。这些通用清单与正在使用的设计系统没有任何联系。
当有疑问时，消费者可能会选择使用具有内置无障碍支持的设计系统，希望变得无障碍。然而，使用这样的设计系统会产生一种虚假的安全感。无障碍组件仅为消费者提供了一个在变得无障碍方面的良好开端。这并不意味着整个应用程序都变得无障碍。因此，在设计系统中引入无障碍指南至关重要。此处介绍的创建文档的方法侧重于三个步骤：(1) 识别主题；(2) 关注无障碍用例；以及 (3) 分配责任。
创建无障碍指南的三个步骤
第一步是识别主题，以组织所有指导。通过倾听消费者的意见并与他们的需求保持一致，可以开发出一组主题，如表 2 所示。可以通过研讨会、对话以及消费者之间的问题；培训目标；以及 WCAG 涵盖的问题范围来确定主题。例如，考虑一个开发人员社区，他们熟悉键盘导航和屏幕阅读器支持的需求，但缺乏关于如何提供此类支持的具体知识。可以创建专门涵盖这两个主题的主题。
表 2：无障碍文档主题集
| 主题 | 描述 |
|---|---|
| 键盘导航 | 使用键盘导航内容、输入信息和调用操作 |
| 屏幕阅读器 | 允许屏幕阅读器用户理解内容结构、识别内容类型、收听内容和导航 |
| 颜色 | 对比度以及通过颜色进行信息编码 |
| 文本信息 | 标签、说明、标题和长文本块 |
| 放大和缩放 | 控制内容的大小以帮助查看 |
| 输入和错误 | 输入以输入信息和错误处理 |
| 鼠标交互 | 调用鼠标操作和处理作为结果出现的内容 |
| 非文本信息 | 图像、图表、音频和视频内容 |
| 动态内容 | 移动、动画或自动更改的内容 |
| 页面导航 | 在页面内和跨页面导航 |
| 语言 | 页面上使用的语言 |
| 工作流程设计 | 整个页面或一系列页面的设计 |
| 硬件 | 手机或平板电脑访问 |
第二步是关注用例的识别。表 2 中提到的键盘导航主题中可能的用例包括在组件内导航、跨组件导航以及跳到页面的主要内容区域。这些用例考虑了现有的 WCAG 建议。应创建用例，直到 WCAG 中的所有无障碍规则都至少在一个用例中得到考虑。
第三步是仔细确定谁负责执行无障碍工作。责任方可能是设计系统（在这种情况下，工作可能已经完成）、消费者或两者兼而有之。这使得设计系统为消费者带来的无障碍价值更加清晰，同时也明确了消费者必须介入的地方。
当所有三个步骤都完成后，每个用例的文档都可以遵循表 3 和表 4 中所示的结构。每个用例都与一个主题相关联。用例的描述是从用户的角度编写的，强调无障碍价值。将用例与 WCAG 规则关联可确保消费者了解将满足哪些指南。额外的背景信息以及应该做什么和不应该做什么为消费者提供了额外的背景信息，以便他们理解原因和方法。
表 3：设计系统承担责任的导航
| 主题 | 键盘导航 |
|---|---|
| 用例 | 我想在组件内使用键盘。 |
| 责任 | 这由设计系统支持；消费者不负责。 |
| 相关 WCAG 规则 | 规则 2.1.1： 所有功能都可以通过键盘访问，绘图等任务除外。 规则 2.4.7： 所有页面元素在聚焦时都有可见的焦点指示器。 规则 3.2.1： 焦点更改不会触发意外操作。示例包括提交表单和打开新窗口。 |
| 背景 | —设计系统内置了对组件内键盘导航的支持。 —所有组件在使用键盘时都具有可见的焦点状态。 —当组件接收焦点时，它们都不会调用操作。 |
| 执行 | 使用默认的键盘导航行为和焦点状态。 |
| 不要执行 | —覆盖组件的键盘导航行为。 —覆盖任何焦点状态。 |
设计系统的意图应该是提供消费者易于理解的文档。消费者宁愿构建无障碍支持，也不愿花时间理解哪些指南适用于他们的产品以及需要做什么。有了建议的结构，创建一个内容表，展示主题及其中的用例，有助于消费。读者可以首先通过浏览主题来识别无障碍支持的广泛领域——增加他们对无障碍考虑因素广度的熟悉程度。在每个主题中，具体的用例说明了他们可以交付的用户价值。每个用例都明确地表明读者是否负责这项工作。消费者可以避免理解按 WCAG 原则组织的指南和与正在使用的设计系统无关的通用清单的复杂性。
表 4：消费者承担责任的导航
| 主题 | 键盘导航 |
|---|---|
| 用例 | 我想使用键盘在组件之间移动。 |
| 责任 | 消费者负责确定用户浏览所有组件的顺序。 |
| 相关 WCAG 规则 | 规则 1.3.2： 代码中内容的正确阅读顺序和顺序相同。 规则 1.4.13： 如果内容要出现在鼠标悬停或键盘焦点上，则必须是可关闭的、可悬停的和持久的。 规则 2.1.2： 用户可以使用键盘浏览所有页面元素而不会被困住。 规则 2.4.3： 用户可以按逻辑顺序依次导航（制表符）浏览页面元素。 |
| 背景 | 设计系统无法确定应用程序的制表符顺序，因此无法为此提供支持。 |
| 执行 | —使用 Tab 键将焦点移动到下一个组件，使用 Shift+Tab 键移动到上一个组件。 —包括所有应该能够获得 Tab 焦点的交互元素。 —Tab 顺序应从页面顶部开始。 —移动焦点时，尽量从左到右，然后从上到下。 —在可能的情况下，允许分组在一起或在同一区域（例如表单或侧边栏）内的组件一个接一个地获得焦点。 —当您到达页面的最后一个组件时，下一次 Tab 键按键应将您带回到第一个组件。 |
| 不要执行 | —当用户可能会迷失方向时，将焦点跳转到页面不同部分的组件。 —阻止用户将焦点移动到页面的另一个区域或将用户限制在页面的子集。 —当组件获得焦点时显示新内容；仅当调用操作时才显示内容。 |
结论
此处介绍的组件设计和文档编写过程是彭博社 Web 设计系统倡议的结果。该倡议继续依赖规范因素，即使设计系统通过添加和修改组件而不断发展，这些因素也有助于考虑无障碍性。
然而，如前所述，拥有无障碍组件是不够的。它们还必须得到为消费者量身定制的指南的支持，这些指南包含主题、用例和责任。彭博社的倡议花费时间了解消费者拥有的无障碍知识，以确保文档具有高度的可消费性。
朝着这些方向迈进的步骤有望创建一个生态系统，在该生态系统中，消费者的无障碍需求通过设计系统得到解决，并且产品采用率因此而提高。这是无障碍支持变得可扩展、高效且一致的标志。
参考文献
1. ARIA 创作实践指南。W3C Web 无障碍倡议； https://www.w3.org/WAI/ARIA/apg/。
2. Carbon 设计系统； https://carbondesignsystem.com/。
3. Combobox 模式。ARIA 创作实践指南。W3C Web 无障碍倡议； https://www.w3.org/WAI/ARIA/apg/patterns/combobox/。
4. Fessenden，T. 2021 年。设计系统 101。NN/g； https://www.nngroup.com/articles/design-systems-101/。
5. Frost，B. 2016 年。原子设计； https://atomicdesign.bradfrost.com/table-of-contents/。
6. Lightning Design System； https://www.lightningdesignsystem.com/。
7. Material Design； https://m3.material.io/。
8. Snider，S.，Scott II，W. L.，Trewin，S. 2020 年。企业中的无障碍信息需求。 无障碍计算汇刊 12(4)，第 16 条，1-23； https://doi.org/10.1145/3368620。
9. WCAG 2 概述。W3C Web 无障碍倡议； https://www.w3.org/WAI/standards-guidelines/wcag/。
Shahtab Wahid 是彭博社的用户体验设计师。他融合了自己的设计和研究专业知识，以解决金融行业的桌面和 Web 平台设计、设计系统和无障碍领域的问题。他学习了人机交互，并于 2011 年在弗吉尼亚理工大学计算机科学系获得博士学位。
版权所有 © 2024，所有者/作者持有。出版权已许可给 。
最初发表于 Queue 第 22 卷，第 5 期—
在 数字图书馆 中评论本文
更多相关文章
Vinnie Donati - 推动组织无障碍
在本文中，我们将探讨微软如何在整个组织中推动无障碍性，并且我们将仔细研究促进包容性文化的基本框架和实践。通过检查诸如意识建设、战略发展、无障碍成熟度建模等各个方面，我们旨在为开始无障碍之旅的组织提供指南。我们的想法是分享我们所学到的知识，希望您可以采纳它，对其进行调整以适合您公司的宗旨，并以一种不仅仅是复选框活动的方式培养无障碍性，而是真正融入您的文化。
Juanami Spencer - 移动应用程序的无障碍考虑因素
在创建移动应用程序时，考虑无障碍性至关重要，以确保尽可能广泛的受众可以使用和享受它们。与桌面体验相比，移动无障碍性有其独特的考虑因素，但它为那些在日常活动中依赖移动设备的用户提供了巨大的价值。通过牢记这些考虑因素，移动产品开发团队可以更好地支持和改善所有用户的日常生活。本文探讨了移动应用程序的一些关键无障碍考虑因素，并重点介绍了 Bloomberg Connects 应用程序在产品和流程中支持无障碍性的几种方式。
Chris Fleizach, Jeffrey P. Bigham - 系统级无障碍
本文通过我们使 iPhone 能够使用 VoiceOver 屏幕阅读器以非视觉方式使用的工作来说明系统级无障碍性。我们为非视觉使用重新构想了触摸屏输入，引入了适用于屏幕阅读器控制的新手势，并且对于输出，我们添加了对合成语音和可刷新的盲文显示器（输出触觉盲文字符的硬件设备）的支持。我们添加了应用程序可以采用的新无障碍 API，并使我们的用户界面框架默认包含它们。最后，我们添加了一个无障碍服务来桥接这些新的输入和输出与应用程序之间。
Stacy M. Branham, Shahtab Wahid, Sheri Byrne-Haber, Jamal Mazrui, Carlos Muncharaz, Carl Myhill - 数字无障碍的现状
如果您是数字无障碍领域的新手，甚至您不是新手，也可能难以掌握全局，而科技行业发展迅速。因此，我们请一组专家向我们介绍最新情况。他们不仅有涉及数字无障碍的日常工作，而且还拥有残疾的生活经验。我们向他们提出了以下问题：无障碍的现状如何？主要挑战是什么？我们为什么需要无障碍软件？我们如何为无障碍性辩护？谁在引领潮流？我们接下来该何去何从？
© 保留所有权利。