Design System Audit: Fix It Once, Fix It Everywhere

What We Keep Finding

Design systems multiply accessibility in both directions. Every component ships its behavior to every product that adopts it, the good, the bad, and the untested. A modal with focus handled properly is a gift that keeps arriving. A select that cannot be operated by keyboard is a defect with a distribution network.

Auditing the system beats auditing its outputs, and the reason is written into the standard. Conformance is defined for a web page, and a component is not one, so a library can never be declared conformant on its own terms. What it can be is correct, which is the thing that decides whether the pages built from it stand a chance. Auditing 20 components covers more ground than auditing 200 pages, and the fixes land at the source.

There is a measured argument for auditing the ARIA specifically. In a sweep of a million home pages, the ones using ARIA averaged 59.1 detected errors against 42 for the ones without. That is a correlation on real pages rather than proof that ARIA causes harm, and the reading that survives is the obvious one. ARIA is what teams reach for when they build custom components, and custom components are where things break.

One thing to know before your team writes tickets from W3C's reference patterns. There are 30 of them, and five components a modern library almost always contains are not among them, so no pagination, no drag and drop, no site search, no toast, no date picker. Every example page also carries a note that its code is not meant for production and deliberately does not work around gaps in assistive technology support. For those five, there is no canonical answer to copy, and we would rather tell you that than send you to a page that does not exist.