WCAG Conformance and the POUR Principles
Concept
The Web Content Accessibility Guidelines (WCAG), published by the W3C's Web Accessibility Initiative, are the standard nearly every legal and organizational accessibility requirement points back to (Section 508 in the US, EN 301 549 in the EU, the ADA's web-accessibility case law). WCAG organizes its ~80 success criteria under four principles, memorized as POUR:
- Perceivable — information and UI components must be presentable to users in ways they can perceive: text alternatives for images, captions for video, sufficient color contrast, content that doesn't rely on color alone to convey meaning.
- Operable — UI components and navigation must be operable: everything reachable by keyboard alone, no content that traps focus or flashes in a way that triggers seizures, enough time to read and use content.
- Understandable — information and UI operation must be understandable: readable text, predictable navigation and behavior, input assistance (labels, error identification) on forms.
- Robust — content must be robust enough to be interpreted reliably by a wide variety of user agents, including assistive technology — valid, semantic markup that a screen reader can parse correctly.
Each success criterion is assigned a conformance level — A (minimum), AA (the level almost every legal standard and enterprise procurement requirement actually cites), or AAA (aspirational, rarely targeted site-wide since some AAA criteria conflict with normal design constraints, e.g. a 7:1 contrast ratio). "WCAG 2.1 AA" or "WCAG 2.2 AA" is the phrase that shows up in contracts and legal settlements; AAA is not a realistic target for most production sites.
Tradeoffs
| Approach | Benefit | Cost |
|---|---|---|
Semantic HTML (<button>, <nav>, <label>, native form controls) |
Keyboard behavior, focus management, and screen-reader semantics come free from the browser; smallest code, most robust | Design constraints — you're limited to what native elements look/behave like without extra styling work |
ARIA attributes on non-semantic elements (<div role="button">, aria-*) |
Lets a custom-styled widget report itself correctly to assistive tech without matching a native element's default appearance | Every behavior ARIA doesn't give you for free (keyboard handling, focus trapping, state sync) must be hand-implemented and kept in sync with visual state — a common source of bugs where the ARIA state lies about what's actually on screen |
| No accessibility consideration | Fastest to ship initially | Excludes real users (screen-reader users, keyboard-only users, low-vision users); retrofitting after the fact costs far more than building it in, since inaccessible patterns (click handlers on divs, unlabeled inputs, color-only status indicators) are usually load-bearing by the time anyone audits them |
The W3C's own guidance states this order directly as the first rule of ARIA use: if a native HTML element or attribute already has the semantics and behavior you need, use it instead of repurposing an element and adding ARIA to fake those semantics back in. ARIA is a bridge for the gap between what native HTML can express and what a design system actually needs — not a first choice.
When to use / when not to
- Target WCAG 2.2 AA as the default bar for any production UI, not just "the booking flow" or other high-stakes paths — a screen-reader user hitting one inaccessible step (an unlabeled input, a keyboard trap in a modal) can be blocked from completing the whole flow regardless of how accessible the rest of it is.
- Prefer native semantic elements (
<button>,<select>,<label for="">, landmark elements like<nav>/<main>) over custom-styled divs with ARIA bolted on, whenever the native element's default look can be restyled to match the design instead of rebuilt from scratch. - Reach for ARIA when a design genuinely needs a widget with no native HTML equivalent — a combobox with autocomplete, a tab panel, a custom slider — and follow the W3C ARIA Authoring Practices Guide's patterns rather than inventing role/state combinations from scratch, since subtly wrong ARIA can be worse than none (it tells assistive tech the element is one thing while it behaves like another).
- Don't treat AAA as a target for an entire site; pick specific AAA criteria only where they don't conflict with other design constraints, and stay honest that AA is the real bar being measured against.
Common pitfall
Adding role and aria-* attributes to a custom component without also implementing the keyboard interaction and state-sync behavior those attributes imply — e.g. giving a <div> role="button" and a click handler, but no tabindex, no Enter/Space key handling, and no focus style. This passes a superficial automated accessibility scan (the role is present) while remaining completely unusable by a keyboard-only user, which is worse than not adding the role at all: it advertises accessibility support the component doesn't actually have. Automated tools (axe, Lighthouse) catch missing attributes reliably but cannot verify that keyboard behavior actually matches the semantics claimed — that requires manual keyboard-only testing.
Engineering Lens
The POUR framing is useful precisely because it forces a check across four independent failure modes rather than one intuitive "does it look fine to me" pass — a UI can be visually Perceivable and still fail Operable (unreachable by keyboard) or Robust (a screen reader misreads the structure). The practical discipline that scales this beyond a one-time audit is defaulting to semantic HTML first: a codebase that reaches for native elements by habit inherits correct keyboard and assistive-tech behavior automatically on every new component, while one that reaches for styled divs by habit accumulates an ARIA-and-keyboard-handling debt on every single custom widget, discovered one bug report at a time rather than designed in from the start.