Exercise 1: What "Headless" Means, and the Real Problem It Solves — Possible Solution
====================================================================

WHAT "HEADLESS" MEANS IN THIS SPECIFIC CONTEXT
------------------------------
Per this chapter, "here it specifically means a component's own
interactive logic — state management, keyboard handling, focus
management, ARIA attribute wiring — is fully implemented and provided,
but rendered with zero default CSS or visual opinion at all. A
headless dropdown menu is fully functional and fully accessible, with
no visual appearance whatsoever until it's styled." A headless
component genuinely works — it opens, closes, responds to keyboard
input, manages focus correctly, and exposes the correct ARIA
attributes — but it renders with absolutely no default visual
appearance at all. All of the hard interactive/accessibility LOGIC is
present; none of the visual DESIGN is.

THE REAL PROBLEM THIS PARADIGM SOLVES
------------------------------
Per this chapter, "building a genuinely accessible interactive
component... correctly is genuinely hard. Real keyboard navigation...,
correct ARIA roles/states/properties, and correct focus management are
all easy to get subtly wrong — web-accessibility1's own material
already established just how much genuine expertise this requires."
web-accessibility1's own material demonstrated, in real depth, how
easy it is to get accessible interactive patterns subtly wrong even
with good intentions — incorrect ARIA usage, missing keyboard support,
broken focus management are all common, real mistakes, not rare edge
cases.

Per this chapter, "headless libraries exist specifically to let a team
not have to solve this hard problem themselves, while still having
complete freedom over visual design." Rather than every individual
team independently attempting to correctly implement this genuinely
difficult accessibility logic from scratch — with real risk of
repeating the exact mistakes web-accessibility1 warned about — a
headless library provides that hard logic once, built and tested by
people specifically focused on getting it right, while leaving the
ENTIRE visual design decision open to whatever the team actually wants
— resolving the gap neither Tailwind (styling only) nor Bootstrap
(styling+behavior bundled, less flexible) fully closes.

WHY THIS WORKS AS AN ANSWER
------------------------------
It defines "headless" precisely using the chapter's own wording, and
explains specifically WHY this paradigm exists by connecting it
directly to web-accessibility1's own demonstrated difficulty of
building genuinely correct accessible components, rather than
describing headless libraries as simply "another styling option."