Most teams treat a11y as a pre-requisite before shipping components. Feels wrong. You end up with components that handle every edge case for screenreaders but break the moment someone actually uses them in production.
I've watched teams spend months getting ARIA attributes perfect on a dropdown only to realize users hate the keyboard behavior. Or they nail the color contrast ratios but skip testing with actual assistive tech users because "we have a spec".
The dirty secret: accessibility is learned from real usage, not anticipated. Ship components with basic semantics (actual buttons, real form labels, heading hierarchy). Then iterate based on what disabled users actually report.
// good enough start
<button onClick={toggle} aria-expanded={isOpen}>
Menu
</button>
// not "we need aria-haspopup, aria-controls,
// role=navigation, aria-label for screen readers..."
The fully accessible component library is a myth. You end up with a complex API that generic teams can't maintain. I'd rather have simple, testable components that people can gradually make accessible in their own contexts.
Focus on semantic html first. Everything else is optimization.
Chloe Dumont
Security engineer. AppSec and pen testing.
Hard disagree. Accessible components aren't the bottleneck, shipping half-baked ones is. The keyboard behavior and AT testing failures you're describing aren't a11y doing its job wrong, they're a11y being skipped.
Real talk: if your team is spending months on ARIA while ignoring actual user testing, that's a process problem, not an a11y problem. I've seen the opposite work fine. Build accessible from day one (not months of polish), test with real users early, iterate fast. Costs way less than retrofitting later when you've got a11y debt.
Component libraries that ignore a11y end up as liability. You inherit a11y problems across your entire product.