FE.ARIA-审核设计系统的可访问性（译）

自2012年开始我的职业生涯以来，关于包容性设计的知识一直受到阻碍和教学空白的束缚。我的志向是帮助设计师解除阻碍，开发人员和技术人员想要建立更好，更具包容性的体验。在这篇博客文章中，我希望特别告知我的同行设计师有关出于可访问性考虑而需要进入的地方。

我将专注于我认为设计师可以做的最关键的可访问性工作：创建具有固有的可访问性合规性的设计系统。特别是，我们将专注于学习如何在现有设计系统中查找可访问性问题，并以使这些问题对我们自己和我们的团队可行的方式记录这些问题。

您可以在YouTube上播本文的视频版本！

设计系统和辅助功能

设计系统到底是什么？设计系统是产品，站点或体验的单一事实来源。这些包括设计/开发组织的共同目标和一组价值，以及品牌元素和组成部分。设计系统将相关的实现元素组合在一起，定义它们的目的并阐明它们的交付。

如果正确完成，则设计系统应随组织发展并扩展。这些系统之所以重要，是因为它们使我们能够进行大规模的工作，做某事然后将其应用到各处并建立更一致的品牌。但是最重​​要的是，设计系统是必不可少的，因为它也可以帮助我们扩展可访问性。

我们在系统中创建的每个原子，分子和有机体都会影响我们向上扩展规模并满足残疾人需求的能力。我对原子，分子和有机体的提及直接引用了布拉德·弗罗斯特（Brad Frost）的“原子设计”（如果您对设计系统的思考感兴趣，我建议您阅读）。

当“原子设计”于2016年发布时，它标志着数字化设计思维的一个重要转变。尽管许多团队已经开始使用模式库和框架，例如Bootstrap，但是“原子设计”承认我们都开始看到的东西：数字化设计需要更好的系统。

四年后，当设计团队为设计系统辩护时，仍然会定期引用Brad Frost的书。我们还可以使用这种方法来帮助告知如何大规模设计可访问性，以及如何审核我们的系统以确保可访问性合规。在《原子设计》中，布拉德·弗罗斯特（Brad Frost）使用原子方法分解了设计系统的规模。我们的系统本质上是相互重叠的，从元素（例如原子）开始，这些元素可以组合以创建分子，并且可以进一步组合以形成生物。

这些生物告知并创建模板，然后可以将其应用于我们平台中的特定页面。在这个规模上，每个人和每个团队都有不同的理解或行话，但是这些原则的基本要素往往会在大多数数字设计系统中始终如一地存在。

我们不必具有健壮或“完美”的设计系统即可使用此方法或审核可访问性。无论我们的团队是刚刚起步，已经有记录良好的可用系统，还是介于两者之间，都可以在我们的设计系统开发中的任何时候应用此博客文章中介绍的内容。

亚原子粒子

让我们从分解原子设计的扩展规模开始。但是在讨论原子之前，让我们先谈谈我们的“亚原子粒子”，即构成我们设计系统的基础元素。

它们不是我们的原子，但它们可以告知原子的产生。这些亚原子粒子往往是品牌颜色或字体之类的东西。尽管仅这些元素似乎对于我们的系统而言并不是最重要的，但它们会影响我们创建的所有元素，从最小规模到完整页面。

原子

Atoms一目了然地展示了我们所有的基本样式，这对于我们在开发和维护设计系统时不断回头是很有帮助的参考。一些系统比其他系统具有更大的粒度，因此请注意，在这种情况下，“原子”之类的词有时在不同团队中可能具有不同的含义。

就我们的目的而言，原子是诸如表单标签，输入和按钮之类的元素，以及其他在不停止起作用的情况下无法分解的元素。下面的示例是一个标签，一个下拉选择器和一个按钮，每个按钮都充当一个唯一的原子。但是，就像自然界中的原子一样，界面原子也不是在真空中存在，只有在应用中才能真正实现。

分子

在下一步进行原子级扩展时，我们有了分子：分子是元素或原子的相对简单的组，它们一起作为一个单元起作用。

例如，表单标签，下拉选择器和保存按钮现在可以是功能表单字段单元。当结合在一起时，这些抽象原子突然具有目的。在拥有标签，下拉菜单和按钮之前，但是现在我们可以通过组合这些元素

现在，选择按钮原子会保存下拉输入，并且标签会指示这些输入的用途。结果是：一个简单，可移植，可重用的组件，可以将其放置在需要下拉输入或保存表单的任何位置。

生物体

再次扩大规模：生物体是由分子和/或原子群甚至其他生物体组成的相对复杂的组成部分。这些生物形成界面的不同部分。

从分子积累到更精细的有机体，为设计师和开发人员提供了基本的环境意识。有机体表现出较小，较简单的动作成分，并作为可重复使用的独特模式。

以下是我们应用于特定环境的示例下拉/保存表单，在这种情况下，是送货信息表单。该生物还由其他原子和分子组成，具有更特定的目的。

模板和页面

摆脱类比，我们可以使用我们的原子，分子和有机体来创建模板和页面。模板是页面级对象，可将组件放置在布局中并阐明内容结构下的设计。

如果我们将页面的结构重用于许多不同的应用程序，则可以将该模板用于其他页面。模板显示所有必要的页面组件一起运行，从而为我们相对抽象的分子和生物提供了上下文。

通过定义页面的模板，我们可以创建一个说明不同动态内容的系统，同时为填充某些设计模式的内容类型提供所需的防护栏。

最后，页面是模板的特定实例，这些模板显示了具有实际代表性内容的体验的样子。除了向用户展示最终界面时，页面还是测试底层设计系统元素有效性的关键。我们可以看看在页面级将实际内容应用于设计系统时，所有这些模式如何保持。

在下面的示例中，我们采用了运送信息表格，并将其应用于网站或应用程序中的特定页面。

设计系统忘记辅助功能时会发生什么？

因此，我们已经将原子带入一个分子中，将该分子与其他原子和分子捆绑在一起以创建有机体，然后将其应用于页面和/或模板。这些是使我们的设计系统在设计和开发中蓬勃发展的基本设计原则。规模合理的设计系统可以使围绕用户需求的想法变得无限容易，并使我们的工作流程更加高效。很简单，对不对？

但是，请稍等！

原子设计非常好，但是当我们创建此示例界面时，我们并未考虑可访问性。我们只是在考虑设计系统。这样做可能会对整个系统产生影响，所以让我们退后一步来了解其中的一些影响。

在示例界面中，我们创建了一个页面，其中包含但不限于以下问题：

• 使用无视觉标签的汉堡菜单，并且程序化标签周围不清晰。汉堡菜单无法提供清晰的上下文，并且用户在不加上视觉和程序化标签的情况下就难以理解其目的。
• 表单字段都没有必填的指示符，因此用户不会知道必填或可选的内容。
• 表单字段的边界对比度很差，这意味着用户可能很难知道在哪里选择表单字段来输入数据（当前对比度为1.48：1）。
• 表单字段标签彼此相邻放置。用户是否可以在不损失内容或功能的情况下在此界面上放大200％？
• 没有提供输入说明。如果输入与所需格式不匹配，用户是否知道如何防止错误发生？
• 保存按钮上的颜色对比度不够高。结果，用户可能难以阅读它（当前的对比度为2.38：1）。
  

设计应考虑可访问性

可能会有比这更多的问题，但是我们可以开始理解，只有少数事件会很快使无法访问的事物变得很快。如果我们在不考虑可访问性的情况下使用原子，分子和生物，那么即使在我们的整个经验中，我们也会在整个页面中遇到涉及可访问性问题和问题的元素。审核整页可能会有些麻烦，尤其是当问题与组件的固有设计或组件的构造有关时。

为简化起见，让我们回到最开始。在我们制造有机体或分子之前，我们已经有了原子。我们可以从一个原子（即我们的按钮）开始查看此页面的可访问性。我们的示例按钮设计可能有一些缺点，但是为了简单起见，让我们集中讨论它不符合颜色对比度标准的情况。

这个错误不仅与我们的原子有关，而且与我们的文字样式和颜色选项中的亚原子有关。在本文的前面，我们讨论了这些基本元素以及它们如何影响这些设计。现在我们可以看到使用这些基础来创建原子而无需考虑可访问性的后果。

我们的按钮在其背景中使用了天蓝色，并在顶部使用了白色文本。我们的文本为14像素，大写，半粗体。当我们使用色彩对比检查器测试此按钮时，我们可以知道此按钮不符合色彩对比要求。当对比度需要达到4.51以通过最低要求水平时，这种颜色/类型的组合的比例为2.39：1 。

此处显示的对比度检查器是Figma的Stark插件。
但是，正如我之前提到的，这种颜色组合不仅会影响此组件，还会影响更多。我们知道某个组件存在问题，并且我们知道它很可能会影响其他人，因为它的问题是基础性的。这是我们的审核真正开始发挥作用的地方。

设计应考虑可访问性

诸如颜色对比示例之类的问题就是为什么设计需要考虑可访问性，尤其是在设计系统中。在设计社区中存在一个误解，即可访问性通常是开发人员的责任，但是当开发人员以设计为中心时，他们便无法解决设计系统问题。

实际上，去年的Deque案例研究发现67％的可访问性问题都源于设计。

如上所示，如果不及早且经常解决，解决可访问性问题可能会增加花费的时间和金钱。由于设计系统是我们最有效地扩展的方式，因此在这些系统中优先考虑可访问性可以节省大量时间和金钱。当在我们的设计系统中广泛应用时，修复诸如颜色对比之类的问题会导致我们产品的全面可访问性改进。

审核设计系统

查看现有文件中的内容

在开发之前，最简单的时间来检查我们的设计是否符合可访问性。但是，我们中的许多人都在设计系统中使用实时组件，飞行中组件，甚至是实时但未记录的组件的组合。设计系统的可访问性审核的开始步骤看起来像是标准组件审核。我们要检查我们的组件，这些组件被最积极地用于创建设计和记录现有内容。

我们现在还不必开始考虑可访问性。相反，这里的目的是记录存在的内容并将具有相似目的的元素收集在一起。在使我们的工作更易于访问之前，我们需要了解系统现在的可访问性以及需要走的距离。我们可以审核单个组件，相关组件或整个组件系统。我们甚至可以审核一个按钮，但仍然可以获得可行的结果。这与我们要如何处理它以及一段时间内拥有的资源有关。

我们可能会发现现有的设计组件包括原子，分子和生物。重要的是要捕获所有这些，并注意它们的预期目的。我们不必写完整的文档或诸如此类的东西，只需做笔记即可。

捕获所有实时组件

同样，我们应该捕获所有实时组件。我们可以通过引用我们的设计文件，开发库，实时经验或两者之间的任何内容来做到这一点，只要我们捕获存在的内容或打算制作的内容即可。我们还应该包括诸如悬停或焦点之类的不同交互状态之类的东西。

为此，我们可以通过屏幕快照捕获每个模式库和实时组件，然后将其上载日期，时间和位置的文件上传到清单文件中。然后，可以将捕获的每个项目放置在按目的命名的页面上。在记录当前存在的内容时，以这种方式捕获组件非常有用，因为当前存在的内容很容易在实时产品中更改。这样可以确保我们能够记住它们的存在时间和地点。

请记住，捕获这些组件的目的是首先审核系统本身以及存在的内容。您的过程的这一部分仅仅是关于了解我们的用户正在与之交互的内容，并确保我们能够了解某个组件对系统整体造成的影响。

例如，我们的按钮将对我们的用户产生更大的影响，因为它们是我们体验中使用的核心组件。如果其他组件与必要的交互（例如用户的登录能力）相关，则可能仍会产生重大影响。

交叉引用并开始绘制问题

在系统审核的最后一部分，我们要确保我们捕获的内容在我们所有经验中都是一致的，并记录所有独立或独特的实例。我们需要确保设计中的这些按钮与开发库中的按钮保持一致，并且还与实际使用的按钮保持一致。

在捕获实况时，我们可以与我们的设计团队进行交叉引用，然后我们可以开始看看存在哪些差距。现在您可能在想：“仅仅审核我们的设计系统不会对可访问性有所帮助！” 但是请记住，可访问性应该纳入我们现有的设计系统策略中。我们需要对我们的设计系统进行审核和扩展，以使其能够扩展可访问性。这些做法应齐头并进。

现在，我们已经审核了系统，现在可以讨论需要检查哪些内容以确保可访问性合规性以及如何进行。

将可访问性纳入我们的审计

设计中常见的可访问性问题

我们应该在设计方面审核什么？正如我们之前提到的，可访问性问题中有67％是从设计开始的，所以它可能比我们意识到的还多！Web内容可访问性指南中概述了许多项目，其中许多与设计一样涉及设计。尽管我们前面的示例着重于数字设计中可访问性的典型示例，但我们需要牢记的不仅仅是色彩对比。

设计中需要概述的其他一些标准可访问性要求包括：

• 颜色使用
• 内容策略
• 标题结构
• 链接行为
• 悬停状态和焦点状态
• 表格（错误，标签等）
• 布局（一致性，响应性）
• 媒体（字幕，替代文字等）
• 制表符顺序和旁路块
• 定时
• 版式
• 和更多！

WCAG的《快速参考指南》是参考我们需要考虑的一个好地方，其中包括所有这些内容以及更多内容，以及满足这些准则的方式。在进行审核和通过审核运行组件时，此快速参考也非常方便。

当我们有一组按目的概述的组件时，我们可以更轻松地浏览UI并了解其他可访问性需求。现在，我们可以根据原子，分子和有机体的样式和用途来研究它们，这将帮助我们解决更多的表面问题。

除了色彩对比，可访问的设计还有更多内容。

您可能在想，WCAG是否真的仅适用于颜色对比或UI？但是，我们设计系统中的可访问性审核不仅涉及色彩对比或UI。审核我们的设计系统的可访问性与UX以及UI一样重要。正如我们所讨论的，可访问性大部分位于系统的其他部分，包括内容，层次结构，图像等等。尽管UI可访问性确实很重要，但设计人员倾向于认为我们对可访问性的责任主要集中在颜色和类型上，因为我们没有意识到UX与可访问性的紧密联系。

因此，让我们一起回顾一下组件。

此示例警报设计为具有一组不同类型的消息：信息，成功，警告和错误。我们可以通过此警报调查几个用户体验项目。例如，我们可以问问自己，这些图标是否应具有替代文字？假设这些图标当前没有替代文本，但我们认为它们应该显示，因为我们希望该图标向可能看不到该图标的用户传达警告音。

因此，在可访问性审核中，我们可以注意到这些图标没有使用替代文本，并将其与WCAG 1.1.1非文本内容相关联。如果我们在其他地方出于类似目的使用这些图标，则审计中的此注释将帮助我们将UX元素扩展到许多不同的实例。

或者，假设我们的错误警报在一个警报容器中显示了多个错误。我们将需要询问该警报是否标识了需要修复的错误，错误的位置以及如何修复它们。如果我们的警报没有执行这些操作，则可以记录该问题并将其与WCAG 3.3.1错误标识关联。

这些只是我们作为设计师可以并且应该在考虑现有组件并构建新组件时应该问自己的问题。如果我们将这些组件放在一起，并提供它们的上下文参考，那么对于我们来说，更容易理解潜在的可访问性差距并将其添加到我们的审核中。

在我们学习如何记录审核之前，还有最后一件事：我们的设计系统审核应该同时审核设计和可访问性代码。如果我们的组件位于组件库中或处于运行状态，我们也将要查看它们的代码。因为尽管我们可以解决设计中67％的问题（如所有可访问性），但我们的工作不会在一个团队中开始或停止。

我知道有些设计师可能会对审核代码的可访问性问题有些畏惧，但是我们不必是开发人员即可审核代码。要查看代码，我们可以直接与开发人员合作，甚至可以使用使我们能够在页面或特定组件上审核代码的工具通过。许多工具使我们能够审核页面或特定组件上的代码。

我会呼吁Chrome开发者使用斧头DevTools插件，这是设计师在审核设计系统时尝试的好选择。当您选择更多信息，与之相关的WCAG标准以及用户影响时，Axe DevTools会告诉您问题出在哪里。使用此工具，我们可以运行自动化测试和指导性手动测试，以彻底审查我们的设计和代码。

使用ax DevTools：

1. 在Chrome中，我将右键单击并选择“检查”，然后选择“ ax DevTools”选项卡。
2. 对于组件审核，可以选择“扫描我的页面的一部分”。然后，选择页面中您要审核的部分，然后单击“扫描”。
3. 使用突出显示工具将重点放在您要关注的设计项目上
4. 保存结果或将问题导出为CSV或JSON文件
   

如何记录审核

到目前为止，我已经讨论了什么是设计系统以及在设计系统可访问性审核中要寻找什么，但是让我们讨论如何记录审核。我知道我已经暗示过要在审计中添加一些内容，但是看起来如何？

包括背景详细信息

请参考此背景示例以及“辅助功能审核模板”中的其他详细信息。
任何辅助功能审核（无论是我们的设计系统，代码还是页面等）都要求您从构建背景开始。我们应该提及谁在审核，我们正在审核的摘要以及我们希望满足的可访问性级别。我们还希望包括审查范围，时间表和概述审查过程。

此背景至关重要，因为在完成审核后将始终引用我们的审核，并且我们需要确保正在审核的人都有进行审核的背景。如果我们的评论较旧，则无论谁查看它，都可能知道它不再具有相关性。包括这些详细信息将帮助我们和我们的同行最大限度地利用审核。它还将为将来的审核创建出色的比较基准。

建立您的审核

既然我们已经讨论了审计本身，那么我将仅简要地介绍构建审计的过程。列出我们捕获的项目列表将有助于我们了解存在的问题，严重性以及解决问题的方法。

如果我们使用的是斧头DevTools Pro，则可以导出结果并根据组织的需要对细节进行微调。默认情况下，Axe总是包含大量详细信息，因此我发现可以轻松地根据我的受众和审核要求进行自定义。我们还可以在遇到更多问题时或在何时/是否在设计工具而不是代码中进行审核时，将项目手动添加到我们正在使用的CSV或JSON斧头文件中。

通常，我建议至少包括：

• 项目/组件–与此问题相关的组件是什么？屏幕快照的链接在这里很有价值，因为它们可以帮助某人理解我们所指的内容。
• WCAG指南– WCAG中的哪些问题与此相关？使用WCAG的快速参考指南链接到相关WCAG项可以对设置上下文有很大帮助。
• 影响–这会对用户或企业产生多大影响？该项目多久使用一次（更多=产生更大影响）？此项用于必要的操作（例如登录）吗？AxenDevTools Pro将推荐影响力，这对作为基准很有帮助。
• 描述–详细描述发现的问题
• 建议–说明您的团队解决问题的方式。在许多情况下，可以通过多种方式解决问题。我们可以描述可能的修复程序，以帮助我们的团队了解选项。

我鼓励您自定义方法，以找到最适合您和您的团队的方法。最重要的是，您正在尝试以使问题可操作的方式记录问题，以便您的组织或团队可以采取相应的行动。

小组主题和常见项目

此外，在进行和记录审核时，我建议将经常发生的项目分组在一起。再次，这触及了我们的原子尺度：如果在许多不同的项目上都发生了对比度问题，则可以将它们归为一组问题。分组和主题化，特别是对于您的设计系统审核，非常重要，因为这意味着您将产生更大的影响，而不必在许多不同的地方进行大量的微调。设计系统的强大功能在于，只需付出一点点努力，一项更改便会产生可观的影响。

注意意图与应用

要记住的另一件重要事情：您可能会发现，当您单独审核设计系统时，并没有捕获到需要使所有内容都更易于访问的所有内容。这是因为设计人员倾向于在复杂的系统中工作，而设计系统都与意图有关。因此，在某些情况下，您在审核和修复中捕获的内容可能不适合您的设计系统的应用程序。

您的原子可能很棒并且易于访问，但是您的有机体需要更多的关注，因为它们在特定情况下更加独特。也许由于您最终使用的副本之类的东西而无法访问您的设计系统组件的实现。

这就是我经历原子量表的原因之一：帮助我们了解意图和应用之间的区别。从设计系统开始将走得很远，但是由于应用程序不同，不一定要修复实时站点上的所有内容。

您应该如何处理审核？

一旦完成审核，下一步该怎么做？首先，您需要使用创建的电子表格中的发现结果来授权您的团队。拿到包含数百个项目的电子表格有助于解决问题，但是如果您只给利益相关者一个电子表格并说“你去了！”，那将是令人生畏的。

相反，这是您应该执行的审核工作，以使其更有用：

• 概述影响区域并确定关键，严重，中等，较小和最佳实践的项目数。
• 确定关键主题，即整个系统中最常见的项目。
• 创建一个影响框架，以确定哪些问题影响最大，工作量最低。
• 以一种可消化的积极方式与您的团队和组织共享结果。
• 与利益相关者一起确定改进的优先级。

使您的审核工作为听众

可访问性审核本身最重要的事情是使其可操作并与团队共享结果，使他们易于学习和采取行动。

下面是一个针对客户的审计共享示例，其中我概述了最常见的问题，主题和影响较大的项目。结束审核后，我们需要确保以高水平介绍已发现的所有内容。也就是说，我们需要概述确定和确定主题最关键的部分，并共享一个影响框架，以帮助确定哪些问题可以最快地得到解决并产生最大的影响。

将这些内容与我们的完整审核一起，意味着我们可以以一种易于消化的方式共享结果，并与利益相关者一起对改进进行优先级排序，同时还拥有针对每个问题采取行动的详细信息。

不适合残疾人士的设计

最后，请记住，可访问性只是设计的一种形式，需要讨论和测试所有设计的方式。区别在于可访问性是确保残疾人的需求可访问我们的设计。

无障碍设计的最重要方面之一是与残疾人并肩而不是为残疾人设计。WCAG由残疾人编写，并由残疾人编写，因此非常适合在审核中使用。但这就是一切吗？不，像所有设计一样，可访问性要求我们与人们交谈并了解他们的独特情况，尤其是在使用我们的网站和产品时。

审核不能代替残疾用户进行测试和设计。尽管我不会在这篇博客文章中（也许是另一篇文章）建议一种完美的包容性研究策略，但我还是想指出这一点，因为我不希望任何人认为审核是关于可访问设计的一切。这是一个关键组成部分，但我们需要不断听到并尊重用户的需求和残疾人。我鼓励您从审计中获得见解，找到方法询问用户的想法，与他们一起测试您的想法，并特别注意边缘化的用户。

概括

无论您对可访问性有多满意，开始审核设计系统的可访问性都是一项艰巨的任务。但是，我想鼓励您保持好奇心。许多设计师都没有接受有关可访问性的培训，而这是在教育机构而非您身上进行的。您对学习感兴趣的事实是非常重要的一步。

如果您不熟悉审核设计或代码的可访问性，请尝试使用DevTools Pro斧头，打开WCAG的快速参考，然后随便记录发现的内容。问自己问题。向您的团队提问。只是玩弄这些工具，略过这些准则，而好奇会带您走远。老实说，我的无障碍知识很多都来自于这些实践。

开始审核的工具：

1. 斧头DevTools Pro
2. WCAG的快速参考
3. 观看如何使用我给的axe-con演示文稿进行审核
4. 原子设计，布拉德·弗罗斯特（Brad Frost）
5. A11y Project的辅助功能清单

原文

https://www.deque.com/blog/au...