Figma 無障礙設計教學:用 WCAG 標準打造人人都能用的產品
為什麼無障礙設計是每位設計師的必修課
說到無障礙設計(Accessibility,簡稱 a11y),很多設計師的第一反應是「那是工程師的事」或「等產品上線再說」。但說實話,這種想法已經過時了。根據世界衛生組織的數據,全球有超過 10 億人有某種形式的障礙,這代表你的使用者中,很可能每十個人就有一到兩個在使用輔助工具瀏覽你的產品。
無障礙設計不只是符合法規(像是歐盟的 EAA 或美國的 ADA),更是好設計的基本功。一個色彩對比做得好的介面,在大太陽下也看得清楚;一個鍵盤可以操作的表單,對進階使用者來說效率更高。所以,無障礙設計其實就是「讓更多人都能順暢使用」的設計,而 Figma 正是實踐這件事的最佳起點。
WCAG 2.2 標準快速入門:設計師需要知道的重點
WCAG(Web Content Accessibility Guidelines)是無障礙設計的國際標準,目前最新版本是 2.2。它分成三個等級:A(基本)、AA(建議)、AAA(最高)。大多數法規和企業要求的是 AA 等級,所以我們主要聚焦在這裡。
對設計師來說,最常碰到的 WCAG 準則包括:
- 1.4.3 色彩對比(AA):一般文字對比度至少 4.5:1,大文字至少 3:1
- 1.4.6 色彩對比(AAA):一般文字 7:1,大文字 4.5:1
- 1.4.11 非文字對比:UI 元件和圖形的對比度至少 3:1
- 2.5.8 目標尺寸:可點擊元素至少 24x24px(WCAG 2.2 新增)
- 1.3.1 資訊與關係:結構化的標題層級、表單標籤
- 2.4.3 焦點順序:Tab 鍵的移動順序要符合邏輯
記住這些數字不是為了考試,而是在設計時有個明確的標準可以對照。接下來我會一步步教你怎麼在 Figma 裡檢查和實踐這些準則。
Figma 色彩對比檢查實戰流程
色彩對比是無障礙設計中最直觀的一環,也是最容易在 Figma 裡驗證的。以下是我日常的檢查流程:
步驟一:使用 Figma 內建對比度檢查
選取一個文字圖層,在右側面板的「Fill」區域點擊色彩,你會看到一個對比度的數值。Figma 會自動計算該文字與背景之間的對比比率,並告訴你是否符合 AA 或 AAA 標準。
步驟二:搭配 Stark 外掛做全面檢查
Figma 內建的檢查雖然方便,但如果你要一次掃描整個頁面,建議安裝 Stark 外掛。它可以自動偵測畫面中所有文字和背景的對比度問題,並生成報告。我個人覺得 Stark 的 Vision Simulator 功能特別實用,它能模擬色覺障礙(如紅綠色盲)下的視覺效果,幫助你確認設計在不同狀況下都能正常閱讀。
步驟三:建立符合標準的色彩系統
與其每次都手動檢查,不如從源頭解決問題。在建立 設計系統建立教學 時,就把每組前景/背景的色彩組合都驗證過一次,並記錄在 Design Token 裡。搭配 Figma Variables 教學 中的變數功能,你可以為 Light Mode 和 Dark Mode 都設定好符合標準的色彩值。
字級規範與觸控目標尺寸指南
字級太小是最常見的無障礙問題之一。WCAG 雖然沒有硬性規定最小字級,但業界普遍的最佳實踐是:
- 內文(Body):至少 16px(1rem),建議 18px 以上更友善
- 輔助文字(Caption):不低於 12px,且對比度要更高
- 行高(Line Height):至少 1.5 倍字級,段落間距至少 2 倍字級
至於觸控目標尺寸,WCAG 2.2 的 2.5.8 準則要求可互動元素的最小尺寸為 24x24 CSS 像素,Apple HIG 建議 44x44pt,Material Design 建議 48x48dp。我的建議是在 Figma 裡統一用 44x44 作為最小觸控區域,這樣在各平台都能達標。
在 Figma 中,你可以利用 Figma Auto Layout 教學 裡的 padding 設定,確保按鈕和連結即使文字很短,觸控區域也夠大。把 Auto Layout 的 padding 設為至少上下 12px、左右 16px,通常就能符合標準。
Figma Annotation 功能:為螢幕閱讀器做標註
螢幕閱讀器(Screen Reader)是視障使用者瀏覽網頁的主要工具,它會把畫面上的內容轉換成語音朗讀。但螢幕閱讀器「看到」的不是你的視覺設計,而是 HTML 的語意結構。所以設計師的工作之一,就是在設計稿中標註清楚每個元素的語意角色。
Figma 在 2024 年推出了內建的 Annotation 功能(Dev Mode 裡的 Annotations),你可以為每個元素標註:
- Heading Level:標題層級(h1-h6),確保層級不跳號
- Landmark:頁面地標(nav, main, aside, footer)
- Alternative Text:圖片的替代文字,讓螢幕閱讀器描述圖片內容
- Aria Labels:當視覺上的文字不夠描述功能時,補充給螢幕閱讀器的標籤
舉個例子:一個只有圖示的「關閉」按鈕,視覺上使用者看到一個 X 圖示就知道是關閉,但螢幕閱讀器需要你標註 aria-label="關閉對話框",否則它只會讀出「按鈕」兩個字,使用者根本不知道這個按鈕是幹嘛的。
我的習慣是在每個頁面設計完成後,花 15-20 分鐘做一輪 Annotation 標註。這個時間投資絕對值得,因為工程師在開發時就能直接參考,不用再來回確認語意結構。
必裝無障礙外掛推薦:Stark、A11y Focus Order、Include
好的工具能讓無障礙設計事半功倍。以下是我最推薦的三個 Figma 外掛:
1. Stark
Stark 是 Figma 上最全面的無障礙工具,功能包括:色彩對比檢查、視覺障礙模擬(色盲、低視力)、焦點順序標註、WCAG 合規報告。免費版就有基本的對比度檢查功能,Pro 版可以做整頁掃描和生成 PDF 報告,非常適合需要交付無障礙文件的團隊。
2. A11y - Focus Order
這個外掛專門用來標註鍵盤焦點順序(Tab Order)。你可以在設計稿上用數字標示每個可互動元素的焦點順序,讓工程師清楚知道 Tab 鍵按下去之後焦點應該移到哪裡。這個外掛是免費的,操作也很直覺。
3. Include - Accessibility Annotations
Include 是 Microsoft 推出的無障礙標註外掛,功能涵蓋 Landmark 標註、標題層級、替代文字、焦點順序和螢幕閱讀器語意標註。它的優勢是和 Microsoft 的無障礙標準整合得很好,如果你的產品需要符合 Microsoft 的無障礙規範,這個外掛會很有幫助。
我個人的工作流程是:日常設計用 Stark 做即時檢查,設計完成後用 A11y Focus Order 標焦點順序,最後用 Include 做完整的語意標註。三個搭配使用,基本上涵蓋了設計階段能做的所有無障礙準備工作。
鍵盤導航與焦點順序設計
有些使用者因為肢體障礙無法使用滑鼠,完全依賴鍵盤操作。還有一些進階使用者(像是工程師或快捷鍵愛好者)也偏好鍵盤操作。所以,設計鍵盤友善的介面其實是在服務很大一群人。
在設計焦點順序時,有幾個關鍵原則:
- 由上到下、由左到右:焦點順序應該跟閱讀順序一致(中文是左到右、上到下)
- 跳過裝飾性元素:純裝飾的圖片或分隔線不應該被 Tab 鍵選到
- Modal 要鎖定焦點:當彈窗打開時,焦點應該被限制在彈窗內,按 Tab 不會跑到背景去
- 焦點可見性:使用者按 Tab 時,當前焦點所在的元素必須有清楚的視覺提示(通常是一個明顯的外框)
- Escape 關閉:所有彈窗、下拉選單都應該支援 Escape 鍵關閉
在 Figma 中,你可以用上面提到的 A11y Focus Order 外掛來標示焦點順序,並在設計文件中附上一份焦點流程說明。這份說明應該記錄每個頁面的焦點路徑,以及特殊互動(如 Modal、Dropdown)的焦點行為。
另外,別忘了設計焦點狀態(Focus State)。我建議焦點框用 2px 以上的實線,顏色和背景有 3:1 以上的對比度,並且留 2px 的 offset 讓焦點框不會和元素本身重疊。透過易用性測試實戰指南中的方法,你可以找到實際使用鍵盤操作的使用者來驗證你的焦點設計是否順暢。
無障礙設計實戰檢查清單
以下是我在每個專案中都會跑過一遍的無障礙檢查清單,你可以把它存下來或加進團隊的 Design Review 流程:
色彩與視覺
- 所有文字/背景組合的對比度達到 WCAG AA 標準(4.5:1 / 3:1)
- 不單純依賴顏色傳達資訊(例如錯誤狀態除了紅色,還要有圖示或文字提示)
- 在色覺障礙模擬下檢查過設計(使用 Stark 的 Vision Simulator)
- Dark Mode 和 Light Mode 都檢查過對比度
文字與排版
- 內文字級至少 16px
- 行高至少 1.5 倍
- 段落間距至少 2 倍字級
- 文字可以放大到 200% 不會破版
互動元素
- 所有可互動元素至少 44x44 觸控區域
- 有清楚的 Hover、Active、Focus 和 Disabled 狀態
- 焦點順序標註完成
- 所有圖示按鈕都有 aria-label 標註
結構與語意
- 標題層級正確且不跳號(h1 → h2 → h3)
- 頁面地標(Landmark)已標註
- 所有圖片都有 alt text(裝飾性圖片標為 alt="")
- 表單欄位都有對應的 label
動態內容
- 動畫可以被暫停或關閉(支援 prefers-reduced-motion)
- 沒有閃爍超過每秒 3 次的內容
- Toast 通知有設定適當的 aria-live 屬性
團隊協作:把無障礙設計融入日常工作流程
無障礙設計不應該是設計完成後才做的「加分項」,而是從一開始就融入工作流程的基本要求。以下是我建議的團隊協作方式:
- Design Token 階段:建立色彩系統時就確認所有組合都符合 WCAG AA,把通過的組合記錄在 Token 文件中
- 元件設計階段:每個元件都設計完整的狀態(Default、Hover、Active、Focus、Disabled、Error),並在元件文件中標註 aria 屬性
- 頁面設計階段:完成設計後做一輪 Annotation 標註(標題層級、地標、焦點順序、alt text)
- Design Review:在設計審查時加入無障礙檢查項目,使用上面的 Checklist 逐項確認
- Handoff 階段:確保工程師能在設計稿中看到所有無障礙標註,必要時附上焦點流程文件
最後想說的是,無障礙設計是一個持續學習的過程。WCAG 標準會更新,輔助技術也不斷進步。重要的不是一次做到完美,而是在每個專案中都比上一次多考慮一點。當你養成了在 Figma 中隨手檢查對比度、標註語意結構的習慣,無障礙設計就不再是額外的負擔,而是你設計品質的一部分。
結語:無障礙設計是讓好設計更好的方式
回到最開始的問題:無障礙設計到底是誰的責任?答案是每一個參與產品開發的人。而作為設計師,我們能做的比想像中多得多。從在 Figma 中檢查色彩對比開始,到標註焦點順序、設定語意結構,每一個小步驟都在讓你的產品變得更包容。
好的設計不是只為「大多數人」而做,而是為「每一個人」而做。希望這篇教學能幫助你在下一個專案中,把無障礙設計做得更好。工具已經準備好了,就差你開始行動了。
繼續閱讀
Figma AI 功能完全攻略:Make、圖片編輯到 MCP 雙向工作流一次搞懂
相關文章
你可能也喜歡
探索其他領域的精選好文