AHWD common mistakes
AHWD · Understand the traps and how to avoid them.
Treating WCAG conformance as a pass/fail checklist and answering that a page 'passes WCAG' when only some success criteria were evaluated, rather than distinguishing Level A, AA, and AAA and noting which criteria were not checked.
Candidates memorize a handful of famous criteria (alt text, contrast) and generalize to the whole standard, forgetting that conformance claims are scoped by level, by page, and by full-page/complete-process requirements.
What to do instead
Before answering, identify the target level and the scope (single page vs. complete process). State conformance only for the level and scope actually evaluated, and flag any success criteria that were not tested rather than implying they pass.
Applying Level AAA criteria (e.g., sign language interpretation, 7:1 contrast, no timing at all) as if they were required for a general AA conformance claim.
AAA criteria are memorable and often more concrete than AA ones, so they surface first in recall and get misattributed to the baseline requirement.
What to do instead
Anchor on the AA list as the default requirement. When a question does not specify a level, answer to AA but explicitly note that AAA criteria are enhanced and not required for AA conformance.
Assuming automated testing tools can certify accessibility, and answering that a clean automated scan means the page is conformant.
Tool output looks authoritative and quantitative, and candidates conflate 'no automated errors' with 'no barriers,' underestimating how many criteria require human judgment.
What to do instead
State that automated tools catch only a subset of issues and must be paired with manual checks and assistive-technology testing; never treat a zero-error scan as proof of conformance.
Evaluating color contrast using only the foreground and background hex values as written in CSS, ignoring state changes, opacity, gradients, images behind text, and large-text thresholds.
Contrast is treated as a simple two-color ratio problem, and candidates forget that hover/focus states, semi-transparent overlays, and text over images change the effective colors.
What to do instead
Check contrast in every state and against the actual rendered background (including images and overlays), and apply the correct ratio thresholds for normal versus large text as defined by the success criterion.
Conflating 'accessible name' with visible label text, and answering that an icon button with a tooltip or a placeholder is adequately labeled.
Visible text and tooltips feel like labels to sighted users, so candidates assume assistive technology receives the same information.
What to do instead
Distinguish the computed accessible name from visible text, placeholder, and title attributes; require a programmatic name (e.g., aria-label, associated label, or off-screen text) and verify it with an accessibility tree inspection.
Choosing ARIA attributes as the first fix for native HTML problems (e.g., adding role and tabindex to a div instead of using a button), and assuming ARIA adds behavior.
ARIA is heavily emphasized in training material, and candidates over-apply it, forgetting that ARIA changes semantics but not keyboard behavior or functionality.
What to do instead
Prefer native semantic elements first; use ARIA only to fill genuine gaps, and remember that adding a role does not add keyboard operability, focus management, or event handling.
Testing keyboard accessibility only with Tab and concluding the page is keyboard accessible, without checking focus visibility, focus order, focus trapping in dialogs, or operability of custom widgets with arrow keys and Escape.
Tab is the only key most testers use, and a page that tabs through controls appears to work even when composite widgets or dialogs are broken.
What to do instead
Test the full keyboard interaction model: visible focus indicator, logical order, no keyboard traps except intentional modal containment, Escape to dismiss, and arrow-key patterns for composite widgets.
Describing disability in medical/deficit terms or treating accessibility as a compliance afterthought, rather than applying the social model and inclusive design principles such as multiple means of representation and user control.
Candidates default to everyday language and compliance framing, which conflicts with the disability-awareness and inclusive-design framing the exam expects.
What to do instead
Frame barriers as mismatches between design and user diversity, use person-first or identity-first language as appropriate, and connect design decisions to inclusive principles like flexibility, perceptibility, and user control.
Treating a PDF or video as accessible because it was exported from an accessible source, without verifying tags, reading order, alt text, document title/language, captions, transcripts, and audio description in the final artifact.
Export is assumed to preserve accessibility, and candidates skip post-export verification of the delivered file.
What to do instead
Verify the final artifact independently: check tagged structure and reading order, alt text, title and language metadata, and for media confirm captions, transcripts, and audio description are present and accurate.
Conflating the legal/regulatory obligation with the technical standard, e.g., answering that a law such as the ADA or Section 508 itself specifies exact technical criteria, or citing WCAG 2.2 success criteria numbers that do not match the named requirement.
Regulations and standards are studied together, and candidates blur which document sets the legal duty versus which document supplies the technical criteria.
What to do instead
Separate the layers: identify the law or regulation as the obligation, the adopted standard/version as the technical benchmark, and the specific success criterion as the testable requirement, and keep citations consistent with the version named.