先判斷答案應否摺起
常見問題頁常用來減少查詢，但收起的答案仍要求顧客先辨認正確問題，再啟動控制項。設計應從真實任務開始，而非先挑元件。若只有數條簡短答案，直接顯示標題與段落，可能更易瀏覽、引用和列印。問題多而互不依賴時，展開控制項尤其可減少手機畫面的長距離捲動。W3C 的摺疊欄模式亦指出可藉此減少捲動，但內容的發現方式會改變。不要只為令頁面看起來短一點，就把價格、資格限制或安全說明藏起來。
問題標題要用顧客會說的字眼，每個標題回答一項決定。「付款後可否修改送貨地址？」比「送貨資訊」更能預示答案。每個內容區先給簡短結論，再列條件和下一步。若兩條問題實際得出相同答案，可合併或清楚交代差別；重複內容會增加日後更新時互相矛盾的風險。即使所有答案都收起，重要聯絡途徑也應清楚可見。不確定哪題適用的顧客，不應被迫打開十多個區塊，才找到基本求助方法。
開發前先決定互動規則。顧客可否同時打開幾條答案作比較，還是打開下一條便會關閉前一條？若答案彼此相關，容許多條同時展開可能更方便。若業務選擇只留一條開啟，就要說明並測試，不應當作元件的必然預設。MDN 記載可讓多個 details 元件使用同一個 name，形成只開一條的組合；但採用哪種方式仍是內容與體驗決策。團隊亦應決定連到某一答案的網址會否自動展開內容，以及進入頁面後焦點應落在哪裏。
選擇原生展開元件或自訂控制項
對簡單而獨立的問題，原生 HTML details 配合 summary 已提供展開元件。MDN 說明 summary 是可見標籤，而 open 屬性決定內容是否顯示。這可減少商店自行維護的狀態程式碼，但仍須在目標瀏覽器測試焦點外觀、間距、翻譯及區內內容。原生標記不會自動解決所有產品選擇。open 是布林屬性；把屬性寫成看似 false 的文字並不能安全地關閉內容。關閉時應移除該屬性，而不是替它填入「假」字。
若設計需要原生 details 無法在目標使用環境穩定提供的行為或結構，可採用自訂摺疊欄。這時應在合適層級的標題內使用真正的 button，不要把一般 div 做成可點擊區，或拿沒有導覽目的的連結充當按鈕。W3C 摺疊欄模式要求按鈕反映展開狀態，並以 aria-controls 指向相應內容區。標題層級須配合整頁架構，不能因為可互動便把每題都升為最高層標題。按該模式實作時，標題內只放控制按鈕，其他獨立操作應放在旁邊，不要塞入標籤。
自訂元件的視覺狀態與程式狀態必須同步。內容區打開時，aria-expanded 應為 true；關閉時應為 false，實際可見性也要一致。箭頭圖示可輔助表示狀態，卻不能獨力承載意思，因為屏幕閱讀器未必讀到圖示，部分顧客也未必理解箭頭方向。視覺上已隱藏的內容區，不能留下仍可用 Tab 鍵到達的連結或表格控制項。若設計規定只剩一條打開時該條不可關閉，W3C 模式亦描述了該標題的 aria-disabled 狀態。
讓鍵盤操作可以預期
W3C 的摺疊欄模式以 Enter 或 Space 啟動目前聚焦的標題，Tab 則按網頁正常次序移往可聚焦元素。某些自訂摺疊欄可額外提供方向鍵捷徑，但不能以此取代基本 Tab 導覽。顧客應能到達問題、理解它可以展開、啟動後再進入答案內的連結或控制項。沒有具體理由，不要打開答案便自動把焦點移入內容區；突如其來的焦點轉移會使閱讀次序難以跟隨。每個狀態下，都要讓真正控制項的焦點位置清楚可見。
實際測試應從第一條問題之前開始：在頁首只用鍵盤操作，順序移到每個問題按鈕，打開一條，進入答案中的連結，再返回並關閉。用 Shift 加 Tab 核對逆向路線。若打開一條會關閉另一條，要觀察焦點本來在被關閉內容區時會發生甚麼；用戶不應被留在隱藏內容內。再於高倍率縮放及狹窄畫面重試，因為展開後的內容可能超出可視範圍。檢查捲動行為是否幫助讀者找到答案，同時保留目前問題的脈絡。
屏幕閱讀器測試不應只看答案最終有否出現，還要聽控制項的名稱、角色及展開或收合狀態。先以標題導覽，檢查問題的層級與整頁其他部分是否協調；再啟動一題並讀完整個答案。若內容區包含次標題、連結或清單，朗讀次序應與可見次序相符。W3C 模式容許某些內容區使用 region 角色，但也提醒當很多區塊可同時打開時，過多地標會妨礙導覽。這項可選結構只應在確實改善使用時採用，並以實際輔助技術檢查。
把答案當作持續維護的內容
以送貨常見問題為例，三題分別問何時寄出、能否更改地址，以及包裹延誤時應聯絡誰。若三個答案都各自有用，容許同時打開會方便顧客比較時間與例外。每條答案開頭先給決定性一句，再解釋條件和聯絡途徑。速遞安排若改變而影響三題，應由指定負責人同時更新。把內容摺起並不會減少核對來源的責任；相反，快速視覺審閱時，隱藏的過期條件可能更難被發現。
直接連結和列印是另外兩項任務。客服人員可能傳送「更改地址」問題的連結；顧客到達後，應有足夠脈絡找到並讀取答案。若元件無法穩定打開連到的區塊，可考慮提供直接可見的答案頁或更簡單的連結目標。若員工或顧客會列印常見問題，列印版不應在不知不覺間漏掉所有收起的答案；應測試列印畫面，決定是否在列印時全部展開。這些都要在實際網站驗證，不能因元件名叫「摺疊欄」便假設行為已自動具備。
驗收應同時檢查內容與互動。請一位不熟悉實作的同事先以滑鼠，再以鍵盤，並在條件許可時以屏幕閱讀器尋找指定答案。觀察對方預期答案在哪裏，以及標題是否準確描述內容。若障礙在用字或排序，就修改內容；若障礙在控制項語意或狀態，就修改元件。記錄測試時的瀏覽器、畫面闊度和輔助技術，日後改版才有真實基準可比較。有用的常見問題頁，應讓顧客辨認問題、打開答案、理解條件，並知道下一步如何行動。
進行前先確認
- 重要條件若直接顯示，會否更容易找到？
- 兩種語言的控制名稱、標題、展開狀態及內容可見性是否一致？
- 顧客能否按需要以鍵盤、屏幕閱讀器、直接連結及列印完成查閱？
