对于那些刚刚开始实施无障碍做法的人来说,学习建立无障碍网站是一项艰巨的任务。我们收集了大量的无障碍工具,从单一用途的书签到完整的应用程序,以帮助你开始建立更多的无障碍网站。
ARIA
WebAIM百万调查发现,有ARIA的主页比没有ARIA的主页平均多出41%的可检测错误。ARIA是创建复杂的网络应用程序的一个重要工具,但该规范很严格,对于那些不经常使用辅助技术的人来说,调试起来可能很棘手。工具可以帮助我们确保正确使用ARIA,而不是给我们的应用程序引入更多的错误。
Paciello集团创建了一个WAI-ARIA书签,它可以扫描您的页面,以确保所有的元素及其给定的角色和ARIA属性都有效。激活书签后,页面将被扫描,以找出任何错误,并将打开一个新的标签,显示结果。结果包括有效角色的总数,任何检测到的ARIA错误,以及发现任何错误的代码片段,这样你就可以轻松地调试你的页面。
上述书签中没有明确测试的一件事是重复的ARIA角色的存在。某些地标角色的名字听起来可能适用于多个元素,但每个页面只应使用一次,如banner
或contentinfo
。Adrian Roselli想出了一个简单的基于CSS的书签,以检查这些ARIA角色是否有重复的情况。激活这个小书签将在任何违规的元素上添加一个红色的轮廓。
NerdeRegion是一个Chrome扩展,它可以记录任何ria-live区域的所有输出。想不明白为什么你的屏幕阅读器会意外地宣布什么?NerdeRegion可以让你在DevTools的一个面板中跟踪有时间戳的公告和它们的源元素。由于不同的读屏器在宣布咏叹调区域时可能存在错误和不一致,NerdeRegion是一个很好的工具,可以找出问题是由你的代码还是由设备组合引起的。
自动测试工具
这类工具可以由开发人员或测试人员使用,对你的代码的输出进行自动测试,捕捉那些在源代码中可能不明显的错误。 除了我们在这里提到的,还有许多高质量的付费服务和其他工具,但我们把重点放在具有全面免费服务的工具上,以减少进入的障碍。所有列出的工具都可以在不在公共互联网上的页面上运行,使它们更容易被纳入开发流程中。需要注意的是,无障碍测试是复杂的,总是需要手动测试来了解网站的全部情况,但这些自动测试工具可以给你一个坚实的开端。
很多工具在引擎盖下使用axe-core,所以使用各种工具的组合可能是多余的。最终,你选择什么样的工具更多的是关于你喜欢什么样的用户界面,以及结果的全面性水平。例如,谷歌浏览器内置的工具Lighthouse使用了部分斧头核心规则,因此,如果你设法用axe DevTools获得一个干净的扫描,你应该不需要同时运行Lighthouse扫描。
[Axe DevTools](chrome.google.com/webstore/de… addons.mozilla.org/en-US/firef…
Accessibility Insights也在axe-core上运行,但有几个特点使其与axe DevTools不同。它可以在各种平台上运行,包括安卓、Windows,或作为浏览器扩展。所有版本的Accessibility Insights都有一个类似检查器的工具,用于查询单个元素信息,以及运行自动检查的方法。该网络扩展还包含一个评估功能,它结合了自动、引导和手动测试,以便让你生成一份完整的报告。
WebAIM的WAVE一直是我的工具箱中不可或缺的一部分。我发现这个工具由于其简单性和速度,最适合在开发时检查我的工作。所有的东西都以面板的形式加载在你的页面上,你可以通过滚动页面来获得一个错误的整体视图。如果一个错误显示在侧面的面板上,但你不确定它在DOM中的位置,你可以关闭样式,在标记中找到它。WAVE的标题和地标功能是我最喜欢的东西之一,因为它可以确保我在构建时的文档语义是正确的。
SiteImprove除了提供付费服务外,还有一个免费的Chrome扩展。像WAVE一样,你在一个页面上运行这个扩展,它就会在页面侧面的面板上列出错误,包括一致性级别、严重程度和责任等方面的过滤器。严重程度过滤器特别有用,因为自动测试总是倾向于产生一些假阳性结果。
颜色
去年,在高达86.4%的主页上发现了低对比度的文本错误。开发人员对调色板的控制往往是有限的,所以在设计过程中尽可能早地建立一个可访问的调色板是很重要的。
当你开始设计一个调色板时,一个浏览器内的选色工具可能会有帮助。Are My Colors Accessible是一个可以帮助你找出一个无障碍调色板的工具。基本模式可以计算出任何两种颜色之间的对比度。你的文字的字体大小和字体重量会影响到基于一致性水平所需的对比度,这个工具有助于列出所有符合的不同标准。它还具有HSL范围滑块,这样你就可以调整任何一种颜色,在你进行调整时,结果会自动更新。调色板模式让你将调色板中的每一种颜色相互比较,并显示对比度和符合的标准,这对确定你如何将不同的颜色组合在一起很有帮助。进行任何颜色调整时,也会更新固定资产,使你能够轻松地与你的团队分享颜色组合。 如果你喜欢不同的界面来选择颜色,Atul Varma建立了一个类似的工具,它使用一个颜色选择器而不是HSL范围滑块。
Geenes试图通过为你添加的每个颜色组建立完整的色调/阴影范围来做到这一点,使你能够设计一个全色系统,而不是一个有限的调色板。除了提供对比度,Geenes还允许你将你的调色板应用到各种模型上,并模拟不同形式的色盲。你可以免费试用大部分功能,并通过捐赠解锁多个调色板。
某些工具可以帮助你解决特定的与颜色有关的无障碍问题。特别是按钮可能很棘手,因为你不仅要担心文本颜色与背景颜色的关系,你还需要考虑按钮背景与页面背景的关系,以及焦点轮廓颜色与两种背景的关系。Stephanie Eckles的项目ButtonBuddy用简单的语言解释了这些要求,并帮助你为这些单独部分挑选颜色。
当没有色盲的人观看时,有些颜色组合在技术上可能符合对比度的要求,但对于特定种类的色盲和低视力来说,可能会造成问题。谁能使用“应用视觉过滤器来模拟不同类型的色盲,然后计算出一个近似的色彩对比度。
如果你想在现有网站的背景下测试你的颜色组合,斯塔克是Chrome浏览器的一个颜色选择器扩展,让你模拟某些类型的色盲。此外,安娜-莫纳斯(Anna Monus)对已经内置于Chrome浏览器的色盲工具进行了有益的编写。虽然这种模拟永远不能完全取代对真实用户的测试,但它可以帮助我们做出更好的初始选择。
有时,作为开发者,我们在一个项目上开始工作时,可能需要边走边设计,在没有完整的、预先建立的品牌调色板的情况下开始写代码。一旦开发工作开始,不断地将调色板来回导入外部工具中可能是很乏味的。在代码环境中检查颜色对比度有很多选择。Alex Clapperton开发了一个CLI工具,你输入两种颜色,它就在终端输出对比度和合格标准。英国广播公司(BBC)发布了一个JavaScript色彩对比度检查工具,该工具采用两种颜色,并确定其是否符合你所期望的标准。像这样的工具可以和你的测试一起存在于你的代码库中,或者在你的设计系统库中实现,比如Storybook、PatternLab等等。
A11y Color Tokens更进一步,让你在CSS或SASS中自动生成互补的颜色标记。你传入一种颜色和所需的比例,以生成符合要求的该颜色的阴影或色调。如果你需要快速检查某些东西的对比度,Chrome和Firefox现在也在各自的开发工具颜色选择器中显示颜色对比度信息。如果这些工具都不适合你,Stephanie Walter在她关于颜色可及性的博文中已经介绍了许多其他与颜色有关的工具选项。
兼容性
当涉及到调试时,为辅助技术构建往往会增加另一个层次的复杂性。因为辅助技术本质上是在浏览器之上的另一层界面,我们现在需要关注浏览器和辅助技术的组合。一个错误可能存在于浏览器或辅助技术中,也可能只存在于某个特定的组合中。在试图修复一个特定的问题时,把这个错误跟踪器的清单放在手边是个好主意。其中一些是公开的,这样你就可以看到其他人是否遇到了你所遇到的问题,但其他的只提供了一种私下报告错误的方法。
并非所有的浏览器和屏幕阅读器组合都能很好地一起工作,也不是所有的无障碍功能都能在不同的浏览器上得到同等的支持。这些工具可以帮助你检查你是否在某个特定的设备组合上遇到了错误。HTML5可及性是一个较新的HTML功能的列表,以及默认的浏览器实现是否被无障碍地支持。与此类似,无障碍支持提供了一个ARIA角色的列表,以及它们在最流行的浏览器和屏幕阅读器组合中的支持。
焦点管理
管理焦点是使复杂的应用程序具有可访问性的一个必要的但往往是困难的部分。我们需要考虑焦点顺序是否合理,焦点是否在任何自定义组件上正确移动,以及每个可交互元素是否有明确的焦点样式。
这个由Level Access制作的书签 给页面上的每一个可关注的元素都贴上了标签,这样你就可以检查关注顺序是否与阅读顺序相符。对于火狐的用户来说,火狐的可访问性检查器从84版开始就增加了这个功能。
在复杂的代码库中,不同的组件或第三方代码可能会意外地四处移动焦点,Scott Vinkle的这个小片段可以帮助你看到当前什么元素拥有焦点。console.trace
如果我正在为焦点被我的应用程序的其他部分移动而苦恼,有时我也喜欢用console.log
,以确定到底是什么功能在移动焦点。
为了测试一个网页上的所有焦点样式,我们可以使用Scott O’Hara的脚本作为起点。浏览每一个元素在一段时间后会变得很麻烦,所以用一个脚本来轮流浏览每一个元素可以帮助我们确保我们的焦点样式看起来是一致的,并且在页面的背景下工作。
设置一个正的tabindex来尝试修复焦点顺序是一个常见的可访问性问题。有一个正的tabindex的元素会迫使浏览器首先点击它们。虽然这在技术上可能不是一个错误,但这往往是出乎意料的,而且会造成更多的问题而不是解决。Paul J. Adam的tabindex书签允许你突出显示所有应用tabindex属性的元素。
布局的实用性
如果一个布局过于依赖CSS网格或Flexbox顺序属性,那么文档的阅读顺序有时会与浏览者可能期望的不同步。Adrian Roselli编写了一个书签,用于跟踪阅读顺序,以帮助你确保你的网站通过有意义的顺序准则。
WCAG包含一个文本间距标准,当应用某些文本设置时,所有的内容都应该仍然有效。为了测试这一点,Steve Faulkner创建了一个书签,可以自动将所需的文本间距设置应用于页面上的所有文本。避免像固定高度和允许溢出这样的事情,不仅使你的网站更容易访问,还能确保你放入网站的任何内容都不会破坏布局,这一点你的内容编辑人员会感谢你。
Jared Smith建立了一个书签,把你的光标变成一个44×44像素的盒子,这样你就可以把它悬停在你的控件上,确保它们符合推荐的目标尺寸标准。
铸币机
Linters是一类工具,它在应用程序运行或构建之前通过扫描源代码来捕捉错误。通过使用linters,我们可以在运行或构建代码之前修复较小的bug,节省以后宝贵的QA时间。
许多开发人员已经知道并在某种程度上使用ESLint。与其学习新的工具,不如在现有的工作流程中加入一个新的插件,这样就可以在无障碍测试中取得先机了。Eslint-plugin-jsx-a11y是一个ESLint插件,适用于你的JSX元素,在你写代码时,任何错误都会被显示。Scott Vinkle写了一份关于设置它的有用指南。
Deque推出了axe Linter,可作为Github应用程序或VS Code扩展。Axe Linter根据核心规则检查React、Vue、HTML和Markdown文件,不需要任何配置,所以很容易启动和运行,尽管欢迎你输入自己的选项。一个有用的功能是,它可以区分WCAG 2和WCAG 2.1,如果你试图满足一个特定的标准,这很有用。
标记
网络是建立在有弹性的基础上的。如果你有破损的标记,浏览器会尽力修补任何错误。然而,这可能会产生意想不到的副作用,无论是从造型的角度还是从可访问性的角度。通过W3C的HTML验证器运行你的输出,可以帮助捕捉到一些东西,比如破碎的标签、应用于不应该有的元素的属性,以及其他HTML错误。Deque基于相同的引擎创建了一个W3C HTML验证器书签,让你可以检查常规验证器无法到达的本地主机或受密码保护的页面上的标记。
如果你更喜欢视觉,Gaël Poupard的项目a11y.css是一个样式表,可以检查你的标记中可能存在的风险。它以扩展或书签的形式提供,你可以自定义语言以及显示的建议水平。类似地,sa11y是一个可以作为书签安装或集成到你的代码库的工具。Sa11y是专门为查看CMS内容的输出而设计的。它以非技术性语言显示任何警告,以便内容编辑者能够理解并作出必要的修正。
阅读水平
一个无障碍网站从无障碍内容开始。认知可及性一直是正在进行的WCAG 3草案的主要焦点,目前在成功标准3.1.5中提到,该标准建议作者争取使内容能够被初中(7-9年级)的阅读水平所理解。
海明威编辑器 会在你写内容的时候计算其阅读水平,这样你就可以通过编辑来确保内容易于理解。侧面的面板为你提供建议,说明如何改进你的内容,使其更具可读性。如果你的网站已经发布,Juicy Studio已经制作了一个可读性工具,你在提供的表格中输入一个URL,你的网站内容就会被分析并使用三种不同的阅读水平算法进行分级。还有一个有用的解释,说明这些分数中的每一个所包含的内容。然而,这个特定工具的一个限制是,它考虑到了页面上呈现的所有文本,包括导航和页脚文本等,这可能会歪曲结果。
测试套件和持续集成
大多数自动化测试工具的缺点是,它们要求人们在浏览器中运行它们。如果你正在处理一个大的代码库,你可以把可及性测试纳入你现有的测试过程,或者作为你持续集成流程的一部分。当你编写自定义测试时,你对你的应用程序有一种自动化测试工具所不具备的意识,使你能够以一种更可扩展的方式进行自定义的、全面的测试。
再一次,axe-core作为一个开源库出现,经常支撑着大多数这些工具,所以一个工具是否适合你,很可能是基于它与你的代码的整合程度,而不是测试结果的差异。Marcy Sutton发表了一份框架无关的指南,用于开始编写可访问性的自动测试。她涵盖了单元测试和集成测试之间的区别,以及为什么在不同的情况下,你可能要选择一个而不是另一个。
如果你已经有一个你喜欢的测试框架,很有可能已经有一个将axe-core纳入其中的库。例如,Josh McClure写了一份使用cypress-axe的指南,Nick Colley在jest-axe中制作了一个Jest风味的版本。
Pa11y是一个围绕测试提供可配置接口的工具,它也有CI版本。它的许多配置选项可以让你解决测试中可能出现的复杂问题。例如,动作功能可以让你在运行测试前传递一个动作数组,对于测试需要在访问页面前进行身份验证的屏幕非常有用。
用户偏好
有许多新的媒体查询可以帮助检测用户的操作系统和浏览器的偏好。这些天来,开发人员经常检测这些设置,以便为运动偏好和黑暗模式等设置默认值,但这也可能导致如果你没有相同的设置,就很难重现的错误。
Magica11y是一套让你确定用户偏好的功能。将文档页面发送给非技术性的测试人员,或者将这些纳入你的应用程序,这样你就可以更准确地重现用户的环境。
总结
据估计,自动可及性测试只能捕捉到30%的可及性错误。即使工具不断改进,它也无法取代将残疾人纳入你的设计和开发过程。一个可持续的、全面的无障碍过程可能涉及到让整个团队使用工具,在过程的早期尽可能多地捕捉这些错误,而不是让测试人员和残疾人用户在后期发现和报告这些问题。
需要更多的工具吗?A11y项目和Stark为开发者和用户策划了更多的无障碍工具清单!或者在这里留下任何建议。或者在下面的评论中留下任何建议,我们很想听听你在工作流程中加入了哪些工具。