安安～我是ChiYu～

昨天把 Breadcrumb、Stepper、Pagination 和完成進度分開後，我總算不會再用一條藍線回答所有問題。接著進入工作區設定，畫面又送來一排整整齊齊的 Tabs。

當時我留給 AI 的需求只有一句：

把設定頁內容分區，畫面做得精簡一點。

下面是依這句需求重建的第一版，不含真實資料：

圖 1：同一排放了八個 Tab，現在只顯示一般設定；另外七類內容全得靠使用者逐一打開尋找。

AI 很俐落。一般設定一個 Tab、成員權限一個 Tab、雙重驗證一個 Tab、資料保留說明一個 Tab，連列表、看板和行事曆也排成一列。

原本塞滿內容的設定頁確實變短了，代價是每一段內容都得先躲起來。

操作幾次後，問題開始跑出來：

• 為什麼雙重驗證和資料匯出規則不能同時打開比較？
• 資料保留明明只是一小段補充，為什麼要切走整個面板？
• 列表和看板只是同一批專案的不同看法，怎麼長得像在切換網站頁面？

這些內容都會「切換」或「收合」，關係卻完全不同。只寫「做成 Tabs，畫面乾淨一點」，AI 會很努力替每一段內容找地方藏，卻不會自動知道哪些內容互相平行、哪些需要同時閱讀。

我把四種關係放進 Tabs、Accordion、Disclosure、Segmented Control 完整比較頁：

圖 2：一般設定、進階規則、補充說明與檢視模式都能被切換，但它們不該全住進 Tabs。

先說出內容關係，再決定要切換還是收合

有一個很好用的反向檢查：兩塊內容如果需要同時閱讀或同時修改，就不要為了「看起來乾淨」把它們關進互斥的 Tab。

乾淨是畫面結果，內容關係才是元件選擇的原因。

如果還在兩個候選之間猶豫，可以沿著這張圖往下判斷：

圖 3：先問內容是平行、分段、補充，還是同一批資料的檢視模式，再決定切換或收合。

這張圖不是把四條路導向四種造型，而是先確認內容關係。只要所有答案最後都通往 Tabs，需求大概還停在「幫我藏起來」這一層。

切換元件不只顯示或隱藏，還要保存自己的狀態

內容被藏起來後，資料並沒有因此消失。每種元件都要先決定：切換前的輸入、目前選取與錯誤狀態要不要保留？

這些規則不一定要用相同方式保存，但不能交給 AI 臨時猜。切換只是畫面動作；切換後使用者原本做到哪裡，才是產品行為。

平行面板用 Tabs：按下 End 後，四個位置要一起換

Tabs 元件頁使用「一般設定、成員與權限、通知」三個同層級面板。這些內容沒有先後依賴，先看通知或先看一般設定都不會破壞任務。

圖 4：選到「通知」後，Tab 的選取狀態、下方面板、狀態文字與焦點要一起更新。

一個 Tab 對應一個 tabpanel。目前項目使用 aria-selected="true"，下方內容也要跟著換。只有藍色底線從「一般設定」滑到「通知」，面板還在顯示成員權限，那不是切換，只是底線自己出去散步。

我先把焦點放在「一般設定」，再按 End。接著對照四個位置：

四個結果一起同步，Tab 和 Tabpanel 才真的綁在一起。

Tabs 的鍵盤行為還要先決定自動或手動啟用。LumenDesk 三個面板已在本機載入，因此方向鍵、Home、End 移到新 Tab 時會直接換面板。內容若要等 API 回來，我會改成手動啟用：先移動焦點，再由使用者按 Enter 或 Space 決定是否載入。W3C 也只建議在面板能無延遲顯示時使用自動啟用。W3C WAI：Tabs Pattern

遠端載入還會多一層狀態：第一次打開時顯示 Loading，失敗時讓目前面板重試，切走再回來是否沿用快取也要先決定。不能每按一次方向鍵就重新呼叫 API，讓鍵盤導覽順便變成壓力測試。

面板裡若有尚未儲存的表單，切換 Tab 後要保留輸入；真的準備丟棄內容時，應明確提醒，而不是因為面板不可見就當作資料可以一起清掉。

昨天的四步驟申請則不適合 Tabs。申請人資訊填完才走到權限設定，內容有先後依賴，應交給 Stepper。

需要比較的長段落用 Accordion；一小段補充才用 Disclosure

Accordion 允許多段一起打開

工作區的邀請限制、雙重驗證與資料匯出設定都是完整段落。有人只想查看其中一段，也有人需要把兩段規則一起攤開核對，因此 Accordion 元件頁允許多段同時展開。

圖 5：手機版維持單欄閱讀，兩段進階規則也能同時展開，不會互相把對方關掉。

每段標題要有合適層級的 Heading，Heading 裡再放完整可操作的 Button；展開時更新 aria-expanded，並用 aria-controls 對應內容區。箭頭只是狀態提示，不能縮成唯一可點的地方。

一次只能開一段，還是能同時開很多段，要由內容決定。這次需要比對規則，所以允許多段展開；若打開新內容會讓前一段失去意義，才適合互斥。W3C 的 Accordion Pattern 沒有規定所有 Accordion 都必須玩打地鼠。W3C WAI：Accordion Pattern

必要欄位與錯誤訊息不要藏進收合區。使用者連「哪裡填錯」都得先猜該展開哪一段，表單只會更短，不會更好修。表單送出失敗時，包含第一個錯誤的段落至少要自動展開，或由摘要提供能展開並定位的路徑。

收合也不應清空段落裡尚未送出的資料。Accordion 在整理閱讀空間，不是在替表單執行 Reset。

Disclosure 只在原地補一段說明

資料保留期限旁邊只有一段方案說明，不需要為它切走整個設定面板。Disclosure 元件頁在原位置放了一個「顯示資料保留說明」，需要時再展開。

圖 6：補充文字在目前設定旁展開，讀者沒有被送到另一個面板。

Disclosure 適合定義、備註或一小段規則。內容簡單時，原生 <details> 與 <summary> 已經能提供鍵盤可用的展開／收合，不必急著自己重做整套控制。MDN：<details>

它和 Accordion 的差別不只在數量。Disclosure 是主要內容旁的可選補充；Accordion 則組織幾段相對完整、可獨立閱讀的內容。當 Disclosure 裡開始塞 FAQ、三組安全設定和一張資料表，它已經不是補充，根本是偷偷搬了一間套房進去。

反過來，會影響使用者決策的必要規則也不應只躲在 Disclosure 裡。若使用者不展開就可能填錯或誤解後果，那段資訊應直接留在主要內容，Disclosure 只補充細節。

同一批資料換看法，交給 Segmented Control

專案仍是同一批，只是有時想看列表，有時需要看板或行事曆。Segmented Control 元件頁把三種檢視放在資料旁邊，切換後立刻更新附近內容。

圖 7：列表、看板與行事曆共用同一批專案資料，改變的是觀看方式。

HTML 沒有一個叫 Segmented Control 的原生元素，所以規格要先選語意模型。LumenDesk 的三種檢視一次只能選一種，這次採單選 Radio Group：方向鍵移動時一併改變選取模式，附近資料也立即更新。W3C WAI：Radio Group Pattern

只讓「看板」外觀變藍，下方繼續排著列表，和剛才只會散步的 Tab 底線是同一個問題。若控制項其實在執行粗體、對齊或排序命令，則應改用 Button／Toggle Button 模型，不要看見膠囊外觀就一律塞進 Radio Group。

切換檢視時，搜尋字、篩選條件與目前選取的專案通常仍應保留，因為資料沒換，只是看法不同。若看板不支援列表的某項狀態，也要明確交代如何轉換，而不是默默把條件清空。

產品如果希望使用者分享「看板檢視」或重新整理後維持原模式，可以把檢視寫入 URL 或偏好設定。這是產品決策，不是 Segmented Control 自帶的能力；至少要避免畫面顯示看板，網址與重新整理結果卻永遠回到列表。

Segmented Control 適合少量、名稱短而且互斥的模式，不適合全站導覽。選項變多、名稱變長，或開始出現上下層關係時，這排控制很快就會變成被壓扁的 Navbar。Material Design 3：Segmented button

改寫 Prompt：不要只告訴 AI「把內容藏起來」

為 LumenDesk 工作區設定頁設計內容切換方式。請依內容關係選元件，不要把所有內容都做成 Tabs。

1. Tabs：一般設定、成員與權限、通知是三個同層級面板。選取狀態與可見面板同步。三個面板已預先載入，因此採自動啟用：Tab 進入目前項目，左右方向鍵、Home、End 移動焦點時也同步切換面板；若日後改成遠端載入，改採 Enter 或 Space 手動啟用，並提供 Loading、Error 與重試。切換面板時保留尚未送出的輸入，不可因面板隱藏而重設資料。這不是填表流程。

2. Accordion：邀請限制、雙重驗證、資料匯出設定是可獨立閱讀的長段落。每段使用符合頁面層級的 Heading，Heading 裡放帶有 aria-expanded 與 aria-controls 的 Button。本案例允許同時展開多段，方便比對規則；收合不得清空輸入。不要把必要欄位或錯誤訊息藏起來，送出失敗時要能展開並定位到問題段落。

3. Disclosure：在資料保留設定旁放「顯示資料保留說明」。展開後只顯示一段保留期限文字，留在原位置；優先使用 details／summary。完成任務不可缺少的規則直接顯示，不要藏在 Disclosure 裡。

4. Segmented Control：以列表、看板、行事曆切換相同專案資料的局部檢視。使用有名稱的單選 Radio Group，一次只選一種模式；方向鍵移動時同步更新目前模式文字與附近資料預覽。切換時保留搜尋、篩選與可相容的選取狀態；若需要分享或重新整理後保留模式，將目前檢視寫入 URL 或偏好設定。不要拿它當全站導覽。

360px：所有操作保留完整文字；Tabs 可在自己的列內捲動，但整頁不能水平溢出；Accordion 與 Disclosure 維持單欄閱讀。

交付前，我不只輪流點一遍，而是沿著四種承諾操作：

1. 在一般設定填入尚未儲存的值，再用左右方向鍵、Home、End 切換 Tabs，確認焦點、選取、面板與資料都沒有各走各的。
2. 同時展開兩段 Accordion，收合後再打開，確認內容能一起閱讀，輸入與錯誤狀態也還在。
3. 展開再收合 Disclosure，確認主要設定沒有跟著消失，而且必要規則不必展開才看得到。
4. 從列表切到看板、再切到行事曆，確認模式文字、資料預覽、搜尋與篩選一起保留。

畫面變短不等於內容變清楚。這四條路走得通，精簡才有意義；否則只是把內容藏起來，讓使用者自己尋寶。

內容關係整理完，三點選單又把資料值和命令排在一起

工作區設定現在各自有位置：平行面板使用 Tabs，能同時比較的長段落交給 Accordion，一小段補充由 Disclosure 原地展開，列表、看板與行事曆則用 Segmented Control 切換同一批資料。

我回到專案列表，最後一欄只放了一顆三點按鈕。展開後依序出現「進行中、編輯、刪除」。

圖 8：「進行中」會保存資料，「編輯」和「刪除」則會立刻執行命令；第一版卻讓三個項目共用同一種外觀。

三個項目排得很整齊，問題也藏得很整齊。使用者按下 Enter 前，根本看不出這次是在替任務選狀態，還是在對資料下命令。

明天就從這顆三點按鈕繼續，把「保存一個值」與「執行一件事」分開。

延伸閱讀

• W3C WAI：Tabs Pattern
• W3C WAI：Accordion Pattern
• MDN：<details>
• W3C WAI：Radio Group Pattern
• Material Design 3：Segmented button

資料查閱：2026-08-07。