Lesson 6 of 30

Accessibility Standards: WCAG in Practice

Q: What does WCAG actually require? Walk me through its structure, not just "make it accessible."

A strong answer covers: Name the four principles — Perceivable, Operable, Understandable, Robust (POUR) — not just a vague general idea of accessibility; Explain that guidelines break into numbered success criteria, each rated at a conformance level (A, AA, AAA); Identify AA as the practical target most products (and most interview questions) assume by default.

WCAG isn't a vague 'be accessible' request — it's a specific, versioned, testable standard organized under four principles, with numbered success criteria and conformance levels. Interviews test whether you know the shape of it, not just the vibe.

14 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 3

A `<div onClick={submit}>Submit</div>` is styled to look pixel-identical to a real `<button>`. Which WCAG principle does the div most directly fail, independent of how it looks?

Robust — assistive technology can't determine any role or state from a div, no matter how it looksPerceivable — the div's color contrast must be insufficientUnderstandable — the label text must be unclear or inconsistent

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on Accessibility Standards: WCAG in Practice

What interviewers actually ask about this, and what a strong answer has to cover.

What does WCAG actually require? Walk me through its structure, not just "make it accessible."

A strong answer covers

Name the four principles — Perceivable, Operable, Understandable, Robust (POUR) — not just a vague general idea of accessibility
Explain that guidelines break into numbered success criteria, each rated at a conformance level (A, AA, AAA)
Identify AA as the practical target most products (and most interview questions) assume by default

Likely follow-ups

A page passes an automated accessibility scan with zero violations. Does that mean it's fully WCAG AA conformant? Why or why not?
Which WCAG principle does a `<div onClick>` styled to look like a button fail, and why doesn't fixing its visual contrast address that?

Practice these with the AI interviewer →

The plain-language idea

WCAG (Web Content Accessibility Guidelines, maintained by the W3C) is organized under four principles, easy to remember as POUR:

Perceivable — content must be presentable in ways users can perceive (alt text for images, captions for video, sufficient color contrast).
Operable — interface components must be operable (keyboard-reachable, no content that requires a precise mouse gesture with no alternative).
Understandable — content and operation must be understandable (predictable navigation, clear error messages, consistent labeling).
Robust — content must work with a wide range of tools, including assistive technology (valid, semantic markup that a screen reader can actually parse).

Each principle breaks down into numbered success criteria (e.g. 1.4.3 is the color-contrast requirement from the first lesson in this track) rated at three conformance levels — A (minimum), AA (the level almost every product targets, and the one most interview questions assume by default), and AAA (the strictest, usually reserved for content specifically serving low-vision or otherwise high-need users).

See it in a real thing: same pixels, different accessibility tree

A div styled as a button isn't a buttonStep 1 of 3

<div onClick={submit}>Submit</div> — looks like a button. Tab to it? A keyboard can't even reach it.

A <div onClick> and a <button> can be styled to look pixel-identical — and that's exactly the trap. WCAG's Robust principle (specifically success criterion 4.1.2, Name/Role/Value) is about what a screen reader or other assistive technology can actually determine from the markup, completely independent of how it looks. A div has no role, no keyboard focusability, and nothing to announce; a real <button> gets all three for free, from the browser, at zero extra code.

What people usually miss

Watch out

AA is the practical target, not AAA. Quoting AAA numbers (7:1 contrast, etc.) as if they're the standard bar is a common tell that someone has memorized isolated facts rather than understanding the three-level structure — AAA is explicitly not required or even achievable for all content per the spec itself.
"Accessible" isn't binary — it's a checklist of numbered criteria, and a page can pass some and fail others. A page can have perfect color contrast (1.4.3) and still fail badly on keyboard operability (2.1.1) — accessibility bugs are specific and independently testable, not one global pass/fail.
Legal requirements (ADA in the US, EAA in the EU, and similar elsewhere) typically reference WCAG AA as their bar, which is part of why AA — not AAA — is the default target: it's the level regulatory compliance is usually measured against.
Automated tools (like axe, used earlier in this platform's own accessibility work) catch a real subset of issues, not all of them. Contrast, missing alt text, and invalid ARIA are mechanically checkable; whether an error message is actually understandable is a judgment call automation can't fully make.

Why this matters in interviews

"What does WCAG AA actually require?" separates candidates who've absorbed accessibility as folklore ("make sure it works with a screen reader") from candidates who can name the actual structure: four principles, numbered criteria, three conformance levels, AA as the practical target. The genuinely strong signal is naming a specific criterion — like 1.4.3 for contrast or 2.1.1 for keyboard access — not just gesturing at the general idea.