到目前為止，您已瞭解個人、企業 數位無障礙的法律層面，以及數位無障礙的基本概念 確保一致性。您已探討有關多元包容設計和 包括何時該使用 ARIA 和 HTML、如何測量色彩對比 就連其他主題都非常需要 JavaScript
在後續模組中，我們將從設計和建構轉換到無障礙測試。我們會採用三個步驟的測試程序 自動化、手動和輔助技術測試工具及技術。我們會在這些測試模組中使用相同的示範，讓網頁從無法存取變成可存取。
每項測試 (自動化、手動與輔助技術) 都是達成以下目標的關鍵： 最容易取得的產品
我們的測試以無障礙網頁內容規範 (Web Content Accessibility Guidelines，簡稱 WCAG) 2.1 符合標準 A 級和 AA 級 做為標準。請注意，您所在產業、產品類型、當地和國家/地區法律和政策，或整體無障礙目標，都會決定您要遵循哪些指南，以及要達到哪個等級。如果您不要求專案符合特定標準，建議您遵循 WCAG 的最新版本。請參閱「如何評估數位無障礙程度？」 ，瞭解無障礙稽核項目、一致性類型/層級、 WCAG，以及 POUR。
如先前所知，無障礙規範並非全貌 旨在支持身心障礙者但這是個很好的起點 提供可做為測試用的指標我們建議您在無障礙相容性測試之外採取其他行動，例如與身心障礙人士進行可用性測試、聘用身心障礙人士加入團隊，或是諮詢具備數位無障礙專業知識的個人或公司，協助您打造更具包容性的產品。
自動化測試基礎知識
自動化無障礙功能測試會使用軟體掃描數位產品，檢查是否有無障礙功能符合預先定義的標準。
自動化無障礙功能測試的優點：
- 在產品生命週期的不同階段輕鬆重複測試。
- 只要幾個步驟就能執行，而且能快速取得結果。
- 如要執行測試或瞭解結果，不需要具備的無障礙程度。
自動化無障礙測試的缺點：
- 自動化工具無法找出產品中所有的無障礙功能錯誤
- 回報的項目並非實際的 WCAG 違規 (回報的問題並非實際的 WCAG 違規)
- 不同產品類型和角色可能需要多種工具
自動化測試是檢查網站或應用程式無障礙功能的絕佳第一步，但並非所有檢查項目都能自動化。我們會進一步說明如何檢查無法自動化測試的元素無障礙程度，請參閱手動無障礙測試單元。
自動化工具類型
1996 年，應用特殊技術中心 (CAST) 開發了第一個線上自動化無障礙測試工具，名為「Bobby Report」。目前有超過 100 種自動化測試工具可供選擇！
自動化工具導入作業會因無障礙瀏覽器擴充功能而異， 程式碼 Linter、桌面與行動應用程式、線上資訊主頁，甚至是 開放原始碼 API 來建立自己的自動化工具
您決定要使用哪種自動化工具，取決於多項因素，包括：
- 您會根據哪些相容性標準和等級進行測試？這可能會 包括 WCAG 2.1、WCAG 2.0、U.S.第 508 節，或經過修改的無障礙規則清單。
- 您要測試哪一種數位產品？這可以是網站、網頁應用程式、原生行動應用程式、PDF、資訊站或其他產品。
- 您在軟體開發生命週期的哪個階段測試產品？
- 設定及使用這項工具需要多久時間？是個人、團隊還是公司？
- 誰會進行測試：設計師、開發人員、品質確保人員，還是其他人？
- 您希望多久檢查一次無障礙功能？報表應包含哪些詳細資料？問題是否應直接連結至支援系統？
- 哪些工具最適合您的環境？適合你的團隊嗎？
還有許多其他因素需要考量。查看 WAI 的文章 「選取 Web Accessibility 評估工具」 。
示範：自動化測試
為了提供自動化無障礙功能測試示範，我們將使用 Chrome 的 Lighthouse。 Lighthouse 是開放原始碼的自動化工具，旨在改善 透過效能、搜尋引擎最佳化 (SEO) 和 更方便存取
我們的示範網站是為虛構的組織「Medical Mysteries Club」所建置。我們故意讓示範使用者無法存取這個網站。部分 只有您看得到，而部分 (但並非所有) 都會被偵測到 以及自動化測試
步驟 1
使用 Chrome 瀏覽器安裝 Lighthouse 擴充功能。
將 Lighthouse 整合至測試工作流程的方法有很多種。我們會使用 Chrome 擴充功能進行示範。
步驟 2
我們在 CodePen 中建立了示範，
請在偵錯模式中查看，以便繼續
接下來的測試這一點非常重要，因為這會移除 <iframe>，
示範網頁可能會幹擾部分測試工具。
進一步瞭解 CodePen 的偵錯模式。
步驟 3
開啟 Chrome 開發人員工具，然後 前往「Lighthouse」分頁。清除以下類別以外的所有類別選項 「無障礙設定」。請保留預設模式，並選擇要執行測試的裝置類型。
步驟 4
按一下「Analyze page load」，並給予 Lighthouse 時間執行測試的時間。
測試完成後，Lighthouse 會顯示評分，用來評估你測試的產品是否符合無障礙標準。Lighthouse 評分的計算方式是根據問題數量、問題類型，以及所偵測到的問題對使用者造成的影響來計算。
除了分數之外，Lighthouse 報告還會提供詳細資訊，說明所偵測到的問題，以及相關資源的連結，以便進一步瞭解如何修正這些問題。本報告也包含通過或不適用的測試，以及 列出要手動檢查的其他項目清單
步驟 5
以下將逐一舉例說明各種自動遇到的無障礙功能問題 並且修正相關樣式和標記
問題 1：ARIA 角色
第一個問題說明：「含有 ARIA [角色] 的元素，需要子項 包含特定 [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 角色，則「Subscribe」一詞就會成為可存取的按鈕名稱。這項功能內建於語意 HTML 按鈕元素中。針對更複雜的情況，您可以考慮其他模式選項。
<button type="submit" tabindex="1">Subscribe</button>
問題 4：圖片 alt 屬性
圖片元素缺少 [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：色彩對比
背景和前景顏色沒有足夠的對比度。低對比度的文字對許多讀者來說難以閱讀或無法閱讀。進一步瞭解色彩對比規則。
其中有兩個示例。
#01aa9d，背景十六進位值為 #ffffff。顏色對比率為 2.9:1。
#7c7c7c，背景的十六進位顏色則為 #ffffff。色彩對比率為 4.2:1。
讓我們來修正這個問題。
系統在網頁上偵測到許多色彩對比問題。正如您所學 色彩與對比模組 一般大小的文字 (小於 18pt / 24 像素) 對色彩對比的要求 4.5:1，大尺寸文字 (至少 18pt / 24px 或 14pt / 18.5px) 基本圖示必須符合 3:1 規定。
針對網頁標題，因為是 24 像素的大型文字，因此青綠色文字必須符合 3:1 的色彩對比度規定。不過，海軍藍按鈕的字型大小為 16 像素粗體，屬於一般大小，因此必須符合 4.5:1 的色彩對比度規定。
在這個例子中，我們可以找出一種夠暗的藍綠色，以符合 4.5:1 的情況；或者 我們可以將按鈕文字大小增加為 18.5px 粗體 藍綠色的數值這兩種方法都能符合設計 美感
所有白色背景的灰色文字也無法用於色彩對比，除了 。這段文字必須調暗，才能符合 以及 4.5:1 色彩對比要求
#008576，背景則維持 #ffffff。更新後的顏色對比度為 4.5:1。按一下圖片即可檢視原尺寸圖片。
#767676，背景仍然是 #ffffff。顏色對比度為 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 屬性中使用正整數。目的地：
保持自然的 Tab 鍵順序，我們可以將 Tabindex 變更為 0 或
徹底移除這項屬性
<button type="submit">Subscribe</button>
步驟 6
如果您已修正所有自動化無障礙功能問題，請改開啟新的 偵錯模式頁面。再次執行 Lighthouse 無障礙稽核。您的分數應該會比第一次執行時好上許多。
我們已將所有自動化無障礙功能更新套用至新的 CodePen。
下一步
太棒了！您達成了許多目標，但我們還沒結束！ 接下來，我們將討論手動檢查，詳情請參閱「手動無障礙性測試」單元。
隨堂測驗
測試您對自動化無障礙功能測試的瞭解程度
您應該進行哪種測試，才能確保網站易於存取？
自動化測試中發現哪些錯誤？