自動化無障礙功能測試

到目前為止，您已瞭解數位無障礙工具的個人、業務和法律層面，以及數位無障礙規範的基本概念。您已探索與多元包容設計和程式設計相關的特定主題，包括何時使用 ARIA 與 HTML，以及如何在必要時使用 JavaScript 時測量色彩對比。

在其餘的單元中，我們將齒輪從設計和建構階段，到測試無障礙功能。我們會採用三個步驟測試程序，包括自動、手動和輔助技術測試工具和技術。我們會在這些測試模組中使用相同的示範，逐步從無法存取的網頁進度取得網頁。

每項測試 (包括自動化、手動和輔助技術) 都有助於實現最容易存取的產品。

我們的測試是以《無障礙網頁內容規範》(Web Content Accessibility Guidelines，簡稱 WCAG) 2.1 合規等級 A 與 AA 的標準做為標準。請注意，您的產業、產品類型、地方/國家/地區法律與政策，或整體無障礙目標，會決定應遵循哪些規範及等級。如果專案不需要特定標準，則建議遵循最新版本的 WCAG。如要瞭解無障礙稽核、法規遵循類型/等級、WCAG 和 POUR 的一般資訊，請參閱「數位無障礙程度的評估方式」一節。

如您所知，無障礙設計並「並非」為身心障礙者提供支援的完整故事，但這是個很好的起點，因為這個平台提供您可以進行測試的指標。除了無障礙功能符合性測試之外，我們也鼓勵您採取其他行動，例如對身心障礙者執行可用性測試、聘請身心障礙者來聘僱您的團隊，或是諮詢具備數位無障礙專業能力的個人或公司，協助您打造更多元包容的產品。

自動化測試基本概念

自動化無障礙功能測試會使用軟體掃描數位產品，查看是否有無障礙問題，是否符合預先定義的無障礙功能符合標準。

自動化無障礙功能測試的優點：

• 在產品生命週期的不同階段輕鬆重複測試
• 只差幾個步驟，就能快速獲得成效
• 執行測試或瞭解結果通常不太具備無障礙程度

自動化無障礙功能測試的缺點：

• 自動化工具無法找出產品中的所有無障礙功能錯誤
• 已回報誤判情形 (系統回報的問題並非真正的 WCAG 違規)
• 不同的產品類型和角色可能需要多種工具

自動化測試是檢查網站或應用程式是否具有無障礙功能的絕佳第一步，但並非所有檢查都能自動執行。我們會在手動無障礙功能測試模組中，詳細介紹如何檢查無法自動化的元素是否無障礙。

自動化工具類型

其中一項線上自動化無障礙功能測試工具是由 應用特別科技中心 (CAST) 於 1996 年開發而成，名為《The Bobby Report》(The Bobby Report)。目前我們有超過 100 種自動化測試工具可供選擇！

自動化工具實作方式，從無障礙瀏覽器擴充功能、程式碼檢查工具、電腦版和行動應用程式、線上資訊主頁，甚至是可用來建構專屬自動化工具的開放原始碼 API 都不同。

決定採用的自動化工具取決於多項因素，包括：

• 你們測試哪些一致性標準和等級？這可能包括 WCAG 2.1、WCAG 2.0、美國第 508 節，或經過修改的無障礙規則清單。
• 你正在測試哪種類型的數位產品？網站、網頁應用程式、原生行動應用程式、PDF、資訊站或其他產品都可以。
• 您測試的是軟體開發生命週期的哪個階段？
• 設定和使用這項工具需要多少時間？個人、團隊或公司？
• 由誰執行測試：設計人員、開發人員、品質確保等？
• 你希望多久檢查一次無障礙設計？報表中應包含哪些詳細資料？問題應該直接連結到支援單系統嗎？
• 哪些工具最適合您的環境？或給團隊

還有許多其他因素需要考量。想要進一步瞭解如何為您和您的團隊選擇最合適的工具，請參閱 WAI 的「選取 Web Accessibility Evaluation Tools」文章。

示範：自動化測試

針對自動化無障礙功能測試示範，我們會使用 Chrome 的 Lighthouse。Lighthouse 是一款開放原始碼的自動化工具，可透過各種稽核類型 (例如效能、SEO 和無障礙功能) 改善網頁品質。

我們的示範網站是專為知名組織「醫學神秘俱樂部」所打造，這個網站刻意設為無法存取示範帳戶。您可能會看到部分這種無障礙設計，並將部分 (但非全部) 擷取到我們的自動化測試中。

步驟 1

使用 Chrome 瀏覽器安裝 Lighthouse 擴充功能。

您可以透過多種方式將 Lighthouse 整合到測試工作流程中。我們會使用 Chrome 擴充功能進行示範。

步驟 2

我們建立了 CodePen 中的示範。請以偵錯模式檢視，以便繼續執行下一個測試。這個步驟非常重要，因為這麼做會移除示範網頁周圍的 <iframe>，這可能會影響部分測試工具。進一步瞭解 CodePen 的偵錯模式。

步驟 3

開啟 Chrome 開發人員工具並前往 Lighthouse 分頁。取消勾選「無障礙設定」以外的所有類別選項。請保留該模式的預設值，並選擇要執行測試的裝置類型。

步驟 4

按一下「分析網頁載入」按鈕，然後讓 Lighthouse 有時間執行測試。

測試完成後，Lighthouse 會顯示分數，用於評估目前測試產品的無障礙程度。Lighthouse 分數是依據偵測到的問題數量、問題類型及對使用者的影響所計算。

除了分數外，Lighthouse 報表不僅包含分數的詳細資訊，還包括偵測到哪些問題的詳細資訊，並提供相關資源的連結，協助您進一步瞭解如何修復這些問題。這份報表也包含已通過或不適用的測試，以及一份手動檢查的其他項目清單。

步驟 5

接下來，我們將逐一舉例說明各個自動化無障礙功能問題，並修正相關樣式和標記。

問題 1：ARIA 角色

第一個問題顯示：「具有 ARIA [角色] 的元素，要求子項包含特定 [角色] 的元素缺少部分或所有必要子項。部分 ARIA 父項角色必須包含特定的子項角色，才能執行預定的無障礙功能。」進一步瞭解 ARIA 角色規則。

在示範中，電子報訂閱按鈕失敗：

<button role="list" type="submit" tabindex="1">Subscribe</button>

一起解決這個問題。

輸入欄位旁的「訂閱」按鈕套用了錯誤的 ARIA 角色。在這種情況下，您可以完全移除角色。

<button type="submit" tabindex="1">Subscribe</button>

問題 2：已隱藏 ARIA

"[aria-hidden="true"] 元素包含可聚焦的子系。[aria-hidden="true"] 元素中的可聚焦子系會禁止螢幕閱讀器等輔助技術的使用者存取這些互動元素。進一步瞭解aria-hidden規則。

<input type="email" placeholder="Enter your e-mail address" aria-hidden="true" tabindex="-1" required>

一起解決這個問題。

輸入欄位已套用 aria-hidden="true" 屬性。加入這項屬性後，元素 (以及其下所有內容) 的輔助技術就會隱藏起來。

<input type="email" placeholder="Enter your e-mail address" tabindex="-1" required>

在這種情況下，您應該從輸入資料中移除這個屬性，讓使用輔助技術的使用者存取資訊並在表單欄位中輸入資訊。

問題 3：按鈕名稱

按鈕沒有無障礙名稱。如果沒有無障礙按鈕名稱，螢幕閱讀器只會讀出「按鈕」，這樣仰賴螢幕閱讀器的使用者就無法知道這個按鈕。 進一步瞭解按鈕名稱規則。

<button role="list" type="submit" tabindex="1">Subscribe</button>

一起解決這個問題。

當您從問題 1 中的按鈕元素移除不正確的 ARIA 角色時，「訂閱」一詞會變成可存取的按鈕名稱。這項功能內建在 HTML 按鈕元素中。您也可以考慮其他模式選項，以處理更複雜的情況。

<button type="submit" tabindex="1">Subscribe</button>

問題 4：圖片替代屬性

圖片元素缺少「[alt]」屬性。說明元素應提供簡短貼切的替代文字若是裝飾元素，則可以使用空白的 alt 屬性予以忽略。進一步瞭解圖片替代文字規則。

<a href="index.html">
  <img src="https://upload.wikimedia.org/wikipedia/commons/….png">
</a>

一起解決這個問題。

由於標誌圖片也是連結，因此您從圖片模組知道它稱為可操作的圖片，且需要圖片用途的替代文字資訊。網頁上的第一張圖片通常是標誌，因此您可以合理假設 AT 使用者知道這一點，您可能會決定不要在圖片說明中加入這項額外的背景資訊。

<a href="index.html">
  <img src="https://upload.wikimedia.org/wikipedia/commons/….png"
    alt="Go to the home page.">
</a>

問題 5：連結文字

連結缺少可辨識的名稱。可辨別、不重複且可聚焦的連結文字 (和圖片的替代文字) 有助於改善螢幕閱讀器使用者的瀏覽體驗。進一步瞭解連結文字規則。

<a href="#!"><svg><path>...</path></svg></a>

一起解決這個問題。

網頁上所有可操作的圖片都必須包含連結將將使用者帶往何處的資訊。其中一個解決方法是為圖片新增與用途相關的替代文字，就像您在上述範例中的標誌圖片一樣。這很適合使用 <img> 標記的圖片，但 <svg> 標記無法使用這個方法。

針對使用 <svg> 標記的社群媒體圖示，您可以使用指定 SVG 的不同的替代說明模式，在 <a> 和 <svg> 標記之間加入資訊，讓使用者清楚看見該資訊、新增支援的 ARIA 或其他選項。視您的環境和程式碼限製而定，其中一種方法可能會優先於其他方法。接下來，我們要使用最輔助技術涵蓋率最高的模式選項，也就是在 <svg> 標記中新增 role="img"，並加入 <title> 元素。

<a href="#!">
  <svg role="img">
    <title>Connect on our Twitter page.</title>
    <path>...</path>
  </svg>
</a>

問題 6：色彩對比

背景和前景顏色的對比度不足。低對比度的文字對許多讀者來說難以閱讀或無法閱讀。進一步瞭解色彩對比規則。

我們收到兩個樣本。

一起來解決這個問題。

系統在網頁上偵測到許多色彩對比問題。如色彩與對比模組所述，一般大小的文字 (小於 18pt / 24px) 的色彩對比需求為 4.5:1，而大尺寸的文字 (至少 18pt / 24px 或 14pt / 18.5px 粗體) 和基本圖示必須符合 3:1 的規定。

對於網頁標題，藍綠色的文字必須符合 3:1 色彩對比要求，因為其放大尺寸為 24px。不過，藍綠色按鈕視為一般大小的文字，大小為 16px，因此必須符合 4.5:1 顏色對比度要求。

在本例中，我們可以找到一個深色可以達到 4.5:1 的藍綠色，也可以將按鈕文字的大小提高為 18.5px 粗體，然後稍微變更藍綠色的值。這兩種方式都能符合設計美學。

除了網頁上的兩個最大的標題之外，白色背景的所有灰色文字也會失效。為符合 4.5:1 色彩對比要求，文字必須調暗。

問題 #7 - 清單結構

清單項目 (<li>) 未包含在 <ul> 或 <ol> 父項元素中。清單項目 (<li>) 必須納入父項 <ul> 或 <ol> 中，螢幕閱讀器才能正確朗讀這些項目。

進一步瞭解名單規則。

<div class="ul">
  <li><a href="#">About</a></li>
  <li><a href="#">Community</a></li>
  <li><a href="#">Donate</a></li>
  <li><a href="#">Q&A</a></li>
  <li><a href="#">Subscribe</a></li>
</div>

一起解決這個問題。

在這個示範中，我們使用了 CSS 類別來模擬未排序的清單，而非使用 <ul> 標記。如果我們以不當的方式編寫這個程式碼，我們移除了這個代碼中內建的語意 HTML 功能。只要將類別替換為實際的 <ul> 標記並修改相關的 CSS，就能解決這個問題。

<ul>
  <li><a href="#">About</a></li>
  <li><a href="#">Community</a></li>
  <li><a href="#">Donate</a></li>
  <li><a href="#">Q&A</a></li>
  <li><a href="#">Subscribe</a></li>
</ul>

問題 #8 - 分頁索引

部分元素的 [tabindex] 值大於 0。如果值大於 0，表示採用明確的瀏覽順序。雖然在技術上有效，但這通常會對仰賴輔助技術的使用者造成困擾。進一步瞭解分頁索引規則。

<button type="submit" tabindex="1">Subscribe</button>

一起解決這個問題。

除非有特定原因幹擾網頁上的自然分頁順序，否則 Tabindex 屬性不需要有正整數。為了維持自然的分頁順序，我們可以將 Tabindex 變更為 0，或者完全移除屬性。

<button type="submit">Subscribe</button>

步驟 6

修正所有自動無障礙功能問題後，請開啟新的偵錯模式頁面。再次執行 Lighthouse 無障礙功能稽核。您的分數應該比第一次執行時高出許多。

我們已將所有自動無障礙功能更新套用至新的 CodePen。

後續步驟

太棒了！您已取得許多成就，但尚未完成！接下來，我們將繼續進行手動檢查，詳情請參閱手動無障礙功能測試模組。

隨堂測驗

測驗您對於自動化無障礙功能測試的相關知識