Web Accessibility: WCAG 2.1 AA
Accessibility is not a feature you add at the end — it is a property of how you build, and it benefits far more people than the permanently disabled users it's named for: someone with a broken arm navigating by keyboard, a user in bright sunlight squinting at low contrast, anyone on a slow connection or a small screen. WCAG 2.1 Level AA is the practical bar most teams and regulations aim for. This guide explains the model behind it so the criteria feel like consequences of a few principles rather than a list to memorize. The auto-generated Checklist below links the criteria that are enforced as rules; the reference checklist at the end covers the wider AA set.
The four principles (POUR)
Every WCAG criterion is an instance of one of four ideas:
- Perceivable — users must be able to sense the content. Images need text alternatives; video needs captions; information must never be conveyed by color alone.
- Operable — users must be able to use the interface. Everything works by keyboard; nothing flashes in a way that can trigger seizures; users have time to read and act.
- Understandable — content and operation must be predictable. Language is declared, labels are clear, errors are explained, navigation is consistent.
- Robust — content must work with assistive technology, now and as it evolves — which in practice means valid, semantic markup.
Hold those four in mind and most specific requirements become obvious.
Start with semantic HTML
The single highest-leverage decision is to use semantic HTML elements: a real <button>, <nav>, <main>, <h1>–<h6> in order, <label> tied to its input. Semantic elements come with keyboard behavior, focus handling, and screen-reader roles for free. A <div onClick> styled to look like a button has none of that, and re-creating it with ARIA and key handlers is far more work than using the element that already does it. Reach for ARIA only to enhance semantic HTML, never to replace it — "no ARIA is better than bad ARIA."
Make everything keyboard-operable
A large group of users never touch a mouse. Ensure keyboard navigation: every interactive element must be reachable and usable with Tab/Shift-Tab/Enter/Space/arrows, in a logical order, with a visible focus indicator so users can see where they are. Watch for the classic traps — a custom modal that doesn't move focus in, doesn't trap focus while open, and doesn't restore focus on close leaves keyboard and screen-reader users stranded.
Don't rely on sight alone
Two criteria carry a lot of weight here. Add alt text to images so screen-reader users get the same information sighted users do — descriptive for meaningful images, empty (alt="") for decorative ones so they're skipped rather than announced as noise. And maintain color-contrast ratios (4.5:1 for normal text, 3:1 for large text and UI components) so low-vision users and anyone in poor lighting can read. The corollary: never use color as the only signal — pair the red error state with an icon and text.
Forms are where accessibility most often breaks: every input needs a programmatically associated label, errors must be announced and tied to their field (not just shown in red), and required/invalid states must be conveyed to assistive tech, not only visually. Respect prefers-reduced-motion for users who get motion sickness, and don't auto-play anything that moves or makes sound.
A practical checklist
The enforceable items appear in the auto-generated Checklist below (linking to each rule). The broader AA set to review:
- Semantic structure; headings in order; landmarks (
<nav>, <main>).
- All functionality keyboard-operable; visible focus; no keyboard traps; focus managed in modals.
- Text alternatives for images; captions for media; information not by color alone.
- Contrast 4.5:1 (text) / 3:1 (large text, UI); honor
prefers-reduced-motion.
- Labels on every field; errors announced and associated; language declared on the page.
- Valid, semantic markup; ARIA only to enhance, never to replace.
Accessibility done this way is mostly not adding barriers rather than bolting on fixes. Where a criterion can be checked, it belongs as a rule in this skill — and the checklist below is generated from those.