如何檢查網站是否有無障礙問題。
判斷網站或應用程式是否可供存取似乎是一項艱鉅的工作。如果您是第一次接觸無障礙設計,那麼主題較廣泛的部分會讓您不知該從何開始。畢竟,如果能因應各種不同的能力,就意味著要考量到各種不同的問題。
在本文中,我會將這些問題拆成有條理地,按循序漸進地逐一審查現有網站是否具備無障礙功能。
從鍵盤開始
對於無法或選擇不使用滑鼠的使用者,鍵盤導覽是顯示在畫面上所有內容的主要方式。這類目標對象包括動作失能的使用者,例如重複性壓力受傷 (RSI) 或癱瘓,以及螢幕閱讀器使用者。為提供優質的鍵盤體驗,請採用邏輯的分頁順序,以及易於辨識的焦點樣式。
重要須知
請先在您的網站中使用 Tab 鍵。元素聚焦的順序應遵循 DOM 順序。如果您不確定哪些元素應接收聚焦,請參閱「聚焦基礎知識」一文,複習相關知識。原則上,任何控制項使用者都能進行互動或提供輸入內容,使其成為可聚焦,並顯示聚焦指標 (例如聚焦環)。常見的做法是在 CSS 中使用
outline: none
停用焦點樣式,但未提供替代方案,但這是反模式。如果鍵盤使用者看不到焦點,就無法與網頁互動。如果您需要區分滑鼠和鍵盤焦點來設定樣式,建議您新增 what-input 程式庫。自訂互動控制項應著重於可聚焦。如果您使用 JavaScript 將
<div>
轉換為精美的下拉式選單,系統不會自動將這個下拉式選單插入分頁順序中。如要將自訂控制項設為可聚焦,請為其提供tabindex="0"
。避免使用
tabindex
> 0 的控制項。無論控制項在 DOM 中的位置為何,這些控制項都會在分頁順序中,優先顯示其他控制項。這可能會對螢幕閱讀器使用者造成困擾,因為他們傾向以線性方式瀏覽 DOM。非互動內容 (例如標題) 應避免成為焦點。開發人員有時會因為認為標題很重要,所以會在標題中加入
tabindex
。這也是一種反模式,因為這會降低鍵盤使用者查看螢幕的效率。對螢幕閱讀器使用者而言,螢幕閱讀器會朗讀這些標題,因此您不必將其設為可聚焦。如果網頁新增了內容,請確保焦點能夠導向該內容,以便使用者採取行動。如需範例,請參閱在頁面層級管理焦點一文。
注意任一處的焦點時,請務必小心謹慎。請留意是否有自動完成小工具,因為鍵盤焦點可能會卡住。在特定情況下,焦點可能會暫時受困,例如顯示強制回應視窗,並不想讓使用者與網頁的其餘部分互動時,但也建議您提供可透過鍵盤存取的方法來逸出互動內容。如需範例,請參閱「強制回應和鍵盤陷阱」指南。
可聚焦的項目並不代表可用
如果您建立了自訂控制項,則請設法讓使用者只用鍵盤就能存取所有功能。如要瞭解改善鍵盤存取方式的技巧,請參閱「管理元件中的焦點」。
別忘了畫面外的內容
許多網站都有顯示在 DOM 但未顯示的畫面外內容,例如回應式導覽匣選單中的連結,或互動視窗內尚未顯示的按鈕。在 DOM 中保留這些元素,可能會導致鍵盤使用體驗不佳,尤其是當螢幕閱讀器將這些畫面外內容視為該頁面的內容。請參閱「處理畫面外的內容」,瞭解處理這些元素的訣竅。
透過螢幕閱讀器試用
改善一般鍵盤支援功能可為下一步做了一些基本準備,也就是檢查頁面是否含有正確的標籤和語意,以及螢幕閱讀器導覽的任何障礙。如果您不熟悉輔助技術如何解讀語意標記,請參閱「語意簡介」中的相關內容。
重要須知
檢查所有圖片是否包含正確的
alt
文字。但這個做法的例外是圖片主要用於呈現,並非內容重點。如要標明螢幕閱讀器應略過圖片,請將alt
屬性的值設為空字串,例如:alt=""
.勾選特定標籤的所有控制項。如果是自訂控制項,可能需要使用
aria-label
或aria-labelledby
。如需範例,請參閱 ARIA 標籤與關係。檢查所有自訂控制項,確認是否有適當的
role
,以及會繫結其狀態的任何必要 ARIA 屬性。舉例來說,自訂核取方塊需要使用role="checkbox"
和aria-checked="true|false"
才能正確傳達狀態。如要大致瞭解 ARIA 如何為自訂控制項提供缺少的語意,請參閱 ARIA 簡介。資訊流通必須合理。由於螢幕閱讀器是以 DOM 順序瀏覽頁面,因此如果您使用 CSS 呈現元素位置,系統可能會以無意義的順序朗讀這些元素。如果您在網頁前段需要顯示某些內容,請試著在 DOM 稍早移動內容。
盡量讓螢幕閱讀器支援瀏覽頁面上所有內容的功能。請避免讓網站的任何部分永久隱藏,或是禁止螢幕閱讀器存取。
如果內容應在螢幕閱讀器中隱藏 (例如畫面外或只是呈現),請務必將內容設為
aria-hidden="true"
。詳情請參閱隱藏內容指南。
操作螢幕閱讀器,操作方式更勝以往
學習使用螢幕閱讀器,聽起來也許很困難,但其實很容易上手。一般來說,大部分開發人員只要輸入幾個簡單的鍵指令即可。
如果你使用的是 Mac,請觀看這部 VoiceOver 使用說明影片 (VoiceOver 是 Mac OS 內建的螢幕閱讀器)。如果您使用電腦,請觀看這部 NVDA 使用教學影片 (NVDA 是一款捐款贊助開發的開放原始碼螢幕閱讀器,適用於 Windows)。
aria-hidden
不會禁止鍵盤焦點
請務必瞭解,ARIA 只能影響元素的語意,對元素的「行為」沒有影響。雖然您可以使用 aria-hidden="true"
將元素隱藏在螢幕閱讀器中,但不會變更該元素的焦點行為。如果是螢幕外的互動內容,您通常需要結合 aria-hidden="true"
和 tabindex="-1"
,確保這些內容能確實從鍵盤流程中移除。我們提議的斷言屬性旨在結合兩個屬性的行為,簡化這項操作。
連結和按鈕等互動元素應載明其目的和狀態
以視覺方式說明控制項的用途,協助使用者操作及瀏覽您的網站。這些提示稱為預設提示。讓使用者能輕鬆在各種裝置上瀏覽您的網站。
重要須知
連結和按鈕等互動元素應與非互動式元素有所區別。如果使用者無法判斷某個元素是否可點擊,就很難瀏覽網站或應用程式。有很多有效方法可以達成這個目標常見的做法是加上底線,以便與周圍文字有所區分。
與聚焦規定類似,連結和按鈕等互動元素需要滑鼠懸停狀態,這樣滑鼠使用者才能知道使用者是否將遊標懸停在可點擊的項目上。不過,互動元素必須能單獨加以區別。單靠懸停狀態來表示可點擊的元素,並對於觸控螢幕裝置沒有幫助。
善用標題和地標
標題和地標元素可透過語意結構美化您的網頁,且能大幅提升輔助技術使用者的瀏覽效率。許多螢幕閱讀器使用者回報,當他們首次前往陌生網頁時,通常會嘗試依標題瀏覽。同樣地,螢幕閱讀器也可以跳到 <main>
和 <nav>
等重要位置。因此,請務必考量您網頁結構的運用方式,據此引導使用者體驗。
重要須知
妥善使用
h1-h6
階層。您可以將標題想成是為網頁撰寫大綱的工具。請勿依賴標題的內建樣式,而是將所有標題視為相同大小,並針對主要、次要和第三內容使用符合語意的適當層級。然後再運用 CSS 讓標題與設計相符使用地標元素和角色,讓使用者能略過重複的內容。許多輔助技術都提供捷徑,可讓您跳到頁面中的特定部分,例如
<main>
或<nav>
元素定義的項目。這些元素具有隱含地標角色。您也可以使用 ARIArole
屬性來明確定義頁面上的區域,例如影片長度為<div role="search">
。如需更多範例,請參閱標題和地標指南。除非您具備使用經驗,否則請避免使用
role="application"
。application
界標角色會指示輔助技術停用捷徑,並將所有按鍵按下動作傳至頁面。也就是說,使用者通常使用螢幕閱讀器來瀏覽頁面時,無法再使用鍵盤操作,因此您必須自行實作「所有」鍵盤處理功能。
透過螢幕閱讀器快速查看標題和地標
VoiceOver 和 NVDA 等螢幕閱讀器會提供內容選單,讓使用者跳至頁面上的重要區域。進行無障礙檢查時,您可以使用這些選單快速瀏覽頁面,判斷標題層級是否適當,以及使用中的地標。詳情請參閱這些操作說明影片,瞭解 VoiceOver 和 NVDA 的基本知識。
自動化相關程序
手動測試網站的無障礙功能可能相當繁瑣,且容易出錯。 最後,您會希望盡可能將這項程序自動化。您可以利用瀏覽器擴充功能和指令列無障礙功能測試套件來完成這項工作。
重要須知
網頁是否通過 aXe 或 WAVE 瀏覽器擴充功能的所有測試?這些擴充功能只有兩種可用選項,因此除了任何手動測試程序之外,還可以迅速解決一些微妙問題,例如失敗的對比度和缺少 ARIA 屬性。如果您偏好透過指令列執行操作,axe-cli 可提供與 aXe 瀏覽器擴充功能相同的功能,不過您可以從終端機輕鬆執行。
為避免發生迴歸問題,尤其是在持續整合環境中,請將 axe-core 等程式庫加入自動化測試套件。Axe-core 是支援 aXe Chrome 擴充功能的引擎,但它同樣採用易於執行的指令列公用程式。
如果您使用架構或程式庫,是否已提供專屬的無障礙工具?例如:Angular 適用的 protractor-accessibility-plugin 與 a11ysuite 適用於聚合者和網頁元件。盡可能善用可用的工具 這樣就不必花太多力氣了
如果你正在建構漸進式網頁應用程式,可以考慮給 Lighthouse 拍照
Lighthouse 是協助評估漸進式網頁應用程式效能的工具,但也會使用 axe-core 程式庫執行一組無障礙功能測試。如果您已經在使用 Lighthouse,請留意報表中是否有無障礙測試失敗的情形。修正這些問題有助於改善網站的整體使用者體驗。
設定程序即將完成
讓團隊定期審查無障礙功能,並盡早且經常檢查,有助於改善網站的整體使用體驗。別忘了,良好的無障礙功能就是良好的使用者體驗!