Interactive without JavaScript: HTML's hidden superpowers

The recipe: a <details> element whose first child is a <summary> (the always-visible clickable line). Everything after the summary is hidden until the user opens it. Add the open attribute to start expanded. The browser supplies the click handling, the keyboard handling, and the screen-reader announcement ("collapsed" / "expanded") - all of it.

<h3>FAQ</h3>
<details open>
  <summary>Does this need JavaScript?</summary>
  <p>No. The browser handles the click,
  the keyboard, and the screen reader.</p>
</details>
<details>
  <summary>Can it start open?</summary>
  <p>Yes - put the open attribute on it,
  like the first question here.</p>
</details>

One distinction worth making: the playground above uses plain, unstyled details - that is the element as taught. The cards on this course page are the same element plus CSS. Same skeleton, different clothes: exactly the HTML-vs-CSS split this course keeps preaching.

Give several details elements the same name value and they become an exclusive accordion: opening one closes the others, like radio buttons for content. This is a recent addition - supported in Chrome and Edge 120+, Safari 17.2+, and Firefox 130+ (so roughly every browser updated since 2024). Older browsers simply ignore name and allow multiple panels open at once - a graceful downgrade, not a breakage.

<details name="faq">
  <summary>Q1 · What closes me?</summary>
  <p>Opening any other panel that
  shares my name attribute.</p>
</details>
<details name="faq">
  <summary>Q2 · Open me to test it</summary>
  <p>Q1 just snapped shut. Radio-button
  logic, zero scripts.</p>
</details>
<details name="faq">
  <summary>Q3 · Me too</summary>
  <p>One name group, one open panel.</p>
</details>

• summary must be the first child of details. Put it later (or omit it) and the browser renders a default "Details" label - a sure sign of a markup slip.
• The triangle marker is styleable, not sacred. It is the ::marker pseudo-element in CSS; this page's cards replace it with the ▶ you see. HTML stays identical.
• Chrome can open them for you: find-in-page (Ctrl/Cmd+F) auto-expands a closed details if the match is inside. Handy, but do not rely on it cross-browser.
• Do not bury critical content. Hiding "how to cancel your subscription" three accordions deep is a dark pattern. Disclosure is for depth-on-demand, not for making things hard to find.

A <dialog> without the open attribute exists in your markup but renders nothing - it waits. Add open and it appears in the flow of the page as a non-modal box: visible, styled by the browser with a strong border, but not blocking anything around it.

<dialog open>
  <p><strong>Heads up!</strong>
  I am a dialog with the open attribute.</p>
  <p>The page around me still works -
  that is what non-modal means.</p>
</dialog>
<p>Regular page content, still clickable.</p>

The famous dialog experience - dimmed page, centered box, Esc to close, focus trapped inside - is modal mode, and honesty requires saying it plainly: opening a modal takes one line of JavaScript. The element does all the hard parts; the script is just the doorbell.

What that one showModal() call buys, free: the page behind gets dimmed (styleable via ::backdrop), keyboard focus is trapped inside the box, Esc closes it, and everything behind becomes inert - unclickable and invisible to screen readers. Note the second HTML gem in there: a <form method="dialog"> closes its dialog on submit, no script for the closing side.

• Modals are interruptions - spend them carefully. Destructive confirmations and must-answer questions earn one; "subscribe to our newsletter" on arrival does not.
• Always provide a visible close button. Esc works in modal mode, but not everyone knows that, and touch users have no Esc.
• Do not fake dialogs with divs. A div overlay gets none of the free behavior: no focus trap, no Esc, no inert background, no announcement. This is the "real button vs onclick div" lesson at box scale.

Two halves: the overlay element carries popover plus an id; the trigger button carries popovertarget pointing at that id. Click toggles it open and closed. Click anywhere else and it dismisses itself ("light dismiss") - the behavior every hand-rolled dropdown gets wrong on the first try.

<button popovertarget="hint">
  What is a disclosure widget?
</button>

<div id="hint" popover>
  <p>A click-to-reveal control, like the
  details element from Part 1.</p>
</div>

The overlay renders in the browser's top layer - a rendering level above everything on the page. No z-index, no positioning fights: the browser guarantees the popover paints on top.

Rule of thumb: if the user must deal with it before continuing, dialog. If it is helpful but skippable, popover. Bonus attribute: popovertargetaction="show" or "hide" makes a button one-directional instead of a toggle - handy for a dedicated ✕ button inside the popover.

Interactive elements - links, buttons, form fields, summary - are focusable automatically, in the order they appear in your HTML. Write the source in a sensible reading order and keyboard navigation is correct with no extra work. This is why CSS tricks that visually reorder content can quietly break keyboard flow: the eye sees one order, Tab follows another.

<p>Press Tab to walk this form:</p>
<input type="text" placeholder="1st stop: name">
<input type="email" placeholder="2nd stop: email">
<p>A link is a stop too:
<a href="#">3rd stop</a></p>
<button>4th stop: submit</button>

• tabindex="0" - adds a non-interactive element into the natural tab order, at its source position. For the rare custom widget that must be focusable.
• tabindex="-1" - focusable by script or by link target, but skipped by Tab. This is how skip links land focus on a heading.
• tabindex="1" or any positive number - a trap, do not use. Positive values hijack the whole page's tab order ahead of everything else, and every future edit has to re-solve the numbering puzzle. Fix the source order instead; that is where tab order belongs.

And the companion rule from CSS-land, stated early because it ruins lives: never remove the focus outline without replacing it. An invisible focus is a keyboard user navigating blind.

First focusable element on the page, usually hidden until focused: one Tab, one Enter, and a keyboard user leaps over your entire navigation. Every serious site has one - check for it with a single Tab press on any government website.

You met them in the wild above - now the formal introductions, from HTML's "other inline text elements" drawer:

• <kbd> - a keyboard input, like Tab and Esc throughout this part. Semantics for "the user types this".
• <mark> - highlighted relevance, like a search-result match. Meaning: "notice this here", not "this is bold".
• <abbr title="Chief Data and AI Officer">CDAIO</abbr> - an abbreviation whose title attribute holds the expansion; hover one to see the built-in tooltip (popover's tiny ancestor).
• <small> - fine print: legal lines, side comments, the footnote voice.