WCAG's four principles
The Web Content Accessibility Guidelines (WCAG 2.1) organize every requirement under four principles, commonly abbreviated POUR:
- Perceivable — information must be presentable in ways users can perceive (text alternatives for images, captions for video, sufficient color contrast).
- Operable — interface components must be usable (full keyboard navigation, no content that traps focus, enough time to read/interact).
- Understandable — content and operation must be predictable (consistent navigation, clear error messages, readable language).
- Robust — content must work reliably across assistive technologies (valid markup, proper semantic roles, compatibility with screen readers).
Each guideline under these principles has three conformance levels — A (minimum), AA (the level most legal standards reference, including ADA-related web requirements in the US and EN 301 549 in the EU), and AAA (enhanced, not required for most sites).
Contrast ratios: a real, testable number
WCAG defines legibility as a contrast ratio derived from relative luminance, not a subjective "looks readable" judgment:
| Level | Requirement |
|---|---|
| AA, normal text | 4.5:1 minimum |
| AA, large text (18pt+/14pt bold) | 3:1 minimum |
| AAA, normal text | 7:1 minimum |
This is a specific, calculable number — a light gray on white that "seems fine" can measure well under 4.5:1 and fail outright, especially for the estimated 1 in 12 men and 1 in 200 women with some form of color vision deficiency, for whom marginal contrast differences are even harder to perceive (see the Complete Guide to Color Systems for how the ratio is calculated).
Keyboard navigation: the test most sites fail silently
A genuinely accessible site must be fully operable using only a keyboard — Tab to move forward, Shift+Tab backward, Enter/Space to activate. The most common real-world failure: custom-styled buttons or dropdowns built from a <div> with a click handler instead of a semantic <button>, which is invisible to keyboard navigation entirely — no native focus, no Enter/Space activation, unless a developer manually re-implements all of that behavior (tabindex, role, key event handlers) that a real <button> provides automatically. The fastest accessibility audit anyone can run right now: unplug the mouse and try to complete the site's core flow using only Tab, Shift+Tab, and Enter.
Screen readers need semantic structure, not just alt text
Alt text is necessary but far from sufficient. Screen readers rely on the underlying HTML's semantic structure to build a navigable outline of the page: heading levels (<h1>–<h6>) in a logical, non-skipping order; landmark regions (<nav>, <main>, <header>); and ARIA roles/labels for custom interactive components that don't map to a native HTML element. A visually well-organized page built entirely from unstyled <div>s is often nearly unusable with a screen reader — sighted structure and screen-reader structure are not the same thing, and only the latter comes from actual markup semantics.
Common mistakes
- Adding alt text but ignoring heading structure and landmarks. Alt text solves image description; it does nothing for a screen reader user trying to navigate a page's overall structure via headings.
- Building custom interactive controls without keyboard support. A
<div onClick>styled to look like a button provides none of a real<button>'s built-in keyboard, focus, and role behavior — each has to be reimplemented manually if you don't use the native element. - Encoding meaning in color alone (e.g., red text meaning "error," with no icon or label) — invisible or ambiguous to colorblind users and screen reader users alike.
- Trapping keyboard focus in a modal with no escape. A modal that opens but doesn't let Tab cycle within it or Escape close it leaves keyboard-only users stuck.
- Testing only with a mouse and sighted review. Visual QA doesn't catch keyboard-trap bugs, missing ARIA labels, or illogical heading order — these require dedicated keyboard and screen-reader testing.
FAQ
Is WCAG a legal requirement?
It's not a law itself, but courts and regulators in several jurisdictions (including under the US ADA and the EU's accessibility directives) reference WCAG 2.1 AA as the practical standard for compliance — many organizations treat AA as a baseline requirement rather than optional.
Does adding alt text make a site accessible?
It's one requirement among many — heading structure, keyboard operability, focus management, and color contrast all matter independently; alt text alone addresses only image content.
Why do custom-styled buttons sometimes not work with Tab?
Because they're often built from a non-interactive element (<div>, <span>) with a click handler, which has no native keyboard focus or activation behavior — only real <button>/<a> elements (or ones with correctly added ARIA roles and keyboard handlers) get that for free.
What's the fastest way to spot-check accessibility myself?
Try navigating your site's core flow using only the keyboard (Tab, Shift+Tab, Enter, Escape), and check actual contrast ratios rather than eyeballing them — both catch a large share of real-world issues without specialized tools.
Check real contrast ratios and preview color-vision-deficiency views with the Color Blindness Simulator — runs entirely in your browser.