自2012年开始我的职业生涯以来，关于包容性设计的知识一直受到教学差距的阻碍和限制。我的目标是帮助想要构建更好、更具包容性的体验的设计师、开发人员和技术人员畅通无阻。在这篇博文中，我想特别告知我的设计师同事们，出于可访问性的原因，他们需要去哪里。我将专注于我认为设计师可以做的最关键的无障碍工作：创建具有内在无障碍合规性的设计系统。特别是，我们将专注于学习如何在现有设计系统中查找可访问性问题，并以一种使我们自己和我们的团队可操作的方式记录它们。您可以在YouTube上播放本文的视频版本！设计系统和可访问性设计系统究竟是什么？设计系统是产品、网站或体验的单一真实来源。这些包括设计/开发组织的共同目标和价值观，以及品牌元素和组成部分。设计系统将相关的实施元素组合在一起，定义它们的目的并阐明它们的交付。正确完成后，设计系统应与组织一起发展和扩展。这些系统很重要，因为它们使我们能够大规模工作，做一些事情，然后将其应用到任何地方，并建立一个更一致的品牌。但最重要的是，设计系统是必不可少的，因为它还可以帮助我们扩展可访问性。我们在系统中创造的每一个原子、分子和有机体都会影响我们扩大规模和满足残疾人需求的能力。我对原子、分子和有机体的引用是对BradFrost的“原子设计”的直接引用（如果您对思考设计系统感兴趣，我建议您阅读它）。当AtomicDesign于2016年发布时，它标志着数字设计思维的重要转变。虽然许多团队已经开始使用Bootstrap等模式库和框架，但AtomicDesign承认我们都开始看到：数字设计需要更好的系统。四年后，当设计团队捍卫设计系统时，BradFrost的书仍然经常被引用。我们还可以使用这种方法来帮助告知如何大规模设计无障碍功能，以及如何审核我们的系统以确保无障碍合规性。在中，BradFrost使用原子方法分解了设计系统的规模。我们的系统本质上是重叠的，从原子等元素开始，这些元素可以结合形成分子，然后进一步结合形成生物。这些生物通知并创建模板，然后可以将其应用于我们平台内的特定页面。在这个规模上，每个人和每个团队都有不同的理解或行话，但这些原则的基本要素在大多数数字设计系统中往往是一致的。我们不必拥有一个健壮或“完美”的设计系统来使用这种方法或审核可访问性。无论我们的团队是刚刚起步，还是已经拥有一个记录完备的系统，或者介于两者之间，这篇博文中介绍的内容都可以在我们设计系统开发的任何时候应用。亚原子粒子让我们从分解原子设计的尺度开始。但在讨论原子之前，让我们先谈谈我们的“亚原子粒子”，它们是构成我们设计的系统的基石。它们不是我们的原子，但它们可以告知原子的产生。这些亚原子粒子通常是品牌颜色或字体之类的东西。尽管这些元素本身对我们的系统来说似乎不是最重要的，但它们会影响我们创建的所有内容，从最小比例到完整页面。Atoms一目了然地展示了我们所有的基本样式，这对于我们在开发和维护设计系统时不断回过头来很有帮助。有些系统比其他系统具有更大的粒度，因此请注意，在这种情况下，像“原子”这样的词有时在不同的团队中可能有不同的含义。就我们的目的而言，原子是表单标签、输入和按钮等元素，以及其他不能在不停止运行的情况下被分解的元素。下面的示例是一个标签、一个下拉选择器和一个按钮，每个都充当一个唯一的原子。然而，与自然界中的原子一样，界面原子并不存在于真空中，只有在应用中才能真正实现。分子在原子水平上更进一步，我们有分子：分子是相对简单的元素或原子组，它们一起作为一个单元发挥作用。例如，表单标签、下拉选择器和保存按钮现在可以是功能表单字段单元。当连接在一起时，这些抽象原子突然有了目的。之前我们有标签、下拉菜单和按钮，但现在我们可以通过组合它们来组合这些元素。现在，选择按钮原子保留下拉输入，标签指示这些输入的用途。结果：一个简单、便携、可重用的组件，可以放置在需要下拉输入或保存表单的任何地方。有机体再次扩大规模：有机体是由分子和/或原子团甚至其他有机体构成的相对复杂的构件。这些生物体形成界面的不同部分。从分子积累到更精细的有机体，它为设计者和开发者提供了基本的环境意识。有机体表现出更小、更简单的运动组件，并作为可重复使用的独特模式。下面是我们应用于特定环境的示例下拉/保存表单，在本例中为运输信息表单。有机体也由具有更特定目的的其他原子和分子组成。模板和页面抛开类比，我们可以使用我们的原子、分子和有机体来创建模板和页面。模板是页面级对象，用于将组件放置在布局中并阐明内容结构下的设计。如果我们为许多不同的应用程序重用该页面的结构，则该模板可用于其他页面。模板显示了所有必要的页面组件一起运行，为我们相对抽象的分子和有机体提供了上下文。通过为页面定义模板，我们可以创建一个系统来考虑不同的动态内容，同时为填充某些设计模式的内容类型提供所需的护栏。最后，页面是模板的特定实例，显示具有实际代表性内容的体验。除了向用户呈现最终界面之外，页面是测试底层设计系统元素有效性的关键。我们可以看到在将实际内容应用到页面级别的设计系统时，所有这些模式是如何保持的。在下面的示例中，我们采用了运输信息表单并将其应用于网站或应用程序中的特定页面。当设计系统忘记可访问性时会发生什么？因此，我们将原子放入分子中，将该分子与其他原子和分子捆绑在一起以创建有机体，然后将其应用于页面和/或模板。这些是使我们的设计系统在设计和开发中蓬勃发展的基本设计原则。一个适当大小的设计系统可以使围绕用户需求的思考变得更加容易，并使我们的工作流程更加高效。简单吧？但是等一下！原子设计很棒，但是我们在创建这个示例界面时没有考虑可访问性。我们只是在考虑设计系统。这样做会产生系统范围的影响，所以让我们退后一步，了解其中的一些影响。在示例界面中，我们创建的页面存在但不限于以下问题：使用没有视觉标签的汉堡菜单，周围的程序标签不明确。汉堡菜单不提供清晰的上下文，如果没有视觉和程序标签，用户很难理解它们的用途。所有表单域都没有必填指示符，因此用户不知道什么是必需的或可选的。表单域边框对比度很差，这意味着用户可能很难知道在何处选择表单域以输入数据（当前对比度为1.48:1）。表单字段标签彼此相邻放置。用户能否在此界面上放大200%而不会丢失内容或功能？没有提供输入说明。如果输入与要求的格式不匹配，用户是否知道如何防止错误发生？保存按钮上的颜色对比度不够高。因此，用户可能难以阅读（当前对比度为2.38:1）。设计应该考虑到可访问性可能存在比这更多的问题，但我们可以开始理解只有少数事件可以快速使事物不可访问。如果我们在不考虑可访问性的情况下使用原子、分子和生物，那么即使在我们的整个体验中，我们也会遇到整个页面中涉及可访问性问题和问题的元素。审核整个页面可能会有点麻烦，尤其是当问题与组件的固有设计或组件的构造有关时。为了简单起见，让我们回到开头。在我们制造有机体或分子之前，我们已经有了原子。我们可以从一个原子开始查看此页面的可访问性，我们的按钮。我们的示例按钮设计可能有一些缺点，但为了简单起见，让我们关注它不符合颜色对比度标准的情况。这个错误不仅与我们的原子有关，而且与我们的文本样式和颜色选项中的亚原子有关。在本文的前面，我们讨论了这些基本元素以及它们如何影响这些设计。现在我们可以看到使用这些碱基来创建原子而不考虑可访问性的后果。我们的按钮使用天蓝色作为背景，顶部使用白色文本。我们的文字是14px，大写，半粗体。当我们用ColorContrastChecker测试这个按钮时，我们可以看出这个按钮不符合颜色对比度要求。当对比度需要达到4.51才能通过最低要求水平时，此颜色/类型组合的比率为2.39:1。这里显示的对比度检查器是Figma的Stark插件。然而，正如我之前提到的，这种颜色组合影响的不仅仅是这个组件。我们知道组件存在问题，并且我们知道它可能会影响其他组件，因为它的问题是根本性的。这是我们的审计真正发挥作用的地方。设计应考虑可访问性颜色对比示例等问题是设计需要考虑可访问性的原因，尤其是在设计系统中。设计界存在一种误解，认为可访问性通常是开发人员的责任，但当开发人员以设计为中心时，他们无法解决设计系统问题。事实上，去年的Deque案例研究发现67%的可访问性问题源于设计。如上所示，如果不尽早和经常解决，解决可访问性问题可能会增加花费的时间和金钱。由于设计系统是我们最有效地扩展的方式，因此在这些系统中优先考虑可访问性可以节省大量时间和金钱。当在我们的设计系统中广泛应用时，解决颜色对比度等问题会导致我们产品的整体可访问性改进。审核设计系统查看现有文件中的内容，这是在开发之前检查我们的设计的可访问性的最简单时间。然而，我们中的许多人使用实时组件、运行中的组件，甚至是实时但未记录的组件的组合来设计系统。设计系统的可访问性审核的开始步骤可能看起来像标准组件审核。我们想要检查我们的组件，这些组件最常用于创建设计和记录现有内容。我们不必现在就开始考虑可访问性。相反，这里的目的是记录存在的内容并将服务于类似目的的元素聚集在一起。在我们使我们的工作更易于访问之前，我们需要了解系统现在的可访问性以及我们需要走多远。我们可以审核单个组件、相关组件或整个组件系统。我们甚至可以审核一个按钮并仍然获得可操作的结果。这是关于我们想用它做什么以及随着时间的推移我们拥有什么资源。我们可能会找到现有的设计组件，包括原子、分子和有机体。捕捉所有这些并注意它们的预期目的很重要。我们不必编写完整的文档或类似的东西，只需做笔记。捕获所有实时组件同样，我们应该捕获所有实时组件。我们可以通过参考我们的设计文件、开发库、现场体验或介于两者之间的任何东西来做到这一点，只要我们捕捉到存在的东西或我们打算制作的东西。我们还应该包括不同的交互状态，如悬停或焦点。为此，我们捕获每个模式库和实时组件的屏幕截图，然后将文件及其上传日期、时间和位置上传到清单文件中。然后可以将每个捕获的项目放置在专门命名的页面上。以这种方式捕获组件在记录当前存在的内容时非常有用，这些内容可以在现场制作中轻松更改。这确保我们能够记住它们存在的时间和地点。请记住，捕获这些组件的目的是审核系统本身以及首先存在的内容。您流程的这一部分只是了解我们的用户正在与之交互的内容，并确保我们了解组件对整个系统的影响。例如，我们的按钮会对我们的用户产生更大的影响，因为它们是我们体验中使用的核心组件。如果其他组件与必要的交互相关，例如用户登录的能力，它们可能仍然会产生重大影响。交叉引用和开始映射问题在系统审计的最后部分，我们希望确保我们捕获的是在我们所有的经验中保持一致，并记录任何孤立或独特的实例。我们需要确保设计中的这些按钮与开发库中的按钮一致，也与实际使用的按钮一致。现场捕捉时，我们可以与我们的设计团队进行交叉参考，然后我们就可以开始查看存在差距的地方。现在您可能在想：“仅仅审核我们的设计系统并不能帮助提高可访问性！”但请记住，可访问性应该融入我们现有的设计系统策略中。我们需要审查和扩展我们的设计系统，以便它可以扩展到可访问性。这些方法应该齐头并进。现在我们已经审核了系统，我们可以讨论需要检查哪些内容以确保可访问性合规性以及如何检查。将可访问性纳入我们的审计设计常见的可访问性问题我们应该在设计方面审计什么？正如我们之前提到的，67%的可访问性问题始于设计，所以它可能比我们意识到的更多！Web内容可访问性指南中概述了许多项目，其中许多项目与设计一样重要。虽然我们之前的示例侧重于数字设计中可访问性的典型示例，但我们需要牢记的不仅仅是颜色对比。设计中需要概述的一些其他标准可访问性要求包括：颜色使用内容策略标题结构链接行为悬停状态和焦点状态表格（错误、标签等）布局（一致性、响应性）媒体（字幕、替代文本、等）标签顺序和旁路块定时排版等等！WCAG的《快速参考指南》是一个很好的参考我们需要考虑的地方，其中包括所有这些以及更多，以及满足这些准则的方式。在进行审计和通过审计运行组件时，此快速参考也很方便。当我们有一组按目的概述的组件时，我们可以更轻松地浏览UI并了解其他可访问性需求。现在我们可以从类型和目的来研究原子、分子和有机体，这将有助于我们解决更肤浅的问题。无障碍设计不仅仅是颜色对比。您可能会想，WCAG真的只是用于颜色对比或UI吗？然而，我们设计系统中的可访问性审计不仅仅是关于颜色对比或UI。审核我们的设计系统的可访问性与UX和UI一样重要。正如我们所讨论的，许多可访问性存在于系统的其他部分，包括内容、层次结构、图像等。尽管UI的可访问性确实很重要，但设计师往往认为我们对可访问性的责任主要集中在颜色和类型上，因为我们没有意识到UX和可访问性之间的联系有多紧密。因此，让我们一起回顾一下这些组件。此示例警报旨在包含一组不同类型的消息：信息、成功、警告和错误。我们可以通过此警报调查几个用户体验项目。例如，我们可以问自己，这些图标是否应该有替代文字？假设这些图标目前没有替代文字，但我们认为它们应该有，因为我们希望图标向可能看不到它的用户传达警告音。因此，在可访问性审核中，我们可以注意到这些图标不使用替代文本并将其与WCAG1.1.1非文本内容相关联。如果我们出于类似目的在其他地方使用这些图标，审计中的这条注释将帮助我们将UX元素扩展到许多不同的实例。或者，假设我们的错误警报在一个警报容器中显示多个错误。我们将需要询问此警报是否识别出需要修复的错误、它们在哪里以及如何修复它们。如果我们的警报不执行这些操作，则可以记录问题并将其与WCAG3.3.1错误ID相关联。这些只是我们作为设计师在考虑现有组件和构建新组件时可以而且应该问自己的问题。如果我们将这些组件放在一起，并在上下文中引用它们，我们将更容易理解潜在的可访问性差距并将它们添加到我们的审查中。在我们学习如何记录审计之前的最后一件事：我们的设计系统审计应该审计设计和可访问性代码。如果我们的组件在组件库中或正在运行，我们还想查看它们的代码。因为虽然我们可以解决67%的设计问题（比如所有可访问性），但我们的工作不会在一个团队中开始或停止。我知道有些设计师可能会因为可访问性问题而审查代码而感到害怕，但我们不必成为开发人员就可以审查代码。要审查代码，我们可以直接与开发人员合作，甚至可以使用允许我们审查页面或特定组件上的代码的工具。许多工具允许我们审核页面或特定组件上的代码。我会敦促Chrome开发人员使用axDevTools插件，它是设计师在审查设计系统时尝试的一个很好的选择。AxeDevTools会在你选择更多信息时告诉你问题出在哪里，它所涉及的WCAG标准，以及对用户的影响。使用此工具，我们可以运行自动化测试和引导式手动测试，以彻底审查我们的设计和代码。使用axDevTools：在Chrome中，我会右键单击并选择“Inspect”，然后选择“axDevTools”选项卡。对于组件审核，有一个选项“扫描我的页面的一部分”。然后，选择您要查看的页面部分，然后单击“扫描”。使用突出显示工具将重点放在您想要重点关注的设计项目上。保存结果或将问题导出为CSV或JSON文件。如何记录审查到目前为止，我已经讨论了什么是设计系统以及设计系统可访问性审查。寻找什么，但让我们讨论如何记录审计。我知道我已经暗示要在审计中添加一些内容，但它看起来像什么？包括背景详细信息请参阅此背景示例和辅助功能审查模板中的其他详细信息。任何可访问性审查（无论是我们的设计系统、代码还是页面等）都需要您从构建背景开始。我们应该提到谁在审阅，我们在审阅什么摘要以及我们想要达到什么级别的可访问性。我们还希望包括审查范围、时间表和审查过程的概述。这个背景很关键，因为我们的审稿完成后总会被引用，我们需要确保审稿的人有做审稿的背景。如果我们的评论较旧，那么无论谁看它都可能知道它不再相关。包括这些详细信息将帮助我们和我们的同行从审核中获得最大收益。它还将为未来的审计创建一个很好的基线。构建审计现在我们已经讨论了审计本身，我将简要描述构建它的过程。列出我们捕获的项目将帮助我们了解问题所在、严重程度以及解决方法。如果我们使用axDevToolsPro，我们可以导出结果并根据我们组织的需要微调细节。默认情况下，Axe总是包含很多细节，因此我发现很容易根据我的受众和评论要求进行自定义。当我们遇到更多问题或者当/如果我们在设计工具而不是代码中进行审查时，我们也可以手动将项目添加到我们正在使用的CSV或JSONax文件中。一般来说，我建议至少包括：Project/Component——与这个问题相关的组件是什么？屏幕截图的链接在这里很有价值，因为它们可以帮助人们理解我们所指的内容。WCAG指南——WCAG中的哪些问题与此处相关？使用WCAG的快速参考指南链接到相关的WCAG项目可以极大地帮助设置上下文。影响——这会对用户或企业产生多大影响？该项目多久使用一次（更多=更大的影响）？这是否用于必要的操作，例如登录？AxenDevToolsPro将推荐有影响力的人，这有助于作为基准。描述——详细描述发现的问题建议——解释你的团队是如何解决问题的。在许多情况下，可以通过多种方式解决问题。我们可以描述可能的修复，以帮助我们的团队了解选项。我鼓励您定制您的方法，以找到最适合您和您的团队的方法。最重要的是，您正在尝试以使其可操作的方式记录问题，以便您的组织或团队可以采取相应的行动。将主题和常见项目分组此外，在进行和记录审查时，我建议将经常出现的项目分组在一起。同样，这达到了我们的原子尺度：如果在许多不同的项目中出现对比度问题，则可以将它们归为一个问题。分组和主题化，特别是对于您的设计系统审核，非常重要，因为这意味着您将产生更大的影响，而无需在许多不同的地方进行大量微调。设计系统的力量在于，只需付出一点努力，一个改变就能产生可衡量的影响。注意intent与app另一件需要记住的重要事情：您可能会发现，当您孤立地审核设计系统时，您并没有捕获使一切更易于访问所需的一切。这是因为设计师倾向于在复杂的系统中工作，而设计系统都是关于意图的。因此，在某些情况下，您在审查和修复中捕获的内容可能不适合您的设计系统的应用。您的原子可能很棒且易于访问，但您的有机体需要更多关注，因为它们在特定情况下更加独特。也许由于您最终使用的副本或其他原因，您无法访问设计系统组件的实现。这就是我研究原子尺度的原因之一：帮助我们理解意图和应用之间的区别。从设计系统开始会有很长的路要走，但由于应用程序不同，不一定要在实时站点上修复所有内容。你应该如何处理审计？审核完成后，下一步是什么？首先，您需要通过您创建的电子表格中的发现来授权您的团队。获得包含数百个项目的电子表格很有帮助，但如果您只是给利益相关者一个电子表格并说“给你！”，这可能会让人望而生畏。相反，您应该对审计执行以下操作以使其更有用：概述影响区域并确定关键、关键、中等、次要和最佳实践项目计数。确定关键主题，即整个系统中最常见的项目。创建一个影响框架，以确定哪些问题以最少的努力产生最大的影响。以易于理解和积极的方式与您的团队和组织分享结果。与利益相关者合作确定改进的优先级。让您的审计为您的受众服务可访问性审计本身最重要的事情是使其可操作并与团队共享结果，使他们更容易学习和采取行动。下面是一个客户的审计共享示例，我在其中概述了最常见的问题、主题和高影响项目。审查结束后，我们需要确保我们发现的所有内容都以高水平呈现。也就是说，我们需要勾勒出识别和识别主题中最关键的部分，并共享一个影响框架，以帮助确定哪些问题可以最快地解决并产生最大的影响。将这些与我们的全面审计结合在一起意味着我们可以以一种易于理解的方式分享结果，并与利益相关者合作确定改进的优先级，同时还拥有针对每个问题采取行动的详细信息。不适合残障人士的设计最后，请记住，可访问性只是设计的一种形式，需要以与所有设计相同的方式进行讨论和测试。不同之处在于可访问性确保我们的设计能够满足残障人士的需求。无障碍设计最重要的方面之一是为残疾人设计，而不是为残疾人设计。WCAG由残障人士编写，并由残障人士编写，因此它非常适合用于审计。但这就是全部吗？不，像所有设计一样，可访问性要求我们与人们交谈并了解他们的独特情况，尤其是在使用我们的网站和产品时。审核不能替代针对残障用户的测试和设计。虽然我不会在这篇博文（也许还有另一篇博文）中建议一个完美的包容性研究策略，但我想指出这一点，因为我不想让任何人认为审计是关于无障碍设计的一切。这是一个关键组成部分，但我们需要不断倾听并尊重用户的需求和残疾。我鼓励你从审计中获得洞察力，想方设法询问用户的想法，与他们一起测试你的想法，并特别关注边缘化用户。总结无论您对可访问性有多满意，开始审核您的设计系统的可访问性都是一项艰巨的任务。但是，我想鼓励您保持好奇心。许多设计师没有接受过可访问性方面的培训，那是在教育机构，而不是你。您对学习感兴趣是非常重要的一步。如果您不熟悉审核设计或代码可访问性，请尝试使用DevToolsPro斧头，打开WCAG的快速参考，然后随意记录您发现的内容。问自己问题。问你的团队问题。只是玩弄这些工具，跳过指南，好奇心会让你走得更远。老实说，我的很多无障碍知识都来自这些实践。开始审阅的工具：AxeDevToolsProWCAG的快速参考观看如何使用我为审阅AtomicDesign而提供的ax-con演示文稿，BradFrost的A11y项目可访问性清单原件https://www.deque.com/blog/au...
