Disclosure: by hand and with <details>
Both behave the same for keyboard and screen reader users ("What is your return policy?, button, collapsed"). <details> needs no state; reach for the hand-made version when you need to control open from React (pass open and listen to onToggle on <details> for that too).
Dialogs, disclosures, tabs, menu buttons and comboboxes each have a standard keyboard pattern in the WAI-ARIA Authoring Practices; build them with the right roles, states and keys, prefer native elements where they exist, and reach for a tested headless library for the hard ones.
Change the code and press Run (Ctrl+Enter). Predict what will happen first, then break it on purpose and read what changes. Your edits are saved and match the lesson page.
Ready for more? This phase has 6 hands-on exercises with automatic checks.
Practice questions
Write the code in the editor, run it, then open the model answer to compare.
Write an accessible Accordion from three disclosures where opening one closes the others.
Add Home and End support to the menu button example.
Explain it without notes
Describe the keyboard interaction of the WAI-ARIA tabs pattern and how roving tabindex implements it in React.
When would you use a disclosure, a menu button and a combobox? Give a native alternative for each where one exists.
Why does a combobox use aria-activedescendant instead of moving focus into the list?
What does a headless component library give you, and name two.
Preview
Console
Nothing logged yet.Expected console output
closed: aria-expanded = false | panel hidden: true
opened: aria-expanded = true | panel hidden: false
details open after clicking summary: true