按鈕設計規範是什麼？先分清楚按鈕、連結與開關
按鈕設計規範的核心，是用明確的元件規則處理「使用者按下去會發生什麼」。UI 按鈕適合提交、確認、取消、刪除、匯出、搜尋等明確操作；連結負責前往另一個位置；switch 或 toggle 則用來切換某個持續狀態。
設計師在建立按鈕設計規範時，第一個判斷不該是顏色好不好看，而是這個可點擊元素到底代表「動作」、「導覽」還是「狀態變更」。很多介面混亂，問題不是按鈕樣式不夠漂亮，而是把所有可點擊元素都做成按鈕，使用者無法預期下一步。
按鈕用於提交、確認、取消與執行任務
按鈕代表一個明確動作。常見例子包括「儲存變更」、「送出申請」、「建立專案」、「取消訂單」、「刪除使用者」、「匯出報表」。這些操作通常會改變系統資料、觸發流程、送出表單，或讓目前畫面進入下一個狀態。
好的按鈕會讓使用者在按下前就知道後果。比起「確定」，「儲存變更」更能降低猶豫；比起「送出」，「送出審核」更能說明流程進入哪個階段。
按鈕和連結差在哪裡？
連結主要用於導覽，例如前往文章、商品頁、說明文件、帳號設定頁。按鈕則用於執行操作，例如送出、建立、刪除、重新整理。這個區分會影響語意、鍵盤操作、螢幕閱讀器理解，也會影響工程端要使用 <a> 還是 <button>。
| 元素 | 主要用途 | 典型文字 | 驗收重點 |
|---|---|---|---|
| 按鈕 | 執行明確操作 | 儲存變更、送出審核、刪除資料 | 按下後有狀態回饋，不能重複誤送 |
| 連結 | 前往另一個頁面或區塊 | 查看說明、前往設定、閱讀條款 | 網址、焦點、開啟方式符合預期 |
| 開關 | 切換持續狀態 | 啟用通知、公開專案、自動續約 | 狀態清楚，切換後能理解目前是開或關 |
按鈕和 switch / toggle 差在哪裡？
switch 或 toggle 適合「開啟或關閉」某個持續設定，例如通知、權限、顯示狀態。按鈕適合一次性任務，例如「寄出邀請」。如果使用者按下後只是讓某個設定保持開啟，通常應該使用 switch；如果按下後是完成一個流程，才適合使用按鈕。
硬體按鈕構造不展開，只回應 PAA 基本疑問
搜尋「按鈕」時可能會看到硬體按鈕、開關構造、電路接點等資訊，但 UI 按鈕設計規範討論的是畫面上的互動元件。硬體按鈕需要處理材料、回彈、電氣訊號；UI 按鈕則需要處理任務語意、按鈕狀態、尺寸、顏色、無障礙與工程交付。
按鈕類型與視覺層級：Primary、Secondary、Text、Outline 怎麼選
按鈕類型應依任務優先級與操作風險決定。Primary button 只留給目前畫面最重要行動；Secondary button 支援主要流程；Text button 適合低干擾操作；Outlined button 適合需要可見但不能搶走焦點的操作；Destructive button 用於高風險行為。
我會把按鈕層級視為產品決策，而不是純視覺問題。一頁出現多個同等強度的主要按鈕，通常代表流程還沒整理好，設計稿只是把決策壓力丟給使用者。
| 類型 | 使用時機 | 視覺權重 | 常見場景 | 避免情況 |
|---|---|---|---|---|
| Primary | 目前畫面最重要的下一步 | 最高 | 送出表單、建立帳號、完成付款 | 同一區塊放多個 primary |
| Secondary | 支援任務但不是主路徑 | 中 | 返回、另存草稿、預覽 | 做得比 primary 更醒目 |
| Text | 低風險、低干擾操作 | 低 | 取消、稍後再說、清除篩選 | 用於高風險或高價值操作 |
| Outlined | 需要可見但不應最高優先 | 中低 | 匯入、預覽、複製設定 | 邊框顏色太重造成誤判 |
| Destructive | 刪除、取消訂閱、重設 | 依風險調整 | 刪除資料、停用帳號 | 未確認就直接執行 |
Primary button：一個畫面只保留最重要行動
Primary button 應該回答「此刻最希望使用者完成哪個動作」。在表單中通常是「儲存變更」或「送出申請」；在空狀態中可能是「建立第一個專案」；在結帳流程中可能是「確認付款」。同一個視覺區域若有兩個 primary，使用者會被迫重新理解哪個才是主路徑。
Secondary button：支援主要任務但不搶焦點
Secondary button 用於保留選項，例如「儲存草稿」、「預覽」、「返回上一頁」。它可以讓流程更彈性，但不應該用色塊、陰影或位置搶過 primary。PM 在審稿時可以直接問：如果使用者只能做一件事，哪個按鈕應該最明顯？答案通常就是 primary。
Text button：低風險、低干擾、常見於對話框
Text button 適合取消、略過、清除、展開更多等操作。它的優點是低干擾，缺點是辨識度較低，所以不適合承載關鍵提交或高風險操作。對話框裡的「取消」常用 text button，是因為它需要被找到，但不該比確認操作更吸引注意。
Outlined button：需要可見但不能高於 primary
Outlined button 適合放在 primary 旁邊，讓使用者知道有另一個選項，例如「預覽」搭配「發布」。外框按鈕的問題常出在邊框顏色太重，看起來像另一個主要按鈕。規範中應明確定義 outline 的邊框、文字、hover、focus 與 disabled 狀態。
Destructive button：刪除、取消訂閱、重設等高風險操作
Destructive button 不等於永遠用紅色實心按鈕。刪除單筆資料、清空設定、取消訂閱、重設 API key 都是高風險操作，但是否使用紅色實心，要看操作是不是當下的主要任務。很多後台把「刪除」做得過度突出，反而提高誤按機率。
按鈕尺寸規範：高度、寬度、padding 與點擊範圍
按鈕尺寸要同時看視覺高度與實際點擊範圍。Web 一般表單常用 40px 高度，行動裝置常落在 44 至 48px，B2B 後台可用 32 至 36px 的密集視覺尺寸，但可點擊範圍仍應保留足夠空間。
尺寸規範不該只寫「按鈕高度 40px」。真正需要驗收的是 touch target、文字 padding、圖示間距、focus ring 是否被裁切，以及行動裝置上手指是否容易誤觸。Apple Human Interface Guidelines 提到按鈕 hit region 至少 44 x 44 pt；Material 參考中常見 48 x 48 dp 的觸控目標；WCAG 2.2 的 AA 成功準則 2.5.8 則要求指標輸入目標至少 24 x 24 CSS px，或符合例外與間距條件。實務上，台灣 Web 與 SaaS 團隊若以 44 x 44px 作為一般最低可操作範圍，會比只追求視覺密度更穩。
| 情境 | 建議高度 | 最小點擊範圍 | 適用場景 | 注意事項 |
|---|---|---|---|---|
| Web 一般表單 | 40px | 44 x 44px | 登入、送出、搜尋 | 文字不可貼邊，左右 padding 建議至少 16px |
| 行動裝置 | 44 至 48px | 44 x 44px 以上 | App、手機版網頁 | 手指操作優先，避免相鄰按鈕太近 |
| B2B 後台密集表格 | 32 至 36px | 仍需保留可操作範圍 | 表格列操作 | 可用 icon button，但需 tooltip 或 accessible name |
| 主要 CTA | 44 至 48px | 44 x 44px 以上 | 購買、註冊、送出 | 視覺權重可高於一般按鈕，但不可壓迫其他資訊 |
Web、App、B2B 後台的尺寸差異
Web 表單通常需要兼顧滑鼠與鍵盤，40px 高度足以支撐清楚文字與穩定點擊。行動裝置以手指操作為主，44 至 48px 更安全。B2B 後台常有高密度表格，視覺高度可以降到 32 至 36px，但點擊範圍、行距與工具提示要一起設計，不能只把按鈕縮小。
最小點擊範圍不能只看視覺高度
視覺高度 32px 的 icon button，仍可透過透明 padding 或表格列高度提供較大的操作範圍。這類規格應在設計稿上標清楚，否則工程師只會照著可見外框切版，最後造成桌機勉強可用、手機很容易誤按。
密集表格中的小按鈕怎麼處理
後台表格常需要「編輯」、「複製」、「停用」、「刪除」等列操作。建議高頻、低風險動作用 icon button 或 text button；低頻、高風險動作放進更多選單或二次確認。若每列都放三個以上醒目按鈕，表格會從資料閱讀工具變成按鈕牆，使用者反而找不到重點。
跨 Material、Apple、WCAG 與 Web 慣例的尺寸整理
Material Design 與 Apple HIG 提供的是平台慣例，WCAG 提供的是無障礙最低要求，產品規範要把它們轉成團隊可驗收的標準。參考來源可見 Material Design accessibility touch targets、Apple Human Interface Guidelines Buttons 與 WCAG 2.2 Target Size Minimum。
按鈕狀態規格表：Normal、Hover、Pressed、Focus、Disabled、Loading
按鈕狀態用來回應互動、可用性與系統處理進度。完整按鈕狀態至少要定義 normal、hover、pressed、focus、disabled、loading、success、error，並同時寫清楚視覺、無障礙與工程行為。
狀態規格是設計系統最容易被低估的一塊。只交付 normal 狀態，等於把 hover、focus、loading、disabled 的判斷全部丟給工程師臨場發揮，最後每個產品頁都會長出不同的按鈕行為。
| 狀態 | 使用時機 | 視覺規範 | 無障礙要求 | 工程注意事項 |
|---|---|---|---|---|
| Normal | 可操作預設狀態 | 顏色與層級清楚 | 文字可讀，對比足夠 | 對應預設 props |
| Hover | 滑鼠移入 | 背景、邊框或亮度微調 | 不可只靠 hover 傳達必要資訊 | touch 裝置不可依賴 hover |
| Pressed / Active | 按下瞬間 | 明確按壓感，避免跳動 | 狀態仍需可辨識 | 避免延遲造成誤判 |
| Focus | 鍵盤聚焦 | focus ring 明顯，不被裁切 | 鍵盤使用者必須看得見焦點 | 不可移除 outline 後沒有替代樣式 |
| Disabled | 暫不可操作 | 降低權重但仍可辨識 | 最好說明不可用原因 | 不應送出事件，也不應偷偷可點 |
| Loading | 送出中或處理中 | spinner、文字變化或進度提示 | 告知目前正在處理 | 鎖定重複送出，避免建立重複資料 |
| Success / Error | 操作結果回饋 | 成功或錯誤狀態清楚 | 不只靠顏色提示 | 搭配 toast、inline message 或 aria-live |
按鈕顏色規範：品牌色、語意色、對比與危險操作
按鈕顏色不是裝飾，而是用來傳達優先級、狀態與風險。Primary color 應保留給主要操作；語意色用於 danger、success、warning 等狀態；所有按鈕都要在淺色與暗色模式下重新驗證對比。
按鈕顏色最常見的錯誤，是把品牌色當成所有操作的通用色。當每個按鈕都很亮，真正重要的按鈕就消失了；當危險操作一律紅色實心，使用者會被推向最不該快速執行的動作。
Primary color 只給最重要操作
Primary color 應該是畫面中最稀缺的視覺資源。註冊、付款、送出審核、建立專案可以使用主要色；取消、返回、清除篩選不應該使用同等強度。規範中可直接寫明：同一任務區塊原則上只允許一個 primary button。
Destructive action 不一定要預設使用紅色實心按鈕
危險操作需要被辨識，但不一定要被鼓勵。刪除資料若是次要選項，可以用紅色文字按鈕搭配確認對話框；若使用者已進入明確刪除流程，才可能使用較高權重的 destructive button。紅色應該代表風險語意，不該變成提高點擊率的工具。
Disabled 不能低到看不見
Disabled 狀態可以降低對比，但仍應讓使用者知道按鈕存在。若按鈕灰到幾乎看不見，使用者會以為功能消失。更好的做法是保留可辨識輪廓，並在旁邊或 hover、focus 時說明原因，例如「請先選擇至少一筆資料」。
暗色模式下按鈕顏色要重新驗證
暗色模式不能只把背景變黑、按鈕沿用淺色模式色票。Primary、danger、disabled、focus ring 在暗色背景上的對比與飽和度都會改變。設計系統應為 dark theme 定義獨立 token，並實測 normal、hover、focus、disabled、loading 的可讀性。
多語系與長文案按鈕的顏色、寬度與換行處理
繁中按鈕通常較短，但英文、德文、泰文或印尼文版本可能膨脹。按鈕寬度不能只依中文稿設定。規範要明確定義最大寬度、是否允許換行、icon 與文字的間距、截斷規則，以及不同語言下 primary 與 secondary 是否仍能維持清楚層級。
按鈕文字與圖示規範：文案要讓使用者知道按下去會發生什麼
按鈕文字應用動詞說明操作結果，讓使用者在按下前知道系統會做什麼。「儲存變更」比「確定」清楚；「刪除 3 筆資料」比「刪除」安全；只有圖示的按鈕必須提供 tooltip 或 aria-label。
PM 審按鈕文案時，可以直接檢查兩件事：文案是否說出結果，以及風險是否被說清楚。模糊按鈕會讓使用者停下來猜，這種停頓在高頻後台特別傷效率。
| 情境 | 不建議 | 建議 | 原因 |
|---|---|---|---|
| 編輯表單 | 確定 | 儲存變更 | 說明資料會被保存 |
| 審核流程 | 送出 | 送出審核 | 說明進入下一個流程狀態 |
| 批次刪除 | 刪除 | 刪除 12 筆資料 | 讓作用範圍可見 |
| 取消訂閱 | 取消 | 取消自動續約 | 避免和關閉對話框混淆 |
| 圖示按鈕 | 只有垃圾桶 icon | tooltip「刪除」並提供 accessible name | 支援螢幕閱讀器與新使用者理解 |
用動詞描述結果，例如「儲存變更」比「確定」清楚
按鈕文字最好以動詞加受詞呈現，例如「建立客戶」、「匯出報表」、「套用篩選」、「邀請成員」。只有在對話框語境非常明確時，才適合用「確認」或「取消」。後台系統中，越靠近資料變更的操作，文案越應該具體。
圖示按鈕必須有可理解的文字替代
圖示按鈕可以節省空間，但不能假設每個人都看得懂圖示。搜尋、關閉、刪除、編輯雖然常見，仍應提供 tooltip；對螢幕閱讀器則需要 accessible name。MDN 的 button 文件也提醒，只有圖示的按鈕若沒有可存取名稱，輔助科技無法理解它的功能，可參考 MDN button accessibility。
危險操作文案要明確說出後果
危險操作不應只寫「確定」。更安全的文案是「刪除專案」、「停用帳號」、「重設 API key」。若是批次操作，按鈕或確認訊息應顯示數量，例如「刪除 8 筆客戶資料」。這能讓使用者在最後一秒發現作用範圍是否正確。
長文案按鈕要處理換行、截斷與多語系膨脹
按鈕文案過長時，不應直接把字縮小到難讀。規範可設定優先縮短文案，其次增加按鈕寬度，最後才允許雙行。若必須截斷，不能截掉關鍵動詞或風險詞，例如「刪除全部」不能被截成只剩「刪除」。
從頁面流程看按鈕：表單、對話框、列表與空狀態的擺放規範
按鈕位置應跟隨使用者任務流程。表單按鈕通常放在流程結尾；長表單可使用固定 action bar；對話框要清楚區分確認、取消與危險操作；列表頁需分開單筆操作與批次操作。
單一按鈕規格再完整，放錯位置還是會造成誤判。按鈕應該出現在使用者做完判斷、準備採取行動的位置，而不是設計師覺得畫面哪裡空就放哪裡。
| 場景 | 建議位置 | 主要按鈕 | 次要操作 | 驗收重點 |
|---|---|---|---|---|
| 表單頁 | 表單結尾或固定操作列 | 儲存、送出 | 取消、儲存草稿 | 不讓使用者找不到完成動作 |
| 對話框 | 內容下方 | 確認目前任務 | 取消、返回 | 危險操作需要明確區隔 |
| 列表頁 | 表格上方、列內或更多選單 | 新增、批次操作 | 單筆編輯、複製、停用 | 批次與單筆不能混淆 |
| 空狀態 | 說明文字附近 | 建立第一筆資料 | 匯入、查看範例 | 引導下一步，不做裝飾 CTA |
表單頁：主要操作放在流程結尾，長表單可用固定操作列
短表單的主要按鈕放在欄位後方最自然。長表單、後台設定頁、分頁式表單則可以使用固定操作列，讓「儲存變更」不會被捲動藏起來。固定列要避免遮住內容，focus 狀態也不能被 sticky 區塊蓋住。
對話框：確認、取消、危險操作的排序
對話框按鈕要符合平台與產品慣例，重點是讓使用者能分辨主行動與退出行動。刪除類對話框建議把風險寫在標題或內容中，按鈕使用明確文案，例如「刪除專案」。若同時有取消與刪除，視覺層級應讓使用者先讀懂後果。
列表頁：單筆操作與批次操作分開
列表頁最容易發生作用範圍混亂。單筆操作應靠近該列資料；批次操作應靠近已選取狀態，例如表格上方顯示「已選取 5 筆」。如果批次刪除按鈕一直常駐且過度醒目，使用者會在未選取資料時困惑，也更容易誤解操作範圍。
空狀態按鈕應引導下一步，而不是只是裝飾 CTA
空狀態的按鈕應該對應使用者下一個合理任務，例如「建立第一個客戶」、「匯入名單」、「新增付款方式」。如果空狀態只放一個泛用 CTA，卻沒有解釋目前為什麼是空的，使用者會不知道該不該按。
B2B 後台按鈕規範：高頻操作、批次操作與危險操作怎麼分層
B2B 後台按鈕要依操作頻率、業務風險與畫面密度分層。高頻低風險動作要降低成本；批次操作要清楚顯示作用範圍；權限不足不能只給 disabled；危險操作需要確認、撤銷或權限控管。
SaaS 與企業後台的按鈕設計，不適合完全套用行銷網站 CTA 思維。後台使用者常在同一頁重複操作幾十次，他們需要的是準確、穩定、低誤觸成本，而不是每個按鈕都像廣告入口。
| 情境 | 操作頻率 | 風險 | 建議按鈕層級 | 設計重點 |
|---|---|---|---|---|
| 新增資料 | 中高 | 低至中 | Primary | 放在列表上方或空狀態主位置 |
| 匯出報表 | 中 | 低 | Secondary 或 outline | 說明匯出範圍與格式 |
| 批次停用 | 中低 | 中高 | Secondary danger | 顯示已選取數量並要求確認 |
| 刪除資料 | 低 | 高 | Destructive | 二次確認，必要時輸入名稱確認 |
| 權限不足 | 依角色 | 中 | Disabled 或可聚焦提示 | 說明需要哪個權限或找誰開通 |
高頻操作要降低操作成本
高頻操作不一定要更大，但要更穩定、更容易預測。例如客服後台的「指派」、「標記已處理」、「回覆」應該固定位置、固定文案、固定快捷鍵或鍵盤路徑。使用者每天點上百次的按鈕，不需要驚喜，需要肌肉記憶。
批次操作要清楚顯示作用範圍
批次操作必須把「選了哪些資料」放在按鈕附近。建議在工具列顯示「已選取 12 筆」，再提供「匯出」、「標記」、「停用」、「刪除」等操作。危險批次操作還要在確認對話框再次顯示數量與條件，避免篩選後誤刪大量資料。
權限不足時不要只給 disabled
企業後台常有角色權限。若按鈕 disabled 卻沒有原因，使用者只會以為系統壞了。較好的做法是保留按鈕可見性，搭配提示文案，例如「需要管理員權限」或「此狀態不可編輯」。若使用 aria-disabled，工程端仍需手動阻止事件；MDN 對 aria-disabled 的說明也強調它只提供語意，不會自動停用功能。
危險操作需要二次確認或延遲撤銷
高風險操作可分成兩類：可復原與不可復原。可復原操作可搭配 toast 與「復原」；不可復原操作應使用確認對話框、輸入名稱確認、權限檢查或延遲執行。不要讓「刪除」和「儲存」並排又同樣醒目，這是後台誤操作的常見來源。
特殊按鈕類型：FAB、Icon Button、Block Button 什麼時候可以用？
特殊按鈕類型要依空間與任務條件使用。FAB 適合全局主要行動；icon button 適合高密度工具列或表格列操作，但必須有文字替代；block button 適合行動裝置與單一路徑任務。
特殊按鈕不是為了讓畫面更活潑，而是解決特定操作條件。FAB 最常被濫用，尤其在 B2B 後台裡，漂浮在表格上的大按鈕常常遮住資料，也不符合高密度操作情境。
FAB 只適合全局主要行動
FAB 適合「新增」、「撰寫」、「建立」這類跨畫面主要行動，尤其在行動 App 中較常見。若一個頁面已經有清楚工具列與主要按鈕，通常不需要再放 FAB。FAB 不適合承載多個同等重要操作，也不適合遮住表格、圖表或表單內容。
Icon button 必須有 tooltip 或 aria-label
Icon button 適合空間有限的位置，例如工具列、卡片操作、表格列。規範中應要求每個 icon button 都有 tooltip、hover/focus 狀態與 accessible name。只靠圖示判斷風險很高，尤其「複製」、「匯出」、「分享」、「重新整理」在不同產品中圖示可能相近。
Block button 適合行動裝置與單一路徑任務
Block button 指全寬按鈕，常見於手機版登入、結帳、註冊、表單送出。它適合單一路徑任務，因為使用者下一步很明確。桌機後台不應過度使用全寬按鈕，否則會讓操作看起來比實際重要，也會破壞資料閱讀節奏。
按鈕元件規格表：設計系統應該定義哪些屬性
設計系統中的按鈕元件應定義 type、size、state、icon、danger、block、disabled、loading 等屬性，並落到 Figma variant、design token、component props、ARIA 與驗收條件。
一份可交付的按鈕設計規範，不能停在「長得像這樣」。設計師要交 variant，工程師要拿到 props 與 token，PM 要能用驗收條件判斷這顆按鈕在真實流程裡是否可用。
| 屬性 | 設計端定義 | 工程端對應 | 驗收條件 |
|---|---|---|---|
| variant | primary、secondary、text、outline、danger | variant |
層級符合任務優先級 |
| size | sm、md、lg 或 dense、default | size |
高度、padding、touch target 符合規範 |
| state | normal、hover、pressed、focus、disabled、loading | CSS state、data attribute | 所有狀態都有樣式與行為 |
| icon | leading、trailing、icon only | icon、iconPosition |
圖示間距固定，icon only 有 accessible name |
| loading | spinner、文字、寬度維持 | loading |
不能重複送出，版面不跳動 |
| block | 是否全寬 | block 或 fullWidth |
只在適合場景使用 |
| type | submit、button、reset 的使用規則 | type |
表單內不誤觸 submit |
| aria-label | 圖示按鈕文字替代 | aria-label |
螢幕閱讀器可理解 |
Figma variant：type、size、state、icon、danger、block
Figma variant 應避免只做幾張靜態樣式圖。建議用 type、size、state、icon、danger、block 組合出可維護的元件。設計稿中還要標注哪些組合不允許，例如 icon only danger button 是否只能出現在表格列更多選單中。
Design token：color、spacing、radius、typography、shadow
Design token 應包含按鈕背景色、文字色、邊框色、hover state layer、focus ring、padding、radius、字級、字重、陰影。token 命名應以語意為主，例如 button.primary.bg，不要直接綁死某個藍色色碼，否則 dark mode 與主題切換會很難維護。
前端 props：variant、size、disabled、loading、type、aria-label
前端元件的 props 應對齊設計規範。常見必要 props 包括 variant、size、disabled、loading、type、aria-label、block、icon。表單內 button 預設 type 要特別小心，否則非送出按鈕可能誤觸 submit。
驗收條件：鍵盤可操作、狀態完整、重複送出被鎖定
按鈕元件驗收不只看截圖。工程交付應確認 Tab 可聚焦、Enter 或 Space 可操作、focus ring 可見、disabled 不送事件、loading 鎖定重複送出、icon button 有 accessible name、danger 操作有確認或復原機制。
按鈕無障礙規範：鍵盤、螢幕閱讀器與焦點狀態
無障礙按鈕必須可被理解、可被鍵盤操作、可被螢幕閱讀器辨識。真正的操作按鈕應使用 button 語意；focus ring 必須可見；圖示按鈕要有 accessible name；disabled、loading、error 不能只靠顏色表示。
無障礙不是最後補檢查清單，而是按鈕規格的一部分。當 focus 被拿掉、圖示沒有名稱、loading 沒有鎖定，受影響的不只螢幕閱讀器使用者，也包括鍵盤使用者、暫時受傷的人，以及在高壓工作情境下操作後台的人。
真正的按鈕應使用 button 語意
執行操作應優先使用原生 <button>。用 <div> 或 <span> 模擬按鈕，會讓鍵盤操作、焦點、語意與螢幕閱讀器支援都變得更脆弱。只有需要前往網址時，才應使用連結語意。
focus ring 必須可見
focus ring 是鍵盤使用者知道目前位置的主要線索。規範應禁止單純移除 outline；若要客製化，必須提供同等或更清楚的替代樣式。focus ring 也不能被 overflow、sticky footer、modal 容器裁切。
圖示按鈕要有 accessible name
只有圖示的按鈕需要可被輔助科技讀出的名稱，例如 aria-label="刪除" 或視覺隱藏文字。tooltip 對滑鼠使用者有幫助，但不一定等同於螢幕閱讀器名稱，因此工程驗收要分開檢查。
disabled、loading、error 不能只靠顏色表示
Disabled 應有語意與原因；loading 應有文字或狀態告知；error 不能只用紅色邊框。可以搭配文字、icon、aria-live、inline message 或 toast。無障礙規範的目標，是讓不同輸入方式與不同感知能力的使用者都能理解目前狀態。
常見錯誤案例：這些按鈕設計會讓使用者猶豫或誤按
常見按鈕錯誤包括雙 primary、點擊區太小、disabled 沒有原因、危險操作太突出、圖示按鈕沒有 label、loading 未鎖定重複送出。修正方式是回到任務優先級、作用範圍與狀態回饋。
按鈕問題通常不是單點錯誤，而是決策、文案、視覺與工程一起鬆掉。把錯誤案例整理進規範，對團隊很有價值，因為設計審稿時能直接指出「這裡會讓使用者怎麼誤解」。
| 錯誤 | 影響 | 修正方式 | 驗收問題 |
|---|---|---|---|
| 同一區塊有兩個 primary | 使用者無法判斷主路徑 | 保留一個主要行動，其餘降為 secondary 或 text | 此刻最重要的下一步是哪一個？ |
| 點擊區太小 | 手機與密集表格容易誤觸 | 增加 touch target 或間距 | 實際可點擊範圍是否達標？ |
| Disabled 沒有原因 | 使用者以為功能壞掉 | 提供提示、說明缺少欄位或權限 | 使用者知道如何讓按鈕可用嗎？ |
| 危險操作太突出 | 提高誤刪或誤停用機率 | 降低預設權重，加上確認或復原 | 最危險的動作是否被過度鼓勵？ |
| 文案過度模糊 | 使用者按下前需要猜結果 | 改成動詞加受詞 | 按鈕是否說出會發生什麼？ |
| 圖示按鈕沒有 label | 新使用者與螢幕閱讀器無法理解 | 加 tooltip 與 accessible name | 不用看圖示也知道功能嗎？ |
| Loading 未鎖定 | 重複送出、重複付款、重複建立資料 | loading 中停用事件並保留狀態提示 | 連點是否只會送出一次？ |
按鈕設計規範最重要的是什麼？
最重要的是狀態、大小與顏色，但不能只看視覺。完整按鈕設計規範還要包含類型層級、文字、位置、無障礙、loading 行為、危險操作與工程交付。可驗收的標準是：使用者知道按下去會發生什麼，工程師知道每個狀態怎麼實作，PM 知道操作風險是否被正確處理。
按鈕開關尺寸應該多大？
若指 UI 裡的 switch 或 toggle，視覺尺寸會依平台與設計系統不同而改變，但實際可操作範圍仍建議至少接近 44 x 44px，行動裝置可抓 44 至 48px 以上。若指硬體開關尺寸，屬於機構與電路設計範圍，不屬於 UI 按鈕規範。
Web 按鈕高度要用 36px、40px 還是 48px？
一般 Web 表單可用 40px 作為預設高度；密集 B2B 後台可用 32 至 36px 的視覺高度，但要保留可操作範圍；行動裝置與主要 CTA 建議 44 至 48px。36px 適合桌機密集介面，48px 適合手指操作或高重要性任務。
iPhone 按鈕形狀一定要圓角嗎？
不一定。iPhone 介面通常會使用符合平台慣例的圓角與足夠 hit region，但重點不是圓角大小，而是按鈕是否容易辨識、容易點擊、狀態清楚。若是跨平台產品，圓角應由設計系統 token 控制，避免每個頁面自行決定。
按鈕和連結有什麼差別？
按鈕用來執行操作，例如送出、儲存、刪除、匯出；連結用來前往另一個頁面、文件或區塊。這個差異會影響 HTML 語意、鍵盤操作與螢幕閱讀器理解。若按下後會改變資料或觸發流程，通常應使用按鈕。
Disabled 按鈕需要說明原因嗎？
需要，尤其在表單、權限控管與批次操作中。只把按鈕變灰，使用者不知道是缺少欄位、沒有權限、狀態不允許，還是系統錯誤。建議在按鈕附近、提示文字或可聚焦提示中說明原因，例如「請先選擇至少一筆資料」。
Loading 按鈕為什麼要鎖定重複送出？
因為重複點擊可能造成重複付款、重複建立資料、重複送出申請或狀態錯亂。Loading 狀態應顯示系統正在處理，並暫時鎖定送出事件。若處理時間較長，還應提供清楚的進度或結果回饋。
一個畫面可以有幾個 primary button？
同一個任務區塊原則上只保留一個 primary button。大型後台頁面可能有不同區塊各自的主要操作，但每個區塊都要能說清楚主路徑。若使用者一眼看到三個同樣醒目的主要按鈕，通常代表資訊架構或流程優先級需要重整。
危險操作按鈕一定要用紅色嗎？
不一定。紅色適合傳達 danger 語意，但危險操作是否做成紅色實心，要看它是不是目前主流程。刪除、取消訂閱、重設等操作通常需要明確文案、確認步驟或復原機制，不應只靠紅色解決風險。
圖示按鈕沒有文字會影響無障礙嗎？
會。只有圖示的按鈕若沒有 accessible name，螢幕閱讀器可能無法說明它的功能。圖示按鈕應提供 tooltip 與 aria-label 或視覺隱藏文字。對高風險操作，圖示旁最好保留文字或放進明確選單中。
B2B 後台表格裡的按鈕可以做比較小嗎？
可以，但要區分視覺尺寸與實際操作範圍。桌機後台表格中的按鈕可用 32 至 36px 視覺高度，搭配足夠列高、間距、tooltip 與鍵盤操作。刪除、停用等危險操作不建議直接放成醒目的小紅按鈕，應加上確認或收進更多選單。
FAB 懸浮按鈕適合用在哪些情境？
FAB 適合行動裝置或 App 中的全局主要行動，例如新增、撰寫、建立。它不適合承載多個操作，也不適合遮住表格、表單或重要內容。B2B 後台若已有工具列與主要按鈕，通常不需要再加 FAB。