自动化可访问性测试（Accessibility Testing，a11y）随着数字包容性倡议的发展而变得尤为重要。最初，检查是手动进行的，这常常导致漏掉关键缺陷或在晚些时候发现问题。现代方法采用特定工具的自动化，并将a11y检查集成到CI/CD中。
问题的历史： 最初的可访问性检查是完全手动的，这耗时且容易受到人为因素的影响。随着标准（WCAG，Section 508）的出现，出现了诸如axe、pa11y和Lighthouse等工具，这些工具大大自动化了这一过程。
问题： 主要的困难是自动化无法覆盖可访问性的所有方面（例如，为复杂图形内容提供适当的替代或确保文本对屏幕阅读器的适用性）。此外，支持特定小部件、异步接口以及在测试管道中正确设置a11y插件常常也会遇到困难。
解决方案：
将标准检查（对比度、aria-*、tabindex、结构、标签）的自动化与关键业务流程的手动验证结合起来，并引入可访问性专家。将a11y扫描器集成到拉取请求和关键发布期间是好的实践，以避免产生“可访问性的技术债务”。
关键特征：
复杂问题 1
"仅使用自动化扫描器是否足以确保全面的可访问性？"
**回答：**不，自动化工具仅覆盖大约30-50%的可访问性要求。其余部分只能通过手动测试和使用真实辅助技术的测试来发现。
复杂问题 2
"如果只添加role="button"或类似属性，元素会变得可访问吗？"
**回答：**并不总是。需要确保焦点的正确管理、键盘支持、事件处理以及为屏幕阅读器提供信息性文本。
复杂问题 3
"可访问性测试严重减慢CI：仅在每月运行一次有意义吗？"
**回答：**不，这些测试应在每次更改时运行，否则可能无法及时发现与可访问性相关的回归，修正会更困难（且成本更高）。
团队决定只运行一次Lighthouse，并已确认清单上的一个勾选。他们找到并修复了一些错误，但后来发现，在真实的银行应用中，盲人用户无法正确申请卡片：重要信息没有读出，按钮对屏幕阅读器“不可见”。
优点：
缺点：
从一开始，a11y检查工具就被集成到管道和项目规范中，定期与辅助技术进行手动检查，并与外部专家进行访谈。结果，盲人客户发现方便使用银行的web界面。
优点：
缺点：