WAS common mistakes
WAS · Understand the traps and how to avoid them.
Treating WCAG conformance as binary pass/fail per page instead of reasoning about conformance at the level of full pages, complete processes, and the chosen conformance level (A, AA, AAA).
Candidates memorize individual success criteria but never internalize the WCAG conformance model, so they answer questions about partial conformance, 'mostly compliant' pages, or mixing levels as if those were valid.
What to do instead
Study the five conformance requirements explicitly: conformance level, full pages, complete processes, only accessibility-supported ways of using technologies, and non-interference. Practice classifying scenarios (e.g., a multi-step checkout with one inaccessible step) as conforming or not.
Conflating the four POUR principles with the guidelines and success criteria beneath them, e.g., placing 'contrast' under Operable or 'keyboard' under Perceivable.
The principle names are abstract and candidates learn criteria in isolation without building the hierarchy map, so recall collapses under distractor options that shuffle levels.
What to do instead
Build a mental tree: Perceivable (1.x), Operable (2.x), Understandable (3.x), Robust (4.x), and note the guideline numbers. Rehearse by sorting a list of 30 criteria into principle and guideline before checking answers.
Assuming ARIA roles and attributes add behavior or accessibility automatically, e.g., adding role='button' to a div and considering it keyboard-operable, or using aria-label on a non-interactive element expecting it to be exposed.
ARIA is often taught as a checklist of attributes; candidates miss the first rule of ARIA (use native HTML where possible) and the fact that ARIA changes the accessibility tree, not behavior.
What to do instead
Memorize the five rules of ARIA use and the native-element equivalents (button, input type=checkbox, nav, dialog). For any ARIA answer, ask: does this require JavaScript for keyboard and state, and is there a native element that already provides semantics?
Treating alt text as a universal requirement rather than deciding per image function: decorative images get empty alt, functional images describe the action/destination, complex images need a nearby long description, and CSS background images are not described via alt.
Simplified guidance ('every image needs alt') leads to incorrect answers for decorative, functional, and complex image scenarios that the exam tests deliberately.
What to do instead
Classify images by purpose before choosing an answer: decorative (alt="" and no redundant title), informative (concise equivalent), functional (describes the function), complex (short alt plus adjacent long description). Practice with 15 varied examples.
Choosing heading levels by visual size or skipping levels for styling reasons, and using ARIA or bold text to fake headings instead of real heading elements.
Candidates carry over visual-design habits and forget that heading structure is a navigation mechanism for screen reader users, where skipped levels and fake headings break outline navigation.
What to do instead
Apply the rule: heading levels reflect document structure and descend by one; style with CSS, not tag choice. Verify with a screen reader's heading list or a browser accessibility outline tool.
Confusing the medical, social, and functional/charity models of disability, or answering accessibility questions from a medical-model premise (e.g., 'the user's impairment causes the barrier').
The models are taught briefly and sound similar in summary form; candidates then misread scenario questions that hinge on where the barrier is located (person vs. environment).
What to do instead
Anchor each model with one sentence: medical locates the problem in the person; social locates it in environmental and attitudinal barriers; functional/charity focuses on impairment limitations and pity. For scenario questions, ask whether the fix changes the person or the environment.
Assuming a passing automated scan means the page is accessible, or that a tool's flagged issue is always a real violation, without manual verification.
Automated tools are easy to demo and produce confident-looking scores; candidates over-trust them and forget that tools cannot judge alt-text quality, reading order, or meaningful link text.
What to do instead
State the limits explicitly: automated testing covers only a minority of success criteria. Pair every tool result with manual checks (keyboard-only pass, screen reader spot check, zoom/reflow, contrast measurement) and treat tool output as a starting inventory.
Testing only with a mouse and one browser, skipping keyboard-only operation, focus visibility, focus order, and screen reader output; or testing with a screen reader but not verifying keyboard traps and skip links.
Candidates lack hands-on AT practice and substitute reading about assistive technology for using it, so they cannot predict real failure points like focus management in dialogs and menus.
What to do instead
Adopt a repeatable protocol: tab through the page recording focus order and visibility, test Escape and arrow keys in widgets, confirm focus returns after dialogs close, then spot-check with at least one screen reader and browser pair, plus 200% zoom and 320px reflow.
Believing CSS techniques like display:none, visibility:hidden, off-screen positioning, and order/position properties affect only visuals; e.g., using display:none for screen-reader-only text or reordering with CSS while DOM order stays different.
Candidates separate 'design' from 'accessibility' and do not realize CSS controls inclusion in the accessibility tree and the reading/focus order.
What to do instead
Learn the visibility matrix: display:none and visibility:hidden remove content from AT; the clip/visually-hidden pattern hides visually but keeps it for AT; CSS reordering does not change DOM or focus order. Test each technique with a screen reader rather than assuming.
Treating remediation as a one-time fix list rather than a governed program: no ownership, no prioritized backlog, no regression prevention, and no acceptance criteria tying fixes to specific success criteria.
Candidates study technical criteria in depth but rarely study program governance, so they answer remediation questions with ad hoc tactics instead of lifecycle controls.
What to do instead
Frame remediation as a cycle: inventory and audit, prioritize by user impact and legal risk, assign owners and deadlines, verify fixes against named success criteria, and add prevention (design reviews, component-library patterns, automated checks in CI, training).