網站訪問權限測試的替代方案

任何關於免費測試網站可訪問性工具的建議（508+）。我們曾經爲此使用http://wsspg.dequecloud.com/worldspace/wsservice/eval/checkCompliance.jsp，並且此站點不再可用。網站訪問權限測試的替代方案

來源

2013-07-09 user2566175

您是否引用了第508條，因爲這是您的合法要求？它已經過時了，並且W3C/WAI WCAG 2。0是一種更好的資源來改善時下的可訪問性（當然，如果你必須符合508，那麼也要測試508） – FelipeAls

嘗試Wave，這是免費使用。但不知道它是否具有完整的功能。自己檢查一下，讓我知道它是否適合你。

來源

2013-07-09 21:33:00

沒有一個自動化工具具有「全部功能」，因爲它不能：它也需要一個人用於測試諸如標題和鏈接等一大堆東西的相關性;）否則當你測試幾頁並且想要顯示*錯誤時，Wave是一個很棒的工具 – FelipeAls

正如Felipe所說，不應該依賴自動化測試。特別是如果您需要測試第508節，則表明您必須使用AT進行測試。 WAVE和Deque WorldSpace不滿足此要求。 WAVE是抓低掛果的好工具。也許Google Plug-in也是如此，但由於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）至少須設置操作，並且不需要用戶的視覺信息檢索模式，或支持的人誰是盲人或視障使用輔助技術應提供。

您可以閱讀爲：代碼的頁面，這樣可以查找/在頁面上的特定部分。什麼是讓人們跳來跳去的好方法？標題，現在WAI-ARIA地標。

508部分也正在採用WCAG 2.0。

來源

2013-07-10 13:45:34

嘗試使用Chrome Google Accessibility Developer Tools Extension。它在單個頁面上運行可訪問性審計，根據WCAG 2.0進行斷言。

如果您有Rails項目，您可以使用capybara-accessible作爲Rspec集成測試套件的一部分運行Google Extension的斷言，該套件定義了一個基於Selenium的Web瀏覽器的Capybara並在頁面加載時創建輔助功能斷言。這樣你可以在你的網站上自動進行測試，也可以在CI中失敗。

來源

2013-07-10 13:46:19 ckundo

我不會推薦這個擴展。儘管Google擁有少數優秀人才，但Google的無障礙記錄以及他們如何實施它卻相當糟糕。 –

@RyanB你使用過擴展名嗎？你有什麼具體的反對意見嗎？ – ckundo

谷歌的觀點通常是，如果它不起作用，我們會繼續將這個方形釘塞入圓孔。例如：他們設計的技術不是讓他們的產品變得易於使用，而是設計出適合該產品的技術哦，你想使用我們的產品？使用Chrome + ChromeVox。你不能安裝chromevox，或者改變瀏覽器來使用一個站點是一種痛苦？吮吸你。所以谷歌的輔助功能擴展不會通過我的嗅探測試 –

網站訪問權限測試的替代方案

回答

相關問題