Exercise 3: Why "Headless Library" ≠ "Definitely Accessible" — Possible Solution ==================================================================== WHY THIS ISN'T AN AUTOMATIC GUARANTEE ------------------------------ Per this chapter's own warn-box, "not every headless library component is equally mature or well-tested. The real value proposition — offloading genuinely hard-to-get-right accessibility work — only holds if the specific library and component are actually well-maintained and thoroughly tested. A poorly-maintained or immature headless library can genuinely have real accessibility bugs of its own, the same way any software can." The entire benefit of a headless library — per this chapter's own earlier material — comes from it being a "professionally-built, thoroughly-tested" implementation of a genuinely hard accessibility pattern. But being LABELED a "headless library" doesn't automatically mean that specific library actually achieved that level of quality. A headless library is still ordinary software, written by real people, and can contain real bugs — including real accessibility bugs — in exactly the same way any other software project can, regardless of its own stated purpose or category. Simply choosing something that calls itself a "headless, accessible component library" doesn't verify that the specific implementation genuinely, correctly handles every keyboard interaction or ARIA state it claims to. THE REAL DUE DILIGENCE THIS CHAPTER RECOMMENDS ------------------------------ Per this chapter, "real due diligence — checking maintenance activity, real usage and adoption, ideally real accessibility auditing — still matters, echoing web-accessibility1's own broader 'don't just trust a checkbox' ethos." Rather than assuming a library is accessible purely because of its category, the chapter recommends actively checking: whether the library is genuinely actively maintained (recent updates, responsive issue-handling) rather than abandoned; whether it has real, substantial adoption by other real projects (a signal that many other people have exercised it in practice, surfacing real bugs over time); and ideally, whether it has actually been subjected to real accessibility auditing by qualified people, rather than only the library's own claims about its own quality. WHY THIS ECHOES WEB-ACCESSIBILITY1'S OWN BROADER ETHOS ------------------------------ Per this chapter, this "echo[es] web-accessibility1's own broader 'don't just trust a checkbox' ethos" — that course's own material consistently emphasized verifying real accessibility outcomes directly (actual screen reader testing, actual keyboard testing) rather than assuming a checklist item or a tool's own claim of compliance is sufficient proof. Applying that same discipline here means not treating "uses a headless library" as a self-certifying claim of accessibility, but as a starting point still requiring real verification. WHY THIS WORKS AS AN ANSWER ------------------------------ It explains precisely why a headless library's own category label doesn't guarantee quality (it's still ordinary software that can have real bugs), states the three specific due-diligence checks the chapter names, and explicitly connects this recommendation back to web-accessibility1's own broader verification-over-assumption ethos.