圖示按鈕只有放大鏡？補上可存取名稱讓人找得到

搜尋按鈕只放一個放大鏡，視覺上很好認。但如果按鈕裡只有被隱藏的SVG，瀏覽器的無障礙資訊可能只剩「按鈕」，沒有告訴人它做什麼。頁面有數個相同圖示時，使用者更難區分這是搜尋文章、搜尋商品，還是開啟搜尋面板。

圖示按鈕需要一個描述動作的可存取名稱。優先考慮直接顯示文字；空間確實有限而保留純圖示時，可以把名稱放在原生button的aria-label。圖形、名稱、鍵盤操作和實際動作都要一致，不能只補一個屬性就認定整個功能已經完善。

先確認按鈕是否有名稱

下面是一個刻意缺少名稱的例子。SVG被設為aria-hidden，表示它不參與無障礙資訊；button裡也沒有其他文字，因此按鈕沒有名稱。圖示的形狀不會自動變成「搜尋」。

<button type="button">
  <svg aria-hidden="true" viewBox="0 0 24 24">
    <circle cx="10" cy="10" r="6" />
    <path d="M15 15 L21 21" />
  </svg>
</button>

保留同一個圖示時，把動作名稱加在button上即可。這裡的名稱是「搜尋文章」，不是「放大鏡」。使用者需要知道按下去會做什麼，而不是圖案長什麼樣。

<button type="button" aria-label="搜尋文章">
  <svg aria-hidden="true" viewBox="0 0 24 24">
    <circle cx="10" cy="10" r="6" />
    <path d="M15 15 L21 21" />
  </svg>
</button>

裝飾SVG被排除，名稱由外層按鈕提供，這樣不用同時維護兩份名稱。不要在button和SVG各放一段意義不同的文字，也不要假設SVG的title在所有搭配裡都會得到你預期的按鈕名稱。檢查的是最後計算出的名稱，而非原始碼裡是否出現某個字。

能顯示文字時，直接把動作寫出來

如果版面放得下「搜尋文章」，讓文字和圖示一起顯示通常更容易理解，也少了看不見的文案來源。原生button可從自己的文字內容取得名稱。下例不需要另外加aria-label。

<button type="button">
  <svg aria-hidden="true" viewBox="0 0 24 24">
    <circle cx="10" cy="10" r="6" />
    <path d="M15 15 L21 21" />
  </svg>
  搜尋文章
</button>

有可見文字時，避免用另一個不相符的aria-label覆蓋它。例如畫面寫「搜尋」，無障礙名稱卻是「開始查詢所有公開資料」，會增加語音操作與辨識的負擔。名稱應包含可見標籤的文字；語言切換時兩者也要一起翻譯。更詳細的操作說明，可以另用描述資訊提供，不必塞進名稱。

若採用視覺隱藏文字，該文字仍必須保留在無障礙樹中。display:none、hidden屬性或visibility:hidden會把一般隱藏內容排除，不能把字這樣藏起來再期待它成為名稱。使用專案已驗證的視覺隱藏樣式，並核對實際計算結果；沒有這套樣式時，aria-label比臨時拼一個藏字方法更直接。

名稱要跟著動作，而不是跟著圖案

垃圾桶可以表示刪除文章、移除購物車商品或清空所有資料，名稱應寫出當下操作。頁面有多個相似按鈕時，加入必要對象，例如「移除商務模板」和「移除作品集模板」。不要只用「操作」「更多」掩蓋不清楚的功能，也不要把「按鈕」寫進名稱，角色本身已表達這件事。

切換狀態也要選一致的模式。收藏按鈕若用穩定的「收藏文章」名稱加aria-pressed，讓使用者知道目前是否按下；若名稱改成「取消收藏」，就要確定那代表下一次動作，別把狀態與動作混在同一句。兩種設計需要各自測清楚，不能隨手換字又留下相矛盾的狀態。

開啟面板的按鈕若實際有展開與關閉狀態，可依元件模式提供aria-expanded等資訊；一般提交搜尋的按鈕不需要硬加這些屬性。可存取名稱是基礎，但它不替代每種元件應有的狀態、焦點管理與互動規則。

用瀏覽器資訊驗證，再走一次鍵盤

本機Chromium案例把缺名稱、aria-label與可見文字三種按鈕放在同一頁，讀取瀏覽器無障礙樹。第一個button名稱為空，後兩個都是「搜尋文章」。這證明範例的名稱計算結果，並不等於已在每個螢幕閱讀器與裝置上測試。

自己的頁面可在開發者工具檢查Accessibility資訊，確認角色是button，名稱符合文案。接著用Tab移到按鈕，確認焦點看得見，再用Enter與Space啟動。原生button提供基本鍵盤行為，仍要驗證事件處理沒有只綁mousedown，或因外層阻止事件而失效。

圖示按鈕應使用button，不要因為好排版就換成只有click事件的div。把div加role也不會自動補齊鍵盤行為、停用處理或焦點。用原生元素通常可以少處理幾個容易漏掉的細節，程式也更容易看出這個控制項的用途。

小圖示不代表只能有小的可按範圍

檢查一排工具按鈕時，可以先遮住圖示，只讀名稱，看看是否仍知道每個按鈕的用途。再反過來只看畫面，確認可見文字與圖示沒有相互衝突。例如左箭頭旁邊的名稱是「下一頁」，即使名稱本身不為空，仍可能是設定錯誤。這個簡單的對照也能找出翻譯遺漏：畫面已切到英文，隱藏名稱卻仍停在另一種語言。

若畫面為了小尺寸改成純圖示，應測不同斷點的名稱。桌面版的文字消失後，手機版不能一起失去唯一名稱來源；若用aria-label補上，確認沒有覆蓋桌面可見文字而形成不同說法。若保留視覺隱藏文字，則要確認 responsive CSS 沒有把整個文字節點設成display:none。桌面通過不能直接代表縮小後仍然正確。

tooltip可以補充資訊，但不應成為唯一能理解動作的方法。滑鼠移入、鍵盤焦點與觸控的觸發方式可能不同；使用者尚未知道這個按鈕做什麼，就得先觸發提示，會讓操作變得費力。重要動作可直接顯示文字，純圖示的名稱則保存在穩定的標記裡，提示只補充必要說明。

放大鏡可以維持視覺尺寸，但按鈕本身應有合適的內距，避免手指難以按到。相鄰的關閉、搜尋與更多按鈕要留足間距，不能只靠名字區分卻讓觸控容易按錯。這類版面問題需要在桌面與手機分別查看，名稱正確不會讓狹小的命中範圍自動改善。

最後把名稱當成產品文案一起管理。修改動作、換語言或調整搜尋範圍時，同步檢查aria-label與可見文字；從文章搜尋改成商品搜尋，就不應留下舊名稱。元件測試可檢查角色與名稱是否存在，實際操作再核功能、焦點與結果提示，兩部分互相補足。

若按下按鈕沒有結果，也要把回饋放在使用者能找到的位置。只讓放大鏡變色或轉圈，不能充分說明「沒有符合文章」或「搜尋失敗」。名稱解決的是啟動前的理解，結果訊息解決的是啟動後的下一步，兩者都應保留清楚的文字。

參考資料