如何正確設定可及名稱？讓按鈕、連結與表單欄位被理解
可及名稱讓螢幕讀取器等輔助科技知道按鈕、連結與表單欄位的用途。這份指南說明如何優先使用原生 HTML 與可見文字，再視情況補上 aria-label 或 aria-labelledby。
重點摘要
- 可及名稱回答「這個控制項叫什麼」或「它要做什麼」。
- 多數情況下，最穩定的做法是使用可見文字、label、alt 與語意 HTML。
- aria-label 與 aria-labelledby 是補充工具，不應拿來掩蓋不清楚的畫面文字或錯誤結構。
可及名稱解決的是理解問題
可及名稱是瀏覽器提供給輔助科技的名稱。當使用者遇到一個按鈕、連結、表單欄位或自訂控制項時，螢幕讀取器通常會把它的角色與名稱一起讀出來，例如「搜尋，按鈕」或「電子郵件，文字欄位」。
它不是額外的行銷文字，也不是把畫面上的所有內容重複一次。它的任務很單純：讓使用者知道目前這個元件是什麼、能做什麼、是否值得操作。
先使用原生 HTML 與可見文字
最穩定的可及名稱通常不是 ARIA 寫出來的，而是來自原生 HTML。可見的按鈕文字、清楚的連結文字、表單的 label、資訊圖片的 alt，都比隱藏在屬性裡的補救文字更容易被團隊理解與維護。
如果畫面文字本身清楚，輔助科技、語音控制、翻譯工具與一般使用者通常都能得到比較一致的資訊。
- 按鈕：優先讓按鈕內有清楚文字，例如「儲存草稿」比只有圖示更容易理解。
- 連結：避免只寫「更多」或「點這裡」，改成能說明目的地的文字。
- 表單欄位：使用 label 關聯欄位；placeholder 不能取代標籤。
- 圖片：有意義的圖片用 alt 傳達必要資訊；裝飾圖片則避免製造多餘朗讀。
- 群組：一組相關欄位可用 fieldset 與 legend 補上群組脈絡。
什麼時候才需要 ARIA？
ARIA 適合補足原生 HTML 不容易表達的情況，但它不是第一選擇。如果畫面上已經有可見文字，通常優先用 aria-labelledby 指向那段文字；只有在沒有可見文字可用時，才考慮 aria-label。
常見情境包括只有圖示的按鈕、需要把標題當成複雜元件名稱、或同一頁有多個外觀相近但目的不同的控制項。
常見錯誤
可及名稱的問題常常不是「完全沒有」，而是名稱和實際用途不一致。自動化工具可以找出一部分缺漏，但最後仍需要人確認名稱是否真的符合使用情境。
- 只有圖示的按鈕沒有名稱，使用者只聽到「按鈕」。
- 同一頁多個連結都叫「更多」，但目的地不同。
- 用 placeholder 當作表單標籤，輸入後提示就消失。
- aria-label 和畫面文字不一致，讓不同使用者得到不同資訊。
- 把補充說明放在 aria-describedby，卻誤以為它會變成控制項名稱。
- 狀態改變後名稱沒有更新，例如展開、收合、加入、移除。
怎麼檢查可及名稱
瀏覽器開發者工具通常可以檢查無障礙資訊樹，查看目前元素的角色、名稱與描述。這是理解輔助科技實際取得什麼資訊的好起點。
DevCheck 可以協助找出缺少可及名稱、ARIA 使用錯誤與部分表單標籤問題。不過，機器掃描只能指出可疑位置；名稱是否符合任務、是否夠清楚，仍然需要人工判斷。
- 用鍵盤移動到控制項，確認焦點順序與畫面位置合理。
- 在開發者工具檢查無障礙資訊樹中的 name、role、description。
- 用自動化工具找缺少名稱、空白名稱或 ARIA 關係錯誤。
- 抽查螢幕讀取器或語音控制工具，確認名稱在實際操作時能被理解。
把它放進團隊流程
可及名稱不只屬於工程師。設計師可以在圖示按鈕旁標示用途，內容維護者可以寫清楚連結文字，QA 可以在主要流程中確認焦點與名稱，產品負責人也可以要求重要操作不要只靠圖示或視覺位置理解。
這類檢查不需要等到正式檢測才開始。越早把名稱說清楚，後面要補救的成本通常越低，也越容易讓團隊討論同一個具體問題。