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.