Accessibility fundamentals — designing for everyone by default

It's tempting to treat accessibility as an extra feature for a narrow group of users — but many accessibility fixes benefit far more people than that framing suggests: captions help someone in a loud room as much as someone who's deaf; sufficient contrast (from the color lesson) helps someone in bright sunlight as much as someone with low vision; clear focus states help anyone briefly using a keyboard, not just people who rely on one permanently. Building accessibly is building for a wider range of real, common situations, not a narrow exception.

A genuinely revealing test: unplug the mouse (or simply don't touch it) and try to complete a task using only Tab, Shift+Tab, Enter, and arrow keys. Every interactive element needs to be reachable this way, in a logical order, with a clearly visible focus indicator — the outline or ring that shows which element is currently focused. Removing that outline for aesthetic reasons (a real, common mistake — outline: none with nothing put in its place) makes an interface completely unusable for anyone navigating by keyboard, since there's no way to tell where you currently are on the page at all.

A screen reader converts an interface into speech (or braille) for users who are blind or have low vision — and it relies entirely on the underlying structure and labels, not visual appearance, to do this. Concretely: images need meaningful alt text describing what they convey (not just present for decoration); buttons and links need real, descriptive text (a button containing only an icon needs an aria-label describing its action); and using real semantic HTML (<button>, not a <div> styled to look like one) gets an enormous amount of this correct behavior for free, since screen readers already understand what a real <button> element is and how it should behave.

A mouse cursor is pixel-precise; a finger on a touchscreen is not. Interactive elements on touch interfaces need real minimum size — commonly cited guidance is roughly 44×44 pixels minimum — so a genuinely common accessibility failure (tiny, closely-packed icons that are easy to mis-tap, especially for anyone with limited fine motor control) doesn't happen by default.

This domain's color lesson already covered this, but it's worth restating here as a core accessibility principle in its own right: any meaning conveyed by color must also be conveyed by at least one other signal (text, icon, pattern) for it to be genuinely accessible to users who can't reliably distinguish that color.

Running this checklist against a real screen you've built catches a meaningful fraction of common accessibility failures with no specialized tooling required at all.