设计系统标注实践：如何让组件无障碍访问不再被忽视

当谈到设计系统时，每个组织在无障碍访问旅程中处于不同的阶段。有些组织在使其设计系统可访问方面付出了大量努力，而其他组织在达到这一目标之前还有很长的路要走。为了帮助这一旅程，许多组织依赖无障碍标注来确保设计准备构建时没有访问障碍。

然而，一个常见的误解（特别是对于拥有成熟设计系统的组织）是，可访问的组件将产生可访问的设计。虽然设计系统在扩展标准和一致性方面非常出色，但它们无法防止我们设计或构建方式中的每个问题。访问障碍仍然可能悄悄进入生产环境。

这是我们的无障碍设计团队着手解决问题的根源。

在这个由两部分组成的系列文章中，我们将准确展示可访问的设计系统组件如何产生不可访问的设计。然后我们将演示我们的解决方案：将标注与我们的Primer组件集成。这使我们能够减少标注时间，增加设计系统采用率，并触及可能没有无障碍支持团队。

让我们深入探讨。

什么是标注及其好处？

标注是包含在设计项目中的注释，通过传达视觉上未显示的设计意图，帮助使不可见的内容变得明确。它们通过为开发人员提供体验应如何运作的整体图景，提高了数字体验的可用性。将标注集成到我们的设计过程中，通过弥合沟通差距并防止质量问题、无障碍审计问题和昂贵的返工，帮助我们的团队更好地合作。

标注帮助我们回答的一些问题包括：

辅助技术如何从页面上的一个元素导航到另一个元素？
信息性图像和无标签按钮的替代文本是什么？
内容如何根据视口大小、屏幕方向或缩放级别而变化？
在移动设备上应为表单输入使用哪个虚拟键盘？
对于复杂交互，应如何管理焦点？

我们对这些问题的回答——或者缺乏回答——可能决定许多人在网络上的体验，特别是残疾用户。一些标注工具专门为此而构建，通过指导设计人员包含有关Web标准、平台功能和无障碍（a11y）的关键细节。

大多数公共标注套件非常适合创建新设计系统组件的团队、尚未使用设计系统的团队或没有专业无障碍知识的团队。它们通常帮助标注以下内容：

控件，如按钮和链接
结构元素，如标题和地标
装饰性图像和信息性描述
需要标签和语义角色的表单和其他元素
辅助技术和键盘导航的焦点顺序

GitHub的标注工具包

我们的首要任务之一是在同事所在的位置与他们见面。我们希望所有设计人员都能开箱即用地使用标注，因为我们相信他们不需要成为认证的无障碍专家才能以可访问的方式构建事物。

为此，去年我们开始创建一个内部的Figma库——GitHub标注工具包（我们旨在很快向公众发布）。我们的工具包建立在CVS Health前包容性设计团队的遗产之上。他们的两个开源标注套件有助于创建易于创建和消费的文档，并且是Figma社区中使用最广泛的标注库之一。

虽然标注增加了清晰度，但它们也可能增加开销。如果团队仅依赖专家为开发人员解释设计和技术规范，交接过程可能比需要的更长。为了创建我们的标注工具包，我们从头开始重建了其前身，以避免这种开销，进行了广泛的改进并添加了内联文档，使其对我们所有设计人员——不仅仅是无障碍专家——更加直观和有用。

设计系统也可以帮助减少这种开销。当您为无障碍访问审计设计系统时，每个产品功能对专家关注的需求减少，因为您使用标注将技术语义和专家知识添加到每个组件中。这意味着设计人员和开发人员只需要一致地遵守使用指南，对吗？

标注和设计系统组件的问题

不幸的是，事情并不那么简单。

无障碍不是二元的

虽然设计系统可以帮助推动更大规模的可访问设计，但它们不断演化，工作永远不会完成。任何组件的可访问性都不是二元的。有些可能有几个严重的问题，造成访问障碍，例如无法用键盘操作或缺少替代文本。其他可能有一些琐碎的问题，例如通用控件标签。

大多数时候，声称您的设计系统"完全可访问"是一种用词不当。总有更多的工作要做——只是多少的问题。Web内容无障碍指南（WCAG）是一个很好的起点，但它们的"成功标准"并不针对您的网站或产品或受众的独特背景。

虽然WCAG应用作构建的基础，但重要的是要理解它无法捕捉残疾用户需求的每个细微差别，因为您的用户需求并非每个用户的需求。如果您从不超越WCAG与用户交谈，很容易相信您的设计系统"完全可访问"。如果Primer有可访问的组件，那是因为我们觉得日常辅助技术用户的直接参与和输入是我们工作中最重要的方面。与真实用户——有残疾和无残疾——测试计划是您真正找到最重要内容的地方。

可访问的组件不保证可访问的设计

在页面上排列一系列可访问的组件不会自动创建准确和信息丰富的标题层次结构。很有可能，没有额外的文档，标题结构在视觉上没有意义——也不作为使用辅助技术导航的媒介。

当可访问的组件灵活且响应迅速时，这很棒，但是当它们放置在组件指南未考虑的布局中时呢？它们是否适应不同的缩放级别、视口大小和屏幕方向？当这些变化时，它们是否失去任何功能或上下文？

组件使用是上下文相关的。您可以在设计中添加图像或图标，但设计系统文档无法为您编写描述性文本。您可以在多个位置使用相同的图像，但图像描述可能需要根据上下文而变化。

类似地，使用相同输入组件构建的表单可能执行不同的操作并需要不同的错误验证消息。难怪采用设计系统组件并不能消除所有审计问题。

Figma中的设计系统组件不包含所有细节

标注套件不包含特定设计系统的组件，因为几乎每个组织都在使用自己的设计系统。当采用标注套件时，团队通常会添加标记其设计系统组件的方法。

这种标记让开发人员知道他们可以使用已经构建的东西，而不需要从头开始构建。它还有助于识别在Figma中"分离"的任何设计系统组件。并且它减少了需要标注的事物数量。

让我们看一个例子：

如果我们使用来自Primer Web Figma库的这个Primer按钮组件，仅通过查看设计或组件属性，有一些重要的事情我们不会知道：

组件实现时的功能差异。这是一个只是视觉上看起来像按钮的链接吗？如果是，开发人员将使用<LinkButton> React组件而不是<Button>。
对使用辅助技术的人的可访问标签。图标可能需要替代文本。在某些情况下，按钮文本可能需要一些视觉隐藏的文本来区分它与类似按钮。我们如何知道该文本是什么？没有标注，Figma组件没有地方显示这一点。
用户数据是否提交。当设计不包括具有输入字段的明显表单时，我们如何传达按钮需要特定属性来提交数据？

让这样的问题 unanswered，希望有人注意到并猜出正确答案，是有风险的。

简化标注过程同时最小化风险的解决方案

在创建新组件时，一组详细的标注可能是它们健壮性和可访问性的重要因素。一旦组件构建完成，设计团队可以开始在其设计中添加该组件的实例。当这些设计准备好进行标注时，这些新组件不应该需要再次标注。在大多数情况下，这将是冗余和不必要的——但并非在所有情况下。

许多Primer组件中有一些重要的细节可能从一个实例到另一个实例发生变化。如果我们使用CVS Health标注套件开箱即用，我们应该能够捕获这些变化，但我们将无法避免那些冗余和不必要的标注。在构建自己的标注工具包时，我们为每个Primer组件构建了一组标注，以同时完成这两件事。

这个手风琴组件已经进行了彻底标注，以便工程师拥有第一次构建它所需的一切。这些包括标题级别、<detail>和<summary>元素的语义、地标和装饰性图标。所有这些都内置在组件中，因此在将手风琴添加到新设计时，我们不需要标注大部分内容。

然而，有两件重要的事情我们需要标注，因为它们可能从一个实例到另一个实例发生变化：

顶部的可选标题。
手风琴内每个项目的标题级别。

如果我们不指定这些内容，我们就是在碰运气，页面的标题结构可能会破坏，或者体验会让人们理解和导航页面感到困惑。对于单个按钮或基本手风琴，风险可能很低，但随着模式复杂性、组件嵌套、交互状态、重复实例等增加，风险也会增长。

与其标注已经内置到组件中的内容或将这些细节留给机会，我们可以添加两个快速标注。一个标记指向组件，一个详细信息标注，我们在其中填写一些空白以使标题级别清晰。

由于特定组件细节的提示在标注中预设，我们称它们为预设标注。

介绍我们的Primer A11y预设标注

通过这个概念验证，我们选择了十个经常使用的Primer组件进行相同的处理，并构建了一组新的预设标注来记录这些容易遗漏的无障碍细节——我们的Primer A11y预设。

这些Primer组件在实现时缺少关键细节时，往往会导致更多的无障碍审计问题。这些组件的问题涉及缺乏适当标签、错误验证消息或缺少HTML或ARIA属性等内容。

我们的每个预设标注都链接到组件文档和Storybook演示。这有望帮助开发人员直接获取他们需要的技术信息，而无需设计人员手动查找和添加链接。我们还包括了如何填写每个预设的指南，以及如何以可访问的方式使用组件。这有助于设计人员在不离开Figma画布的情况下获得内联支持。

想创建自己的？查看设计系统标注，第2部分

Google的Material Design、Shopify的Polaris、IBM的Carbon或我们的Primer设计系统中的按钮组件彼此都非常不同。由于预设标注基于特定组件，它们只有在您也使用它们所针对的设计系统时才有效。

在本系列的第2部分中，我们将引导您如何为自己的设计系统构建一组预设标注，以及在开发开始前记录重要无障碍细节的一些不同方法。