Accessibility (a11y)
🚧 ExpandingAccessibility — a11y, eleven letters between the a and the y — is about building software that people with disabilities can actually use: people who navigate by keyboard, rely on screen readers, can’t perceive color differences, or need larger text. It matters because it’s the right thing to do, because in many places it’s the law, and because the techniques that make software accessible (clear structure, good contrast, real keyboard support) tend to make it better for everyone. Captions help people in loud rooms; high contrast helps people outdoors in sunlight. It sits alongside internationalization as the other foundation aimed at the same thing — software that reaches more people, not fewer. Accessibility is a baseline of competence, not a premium feature.
When this page is filled in, it’ll cover the four WCAG principles (perceivable, operable, understandable, robust), why semantic HTML does most of the work for free, color contrast, keyboard navigation, alt text that’s actually useful, and when ARIA helps versus when it hurts. Until then, the Go Deeper links carry it — the WCAG principles are the mental model worth internalizing first.
📚 Go Deeper
Books
- Inclusive Components — Heydon PickeringPattern-by-pattern walkthroughs of building genuinely accessible UI components from scratch.
Tools
- WCAG — Web Content Accessibility Guidelines (W3C)The standard everyone references. Start with the four principles — perceivable, operable, understandable, robust — before drowning in the success criteria.
- MDN — AccessibilityThe hands-on, code-first companion to WCAG: semantic HTML, ARIA, keyboard navigation, and how to actually test.
- The A11Y ProjectA friendly, checklist-driven entry point when WCAG feels like reading a legal document.