在建立一个组件库时，一个很大的挑战是优先考虑可访问性。
可访问性通常被看作是那些 "不错的 "功能之一，不幸的是，我们仍然远远没有把它看作是开发人员技能组合的一个重要部分。我明白 - 引入可访问性实践可能是具有挑战性和耗时的。但是，有一些惊人的工具可以帮助你和你的团队使这种实施不那么令人难以接受，更重要的是，使其持久。
在这篇文章中，我们将在以下几个部分探索Storybook的可访问性附加组件。
- 如何安装和配置该插件
- 使用可访问性插件来测试导航组件
- 通过一些常见的可访问性问题，在Storybook的帮助下可以很容易地进行审核
为什么选择Storybook？
Storybook被广泛用于各团队，以开发一个一致的用户界面。这个开源项目将设计和工程团队聚集在一起，专注于组织一个完美的组件库。
在多个贡献者的帮助下，Storybook的团队一直在开发新的附加组件，为其核心UI扩展更多的功能。在他们帮助用户建立无障碍应用程序的努力中，Storybook发布了他们的无障碍附加组件。
这个项目背后的想法是为Storybook内的自动可及性测试提供支持，以捕捉和浮现可及性错误。在整个开发过程中解决这些问题，可以让我们花更多的时间在辅助技术的手动测试上，从而提高整个网络的可访问性标准。
可及性插件在每个Story上运行 deque axe可及性测试工具。axe是一个自动化的可及性测试工具，可以与你选择的框架或浏览器一起使用。
可访问性插件提供了一个面板，我们可以在每个故事的用户界面中看到axe的测试结果。这非常好，因为我们可以在开发过程中测试我们的组件是否符合通用的可访问性标准和准则。
除此之外，可访问性插件还包括一个色盲模拟器，它可以复制视觉障碍，如脱色症、原色症或三色症。
将无障碍插件添加到你的项目中
在安装Storybook之前，重要的是要记住，它不能在一个空的项目中运行。Storybook需要检查你的项目的依赖性，以便为你提供最佳配置。在我们的案例中，我们将在一个React应用程序中运行它。
出于这个原因，我们将首先运行Create React App来初始化我们的React应用程序。如果你心中有一个想要的项目，你可以简单地安装Storybook。
# Add Storybook:
npx sb init
# Starts Storybook in development mode
npm run storybook
Storybook已经附带了一些essential addons ，但不幸的是，这些并不包括无障碍插件，所以我们也要安装它。
npm install @storybook/addon-a11y
为了结束设置，我们需要在.storybook 文件夹内创建或添加一个main.js 文件，内容如下。
// .storybook/main.js
module.exports = {
addons: ['@storybook/addon-a11y'],
};
测试我们的组件
让我们来看看一个顶部导航组件的例子。
乍一看，这个组件看起来已经准备好了，但如果我们进入可访问性选项卡，测试结果告诉我们一些不同的东西。
该导航组件缺少某些可访问性要求，因此axe列举了四种违规情况。
可访问性插件有一个高亮结果复选框，有助于识别失败的组件。在处理较大的组件时，这可能非常有用，因为它将使我们不必在每个组件中单独重新运行这些测试。
-
确保按钮有可识别的文本- 表示当使用图标作为按钮而没有可见的标签时，必须为屏幕阅读器添加一个内部文本，这可以通过添加
aria-label- 我们的对比度不符合WCAG AA比例的阈值，这使得我们的链接和文本在整个组件中很难读懂。
-
我们的导航条包括一个带有图像的头像，而这个头像没有一个
alt属性用于替代文本描述 -
确保
<li>元素的使用是有语义的-- 检测出被用作链接的列表元素没有被包裹在<ul>元素中。强烈建议使用语义HTML，因为它允许屏幕阅读器和辅助技术用户轻松浏览页面的标题和章节
正如我前面提到的，可及性插件可以相当快地检测到所有这些可及性违规行为，这使得它非常适合在开发过程的早期阶段保持对核心可及性标准的高度关注。
根据你的需要配置axe
值得一提的是，可访问性插件尊重axe的基于规则的系统，并允许我们根据我们的需要配置可访问性违规。
为了更好地了解你可以覆盖和禁用的一组规则，请查看 axe-core configurationOptions.如果你对axe不太熟悉，我强烈建议你浏览一下规则描述--它将使你了解哪些规则可以定制，并为你提供进一步的研究，了解在哪些情况下可以这样做。
例如，我们可以使用parameters.a11y.config.rules 在Story级别上覆盖其中的一些规则。
const Story = {
title: "Components/Navigation",
component: Nav,
parameters: {
a11y: {
config: {
rules: [
{
// Override the result of a rule to return "Needs Review" rather
// than "Violation" if the rule fails. It will show in the
// 'Incomplete' tab.
id: "color-contrast",
reviewOnFail: true,
},
],
},
},
},
};
如果我们想在全局层面上忽略一个规则，我们可以在我们的故事书的preview.js 文件中使用parameters.a11y.config.rules 。
// .storybook/preview.js
export const parameters = {
a11y: {
config: {
rules: [
{
id: 'listItem',
enable: false,
},
],
},
},
};
我们总是建议包括一个注释，说明规则被覆盖的原因，因为这将帮助你和你的团队理解为什么有些规则在测试中没有被报告。
自动化可访问性测试
可以在自动化测试中使用Storybook，它支持将你的故事与Jest等测试框架集成。此外，你也可以使用React测试库。或者，你可以同时使用两者。
在此基础上，我们还可以通过Jest Axe的集成在我们的每个组件上实现可访问性测试。这个项目在Jest中引入了一个Axe-matcher，这样你就可以自动搜索违规行为了。
const { axe, toHaveNoViolations } = require('jest-axe');
expect.extend(toHaveNoViolations);
/// tests
总结
最后说明：其他的无障碍实践，比如针对最常见的辅助技术测试用户界面，以及在你的用户研究中包括残疾，仍然是非常值得鼓励的测试你的应用程序无障碍性的方法。这只是在你的应用程序中浮现无障碍性问题的一种方法，而绝不是我们所描述的手动测试的替代。
看到越来越多的开发者努力引入有助于建立无障碍用户界面的工具是非常令人兴奋的。尽管增加测试覆盖率并不能确保你的组件库是完全无障碍的，但它肯定是朝着承认无障碍性是一个完美组件库的标准而迈出的一步。
The postTesting accessibility with Storybookappeared first onLogRocket Blog.
