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

Question

有关测试网站可访问性的免费工具的任何建议（508+）。为此，我们过去常常使用http://wsspg.dequecloud.com/worldspace/wsservice/eval/checkCompliance.jsp，此网站已不再可用。

Answer 1

尝试使用Google Accessibility Developer Tools Extension Chrome浏览器。它在各个页面上运行可访问性审计，根据WCAG 2.0进行断言。

如果您有一个Rails项目，您可以使用capybara-accessible作为Rspec集成测试套件的一部分从Google Extension运行断言，这是一个为Capybara定义基于Selenium的webdriver并在页面上创建可访问性断言的rubygem负载。这样，您就可以在整个站点中自动化测试，并在CI中获得失败。

Answer 2

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

Answer 3

正如费利佩所说，不应依赖自动化测试。具体来说，如果您需要测试Section 508，它会声明您必须使用AT进行测试。 WAVE和Deque WorldSpace不满足此要求。 WAVE是抓住低垂果实的好工具。也许谷歌插件也可以，但由于Chrome处理并向MSAA和其他API报告内容，因此不会依赖它。

我听说有关自动化测试仪的数据。就个人而言，我将它们设定在50％左右，特别是由于菲利普在穆罕默德的回答中提到的“全功能”方面。就第508节而言，这个短语被称为“等效促进”，在1194.31中有所涉及，没有自动化测试人员可以覆盖。子部分1194.31是功能标准，如果适用第508节，则适用于所有活动。 1194.41也是如此。

费利佩尔斯说：

  

[第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。