Accessibility Glossary
WCAG criteria, patterns, and standards — with interactive demos, detection methods, and audit data.
WCAG principle 4 of 4 (POUR): code must be solid enough for browsers and assistive technologies (like screen readers) to interpret reliably.
Accessibility Tree
The parallel DOM that assistive technology reads. If an element isn't in the accessibility tree, it doesn't exist for screen reader users. Inspect via DevTools → Accessibility tab.
Accessible Name
Every interactive element needs a computed accessible name. Sources (in priority): aria-labelledby → aria-label → <label> → text content → title. Empty name = invisible to assistive tech.
ARIA: Use & Misuse
80% fail80% of homepages use ARIA — and those pages have 2× more errors than pages without. ARIA doesn't add behavior, only semantics. Misused ARIA is worse than no ARIA. Five rules: don't use ARIA if native works.
Forced Colors & High Contrast
Operating systems let people swap every color for their own palette (Windows High Contrast / `forced-colors` mode). Don't fight it: use semantic HTML, keep meaning out of background images, and check that content still reads after the swap.
Live Regions
A part of the page marked with `aria-live` so screen readers announce changes without moving focus. Use `polite` for routine updates (a results count) and `assertive` for urgent ones (an error). The region must exist before its text changes.
Name, Role, Value
Every interactive element must expose its name (label), role (button, link, checkbox…), and state (expanded, checked, disabled…) to assistive technology. The foundation of everything.
Semantic HTML
Use elements for their meaning: <button> not <div onclick>, <nav> not <div class='nav'>, <main>, <article>, <aside>. The first rule of ARIA: don't use ARIA if a native element works.
Status Messages
Dynamic status updates (search results count, form success, loading) must be announced without moving focus. Use role='status' or aria-live='polite'.