How do you approach DOM: Single-Open Accordion?

document.querySelectorAll('#faq button[aria-controls]') is the button list; document.getElementById(btn.getAttribute('aria-controls')) is its panel.

What are common mistakes on DOM: Single-Open Accordion?

An incomplete dependency array, which pins the effect to a stale closure. Mutating state in place instead of replacing it, so no re-render is scheduled. Never cleaning up the timer, listener or subscription on unmount.

gitGood.dev

← Back to problems

DOM: Single-Open Accordion

MediumFrontend Frameworks

Description

Runs in a real DOM. Each test seeds <div id="faq"> with three header buttons (aria-expanded, aria-controls) and three panels (hidden when closed).

Implement togglePanel(index) with single-open semantics:

If the panel at index is closed, open it and close every other panel.
If it is already open, close it (so all panels are closed).
Out-of-range index: no change.

Keep aria-expanded on each button and the hidden attribute on each panel in agreement. Use aria-controls to find a button's panel rather than assuming positions. Return { expanded, hidden } - each button's aria-expanded as booleans and each panel's hidden property, read back from the DOM.

Example 1

Input: index = 1 (all closed)

Output: {"expanded":[false,true,false],"hidden":[true,false,true]}

Example 2

Input: index = 0 (panel 0 open)

Output: {"expanded":[false,false,false],"hidden":[true,true,true]}

Constraints

- Exactly 3 button/panel pairs; each button's aria-controls is its panel's id.

DOM: Single-Open Accordion: approach, complexity and pitfalls

A medium frontend problem, graded against 5 test cases (2 of them hidden).

The pattern: Frontend

React and browser-platform problems - hooks, event handling, and rendering behaviour.

Reach for it when you see: A component, hook, or DOM-behaviour question rather than an algorithm.

If you are stuck

Show the 3-step hint ladder

document.querySelectorAll('#faq button[aria-controls]') is the button list; document.getElementById(btn.getAttribute('aria-controls')) is its panel.
Read the current state first: wasOpen = btn.getAttribute('aria-expanded') === 'true'. Then the new state of button i is (i === index && !wasOpen).
Setting every pair in one loop from that boolean keeps aria-expanded and hidden from drifting apart.

The optimal approach

Show the approach: Compute the target state, then write it everywhere

The bug-prone version toggles the clicked panel and then loops to close the others - which double-handles the clicked one and lets `aria-expanded` and `hidden` disagree. The clean version:

1. Read whether the target is currently open.

2. Define `open(i) = i === index && !wasOpen`.

3. Loop once over all pairs writing both the button's `aria-expanded` and the panel's `hidden` from `open(i)`.

Using `aria-controls` to find the panel (instead of "the next sibling" or "panel i") is what keeps this working when the markup changes - and it is the relationship assistive tech already uses.

Time: O(panels).

The full reference solution in every supported language stays in the editor above - reveal it there once you have had a real attempt.

What the tests check

Read off this problem's own test suite, so these are the cases a submission actually has to survive.

Zero. Zero appears in the input, which is the value most likely to break a truthiness check used in place of an explicit comparison.

Common Frontend mistakes

These apply to the pattern as a whole, not just this problem.

An incomplete dependency array, which pins the effect to a stale closure.
Mutating state in place instead of replacing it, so no re-render is scheduled.
Never cleaning up the timer, listener or subscription on unmount.