只有圖示的按鈕，應如何命名？

說明動作，而非描述圖案

只有圖示的控制項，設計者或許一眼看懂，屏幕閱讀器使用者卻未必知道用途。放大鏡在不同頁面可能代表搜尋、開啟搜尋欄、篩選、檢視或放大。W3C 的按鈕模式指出按鈕需要可讀取的名稱；一般按鈕可由內文提供，沒有可見文字時亦可用 aria-label 或 aria-labelledby。編輯上的關鍵是說明在該位置啟動控制項會做甚麼。產品目錄中的「搜尋產品」比「放大鏡」更有用。

首先判斷控制項是執行動作，還是前往另一頁。加入購物籃或打開面板等動作應用真正的按鈕；前往產品頁則應用連結。一般容器即使設成可點擊，仍需額外處理鍵盤及語意，容易增加問題。可讀取名稱要簡潔，但足以分辨相鄰控制項。不要假設只有滑鼠移上去才顯示的提示文字，就能提供可靠的按鈕名稱或鍵盤操作路徑。

盤點顧客實際會用的控制項

按顧客流程列出只有圖示的控制項，例如頁首搜尋、購物籃數量、收藏、輪播、產品圖片檢視、帳戶設定及可關閉通知。逐項記下所在頁面、可見圖示、目前可讀取名稱、執行動作及其結果。重複列表控制項也要納入。十個都叫「移除」的按鈕，雖然各有名稱，顧客仍可能不知道會刪去哪件商品。若商品名稱穩定且是關鍵區別，可使用「移除藍色筆記簿」之類的情境名稱。

先決定名稱應傳達甚麼，再選擇技術屬性。頁面若已有可見文字可為控制項命名，沿用該文字通常較易維護和翻譯。W3C 的命名指引提醒，aria-label 可能覆蓋後代內容在無障礙樹中的名稱。若按鈕本身已有清楚可見標籤，再加一個籠統 aria-label，讀出來的名稱反而可能變差。應在瀏覽器檢查實際計算出的名稱，不要只憑原本想設定的 HTML 屬性推斷。

讓重複動作有清楚對象

產品卡片上的心形圖示說明對象名稱的重要。「收藏」表達動作，但同頁有多件商品時可能不清楚；「收藏亞麻襯衫」則指出目標。若所選規格會改變商品名稱，要先釐清按鈕收藏的是產品系列，還是該個別規格，再按真實功能命名。若系統只保存產品頁面，不應在名稱中承諾已保存特定尺寸。標籤必須與系統實際行為一致。

通知、訂單及附件中的控制項亦相同。若畫面只有一個開啟的對話框，「關閉」可能足夠；一列可移除的上傳附件則需要分辨檔案。不要把整張卡片說明塞進每個名稱，否則鍵盤瀏覽時會重複冗長資訊。選擇最短、但能分清動作及對象的片語。若對象名稱涉及敏感資料，亦要考慮共享裝置讀出名稱的影響；可透過程式可辨的列結構提供情境，避免不必要的重複。

如實表達切換狀態和變動動作

部分圖示是切換按鈕，而非一次性動作。W3C 按鈕模式說明，兩態切換可使用 aria-pressed，採用這種模式時標籤應保持穩定。例如「收藏亞麻襯衫」可配合已按下或未按下狀態，前提是功能真正按切換方式運作。另一種設計會把動作及標籤由「收藏亞麻襯衫」改成「從收藏移除亞麻襯衫」；這就不屬於穩定標籤的切換慣例。先決定實際互動，再測試輔助工具讀出甚麼。

不要只靠圖示形狀表達狀態。實心心形對部分人有意義，但不應是「已收藏」的唯一提示。應一起檢查名稱、角色和狀態，再確認動作是否真正保存，或在失敗時提供可見說明。網絡回應較慢時，需要如實更新狀態；伺服器未確認前便把控制項改成「已收藏」會誤導顧客。企業應先界定狀態何時改變，以及失敗或重試時如何處理，再讓可讀取文字遵循同一規則。

以兩種語言表達同一決策

動作和對象應自然地以兩種語言撰寫，不必逐字對譯。按鈕若只是顯示搜尋欄，英文可用「Open search」、中文用「開啟搜尋」；若它提交產品查詢，「Search products」和「搜尋產品」才貼切。這是兩種不同動作，內容團隊須先核實功能再翻譯名稱。還要檢查頁面語言標示是否正確，否則屏幕閱讀器在宣告英文的頁面讀中文可能發音不當。繁體中文介面中，不應遺留未翻譯的英文 aria-label。

按鈕若有可見文字，其可讀取名稱應與該文字一致。WCAG 2.5.3 要求相關控制項的程式名稱包含畫面上的文字，讓語音操作使用者可說出所見標籤來啟動。只有圖示的按鈕沒有可見詞語須逐字對應，但旁邊的指示或提示仍可能造成實際矛盾：畫面說「搜尋」，讀出卻是「開啟目錄篩選」。兩種語言都應檢查整段互動，讓視覺、語音及屏幕閱讀器使用者收到相容指示。

以購物籃作實際例子

假設購物籃一列顯示筆記簿、數量控制項及小型垃圾桶圖示。開發人員把每個垃圾桶都命名為「刪除」，屏幕閱讀器使用者會聽到多次相同名稱，無法放心判斷哪一列會改變。先界定動作是移除一行購物籃商品，而非刪除帳戶或商品本身；再根據該列實際名稱，寫成「從購物籃移除藍色筆記簿」。啟動後，檢查正確商品列消失、總額更新，顧客亦收到清楚結果。這是示範設計情境，並非觀察到的商戶缺陷。

再加入名稱相近的第二本筆記簿，並切換至繁體中文。若兩個按鈕讀出來仍指向同一對象，才考慮加入能可靠從該列及商品資料取得的規格區別。用屏幕閱讀器按按鈕逐個瀏覽，亦以鍵盤 Space 或 Enter 按照原生按鈕行為啟動。失敗路徑同樣要測：若移除不成功，商品列應保留，結果亦要如實說明。圖示好看、標籤拼寫正確仍不足夠；動作若作用於錯誤商品列，或結果沒有提示，顧客仍會受影響。

驗證計算名稱與實際結果

用瀏覽器無障礙樹或同等檢查工具，讀取每個控制項實際計算出的名稱、角色及狀態。然後用鍵盤及屏幕閱讀器在頁面情境中聽整個順序，對比讀出名稱、可見圖示、附近文字和真正執行的動作。這可找出意外覆蓋的 aria-label、被 SVG 隱藏的空名稱、重複的籠統標籤，以及狀態改變後沒有更新的名稱。自動掃描可發現空名稱，但無法判斷多個相鄰控制項中「開啟」究竟指向哪個目標。

最後建立簡短驗收表，記下頁面、語言、控制項、預期動作、計算名稱、啟動前後狀態及失敗結果。若圖示在桌面與手機版的意思或附近文字不同，兩者都要檢查；緊湊版面可能移除原本提供情境的文字。把這些標籤納入與可見文案相同的翻譯流程，日後產品或導覽改動才會觸發審閱。實際下一步是先審核一條重要顧客流程，修正含糊按鈕，再把命名規則納入元件庫。

元件團隊需要一套簡短命名規則，而不只是一份核准詞語清單。規則可要求指出動詞、相鄰按鈕重複時受影響的對象、狀態處理方式，以及顧客應看見的結果。往後即使新圖示外觀不同，也能依同一原則判斷。發布前在實際呈現的介面比對英文和繁體中文計算名稱，並各執行一次動作。按鈕若停用，應透過附近指示或介面狀態讓顧客明白原因。商品名稱、流程步驟或帳戶權限改動後亦須重看標籤，因為圖示完全沒變，原本正確的名稱仍可能變得誤導。 若一個按鈕在不同頁面執行不同操作，應分別命名及測試；重用同一圖示或元件，不代表可重用同一個可讀取名稱。