Decide whether answers should collapse
An FAQ page is often written to reduce support enquiries, but a collapsed answer still requires the customer to recognise the right question and activate its control. Start with the real task, not a component catalogue. If the page has only a few short answers, visible headings and paragraphs may be easier to scan, quote and print. A long list of independent questions may benefit from disclosure controls, especially on a narrow screen. An accordion can reduce scrolling, as the W3C authoring pattern notes, but it also changes how people discover content. Do not hide prices, eligibility conditions or safety instructions merely to make the page look shorter.
Write questions in the words customers use, with one decision per heading. “Can I change the delivery address after payment?” is more useful than “Delivery information” because it signals what the answer resolves. Keep a short answer near the top of each panel, then add conditions and the next action. If two questions lead to the same answer, consolidate them or explain the distinction; duplication creates conflicting maintenance points. Important contact routes should remain obvious even when every panel is closed. A customer who is uncertain which question applies should not have to open a dozen panels to locate a basic help option.
Choose the interaction rule before development. Can several answers stay open so a customer can compare them, or does opening one close the previous one? If the answers refer to one another, allowing more than one open may support comparison. If the business requires a single open panel, explain and test that behaviour rather than assuming it is the default. MDN documents that grouped details elements can be given the same name to create an exclusive accordion, but the choice remains editorial. The team should also decide whether a link to a particular answer opens that answer and where focus lands after the page follows the link.
Choose native disclosure or a custom control
For a straightforward independent question, native HTML details with a summary provides a built-in disclosure widget. MDN explains that summary supplies the visible label and the open attribute controls whether content is shown. This can reduce the amount of custom state code the business must maintain. Nevertheless, the team still needs to test the chosen browsers, visual focus, spacing, translation and the content inside the panel. Do not assume native markup alone decides every product behaviour. The open attribute is Boolean: writing a textual value that looks like false is not a safe way to close it; the attribute must be absent when closed.
A custom accordion may be justified if the design needs behaviour or structure that native details cannot provide consistently for the intended audience. Then use an actual button in an appropriate heading, not a clickable div or a link with no navigation target. The W3C accordion pattern specifies an expanded state on the button and a relationship to the panel through aria-controls. The heading level must fit the page structure; do not turn every question into a top-level page heading merely because it is interactive. Keep the button as the only element inside that heading when following the pattern, with any separate action placed alongside rather than nested in the label.
For a custom control, visual state and programmatic state must change together. When the panel opens, aria-expanded changes to true; when it closes, the value changes to false. The panel’s visibility must match. An arrow icon can reinforce the state but cannot carry the whole meaning, because it may be missed by a screen reader or by someone who does not understand its direction. Avoid leaving focusable links or form controls inside content that is visually hidden but still reachable by Tab. If the design requires a panel that can never close while it is the only one open, the W3C pattern describes an aria-disabled state for that particular header.
Make the keyboard sequence predictable
The W3C accordion pattern uses Enter or Space to toggle the focused header and Tab to move through focusable elements in normal page order. Optional arrow-key shortcuts can help in some custom accordions, but they do not replace basic Tab navigation. A person must be able to arrive at the question, understand it is expandable, activate it, then continue into any links or controls in the revealed answer. Do not move focus to the panel automatically without a specific reason; unexpected focus movement can make the reading sequence harder to follow. Keep a visible focus indicator around the actual control at every state.
A practical test begins before the first question. Start at the page header and use only the keyboard. Move to each FAQ button in order, open one, enter a link inside its answer, return, and close it. Use Shift and Tab to check the reverse route. If opening one panel closes another, observe what happens when keyboard focus was inside the panel being closed: the user should not be stranded in hidden content. Repeat at high browser zoom and on a small viewport, because a panel may expand beyond the visible screen. Check that the chosen scroll behaviour helps the reader locate the revealed answer without masking the active question.
Screen-reader testing should verify the spoken name, role and expanded or collapsed state, not merely that the text eventually appears. Navigate by headings to see whether question levels make sense among the page’s other sections. Then activate a question and read through the answer. If a panel contains another heading, link or list, make sure its reading order follows the visible order. The W3C pattern permits a region role on panels in some cases, but warns against multiplying landmarks when many panels can be open. Use that optional structure only when it improves navigation, and test the result with actual assistive technology.
Check an answer through its whole life
Consider a delivery FAQ with three questions: when dispatch occurs, whether a customer can change the address, and whom to contact if a parcel is delayed. If each answer is independently useful, let people open more than one so they can compare the timing and exception. Keep the decisive sentence visible early within each answer, then explain conditions and a contact route. If a change to courier operations affects all three answers, assign an owner to update the three panels together. Collapsing content does not reduce the need for source checking; in fact it can make a stale condition less likely to be noticed during a quick visual review.
Test direct links and printing as separate tasks. A support agent may send a link to the address-change question; the customer should arrive with enough context to find and read the answer. If the implementation cannot open a linked panel reliably, consider a visible answer page or another straightforward link target. A printed FAQ should not silently omit all collapsed answers if staff or customers use printouts; test the print presentation and decide whether all answers should be expanded there. These are product choices to verify on the actual site, not behaviours guaranteed by the word accordion.
An acceptance review should pair content and interaction. Ask a colleague unfamiliar with the implementation to find one answer using a mouse, then a keyboard, then a screen reader if available. Observe where they expect the answer to be and whether the heading describes it accurately. Fix wording or ordering when the content itself is the obstacle; fix semantics and state when the control is the obstacle. Record the tested browser, viewport and assistive technology so future changes can be compared against a real baseline. A useful FAQ is one where the customer can identify the question, reveal the answer, understand its conditions and act on it.
Before you proceed
- Could important conditions be easier to find if they were visible instead of collapsed?
- Do the control label, heading, expanded state and panel visibility agree in both languages?
- Can a customer complete the answer journey by keyboard, screen reader, direct link and print where relevant?
