设计系统标注实践：如何解决组件可访问性缺失问题

当谈到设计系统时，每个组织在可访问性旅程中都处于不同的阶段。有些组织投入了大量工作来使其设计系统具备可访问性，而其他组织在实现这一目标之前还有很长的路要走。为了在这一旅程中提供帮助，许多组织依赖可访问性标注来确保设计准备构建时不存在访问障碍。

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

这正是我们的可访问性设计团队着手解决问题的根源。

在这个由两部分组成的系列中，我们将准确展示可访问的设计系统组件如何产生不可访问的设计。然后我们将演示我们的解决方案：将标注与我们的Primer组件集成。这使我们能够减少标注时间，增加设计系统采用率，并触达可能没有可访问性支持的团队。在我们的下一篇文章中，我们将引导您如何为自己的组件做同样的事情。

让我们深入探讨。

什么是标注及其好处？

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

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

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

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

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

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

GitHub的标注工具包

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

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

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

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

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

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

可访问性不是二元的

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

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

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

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

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

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

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

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

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

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

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

让我们看一个例子：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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