Exercise 2: Why Headless Libraries Aren't a Substitute for Understanding Accessibility — Possible Solution
====================================================================

THE HONEST NUANCE THIS CHAPTER DRAWS
------------------------------
Per this chapter, "this isn't a substitute for actually understanding
accessibility. web-accessibility1's own material remains essential for
knowing whether a given headless component is being used and
configured correctly, and for anything the library doesn't cover."
Even though a headless library provides genuinely correct underlying
behavior, that correctness can still be UNDONE or compromised by how
the developer uses and configures it — the library being correct
doesn't automatically guarantee the final, assembled product is
correct too.

WHAT WEB-ACCESSIBILITY1'S OWN KNOWLEDGE IS STILL NEEDED FOR:
CONFIGURING THE COMPONENT CORRECTLY
------------------------------
A headless dropdown primitive, per this chapter's own worked example,
still requires the developer to supply real content and structure —
labels, item text, and how the component is actually wired into the
surrounding page. Without real accessibility knowledge, a developer
could still misuse a correctly-built headless component: for example,
failing to give the trigger button a meaningful accessible name,
nesting the component in a way that breaks the surrounding page's own
heading structure, or misapplying custom styling in a way that removes
a visible focus indicator the library provides by default (a real,
common mistake even with an otherwise-correct underlying component).
The library gets the LOGIC right; the developer still has to use it
correctly.

WHAT WEB-ACCESSIBILITY1'S OWN KNOWLEDGE IS STILL NEEDED FOR:
EVERYTHING THE LIBRARY DOESN'T COVER
------------------------------
A headless library typically only covers the SPECIFIC interactive
patterns it was built for (a dropdown, a modal, a combobox) — it says
nothing about the rest of a real page's own accessibility (heading
structure, color contrast, form labeling, alt text, and everything
else web-accessibility1 covered across its own full range of
material). A team relying entirely on headless libraries for
accessibility, without any broader accessibility knowledge, would
still be genuinely exposed on every part of their product a headless
library doesn't happen to touch.

WHY THIS WORKS AS AN ANSWER
------------------------------
It names two distinct, concrete categories where web-accessibility1's
own knowledge remains necessary (correct usage/configuration of the
library itself, and everything outside the library's own scope), using
the chapter's own wording and connecting each to a real, specific
example rather than a vague "you still need to know accessibility"
statement.