改善無障礙設計能讓所有人輕鬆操作你的網站。
請務必打造具有包容性且讓所有人存取的網站。 關於身心障礙狀態，您至少應針對六個主要面向進行最佳化設定：視覺化、聽覺、行動性、認知、語音和類神經。即使您是第一次接觸網頁無障礙工具 也有許多工具和資源可以提供協助
超過 10 億人患有某種形式的身心障礙。
為方便瀏覽，網站必須能在不同螢幕大小和輸入類型 (例如螢幕閱讀器) 的多部裝置上運作。此外，網站應可供最廣泛的使用者使用，包括身心障礙者。
以下列舉使用者可能會有的身心障礙：
| 視覺 | 聽力 | 無障礙服務設施 |
|---|---|---|
|
|
|
| 認知 | 語音 | 神經元 |
|
|
|
視覺問題的範圍包括「無法辨認顏色」或「完全沒有視覺問題」。
- 確保文字內容符合最低對比度門檻。
- 請避免只使用顏色傳達資訊，並確保所有文字都resizable。
- 確保所有使用者介面元件都能與螢幕閱讀器、放大鏡和點字顯示器等輔助技術搭配使用。亦即確保 UI 元件已加上標記，讓無障礙 API 能夠透過程式輔助方式判斷任何元素的「角色」、「狀態」、「值」和「名稱」。
我個人是低視能，常常發現我自己會放大瀏覽網站、開發人員工具和終端機。雖然支援縮放功能幾乎絕對不會出現在開發人員待辦事項清單的頂端，但對使用者來說，支援縮放功能可以為我和其他使用者帶來改變。
聽覺問題代表使用者可能無法順利聽從網頁發出的聲音。
行動不便包括無法使用滑鼠、鍵盤或觸控螢幕操作。
- 讓 UI 元件的內容可由鍵盤正常運作，以用於任何其他會使用滑鼠的動作。
- 確保已為輔助技術 (包括螢幕閱讀器、語音控制軟體和實體開關控制項) 正確標記網頁，這些技術通常使用相同的 API。
「認知問題」是指使用者可能需要輔助技術來協助他們閱讀文字，因此務必確保有替代的文字。
使用動畫時請務必謹慎。避免使用會重複或閃爍的影片和動畫，這樣可能會對部分使用者造成問題。
prefers-reduced-motionCSS 媒體查詢可讓您針對偏好較慢動作的使用者，限制動畫和自動播放影片：/* 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 元件。模擬色盲的實用工具是名為 Colorblindly 的 Chrome 擴充功能。(目前有四種類型的色盲模擬可用)。 建議您一併瞭解 Daltonize 擴充功能，這項做法十分實用。
您的 UI 元件能否在啟用高對比模式的情況下運作？
所有現代化作業系統都支援高對比模式。高對比這項 Chrome 擴充功能可以派上用場。
標準化控制項 (例如 <button> 和 <select>) 內建於瀏覽器中的無障礙功能。您可以使用 Tab 鍵聚焦這些類別；回應鍵盤事件 (例如 Enter、Space 和方向鍵)，以及無障礙工具使用的語意角色、狀態和屬性。他們的預設樣式也應符合列出的無障礙需求。
自訂 UI 元件 (擴充標準元素 (例如 <button>) 的元件除外) 不具備任何內建功能 (包括無障礙功能)，因此您必須自行提供。實作無障礙功能時，建議您先將元件與類似的標準元素進行比較，或結合多個標準元素的組合，視元件的複雜程度而定。
大部分瀏覽器開發人員工具都支援檢查網頁的無障礙功能樹狀結構。在 Chrome 開發人員工具中，您可以前往「元素」面板的「Accessibility」分頁找到這項設定。
Firefox 也提供「無障礙設定」面板。
Safari 會在「Elements」面板的「Node」分頁中顯示無障礙功能資訊。
當您嘗試提高 UI 元件的無障礙程度時，不妨思考以下問題。
改善鍵盤焦點
在理想情況下，請確保 UI 元件中的所有功能都能使用鍵盤存取。設計使用者體驗時，請思考如何單獨將元素與鍵盤搭配使用，並打造出一致的鍵盤互動組合。
首先，請確認每個元件都設有合理的焦點目標。舉例來說，選單等複雜的元件可能是頁面中的一個焦點目標，但應該管理焦點本身，讓使用中的選單項目一律聚焦。
使用 Tabindex
您可以使用 tabindex 屬性，為元素和 UI 元件新增鍵盤焦點。純鍵盤和輔助技術使用者必須能夠將鍵盤焦點放在鍵盤上，才能與元素互動。
內建互動元素 (例如 <button>) 可隱式聚焦，因此這類元素不需要 tabindex 屬性，除非您需要變更分頁順序在分頁中的位置。
tabindex 值可分為三種類型：
tabindex="0"是最常見的，會將元素以自然分頁順序排列 (由 DOM 順序定義)。- 如果
tabindex值大於 0，元素會依手動定位點順序排列。系統會依數字順序造訪網頁中所有具有tabindex正值的元素，且這些元素會按照自然分頁順序排列， - 如果
tabindex值等於 -1，則元素可以透過程式輔助方式聚焦，但不會顯示在分頁順序中。
如果是自訂 UI 元件，請一律使用 0 或 -1 的 tabindex 值，因為您無法事先決定特定網頁上的元素順序。tabindex 值為 -1 特別適合用於管理複雜元件中的焦點。
使用預設的焦點環樣式，或套用可辨別的自訂焦點樣式，確保焦點一律會顯示。提醒您，請不要攔截鍵盤使用者，他們應該只需使用鍵盤，就能將焦點從元素移開。
使用自動對焦功能
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 門檻的高對比主題，並確保使用者需要自訂對比度或顏色時，可以套用使用者代理程式樣式表。設計元件時，您可以使用這個色彩對比檢查工具做為輔助。
移動或刷新內容是否可停止且安全？
使用者應該要能暫停、停止或隱藏移動、捲動或閃爍的內容超過五秒。一般而言，請避免閃爍內容。
如果某些元素必須閃爍，請確保其每秒閃動不超過 3 次。
無障礙工具和測試
以下提供幾點建議：
- Axe 會針對您使用的架構或瀏覽器提供自動化的無障礙功能測試。Axe Puppeteer 可用來編寫自動化無障礙功能測試。
Lighthouse 無障礙功能稽核可提供實用的深入分析資料，協助您找出常見的無障礙功能問題。無障礙功能分數是依據 Axe 使用者影響評估得出的所有無障礙功能稽核加權平均值。如要瞭解如何透過持續整合監控存取行為，請參閱「Lighthouse CI」一文。
Tenon.io 適合用於測試常見的無障礙功能問題。Tenon 提供多項建構工具、瀏覽器 (透過擴充功能)，甚至是文字編輯器的整合功能。
有許多程式庫和架構專用的工具可醒目顯示元件的無障礙功能問題。舉例來說，使用 eslint-plugin-jsx-a11y，即可醒目顯示編輯器中 React 元件的無障礙功能問題。
如果您使用 Angular，codelyzer 也提供編輯器內的無障礙功能稽核功能：
使用輔助技術
- 您可以使用無障礙功能檢查器 (Mac) 或 Windows Automation API 測試工具和 AccProbe (Windows)，檢查輔助技術看到網頁內容的方式。
前往
about://accessibility也可以查看 Chrome 建立的完整無障礙功能樹狀結構。 - 如要在 Mac 上測試螢幕閱讀器支援功能，最好的方法就是使用 VoiceOver 公用程式。使用
⌘F5可啟用或停用，Ctrl+Option ←→則可在頁面間移動，使用Ctrl+Shift+Option + ↑↓則可上下移動無障礙樹狀結構。如需詳細操作說明，請參閱 VoiceOver 指令的完整清單和 VoiceOver 網路指令清單。 在 Windows 中，NVDA 是免費的開放原始碼螢幕閱讀器。但視力不佳的使用者來說，學習歷程並不多。
ChromeOS 提供內建螢幕閱讀器。
一直以來，我們持續致力改善網路無障礙設計。 根據Web Almanac：
- 每 5 個網站中，就有 4 個文字與背景融為一體，難以閱讀。
- 49.91% 的網頁仍無法提供部分圖片的
alt屬性。 - 使用按鈕或連結的網頁中，只有 24% 含有標籤。
- 只有 22.33% 的網頁為所有表單輸入提供標籤。
我們還有很多方法可以打造更無障礙的體驗。