Accessibility (often shortened to a11y) means designing products that people with disabilities can actually use, including people who rely on screen readers, keyboard navigation, captions, or high contrast. In many regions it's also a legal requirement, not a nice-to-have.
Use cases
Skip it and you exclude real customers, and increasingly you invite a legal complaint.
Screen reader hits a wall: A blind user reaches checkout, but the buttons have no labels, so their screen reader announces "button, button, button." They can't finish the purchase and you lose the sale and the trust.
Contrast too low to read: Light gray text on white looks elegant in the mockup and disappears for low-vision users, and for everyone in bright sunlight.
How it's used in practice
Use semantic structure: Real headings, labels, and roles let assistive tech read the interface. Generic divs with no labels leave it silent.
Check contrast while designing: Test color pairs against the WCAG ratios in the design file, before handoff, not after a complaint.
Test keyboard and screen reader: Walk the core flows with a keyboard only and a screen reader, since a mouse hides most of the problems.
Spec the details: Put alt text, captions, focus order, and focus states into the design spec so engineering builds them in.
🪄
Pro-tip: Accessibility added at the end is a rebuild. Built in from the start it's nearly free. Bake contrast, labels, and focus order into your design system once, and every new screen inherits it. Retrofitting one screen at a time is where teams burn out.
Challenges & limitations
Automated tools miss most issues: Checkers catch roughly a third of problems. The rest need manual testing and real users with disabilities.
It gets cut under deadlines: Treated as a checkbox, it's the first thing dropped when the sprint runs late.
Compliant isn't the same as usable: A product can pass the POUR principles (perceivable, operable, understandable, robust) and still feel clunky for the people it's meant to serve.
