Web Accessibility Basics (WCAG 101) Every Developer Should Know
Not a compliance checklist — the four real principles behind WCAG, and the handful of checks that catch most real-world accessibility bugs.
WCAG (Web Content Accessibility Guidelines) is organized around four principles, usually remembered by the acronym POUR — and knowing the four categories is more useful day to day than memorizing individual success criteria, because it tells you what *kind* of bug you're looking for.
Perceivable
Can the content be perceived, by any sense — not just sight? This covers alt text on images, captions on video, and color contrast — a light-gray label on a white background fails this even for a fully sighted user in bright sunlight, not just someone with low vision. This site's own build caught a real contrast failure this way: a UI token measuring 1.57:1 against its background, well under the 3:1 floor for a form input's border, found by actually calculating the ratio rather than eyeballing it.
Operable
Can every interactive element be operated without a mouse? Keyboard-only navigation is the practical test: tab through the entire page — does focus land on everything interactive, in a sensible order, with a visible focus indicator, and does nothing trap focus somewhere it shouldn't? This site's own keyboard audit found 99 invisible-but-focusable elements in a closed mobile drawer — invisible to a sighted mouse user, a real dead end for a keyboard user.
Understandable
Is the content and the interface predictable? Form labels that actually describe what's expected, error messages that say what's wrong and how to fix it (not just "invalid input"), and navigation that behaves consistently across the site.
Robust
Does the content work correctly with assistive technology — screen readers, voice control, browser zoom? This is largely where semantic HTML (the previous post) pays off directly: a robust page uses real elements a screen reader already knows how to announce correctly, rather than custom widgets needing extensive ARIA to approximate that same robustness by hand.
Where to actually start
Four checks catch a disproportionate share of real bugs: can you complete every flow using only the keyboard, does every image have meaningful (or deliberately empty, for decorative images) alt text, does text meet a 4.5:1 contrast ratio against its background, and does every form input have a real, associated `<label>`. None of these require a screen reader to check — they're testable in a few minutes, on any page, right now.