Lesson 29 of 30
This track's earlier WCAG lesson covered the testable standard. This is the honest follow-up: real user impact a WCAG audit can pass and still miss.
12 min read
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 form passes a full automated axe-core scan with zero violations, but uses dense internal jargon in its field labels and gives users a hard, non-extendable 10-minute session timeout. Is this form fully accessible?
Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.
Sign up freeWhat interviewers actually ask about this, and what a strong answer has to cover.
A strong answer covers
Likely follow-ups
This track's earlier lesson on WCAG covered the standard as it's actually structured — four principles, numbered success criteria, three conformance levels. That standard is genuinely useful and genuinely testable, which is exactly why it's the industry default. It's also not the whole picture: WCAG's success criteria are written to be objectively checkable, and some real, common accessibility needs don't reduce cleanly to a pass/fail check.
Two categories worth naming specifically:
Cognitive accessibility — plain language over jargon and unnecessarily complex sentence structure, consistent and predictable navigation (not clever, novel interaction patterns that have to be relearned per screen), time limits that can be extended or disabled rather than a hard countdown, and fewer unnecessary steps in a flow. None of these map to a single numbered WCAG criterion the way color contrast maps to 1.4.3 — they're closer to a design discipline than a checkbox.
Motor accessibility — large, well-spaced targets (the same reasoning as this track's Fitts's Law lesson: distance and size determine time-to-target, and that cost is much higher for someone with limited fine motor control), tolerance for imprecise input (a slightly-missed tap should still register if it's close enough, rather than failing silently), and avoiding interactions that require a precise drag or a held gesture with no alternative — a slider with no keyboard or tap equivalent, or a long-press action with no simpler substitute, excludes users who can't reliably sustain that exact motion.
A multi-step signup form has correct color contrast, full keyboard operability, proper ARIA labeling, and a visible focus ring on every field — a real axe-core scan would report zero violations. It also uses internal product jargon in its field labels ("Configure your workspace tenancy"), resets a 10-minute session timer with no way to extend it, and requires a drag-to-reorder step with no keyboard alternative for reordering. Every one of those three problems is a genuine barrier for real users — someone unfamiliar with the product's internal vocabulary, someone who reads slowly or gets interrupted, someone who can't perform a sustained drag gesture — and none of them is a WCAG conformance failure the way missing alt text or insufficient contrast would be.
"This screen passes every automated accessibility check — are we done?" is a genuine trap question, and the strong answer names the gap directly: automated and even manual WCAG conformance is real, necessary evidence, but cognitive load, motor precision, and rigid time limits are real barriers that a testable, numbered-criteria standard doesn't fully capture — showing you understand both where WCAG's authority ends and what still needs deliberate design attention past it.