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 assertions

The 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.