What are web accessibility standards (WCAG) and how do you implement them
WCAG is the W3C standard organized around four principles — Perceivable, Operable, Understandable, Robust (POUR) — with three conformance levels (A, AA, AAA). AA is the practical legal/industry target. You implement it with semantic HTML first, ARIA only to fill gaps, keyboard operability, sufficient contrast, visible focus, accessible names, and testing with axe + a real screen reader.
WCAG (Web Content Accessibility Guidelines) is the W3C standard that defines what an accessible web experience means. It's the spec behind most accessibility laws (ADA in the US, EAA in the EU, AODA in Canada).
The POUR principles
WCAG is organized around four principles:
- Perceivable — users can perceive the content. Text alternatives for images, captions for video, sufficient color contrast, content not conveyed by color alone.
- Operable — users can operate the UI. Everything works by keyboard, no keyboard traps, enough time to read, no seizure-inducing flashes, visible focus.
- Understandable — content and operation are predictable. Readable text, consistent navigation, clear error messages, labels on inputs.
- Robust — works with current and future assistive tech. Valid HTML, correct name/role/value for every component.
Conformance levels
- A — bare minimum, fixes things that block users entirely.
- AA — the real-world target. This is what laws require and what teams should aim for. Includes 4.5:1 text contrast, resize to 200%, focus visible, etc.
- AAA — aspirational, not expected site-wide (e.g. 7:1 contrast, sign language for video).
When someone says "we need to be accessible," they almost always mean WCAG 2.1 (or 2.2) Level AA.
How you actually implement it
1. Semantic HTML first. This is 80% of accessibility for free.
<!-- Bad: div soup, no semantics -->
<div class="btn" onclick="submit()">Submit</div>
<!-- Good: real button — focusable, Enter/Space work, announced as "button" -->
<button type="submit">Submit</button>Use <nav>, <main>, <header>, <button>, <a href>, <label>, headings in order (h1 → h2, no skipping). Landmarks let screen-reader users jump around.
2. ARIA only to fill gaps. The first rule of ARIA is don't use ARIA if a native element exists. ARIA changes how AT announces things but adds zero behavior — you still wire up keyboard handlers yourself.
<!-- A custom toggle that has no native equivalent -->
<button aria-pressed="true" aria-label="Mute">🔊</button>3. Keyboard operability. Tab order follows DOM order, focus is always visible, no traps. Interactive custom widgets implement the expected key patterns (Arrow keys for tabs/menus, Escape to close, etc. — see the WAI-ARIA Authoring Practices).
4. Accessible names. Every input has a <label>. Every icon-only button has aria-label. Every meaningful image has alt; decorative images have alt="".
5. Color & contrast. 4.5:1 for body text, 3:1 for large text and UI components. Never use color as the only signal (add an icon or text).
6. Dynamic content. Announce async changes with aria-live regions. Manage focus on route changes and when modals open/close.
Testing — automated + manual
Automated tools catch ~30–40% of issues:
# axe-core via Playwright / Jest, or the axe DevTools extension
npx playwright test # with @axe-core/playwright assertionsThe other 60% needs humans:
- Keyboard only — unplug the mouse, tab through every flow.
- Screen reader — VoiceOver (Mac), NVDA (Windows), TalkBack (Android).
- Zoom to 200%, check reflow at 320px width.
- Lighthouse accessibility audit as a CI gate.
Senior framing
The interviewer wants to hear that accessibility is a process, not a checklist: semantic HTML by default, ARIA as a scalpel not a hammer, automated tests in CI to prevent regressions, and manual screen-reader testing for the things tools can't catch. Mentioning that it's a legal requirement (ADA/EAA) and that it overlaps heavily with good SEO and general UX shows you understand why it matters to the business, not just to pass an audit.
Follow-up questions
- •What's the difference between WCAG 2.1 and 2.2?
- •Why is 'semantic HTML first, ARIA second' the rule?
- •What accessibility issues can automated tools NOT catch?
- •How would you add accessibility checks to CI?
Common mistakes
- •Treating ARIA as a substitute for semantic HTML or for behavior — ARIA adds no keyboard handling.
- •Relying only on Lighthouse/axe and assuming green = accessible.
- •Using color alone to convey state (errors, required fields).
- •Removing focus outlines for aesthetics with no visible replacement.
- •Skipping heading levels (h1 → h3) for visual sizing instead of using CSS.
Edge cases
- •Single-page apps: route changes don't move focus or announce — must be handled manually.
- •Custom components (comboboxes, tabs, trees) need full keyboard interaction patterns from the ARIA Authoring Practices.
- •Auto-playing carousels and toasts can disappear before a screen reader user reaches them.
Real-world examples
- •Government and banking sites are legally required to meet WCAG AA.
- •E-commerce checkout flows are common ADA lawsuit targets when not keyboard-operable.