# 如何正確設定可及名稱？讓按鈕、連結與表單欄位被理解 English version: [https://accesserty.com/en/ai/guides/how-to-implement-accessible-names.md](https://accesserty.com/en/ai/guides/how-to-implement-accessible-names.md) Page version: [https://accesserty.com/guides/how-to-implement-accessible-names/](https://accesserty.com/guides/how-to-implement-accessible-names/) Last updated: 2026-09-29 可及名稱讓螢幕閱讀器等輔助科技知道按鈕、連結與表單欄位的用途。這份指南說明如何優先使用原生 HTML 與可見文字，再視情況補上 aria-label 或 aria-labelledby。 ## 重點整理 - 可及名稱回答「這個控制項叫什麼」或「它要做什麼」。 - 多數情況下，最穩定的做法是使用可見文字、label、alt 與語意 HTML。 - aria-label 與 aria-labelledby 是補充工具，不應拿來掩蓋不清楚的畫面文字或錯誤結構。 ## 可及名稱解決的是理解問題可及名稱是瀏覽器提供給輔助科技的名稱。當使用者遇到一個按鈕、連結、表單欄位或自訂控制項時，螢幕閱讀器通常會把它的角色與名稱一起讀出來，例如「搜尋，按鈕」或「電子郵件，文字欄位」。它不是額外的行銷文字，也不是把畫面上的所有內容重複一次。它的任務很單純：讓使用者知道目前這個元件是什麼、能做什麼、是否值得操作。 ## 先使用原生 HTML 與可見文字最穩定的可及名稱通常不是 ARIA 寫出來的，而是來自原生 HTML。可見的按鈕文字、清楚的連結文字、表單的 label、資訊圖片的 alt，都比隱藏在屬性裡的補救文字更容易被團隊理解與維護。如果畫面文字本身清楚，輔助科技、語音控制、翻譯工具與一般使用者通常都能得到比較一致的資訊。 - 按鈕：優先讓按鈕內有清楚文字，例如「儲存草稿」比只有圖示更容易理解。 - 連結：避免只寫「更多」或「點這裡」，改成能說明目的地的文字。 - 表單欄位：使用 label 關聯欄位；placeholder 不能取代標籤。 - 圖片：有意義的圖片用 alt 傳達必要資訊；裝飾圖片則避免製造多餘朗讀。 - 群組：一組相關欄位可用 fieldset 與 legend 補上群組脈絡。 ```html 電子郵件

用來回覆這次詢問。

``` 這是命名示範，不會儲存或傳送資料。欄位的名稱是「電子郵件」，描述是「用來回覆這次詢問。」；按鈕的名稱來自「儲存草稿」。在開發者工具確認這些值，再用實際螢幕閱讀器檢查操作時的朗讀；無障礙資訊樹不是朗讀測試的替代品。 ## 連結範例：把目的地寫在可見文字裡如果連結只是「更多」，先改善畫面文字，不必先用 aria-label 蓋掉它。下面的連結直接前往聯絡頁，名稱和使用者看見的文字相同；它不是送出資料的按鈕。 ```html 聯絡 Accesserty ``` 預期角色是連結，名稱是「聯絡 Accesserty」。Tab 可到達、Enter 可前往目的地；不要要求連結像按鈕一樣用 Space 啟動。這是官網站內連結，複製到其他網站時必須換成實際路徑。若另外加 aria-label，名稱仍應包含可見標籤，而不是換成另一套說法。 ## 什麼時候才需要 ARIA？ ARIA 適合補足原生 HTML 不容易表達的情況，但它不是第一選擇。如果畫面上已經有可見文字，通常優先用 aria-labelledby 指向那段文字；只有在沒有可見文字可用時，才考慮 aria-label。常見情境包括只有圖示的按鈕、需要把標題當成複雜元件名稱、或同一頁有多個外觀相近但目的不同的控制項。 ## 常見錯誤可及名稱的問題常常不是「完全沒有」，而是名稱和實際用途不一致。自動化工具可以找出一部分缺漏，但最後仍需要人確認名稱是否真的符合使用情境。 - 只有圖示的按鈕沒有名稱，使用者只聽到「按鈕」。 - 同一頁多個連結都叫「更多」，但目的地不同。 - 用 placeholder 當作表單標籤，輸入後提示就消失。 - aria-label 和畫面文字不一致，讓不同使用者得到不同資訊。 - 把補充說明放在 aria-describedby，卻誤以為它會變成控制項名稱。 - 名稱或狀態沒有反映目前操作。例如展開按鈕可維持「顯示詳細資料」的名稱，但 aria-expanded 應跟著展開或收合更新；不必每次狀態改變都改名。 ## 怎麼檢查可及名稱瀏覽器開發者工具通常可以檢查無障礙資訊樹，查看目前元素的角色、名稱與描述。這是理解輔助科技實際取得什麼資訊的好起點。 DevCheck 可以協助找出缺少可及名稱、ARIA 使用錯誤與部分表單標籤問題。不過，機器掃描只能指出可疑位置；名稱是否符合任務、是否夠清楚，仍然需要人工判斷。 - 用鍵盤移動到控制項，確認焦點順序與畫面位置合理。 - 在開發者工具檢查無障礙資訊樹中的 name、role、description。 - 用自動化工具找缺少名稱、空白名稱或 ARIA 關係錯誤。 - 抽查螢幕閱讀器或語音控制工具，確認名稱在實際操作時能被理解。 ## 把它放進團隊流程可及名稱不只屬於工程師。設計師可以在圖示按鈕旁標示用途，內容維護者可以寫清楚連結文字，QA 可以在主要流程中確認焦點與名稱，產品負責人也可以要求重要操作不要只靠圖示或視覺位置理解。這類檢查不需要等到正式檢測才開始。越早把名稱說清楚，後面要補救的成本通常越低，也越容易讓團隊討論同一個具體問題。 ## 接下來可以做什麼 - [如何寫出有意義的圖片替代文字]() — 依圖片在頁面中的用途判斷 alt，而不是只描述畫面上有什麼。 - [網頁上線前，色彩對比要檢查哪些狀態？]() — 檢查文字、焦點、錯誤與選取狀態；區分必要的圖示／邊界、裝飾，以及真正停用元件的例外。 ## 延伸閱讀 - [Accesserty DevCheck]() — 用瀏覽器內工具檢查本機、測試站、登入後頁面與互動狀態。 - [可及名稱術語頁]() - [語意 HTML 術語頁]() - [ARIA 術語頁]() - [ARIA Patterns 指南]() - [自動化檢測限制指南]() - [圖片替代文字指南]() - [W3C Accessible Name and Description Computation]() - [W3C：可見標籤與可及名稱]() - [網站無障礙檢測工具]() — 針對實際頁面、登入後狀態與互動狀態做初步無障礙檢查。 - [看懂 WCAG 檢測結果]() — 檢視 WCAG A/AA 相關問題、嚴重程度、受影響元素與修正線索。 - [Accesserty UI Kit]() — 使用 HTML-first Web Components 降低重複互動缺陷。 - [無障礙實作與維護指南]() — 依實際任務瀏覽公開訊號、上線前檢查、上線後維護與標準限制指南。