web - 网站可访问性测试的替代方案

Question

有关测试网站可访问性 (508+) 的免费工具的任何建议。我们曾经为此目的使用http://wsspg.dequecloud.com/worldspace/wsservice/eval/checkCompliance.jsp并且该站点不再可用。

Answer 1

试用适用于 Chrome 的Google Accessibility Developer Tools Extension。它在各个页面上运行可访问性审计，根据 WCAG 2.0 做出断言。

If you have a Rails project, you can run the assertions from the Google Extension as part of an Rspec integration test suite using capybara-accessible, a rubygem that defines a Selenium based webdriver for Capybara and makes accessibility assertions on page loads. That way you can automate testing across your site and also get failures in CI.

Answer 2

试试Wave，它可以免费使用。但不确定它是否具有完整的功能。自己检查一下，让我知道它是否适合您。

Answer 3

正如 Felipe 所说，不应依赖任何自动化测试。具体来说，如果您需要测试第 508 节，则说明您必须使用 AT 进行测试。WAVE 和 Deque WorldSpace 不满足此要求。WAVE是捕捉低垂果实的好工具。也许 Google 插件也可以，但由于 Chrome 处理和报告给 MSAA 和其他 API 的方式，它不会依赖它。

我听说过关于自动化测试人员有多好的数字。就个人而言，我将它们设置在 50% 左右，部分原因是 Felipe 在 Mohammad 的回答中提到了“全功能”方面。根据第 508 节，这句话被称为“等效促进”，它在 1194.31 中有所涵盖，这是任何自动化测试人员都无法涵盖的。子部分 1194.31 是功能标准，如果第 508 节适用，则适用于所有活动。1194.41 也是如此。

FelipeAls 说：

[第 508 节] 已过时，W3C/WAI WCAG 2.0 是当今改善可访问性的更好资源（当然，如果您必须符合 508，那么还要测试 508）

虽然我会说第 508 条的边缘很粗糙，但我不会说它像某些市场那样没有用。以我的经验，推动这一点的人，实际上处理第 508 节的经验有限，或者他们在进行测试的产品背后工作。他们最大的争论通常是“嘿，看，如果第 508 条这么好，为什么它不需要标题（<h1>）？” 嗯，第 508 节是从 WCAG 1.0 派生的，它也没有，所以我认为这个论点很弱。另外，还记得我说过人们没有意识到 1194.31 是适用的吗？让我们看一下 1194.31(a)：

(a) 应提供至少一种不需要用户视觉的操作和信息检索模式，或应提供对盲人或视力障碍者使用的辅助技术的支持。

您可以将其解读为：对页面进行编码，以便 AT 可以找到页面的特定部分。有什么好办法让人跳来跳去？标题，现在是 WAI-ARIA 地标。

第 508 节也正在制定以采用 WCAG 2.0。