一排收納櫃的抽屜，如果每一格同時都拉開，你反而得在滿地雜物裡翻找半天才找得到要的那雙襪子。多數人做 FAQ 手風琴設計時，犯的正是類似的誤會，以為做出「點一下展開、收合」的效果就算完工，隨手套一個現成樣式或抄一段程式碼就上線。但真正決定訪客會不會把整頁 FAQ 看完的，往往是幾個很少被講清楚的細節，展開的動畫夠不夠順、圖示夠不夠明顯讓人知道可以點、螢幕閱讀器唸出來的到底是「已展開」還是什麼都沒說。
這篇要拆的正是這個元件本身——訪客眼睛看到的樣子、手指點到的手感、螢幕閱讀器唸到的內容。跟它完全不同層次的，是讓 Google 讀懂 FAQ 內容、在搜尋結果多長出一塊摘要的結構化資料標記，那是另一篇該談的題目，這篇只談介面設計本身。
先從手風琴實際在解決什麼問題講起，再一路拆進每一個非做不可的設計判斷。
答案全部攤開，訪客看到一半就關掉分頁
把二十則退換貨問題一次全部攤在頁面上，訪客通常滑到一半就已經放棄往下讀，這是多數 FAQ 頁面最後都選擇把答案收合起來的原因。根據 Nielsen Norman Group 針對桌面版手風琴的研究，收合內容最大的好處是降低認知負荷：訪客一次只需要面對眼前這一則問答，不必應付一整頁滾動不完的文字牆，頁面也顯得更容易掃視。
不過同一份研究也老實列出代價。當好幾則資訊分散在不同面板裡，訪客很難互相對照；每展開一次都多一次點擊的互動成本；而收起來的內容，有一部分訪客根本連點都不會點，等於完全被忽略。這些代價都是選擇手風琴之前該先想清楚的事，不是做了才發現。
UX Patterns for Developers 這份整理各家實作經驗的指南，給出更明確的判斷準則。如果 FAQ 裡每一則問答彼此獨立，訪客通常只想找到自己關心的那一題，其他題碰都不會碰，這種情境手風琴最合適；但如果內容本身很簡短，或者訪客需要同時比對好幾則才能做決定，例如收費方案的條款差異這種需要逐條對照的內容，直接攤開反而比收合更好讀，硬套手風琴只是多一層沒必要的點擊。
換句話說，FAQ 要不要用手風琴，答案不是「當然要」，而是先看內容彼此獨不獨立、需不需要一次看到全部再決定。
FAQ 手風琴要做對，得先想清楚這幾個決定
決定要用手風琴之後，接下來六個 FAQ 手風琴設計的判斷不分先後順序，但每一個都直接影響訪客會不會把 FAQ 看完、螢幕閱讀器使用者能不能正常操作。
要不要讓第一則 FAQ 預設先展開？
多數 FAQ 頁面預設把所有問答都收合，版面最乾淨，也不會讓訪客一打開頁面就被大量文字壓迫。但 UX Patterns for Developers 對「預設展開行為」的建議是，如果第一則問題是使用頻率最高、訪客最需要立刻看到的資訊，像退換貨這種關鍵條件，讓它預設先展開能省下訪客一次多餘的點擊。判斷的關鍵只有一個，這則內容夠不夠重要，重要到值得犧牲一點版面的乾淨感。
同一份指南也提醒一致性的重要。同一頁裡不要有的問答預設展開、有的維持收合，訪客會搞不清楚這個頁面的規則到底是什麼，反而增加認知負擔。要嘛全部收合，要嘛只讓真正重要的那一兩則展開，別讓規則自相矛盾。
該一次只能開一則，還是同時開好幾則？
手風琴的互動模式分成兩種。single-active 展開一則會自動收掉其他已展開的內容，適合需要讓訪客聚焦單一任務的情境，例如一份分成好幾步驟的表單，一次只處理一個步驟比較不容易分心；multi-active 則可以同時展開好幾則，彼此不互相影響。
FAQ 的情境通常比較適合後者。Nielsen Norman Group 建議讓訪客可以同時展開多則問答，方便交叉比對不同題目的答案；如果問題數量夠多，也可以加一組「全部展開」與「全部收合」按鈕，讓訪客一次看完所有內容或方便列印。Smashing Magazine 進一步指出一個容易被忽略的細節，當問題項目多到一定程度，如果每展開一則就自動收掉別則，畫面會一直跳動，掃視起來反而吵，這種情況下讓已經展開的內容維持原狀、不自動收合，閱讀體驗會穩定得多。
這兩種模式在鍵盤操作上也不完全一樣。W3C 的 WAI-ARIA 設計模式規格裡，單開與多開兩種實作方式在鍵盤互動細節上各有規定，實作前值得對照著查，別憑感覺自己兜一套。
用什麼圖示，訪客才看得出可以點開？
圖示是告訴訪客「這裡可以點」最直接的訊號。Nielsen Norman Group 找了 136 位受測者測試手風琴圖示，結論是尖角的 chevron（caret）最符合使用者預期，也是最安全的選擇，明顯比完全不放圖示更能讓訪客知道點下去會就地展開；至於加號或箭頭，實測下來並沒有比不放任何圖示更好。換句話說，真要挑一種圖示，chevron 幾乎是唯一穩妥的答案，加號、箭頭則不見得有加分。
圖示放的位置也有慣例可循。Smashing Magazine 整理的做法是把圖示放在標題文字的尾端而不是前面，訪客的視線會先讀到問題本身，圖示只當補充線索。這也帶出一個容易被忽略的細節，標題長短不一時，尾端圖示很容易對不齊，排版前要先確認好對齊規則。圖示本身也該留夠大的可點擊範圍，Smashing Magazine 建議至少要有44 乘 44 像素，手指才點得準。
最後還有一點容易被跳過，圖示不能是唯一的線索。展開與收合的狀態，除了圖示要跟著轉動方向之外，最好搭配標題文字或底色一起變化，免得看不清楚圖示細節的訪客完全抓不到現在是開還是關。
展開收合的動畫要多快，才不會讓人等？
展開收合的動畫，原則其實很簡單，重點是要滑順，但不能讓訪客等。UX Patterns for Developers 對動畫互動的建議是，圖示要跟著展開或收合的狀態一起轉動，而不是瞬間切換方向，讓訪客感覺得到自己剛剛做了什麼；同時也要尊重「減少動態效果」這項作業系統層級的使用者偏好，對開啟這項設定的訪客，動畫該收斂或直接關掉，不能強迫所有人都看同一套效果。
技術上，2025 年之後有一件事值得留意。CSS 新增的 ::details-content 偽元素，加上 interpolate-size 屬性，讓原生的 <details> 元素也能做出高度從零平滑滑到全開的展開動畫，不必再靠 JavaScript 去量測內容實際高度、再手動設定數值。這對想用原生 details 元素、又想要動畫效果的人是一個好消息。
不過目前這套能力還沒有全面普及。完整順暢的效果目前只有 Chromium 系列瀏覽器支援，Firefox 與 Safari 是直接跳開、沒有中間過程。也就是說這是一種漸進增強，能跑動畫的瀏覽器多一層體驗加分，不支援的瀏覽器內容一樣正常展開收合，只是少了滑順的過程，並不影響功能本身。
手風琴該用 HTML 原生的 details 元素，還是自己刻 JavaScript？
手風琴在技術上有兩條可以走的路。第一條是直接用 HTML 原生的 <details> 與 <summary> 元素，瀏覽器內建展開收合的行為與鍵盤操作，不必自己寫一行 JavaScript，程式碼也精簡很多；缺點是樣式彈性比較低，而且原生 details 預設不會提供 aria-expanded 這類明確的狀態屬性，部分螢幕閱讀器不會主動唸出目前是展開還是收合。第二條路是自己刻一顆 button 搭配 ARIA 屬性，樣式完全可以照設計稿走，每個狀態都能精確控制，只是鍵盤互動與狀態管理都得自己動手寫、自己測試。
原生 details 元素最近有一項值得留意的新進展，details 新增了一個 name 屬性，只要讓好幾個 details 用同一個 name 分成一組，就會變成「同名互斥」的手風琴，展開其中一個，其他同名的會自動收合，完全不必再自己寫 JavaScript 去判斷互斥邏輯。程式碼大致長這樣：
<details name="faq-group">
<summary>退換貨的期限是多久?</summary>
<p>收到商品後 7 天內可申請退換貨。</p>
</details>
<details name="faq-group">
<summary>運費怎麼計算?</summary>
<p>滿一定金額免運,未滿則依重量計價。</p>
</details>Code language: HTML, XML (xml)這項能力 Chrome 與 Safari 從 2023 年底就開始支援，Firefox 到 2024 年下半年也跟上腳步，主流瀏覽器已經到齊。判斷該走哪條路可以看兩個條件：內容單純、不需要高度客製化的視覺樣式，原生 details 搭配 name 屬性最省事；網站已經有一套既定的設計系統、需要精細控制每個狀態的視覺呈現，自訂 button 搭配 ARIA 屬性會是比較務實的選擇。
螢幕閱讀器唸得出「已展開」，還是只有你自己看得懂？
不管走原生 details 還是自訂 button 這條路，最終都要確保螢幕閱讀器使用者聽得懂這個元件在做什麼。W3C 的 WAI-ARIA 設計模式規格，對手風琴列出四個核心屬性。aria-expanded 裝在觸發按鈕上，用 true 或 false 標示目前是展開還是收合；aria-controls 指向被控制的內容區塊 id，讓輔助技術知道按下去會影響哪一塊；aria-labelledby 則反過來，讓內容面板知道自己對應的是哪一個標題。觸發元件本身也該用真正的 <button> 元素，而不是隨便一個 <div> 掛點擊事件，button 天生就能用 Tab 鍵聚焦、用 Enter 或 Space 鍵觸發，不必自己再補一段鍵盤事件的程式碼。
LogRocket 部落格整理這幾個屬性時特別提醒一個很少被注意到的細節，收合起來的內容要用 hidden 屬性讓它真的從畫面上消失，而不是只靠 CSS 把它藏起來。只用 CSS 隱藏的話，鍵盤使用者按 Tab 還是可能碰到那些看不見的連結或按鈕，螢幕閱讀器也可能唸出根本看不到的內容，反而造成混亂。另外，每一則問題的標題也該包在對應階層的標題標籤裡，例如 <h3>，這樣螢幕閱讀器使用者才能用標題導覽功能直接跳到自己想看的那一題，不用整頁從頭聽到尾。
上線前，用這張清單再檢查一次
前面六個判斷做完，上線前還有幾個容易漏掉的地方值得再檢查一次。
第一個是別把關鍵資訊藏進手風琴裡。Nielsen Norman Group 特別提醒，退換貨期限、聯絡方式這類訪客急著要用的資訊，不該收在需要點擊才看得到的面板裡，這種內容該直接露出在頁面上，手風琴留給真正屬於補充說明的問答。
第二個是圖示對齊的一致性。前面提過標題長短不一時圖示容易對不齊，上線前最好把整組 FAQ 攤開來看一次，確認每一則的圖示都落在同一條垂直線上，不會因為某幾則標題特別長就跑版。
第三個常被漏看的是列印情境。收合起來的內容，預設印不出來，如果訪客習慣把整頁 FAQ 印下來留存，常見於保固條款、退換貨政策這類頁面，就得準備一顆全部展開按鈕，或者另外寫一份專門給列印用的樣式，確保收合的內容在列印時能完整呈現。
最後回到最基本的一致性原則，整頁的手風琴行為要一致，不要這一區塊預設展開、那一區塊預設收合，讓訪客猜不透這個頁面遵循什麼規則。這條看似最簡單，卻是最容易在改版、加內容的過程中被悄悄破壞的一條。
手風琴做對了，是幫訪客省力氣，讓他一次只需要面對眼前這一題；做錯了，只是把答案藏進看不見的地方，假裝問題已經解決。FAQ 手風琴設計最容易被誤解的地方，在於它看起來像一個純視覺的小元件，實際上每一個互動細節都在替訪客做決定。
先把這些決定做對，排版與視覺風格才輪得到上場。順序顛倒過來，再漂亮的介面，也只是一座好看的抽屜櫃，拉開來還是一團亂。