许多人在其开发工作流程过程中使用组件驱动的开发，包括模式样式指南、组件库或完整的设计系统。即使您没有正式使用过这些工具，您也可能使用类似的过程将网站、应用或其他数字产品的大型设计分解为可管理的部分。
就像建造实体结构一样，一次构建一个部分非常重要。首先是地基、结构、墙壁、窗户、屋顶以及介于两者之间的一切。组件驱动的开发工具使我们能够为网站、应用和其他数字产品做到这一点。
组件驱动开发的一些好处包括将事物分解为可管理的部分，因此使用这些可重用组件可以减少开发时间。它允许设计师、前端和后端开发人员以及 QA 同时工作。客户、设计师、PM 等也喜欢它，因为他们可以预览构建过程，并在网站启动后使用动态样式指南作为参考。
然而，当我们从无障碍功能的角度看待模式、组件和设计系统时，出现了一些问题。在无障碍功能方面，您如何知道哪些模式是最佳的？您应该使用已建立的模式或库，还是创建新的模式或库？您如何知道这些模式是否真的能帮助您的用户？
由于有无数种选择，因此很容易对模式、组件和设计系统感到困惑。本模块旨在为您提供有关如何评估模式、组件和设计系统的无障碍功能的一般信息，并为您提供一个起点，以帮助您做出更易于访问的选择。
批判性思考
选择可访问的模式、组件或设计系统并非火箭科学，但确实需要时间和批判性思考。事实上，没有所谓的“完美模式”，但可能有许多可行的选项。关键在于学习为您的独特情况选择最佳选项。
在后续的测试模块中，您将阅读更多关于如何评估模式、组件和设计系统的无障碍功能的技术和方法。在您开始之前，您需要问自己一些基本问题，例如
- 是否已经存在已建立的可访问模式、组件或设计系统？
- 我支持哪些浏览器和辅助技术 (AT)？
- 是否存在任何代码或框架限制？是否还有其他集成、因素或用户需求我应该考虑？
根据您的开发环境和用户需求，您可能还有其他或不同的问题。将这些问题视为您无障碍功能评估的起点。
已建立的资源
在构建全新的东西之前，请尽职调查并审查在可访问模式、组件和设计系统方面已存在的内容。只需稍作研究，您可能会惊讶地发现一个（或多个）适合您需求的解决方案。
一些关于可访问模式、组件和设计系统的优秀资源包括
- Accessible Components
- Deque University ARIA library
- Gov.UK Design System
- Inclusive Components
- MagentaA11y
- U.S. Web Design System (USWDS)，为美国联邦政府创建
- Smashing Magazine 的可访问模式列表
对于 JavaScript 框架，以下资源在默认情况下相当容易访问或可自定义以实现无障碍功能
- 当 CSS 不够用时：可访问组件的 JavaScript 要求
- React
- Angular：Material library
- Vue：Vuetensils
然而——这一点怎么强调都不为过——您永远不应仅仅复制/粘贴代码并假设它将适合您的环境并自动满足您的用户需求。这适用于所有模式、组件和设计系统，即使它们被标记为完全可访问。
所有资源都应被视为起点。务必测试一切！
浏览器和辅助技术 (AT) 支持
在研究了一些可能适用于您的开发环境的基础模式、组件或完整设计系统之后，您可以继续进行辅助技术支持。在评估模式、组件和设计系统时，您需要关注的一种主要 AT 类型是屏幕阅读器。
屏幕阅读器在构建时考虑了特定的浏览器，并且在与这些浏览器配对使用时效果最佳。我们将在关于 AT 测试的模块中更详细地探讨这个主题，但出于模式评估的目的，了解这些组合的存在很有帮助，这样您就可以知道您在支持方面需要什么。
| 屏幕阅读器 | 操作系统 | 浏览器兼容性 | 费用 |
|---|---|---|---|
| Job Access with Speech (JAWS) | Windows | Chrome、Firefox、Edge | 需要许可证（存在 40 分钟免费版本） |
| Non-Visual Desktop Access (NVDA) | Windows | Chrome 和 Firefox | 免费（需要下载） |
| 讲述人 | Windows | Edge | 免费（内置于 Windows 计算机中） |
| VoiceOver | macOS | Safari | 免费（内置于 macOS 计算机中） |
| Orca | Linux | Firefox | 免费（内置于基于 Gnome 的发行版中） |
| TalkBack | Android | Chrome 和 Firefox | 免费（内置于某些版本的 Android 操作系统中） |
| VoiceOver | iOS | Safari | 免费（内置于 iOS 设备中） |
浏览器支持通常很复杂，当您将 AT 设备和 ARIA 规范添加到组合中时，事情会变得更加棘手。
但这并非全是坏消息。值得庆幸的是，HTML5 Accessibility、Accessibility Support 和 WCAG 的 自定义控件可访问开发清单等优秀资源帮助我们更好地理解当前的浏览器和 AT 设备支持，甚至在何时首先使用 ARIA。
这些资源概述了可用的不同 HTML 和 ARIA 模式子元素，包括开源社区测试。您还可以查看一些适用于桌面、移动浏览器和 AT 设备的模式示例。因此，这些资源可以帮助您就您可能想要使用的模式、组件和设计系统做出更易于访问的决定。
其他注意事项
一旦您选择了几个可访问的基础模式或组件，并考虑了浏览器和 AT 设备支持，您就可以继续提出关于模式、组件、设计系统和开发环境的更具体的上下文问题。
例如，如果您在管理系统 (CMS) 中工作或有遗留代码，则您可以使用哪些模式可能会受到一些限制。经过审查，几种模式选择可能会很快减少到一两个选项。
许多 JavaScript 框架允许开发人员使用他们选择的几乎任何模式。在这些情况下，您可能受到的限制较少，并且可以选择最易于访问的模式选项。
在选择模式、组件或设计系统时，还需要权衡其他注意事项，例如
- 性能
- 安全性
- 搜索引擎优化
- 语言翻译支持
- 第三方集成
这些因素无疑会影响您对模式的选择，但您还应该考虑创建内容和代码本身的人员。您选择的模式必须足够强大，以处理围绕编辑器生成或用户生成内容的任何潜在限制，并且以所有无障碍功能知识的开发人员都可以使用的方式构建。
检查您的理解
测试您对模式的了解
可访问的组件是否始终对用户保持可访问性？