自動化無障礙功能測試

在本課程中，您已瞭解數位無障礙的個人、業務和法律層面，以及數位無障礙一致性的基本概念。您已探索與無障礙設計和編碼相關的特定主題，包括何時使用 ARIA 與 HTML、如何測量色彩對比度，以及何時需要使用 JavaScript 等主題。

在接下來的單元中，我們將從設計和建構轉向測試無障礙功能。我們將分享三步驟測試程序，包括自動、手動和輔助技術測試工具與技術。在這些測試模組中，我們將使用相同的示範網頁，逐步將網頁從無法存取改為可存取。

自動、手動和輔助技術測試對於打造最容易使用的產品至關重要。我們的測試依據是無障礙網頁內容規範 (WCAG) 2.1 A 級和 AA 級的符合標準。

請注意，您所屬的產業、產品類型、當地和國家/地區的法律與政策，或整體無障礙目標，都會決定要遵循哪些指南和符合哪些等級。如果專案不需要特定標準，建議遵循最新版 WCAG。如要瞭解無障礙稽核、一致性類型/等級、WCAG 和 POUR 的一般資訊，請參閱「如何評估數位無障礙程度？」一文。

如您所知，無障礙一致性並非支援身心障礙者的全貌。但這項指標可做為測試基準，因此是個不錯的起點。除了進行一致性測試外，我們也建議您採取下列行動，協助打造更具包容性的產品：

• 與身心障礙者一起執行可用性測試。
• 聘用身心障礙者加入團隊。
• 諮詢具備數位無障礙專業知識的個人或公司。

自動化測試基礎知識

自動無障礙測試會使用軟體，根據預先定義的無障礙一致性標準，掃描數位產品的無障礙問題。

自動無障礙測試的優點：

• 在產品生命週期的不同階段快速重複測試。
• 只要幾個步驟就能執行，而且很快就能取得結果。
• 執行測試或解讀結果時，不需要具備無障礙功能相關知識。

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

• 自動化工具無法偵測產品中的所有無障礙錯誤
• 回報誤判情況 (回報的問題並非真正的 WCAG 違規事項)
• 不同產品類型和角色可能需要多種工具

自動化測試是檢查網站或應用程式無障礙程度的第一步，但並非所有檢查都能自動完成。在手動無障礙測試單元中，我們會詳細說明如何檢查無法自動化的元素無障礙程度。

自動化工具類型

1996 年，應用特殊技術中心 (CAST) 開發了最早的線上自動無障礙測試工具之一，名為「The Bobby Report」。如今，市面上已有超過 100 種自動化測試工具可供選擇！

自動化工具的實作方式不一，從無障礙瀏覽器擴充功能到程式碼檢查工具、桌機和行動應用程式、線上資訊主頁，甚至是可用於建構自家自動化工具的開放原始碼 API，應有盡有。

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

• 您要測試是否符合哪些一致性標準和等級？這可能包括 WCAG 2.2、WCAG 2.1、美國第 508 條規定，或修改後的無障礙規則清單。
• 您要測試哪種數位產品？例如網站、網頁應用程式、原生行動應用程式、PDF、資訊站或其他產品。
• 您是在軟體開發生命週期的哪個階段測試產品？
• 設定及使用這項工具需要多少時間？是個人、團隊還是公司？
• 誰要進行測試：設計師、開發人員、品質保證人員或其他人員？
• 您希望多久檢查一次無障礙功能？報告應包含哪些詳細資料？問題是否應直接連結至票證系統？
• 哪些工具最適合您的環境？還是團隊？

此外，還有許多其他因素需要考量。如要進一步瞭解如何為自己和團隊選取最合適的工具，請參閱 WAI 的「選取網頁無障礙評估工具」一文。

示範：自動測試

在自動化無障礙測試的示範中，我們會使用 Chrome 的 Lighthouse。Lighthouse 是一項開放原始碼的自動化工具，可透過不同類型的稽核 (例如效能、搜尋引擎最佳化和無障礙功能)，提升網頁品質。

我們的示範網站是為虛構的組織「Medical Mysteries Club」所建。這個網站刻意設為無法存取，僅供示範。您可能會發現部分無障礙問題，而自動測試會找出部分 (但不是全部) 問題。

步驟 1

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

整合 Lighthouse 的方法有很多種，在本示範中，我們使用 Chrome 擴充功能。

步驟 2

我們在 CodePen 中建立示範。 請在偵錯模式下查看，以便繼續進行下一個測試。這項步驟非常重要，因為它會移除包圍示範網頁的 <iframe>，避免干擾部分測試工具。

進一步瞭解 CodePen 的偵錯模式。

步驟 3

開啟 Chrome 開發人員工具，然後前往 Lighthouse 分頁。清除所有類別選項，但「無障礙」除外。將模式設為預設值，然後選擇要執行測試的裝置類型。

步驟 4

按一下「分析網頁載入作業」，讓 Lighthouse 執行測試。

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

除了分數之外，Lighthouse 報告還會詳細說明偵測到的問題，並提供資源連結，方便您進一步瞭解如何修正問題。這份報告也包含通過或不適用的測試，以及需要手動檢查的其他項目清單。

步驟 5

現在，請逐一查看系統發現的每個自動無障礙問題，並修正相關樣式和標記。

問題 1：ARIA 角色

第一個問題指出：「有些元素具備 ARIA [role] 且要求子項包含特定 [role]，這些元素缺少部分或全部的必要子項。部分 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 的規定。

由於頁面標題是 24 像素的大型文字，因此藍綠色文字必須符合 3:1 的顏色對比度規定。不過，青色按鈕的文字大小為 16 像素粗體，屬於一般大小的文字，因此必須符合 4.5:1 的顏色對比度規定。

在這種情況下，我們可以找到深到足以達到 4.5:1 的藍綠色，或是將按鈕文字大小增加到 18.5 像素的粗體，並稍微變更藍綠色值。無論選擇哪種方法，都能維持設計美感。

白色背景上的所有灰色文字也無法通過色彩對比度測試，但網頁上最大的兩個標題除外。這段文字必須調暗，才能符合 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

部分元素的 tabindex 值大於 0。如果值大於 0，表示採用的是明確的瀏覽排序。雖然這在技術上可行，但經常會對仰賴輔助技術的使用者造成困擾。進一步瞭解 tabindex 規則。

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

該如何解決這個問題呢？

除非有特殊原因要中斷網頁上的自然分頁順序，否則不需要在 tabindex 屬性中加入正整數。如要保留自然分頁順序，我們可以將 tabindex 變更為 0，或完全移除屬性。

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

步驟 6

現在您已修正所有自動化無障礙問題，請開啟新的偵錯模式頁面。再次執行 Lighthouse 無障礙稽核。您的分數應該會比第一次執行時好很多。

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

下一步

太棒了！你已經完成許多步驟，但我們還沒結束！ 接下來，我們將進行手動檢查，詳情請參閱「手動無障礙測試」單元。