在本文即如何利用可访问性检查的自动化测试结果来推动变革并实现可持续的数字可访问性转型。 粗略的谷歌搜索将返回博客文章和文章的宝库，这些文章和文章支持将可访问性检查添加到测试自动化管道的价值。
这些文章中充斥着教程和代码片段，展示了获取一个人最喜欢的开放源代码可访问性测试库是多么简单，将它塞进一个赛普拉斯项目中，然后转瞬即逝，向左移动，并且已经实现了可访问性……对吧？ 不幸的是，不，因为行动导致一致、可重复的过程是左移的实际目标，而不仅仅是注入更多测试。
与前面提到的关于如何将可访问性检查添加到测试自动化 whatsapp 手机号码列表 的博文宝库不同，关注如何利用这些可访问性检查的结果来推动变革和提高可访问性的内容明显缺乏。 考虑到这一点，下面的文章旨在通过各种方式回答“下一步是什么？”的问题来填补这一空白。测试集成完成后。
现状 # 最大可扩展性和可访问性作为需求的融合使大多数现代数字团队得出结论
可持续可访问性改进的路径需要向左移动可访问性。毫不奇怪，关于左移优点的普遍共识导致了一波内容关注在 DevOps 流程中包含可访问性检查的重要性，例如前端测试自动化，作为在产品早期解决可访问性问题的一种手段生命周期。
不幸的是，还没有类似的内容浪潮来解决如何有效地使用测试结果来解决问题以及如何创建流程和策略以减少重复问题和回归的重要后续步骤。这种能力上的差距造成了今天存在的问题： 在自动化中执行的可访问性测试数量的急剧增加与数字世界可访问性的成比例增加无关
他们才能有效地使用结果将开发生命周期中可访问性测试的增加转化为应用程序中存在的可访问性问题按比例减少。 我们怎样才能做到这一点？通过在 CI/CD 管道中结合战略定位和结构化的质量关卡，并利用免费提供的工具和技术在发现错误时有效地修复错误，您的开发团队可以顺利地有效使用自动化的可访问性结果。让我们深入探讨
些想法！ 跳转后更多！继续往下看↓ Web 表单是每个有意义的交互的中心，因此值得牢牢掌握。了解一下 Adam Silver 的表单设计模式，这是一本设计和构建 Web 表单的实用指南。 跳转到目录↬ 功能面板 质量门 # 制作质量门是一种在提交代码时自动执行项目操作的简单有效的方法。大多数开发团
队现在创建门来检查是否没有 linting 错误，是否所有测试用例都已通过，或者项目是否没有错误。自动化的可访问性结果可以轻松地适合同一个模型！ 大门在哪里？ # 在大多数情况下，软件开发生命周期 (SDLC) 中质量关卡的两个主要位置是在拉取请求 (PR) 和构建作业（在 CI 中）期间。