Hide only genuinely optional detail, use an implementation whose semantics match its behaviour, and verify open state, keyboard operation and access to the answer in the public page.
An FAQ accordion should help readers locate optional detail, not hide the information they need to make a decision. Choose what belongs behind each disclosure before styling the arrow. Then check that its actual open state, controls and reading order agree.
Consider a fictional community studio with questions about arrival, borrowing tools and changing a booking. Its answers below are editorial examples, not published studio policies. The goal is to design an understandable interaction, rather than to make the shortest possible page.
Decide which information should remain visible
If every visitor must know an arrival deadline or safety requirement, place that essential fact in the main explanation. A question labelled “Anything else?” is a poor sole location for a condition that changes whether someone can attend.
Use disclosures for secondary detail that readers can identify from a meaningful question. “Can I borrow tools?” tells the studio visitor which answer to open. Several triggers labelled “More information” create work without explaining the distinction.
If there are only two short answers, ordinary headings and paragraphs may already be clearer. If questions have grown into long independent procedures, a linked guide may be easier to maintain. Collapsing a collection does not resolve unclear writing or an unmanageable information structure.
Identify native disclosure versus custom accordion
MDN’s details reference describes the native disclosure element, with summary as its visible trigger. Its open attribute is boolean: writing open=”false” still leaves the attribute present. Remove the attribute to represent a closed initial state, rather than relying on that text value.
For a simple answer, native behaviour can reduce the custom interaction code to maintain. A custom accordion may instead be supplied by a maintained theme or block with a defined heading-and-panel structure. Identify which implementation the site already uses before adding a second script to manage it.
Do not treat every expandable surface as a modal dialog or a set of tabs. Opening the studio’s borrowing answer should reveal the answer in the reading flow. It should not impose a focus trap merely because the design draws a border around the panel.
Give the trigger one understandable job
MDN’s summary documentation notes browser differences in the semantics exposed for its children. In particular, placing a heading inside summary is not a guarantee that every platform presents that child as a heading. Review the structure in the combinations your site supports.
Keep the trigger descriptive and avoid nesting competing interactive actions inside it. Put an answer’s external link or booking action in the expanded content, with its own purpose and focus position. A visitor should not have to guess whether clicking the question opens detail or leaves the page.
Use a visible open/closed indication that remains understandable beyond one colour. Retain a clear focus indication. If a decorative icon is changed, verify that the question’s usable name and state have not become a repeated “plus plus” announcement.
Implement the custom pattern as a whole
The WAI-ARIA Accordion Pattern uses a button in an appropriately levelled heading, expanded state and a relationship to its panel. Enter or Space operates the header button; ordinary Tab movement reaches available controls. Some additional navigation keys are optional pattern choices.
For a custom studio FAQ, ask who maintains those relationships as items are reordered or duplicated. Unique, correct target relationships matter more than a screenshot of the expanded panel. A button claiming expanded while the answer stays hidden gives inconsistent information.
Native details has its own semantics. Do not copy every custom-pattern role and attribute onto it without understanding the resulting behaviour. Likewise, a styled text container does not become a complete custom control merely by receiving one ARIA property.
Choose one-open or multiple-open deliberately
A reader comparing borrowing rules with arrival arrangements may benefit from keeping both answers open. A compact set of mutually exclusive alternatives may suit one-open behaviour. The choice should reflect the task rather than a preference for uniform card heights.
Native details can use a shared name for a one-open group, with support to verify. In a custom component, use its supported coordinated-state option. Check what happens to the reader’s position when a long earlier answer closes; the selected question should remain easy to find.
| Reader task | Possible choice | Acceptance concern |
|---|---|---|
| Compare two related conditions | Allow both answers open | Each state remains identifiable |
| Read one optional explanation | Independent disclosure | Opening does not steal focus |
| Review a required instruction | Visible main-page content | No hidden prerequisite |
| Follow a long procedure | Dedicated linked guide | A clear route back to context |
Configure the editor’s real component
Current WordPress Accordion block documentation describes an accordion containing item headings and panels, with settings for opening behaviour. Inspect the installed editor and intended result; control labels and availability are version-dependent. An older installation may not offer the same native block.
Use List View or the editor’s equivalent to select the correct level. A collection setting and one item’s initial state are different decisions. After saving, open the public page and confirm the answer text, heading levels and state, rather than relying on editor-only expansion.
Keep existing content recoverable when converting a layout. Compare each old answer with the saved new answer and its links. A conversion that looks tidy while dropping the second paragraph is not an acceptable presentation change.
Review discovery, printing and keyboard continuation
- Read all visible questions before opening anything; each should identify its answer.
- Use the keyboard to open and close each supported trigger.
- Enter an answer’s links, then continue to the next meaningful control.
- Close or coordinate panels and verify no hidden link remains an invisible stop.
- Check long questions, narrow layouts and enlarged text.
- Review browser Find, direct section entry and printing in the supported browsers.
- Use a relevant screen reader to inspect names, state and reading order.
Do not assume every browser’s Find or print behaviour exposes collapsed content in the way you intend. If a printable policy must include every condition, provide and verify that complete presentation. Compare the printed answers with the saved page after a content revision, especially when an answer contains a list or a second paragraph. Disclosure markup alone is not an indexing, ranking or rich-result promise.
Keep a small record of the tested component and its limitations. The dialog guide covers temporary overlays, while the text and zoom review helps assess wrapped answers. A useful FAQ succeeds when the right answer is discoverable and operable, with essential information still easy to find.
Sources and verification
Editorial review 2026-10-15. Source check dates are recorded separately. Notes describe what each source supports and its limits.
View sources
- MDN: details elementChecked Native disclosure, boolean open state and optional named grouping.
Limits: Grouped behaviour and styling need checking in supported browsers; this is not the custom ARIA accordion pattern. - MDN: summary elementChecked A descriptive native disclosure trigger and browser differences in semantics of children.
Limits: Adding a heading inside summary does not ensure that every platform exposes that child as a heading. - W3C APG: Accordion PatternChecked Custom accordion header buttons, expanded state, panel relationships and keyboard responsibilities.
Limits: The pattern is implementation guidance requiring real testing, not attributes to add indiscriminately to native details. - WordPress: Accordion blockChecked Current native block structure and settings for initial and coordinated opening behaviour.
Limits: Available controls and labels depend on the installed version; inspect actual output rather than assuming every older editor includes this block.