跳至中央內容區塊 :::
:::

給開發者的 ARIA Patterns：先用原生 HTML，再補 ARIA

ARIA 可以補足複雜元件語意，但錯誤 ARIA 會更糟。用 W3C APG Patterns 檢查 tabs、dialog、accordion、menu button 等互動模式。

重點摘要

  • No ARIA is better than Bad ARIA。
  • 能用原生 HTML 就先用原生 HTML；只有原生語意不足時才補 ARIA。
  • 使用 APG Patterns 時，要同時實作鍵盤操作、焦點管理與狀態更新。

先用原生 HTML，真的不夠再用 ARIA

ARIA 的第一原則很直接：能用原生 HTML 就不要先加 ARIA。button、a、input、select、details、summary 這些元素已經帶有瀏覽器和輔助科技理解的語意與鍵盤行為。

如果用 div 或 span 重新做按鈕、選單或分頁，就必須自己補上名稱、角色、狀態、鍵盤操作與焦點管理。這通常比使用原生元素更容易出錯。

不要只複製 role

ARIA 只改變輔助科技接收到的語意，不會自動補上互動行為。role="button" 不會讓 div 自動支援 Enter 或 Space；aria-expanded="true" 也不會自動打開內容或管理焦點。

錯誤 ARIA 會讓畫面看起來正常，但讓輔助科技收到錯誤訊號。這比沒有 ARIA 更難除錯，因為問題常常只出現在螢幕閱讀器、語音控制或鍵盤流程中。

使用 APG Pattern 時要一次實作整組契約

W3C APG Patterns 適合當作複雜元件的參考，但不能只複製其中一兩個屬性。tabs、dialog、accordion、menu button、combobox 這類元件都有一組完整契約：鍵盤操作、焦點位置、可及名稱、角色、狀態與 DOM 關係要一起成立。

  • 名稱：使用者聽到或看到的控制項名稱是否清楚。
  • 角色：role 是否符合元件實際用途。
  • 狀態：expanded、selected、checked、disabled 等狀態是否即時更新。
  • 鍵盤：方向鍵、Enter、Space、Escape、Tab 的行為是否符合 pattern。
  • 焦點：開啟、關閉、切換內容後，焦點是否落在合理位置。

常見錯誤

ARIA 問題常見於自訂元件、設計系統元件與第三方元件。這些元件一旦被重複使用，錯誤也會跟著出現在很多頁面，所以應該盡量在元件層修正。

  • 用 role 改語意，卻沒有補鍵盤操作。
  • aria-label 覆蓋了畫面上更清楚的文字。
  • aria-hidden 隱藏了仍可聚焦或仍可操作的內容。
  • aria-expanded、aria-selected、aria-current 等狀態沒有跟畫面同步。
  • dialog、menu 或 tabs 看起來可用，但焦點管理不符合使用者預期。

DevCheck 與 UI Kit 的角色

DevCheck 可以協助在目前頁面找出部分 ARIA 與語意問題，也能讓團隊在互動後狀態重新檢查。但它不能替你保證 pattern 已完整實作，因為鍵盤行為、焦點管理和內容理解仍需要人用真實流程測。

UI Kit 的方向則是在元件層減少重複錯誤。對常用元件來說，越早把原生 HTML、ARIA、鍵盤和焦點規則放進元件基礎，越不容易在每個頁面重新犯同樣的錯。

相關頁面