策略型高端网站设计公司

网站设计的可访问性是检验网站是否成功的关键因素之一，之前我们也大家分享了有关与如何提高网站设计的可访问性的相关知识。今天我们要说说使用自动化检测来提升可访问性。

自动化易访问性测试采用的巨大增长是一个很好的第一步，但是如果我们不知道如何处理结果，最终它的影响是有限的。如何利用来自可访问性检查的自动化测试结果来推动变革并实现可持续的数字可访问性转换。与前面提到的关于如何将可访问性检查添加到测试自动化的博客文章不同，这里明显缺乏关注的内容如何利用这些可访问性检查的结果来推动变更并提高可访问性.

最大的可伸缩性和可访问性作为需求的汇合使大多数现代数字团队得出结论，可持续的可访问性改进的途径需要向可访问性方面转变。毫不奇怪，对左移优点的普遍认同导致了一波内容浪潮，集中于在DevOps过程中包括可访问性检查的重要性，如前端测试自动化，作为在产品生命周期早期解决可访问性的一种方法。

不幸的是，还没有类似的内容浪潮来解决如何有效地使用测试结果来解决问题，以及如何创建过程和策略来减少重复问题和回归的重要后续步骤。这种实现上的差距造成了今天存在的问题:现状的问题是，没有关于如何处理结果的指导，增加的测试与增加的可访问性(或可访问性错误的减少)没有关联。

为了恰当地解决这个问题，开发团队需要被授权来充分利用自动化易访问性测试的成果。只有这样，他们才能有效地利用结果，将开发生命周期中易访问性测试的增加转化为应用程序中存在的易访问性问题的相应减少。如何才能实现这一点？通过在CI/CD管道中结合战略定位和精心构建的质量关口，并利用免费提供的工具和技术来有效地修复发现的错误，您的开发团队可以有效地使用自动化可访问性结果。让我们深入研究这些想法吧！

在提交代码时，创建质量关是一种简单有效的方法，可以自动执行项目中的操作。大多数开发团队现在创建关卡来检查是否没有林挺错误，是否所有的测试用例都已经通过，或者项目是否没有错误。自动化的可访问性结果可以很容易地适应同样的模型！

在很大程度上，软件开发生命周期(SDLC)中质量关口的两个主要位置是在拉式请求(PRs)和构建作业(CI)期间。对于pull请求，最常用的工具之一是GitHub Actions，它允许开发团队在提交或部署代码时自动化一组应该完成或检查的任务。在CI作业中，工具的内置功能(Azure、Jenkins)用于创建脚本，检查测试用例或场景是否通过。那么，为你的团队准备一个有什么意义呢？这完全取决于开发团队希望为易访问性测试结果设置什么样的关卡。如果团队正在进行更多的林挺和组件级测试，那么可访问性门在拉请求级别上最有意义。如果自动化测试处于集成级别，这意味着一个完全成熟的站点已经准备好进行部署，那么就可以将gate与CI作业放在一起。

软检查在定义上相对简单。它查看可访问性测试是否被执行。就是这样！如果运行了可访问性检查，则测试通过。相比之下，断言对允许通过的内容更加具体和严格。例如，如果我的可访问性测试用例运行，并且它发现了一个问题，断言失败，gate将说它没有通过。那么哪个对你的团队最有效呢？如果你想让更多的团队整体上接受易访问性测试，最佳实践是不要马上抛出一个强硬的断言。团队最初会为增加的任务或需求而挣扎，可访问性也不例外。从软门开始，团队可以看到需求是什么，他们需要做什么。

一旦经过了一定的时间，那么软门可以切换到硬断言，不允许单个自动发布出去。然而，如果您的团队足够成熟，并且已经使用可访问性自动化有一段时间了，最初可能会使用硬断言，因为他们已经有了这方面的经验。