改善無障礙設計,讓所有使用者都能更輕鬆地使用你的網站。
因此,打造適合所有人存取的網站至關重要。 以下至少提供了六個主要的身心障礙領域: 視覺化、聽覺、行動能力、認知、語音和神經元。 許多工具和資源都能派上用場 即使你是網頁無障礙功能的新手也能輕鬆上手
超過 10 億人 患有某種形式的身心障礙
如要使用,網站必須在多種裝置上運作 ,例如螢幕閱讀器等不同的螢幕大小和輸入方式 此外,網站應由廣大的使用者群體使用 包括身心障礙者
以下是使用者可能遭遇的一些身心障礙:
Vision | 聽力 | 機動性 |
---|---|---|
|
|
|
認知 | 語音 | Neural |
|
|
|
影像問題包括無法分辨色彩和所有視覺問題。
- 確保文字內容符合最低品質要求 對比度門檻。
- 避免傳達資訊 單色的 並確保所有文字都採用 調整大小。
- 確保所有使用者介面元件都能與輔助技術搭配使用 例如螢幕閱讀器、放大鏡和點字顯示器 這包括確保已為 UI 元件加上標記 讓無障礙 API 能透過程式輔助方式 任何元素的 role、state、value 和 title。
我個人身在低視能,經常發現自己想放大瀏覽網站 和終端機 雖然支援縮放功能幾乎絕不會放在開發人員的頂端待辦事項清單 這可以造福像我這樣的使用者
聽覺問題:使用者可能無法聽到網頁發出的聲音。
- 賦能 替代文字 。
- 測試 UI 元件是否仍正常運作
行動不便,包括無法操作滑鼠、鍵盤或 觸控螢幕
- 製作 UI 元件的內容 可透過鍵盤使用功能 一般使用滑鼠進行的操作
- 確認輔助技術的網頁已正確加上標記,包括 螢幕閱讀器、語音控制軟體和實體開關控制選項, 通常會使用相同的 API
出現認知問題時,使用者可能需要用到輔助技術 因此在朗讀文字時,請務必提供替代文字。
使用動畫時請務必小心。避免使用會使 重複 否則可能會造成問題 部分使用者
prefers-reduced-motion
你可以使用 CSS 媒體查詢限制動畫 並自動播放影片/* If the user expresses a preference for reduced motion, don't use animations on buttons. */ @media (prefers-reduced-motion: reduce) { button { animation: none; } }
避免使用屬於 以時間為基礎。
這看起來可能有很多個底 但我們會逐步說明評估流程 以及改善 UI 元件的無障礙功能
為了增添視覺輔助,GOV.UK 無障礙中心團隊建立了一系列的 無障礙功能的注意事項, 可以與團隊分享最佳做法
測量 UI 元件無障礙功能
稽核網頁的 UI 元件時,請思考下列問題:
您只能透過鍵盤使用 UI 元件嗎?
這個元件是否管理了焦點並避免焦點陷阱? 它能回應適當的鍵盤事件嗎?
您可以將 UI 元件與螢幕閱讀器搭配使用嗎?
你是否已為視覺呈現的任何資訊提供替代文字? 你是否已使用 ARIA 新增語意資訊?
UI 元件是否可以在靜音的情況下運作?
請關閉喇叭,逐步瞭解其他用途。
即使不使用顏色,UI 元件也能正常運作嗎?
確保看不到顏色的人都能使用你的 UI 元件。 如要模擬色盲,可使用 Chrome 擴充功能 色盲。 (可試用四種色盲模擬工具)。 您可能也想瞭解 Daltonize 這項功能也很實用
UI 元件是否能在啟用高對比模式時運作?
所有新型作業系統都支援高對比模式。 高對比 是可派上用場的 Chrome 擴充功能
標準化控制項 (例如 <button>
和 <select>
) 具備無障礙功能
。可使用 Tab
鍵可聚焦;
回應鍵盤事件 (例如 Enter
、Space
和方向鍵)。
擁有無障礙工具使用的語意角色、狀態和屬性
其預設樣式也必須符合列出的無障礙規定。
自訂 UI 元件 (擴充標準的元件除外)
元素 (例如 <button>
) 沒有任何內建功能,包括
因此您需要提供這些功能。何時適合開始
就是比較您的元件與類似標準
元素 (或數個標準元素的組合,視模型的複雜程度而定)
元件)。
大多數的瀏覽器開發人員工具都支援檢查網頁的無障礙功能樹狀結構。 在 Chrome 開發人員工具中,您可以透過「Elements」面板的「Accessibility」分頁開啟這項功能。
Firefox 也有「無障礙」面板。
Safari 會在「Elements」Elements面板的「Node」Elements分頁中顯示無障礙資訊。
當您嘗試讓 UI 元件更易於存取時,可以思考以下問題。
改善鍵盤焦點
在理想情況下,請確保使用者可以存取 UI 元件中的所有功能 使用鍵盤設計使用者體驗時 思考如何單單使用鍵盤建構元素 辨別一組一致的鍵盤互動方式
首先,確認每個元件都有合理的焦點目標。 舉例來說,選單等複雜的元件可能是 而應在其內部管理焦點,讓使用中的選單項目 通常都會聚焦
使用 Tabindex
您可以使用 tabindex
為元素和 UI 元件新增鍵盤焦點
屬性。使用者必須支援純鍵盤和輔助技術,
鍵盤焦點會聚焦在元素上,以便與其互動。
內建互動元素 (例如 <button>
) 可明確聚焦。因此,
不需要 tabindex
屬性 (除非需要變更其位置)
分別是
tabindex
值分為三種類型:
tabindex="0"
是最常見的元素,並將元素放在自然分頁中 順序 (由 DOM 順序定義)。- 如果
tabindex
值等於 -1,元素就會以程式輔助方式運作 可聚焦,但無法按照分頁順序排列。 - 如果
tabindex
值大於 0,則元素會依手動分頁順序排列。 系統會將tabindex
值為正的所有元素造訪於 排列順序 (在自然定位點順序前面)。
參考文章,瞭解 tabindex
的某些用途
使用 Tabindex。
無論是否使用預設對焦環,都必須確保焦點始終可見 或套用可辨識的自訂焦點樣式記得不要陷入陷入困境 鍵盤使用者—他們應能夠將焦點移至元素以外的地方 只要使用鍵盤即可
使用自動對焦功能
HTML 自動對焦屬性可讓作者指定
元素應自動聚焦
當我們載入網頁時
autofocus
已支援以下裝置:
所有網路表單控制項,
包括按鈕
如要在自訂 UI 元件中自動對元素,
呼叫 focus()
方法
都支援所有可聚焦的 HTML 元素
(例如 document.querySelector('myButton').focus()
)。
新增鍵盤互動操作
將可聚焦的 UI 元件後,提供良好的鍵盤互動故事
當聚焦元件時 (透過處理適當的鍵盤事件) 時。
例如,允許使用者使用方向鍵選取選單選項
和 Space
或 Enter
來啟動按鈕。
ARIA 設計模式指南
這裡提供一些指引
最後,請確認鍵盤快速鍵可供搜尋。 常見的做法是使用鍵盤快速鍵圖例 (畫面上的文字) 告知使用者捷徑存在。例如:「按下 ?鍵盤輸入 。」或者,您也可以使用工具提示等提示來通知使用者 快速指令
管理焦點的重要性不容忽視。其中一個重要例子是 導覽匣如果您在頁面中新增 UI 元件 您需要將焦點移到其中的某個元素 否則使用者可能必須切換整個網頁,才能到達該頁面。 這可能會令人困擾 因此請務必測試網頁上所有鍵盤可瀏覽元件的焦點。
// Example for expanding and collapsing a category with the Space key
const category = await page.$(`.category`);
// verify tabIndex, role and focus
expect(await page.evaluate(elem => elem.getAttribute(`role`), category)).toEqual(`button`);
expect(await page.evaluate(elem => elem.getAttribute(`tabindex`), category)).toEqual(`0`);
expect(await page.evaluate(elem => window.document.activeElement === elem, category)).toEqual(true);
// verify aria-expanded = false
expect(await page.evaluate(elem => elem.getAttribute(`aria-expanded`), category)).toEqual(`false`);
// toggle category by pressing Space
await page.keyboard.press('Space');
// verify aria-expanded = true
expect(await page.evaluate(elem => elem.getAttribute(`aria-expanded`), category)).toEqual(`true`);
確保螢幕閱讀器成功使用
使用螢幕閱讀器的使用者約有 1% 至 2% 的使用者。你能瞭解所有重要資訊嗎? 使用螢幕閱讀器和鍵盤,與元件互動 獨自一人嗎?
以下問題應有助於解決螢幕閱讀器的無障礙功能問題。
所有元件和圖片是否都有有意義的文字替代文字?
任何有關名稱或用途的資訊 以視覺化方式傳達互動元件 提供方便存取的文字替代選項
舉例來說,如果您的 <fancy-menu>
UI 元件只顯示齒輪圖示
表明這是設定選單
還需要無障礙文字,例如「設定」
可以傳達相同資訊
根據背景資訊
您可以運用 alt
屬性提供文字替代選項
aria-label
屬性、aria-labelledby
屬性
或 Shadow DOM 中的純文字
如需一般技術提示,請參閱 WebAIM 快速參考指南。
所有顯示圖片的 UI 元件,都應提供機制
替該圖片提供替代文字,類似於 alt
屬性。
您的元件是否提供語意資訊?
輔助技術可傳達語意資訊, 會吸引視覺元素的使用者,例如格式、遊標樣式或位置。 標準化元素在瀏覽器中內建這項語意資訊 但若要自訂元件 ARIA 用於新增資訊。
一般來說,任何會監聽滑鼠點擊或懸停事件的元件 必須具備某種鍵盤事件監聽器以及 ARIA 角色, 還有 ARIA 狀態和屬性
舉例來說,自訂 <fancy-slider>
UI 元件可採用滑桿的 ARIA 角色。
其具有一些相關的 ARIA 屬性:aria-valuenow
、aria-valuemin
及 aria-valuemax
。
將這些屬性繫結至自訂元件中的相關屬性後
您可以讓輔助技術的使用者與元素互動
變更該值,甚至導致元素的視覺呈現方式隨之變更。
<fancy-slider role="slider" aria-valuemin="1" aria-valuemax="5" aria-valuenow="2.5">
</fancy-slider>
使用者可以在不依賴顏色的情況下瞭解所有資訊嗎?
色彩不應用作資訊傳達的唯一方式,例如 指出狀態、提示使用者回覆,或以圖表呈現資料。 舉例來說,如果你使用的是圓餅圖,請為各區塊提供標籤和值 方便視障使用者理解資訊 即使他們無法查看片段的開始和結束時間:
影片是否有足夠的對比度?
元件中顯示的所有文字內容都應符合 最低 WCAG AA 層級對比門檻。 建議您提供與 更高的 AAA 門檻 並確保可套用使用者代理程式樣式表 自訂對比度或顏色 你可以使用顏色對比檢查工具 來輔助設計元件
移動或閃爍的內容是否能夠停止並安全?
使用者必須能夠暫停、停止或隱藏會移動、捲動或 閃爍超過 5 秒。一般來說,請避免使用閃爍的內容。
如果有東西必須閃爍,請確保每秒閃光不超過 3 次。
無障礙工具和測試
我們提供超過 100 項工具 評估網站的無障礙程度 與其元件有些工具會自動自動化,有些則需要手動測試。
以下提供幾個建議供您參考:
- Axe 提供自動化無障礙功能 來測試您的架構或瀏覽器 Axe Puppeteer 可用於編寫自動化無障礙功能測試
Lighthouse 無障礙設施 稽核功能可提供實用的深入分析,協助您找出常見的無障礙功能問題。 無障礙功能分數是所有無障礙稽核的加權平均值 Axe 使用者影響評估。 如要透過持續整合監控無障礙功能,請參閱 Lighthouse CI。
Tenon.io 很適合用來測試常見的無障礙功能問題。 Tenon 在所有建構工具和瀏覽器上都享有強大的整合支援 (透過 ,甚至是文字編輯器。
有很多程式庫和架構專屬工具可用來醒目顯示 元件遇到無障礙功能問題時,就會解決這類問題。例如,使用 eslint-plugin-jsx-a11y 醒目顯示編輯器中 React 元件的無障礙功能問題。
如果使用 Angular,請codelyzer。 也能在編輯器中進行無障礙功能稽核:
使用輔助技術
- 您可以使用以下項目,檢查輔助技術解讀網頁內容的方式:
無障礙功能檢查器 (Mac)
或 Windows Automation API 測試工具
和 AccProbe (Windows)。
也可以查看 Chrome 建立的完整無障礙功能樹狀結構
請前往
about://accessibility
。 - 如要在 Mac 上測試螢幕閱讀器支援,最好的方法就是使用 VoiceOver
公用程式使用
⌘F5
可啟用或停用這項功能,Ctrl+Option ←→
即可前往 網頁,以及Ctrl+Shift+Option + ↑↓
可用於上下移動無障礙功能 。如需更詳細的操作說明 請參閱 VoiceOver 命令的完整清單 和 VoiceOver 網路指令清單。 在 Windows 上,NVDA 是免費的開放原始碼畫面 讀取器。但這對視障使用者來說是難以學習的曲線。
ChromeOS 提供 內建螢幕閱讀器。
一直以來,我們都在努力改善網路無障礙功能。 根據網頁 Almanac 的說明:
- 每 5 個網站中,有 4 個文字與網頁背景融合 無法讀取
- 49.91% 的網頁還是無法為部分圖片提供
alt
屬性。 - 只有 24% 使用按鈕或連結的網頁會包含標籤。
- 只有 22.33% 的網頁會為表單輸入的所有網頁提供標籤。
我們有更多時間可以打造更便利的體驗 大家都愛不釋手