THE WEB IS
A MATERIAL.

THE OPEN STUDIO / INTERACTION

Why isn't hover enough?

A visually clever interaction is only the beginning. Discover keyboard focus, native disclosures, popovers, dialogs and the difference between links and actions.

Native HTML · Keyboard firstPlain HTML routeOpen source

A hover isn't a universal gesture.

The original collection explored the same CSS :hover property across several layouts. It's a beautiful experiment, but hover assumes a pointing device that can rest over an element. Touchscreens may not offer it, and keyboard users need a different way to activate controls.

The web platform gives us semantic controls that already understand keyboard input, focus, state and assistive technology. Rather than rebuilding those foundations with click handlers, we can build on them and style the results.

Three native interactions.

1. A disclosure

Why does this open with the keyboard?

The browser handles the open state and keyboard activation for a semantic <details> with a <summary>. No script required.

2. A popover

A browser-managed layer

Try Escape or clicking outside. The browser handles showing and hiding this nonmodal surface. Popover does not automatically provide all menu or dialog semantics.

3. A modal dialog

A real modal dialog

Focus moves into a native modal dialog and the rest of the document becomes inert while it is open. Try Escape, then reopen it.

Try all three without a mouse. Use Tab, Enter or Space as appropriate, and Escape to dismiss the modal and popover.

Native semantics are behavior.

<details>
  <summary>More information</summary>
  <p>Extra content here.</p>
</details>

<button popovertarget="help-popover">
  Show help
</button>
<div id="help-popover" popover>
  Useful help text
</div>

<dialog id="confirm-dialog">
  <form method="dialog">
    <button>Close</button>
  </form>
</dialog>

Popover uses built-in show/hide behavior, top-layer placement and light-dismiss behavior. It is not automatically a modal or a menu. Modal dialogs behave differently: calling showModal() puts the dialog in the top layer and makes other document content inert. We use a few lines of JavaScript only to open the modal, not to recreate the browser's focus trap.

:focus-visible helps style focus for keyboard-style interaction without indiscriminately hiding focus. A good focus outline needs sufficient contrast against whatever happens behind it.

Choose the semantic contract.

  • Navigation? Use an anchor with a real href.
  • Action? Use a button.
  • Optional expandable text? Try details/summary.
  • Lightweight contextual surface? Consider popover, and test its actual interaction model.
  • Blocking task requiring a response? Consider a modal dialog, with clear instructions and an obvious way to close.

Focus is how many people navigate.

Keyboard users need visible focus and a logical order. Touch users need generously sized targets, not tiny hover-only hotspots. Screen-reader users need controls with names and meaningful state. Native elements make many of these expectations easier, but they are not an excuse to skip testing.

For performance, native behavior often avoids custom event listeners, state synchronization and rendering work. For accessibility, avoid automatic focus movement except when a real interaction requires it.

Make the interaction fail on purpose.

Break it

Imagine replacing the first button with a clickable <div>. Without additional work, can it be tabbed to? Does Space activate it? Is its role and state exposed?

Build it

Make an FAQ using semantic disclosures, then build a “More details” button that opens a native dialog. Add a visible focus style, test with keyboard only, and verify that the dialog returns focus sensibly when closed. Visit the accessibility track for a manual checklist.

Go a little deeper.