IAAP CAP common mistakes
IAAP CAP · Understand the traps and how to avoid them.
Answering a question about legal obligation by citing WCAG success criteria (e.g., 'what does the law require a US federal agency's website to do?' answered as 'meet WCAG 2.0 Level AA').
Most study time goes into memorizing WCAG checklists, so the standard becomes the default answer even when the question is about scope, entity type, or enforcement.
What to do instead
Build a two-layer model and rehearse it: the law/regulation (ADA titles, Section 508, EN 301 549, national accessibility acts) establishes who must do what; the standard (WCAG version and level) supplies the technical test, and is only binding because a law or policy incorporates it by reference. Before answering, decide which layer the question is asking about.
Describing disability purely as a personal medical condition to be accommodated, and treating accessibility as an accommodation added after a product is built.
Everyday language and many workplace trainings still use the medical/deficit framing, so it feels like the neutral default, and accessibility gets filed next to HR accommodations rather than design.
What to do instead
Practice stating the social and human-rights models explicitly: disability arises from the interaction between a person's impairment and environmental or attitudinal barriers, so removing barriers is a design responsibility, not an individual fix. Ground answers in the principle 'nothing about us without us' and in universal/inclusive design (design for the edges benefits everyone).
Treating a clean automated scan (zero axe/Lighthouse violations) as evidence that a page conforms to WCAG.
Automated tools produce a satisfying, concrete score, and stakeholders ask for exactly that number; the tools themselves are marketed as 'accessibility testing'.
What to do instead
State the limitation concretely: automation reliably detects only a minority of success criteria and cannot judge alt-text quality, meaningful reading sequence, link purpose in context, or whether focus order makes sense. Treat scan results as a screening baseline, then add manual keyboard/screen-reader checks and expert review to reach a conformance claim.
Assuming a PDF is accessible because it has been 'tagged' (e.g., one-click autotag in Acrobat reported success), and signing it off without inspecting the tag tree.
The remediation UI presents tagging as a single completed action, and the file 'looks fine' visually when reopened.
What to do instead
Verify the artefacts that autotagging routinely gets wrong: tag tree structure and correct use of headings/lists/tables, reading order matching the visual order, alt text on meaningful images, decorative content marked as an artefact, labelled form fields, table header associations, and document language/title. Where possible, fix the source document and re-export rather than patching the PDF.
Using 'captions', 'transcript', 'audio description' and 'auto-generated captions' interchangeably when answering questions about time-based media.
In consumer products these features are collapsed into one 'subtitles' button, and auto-captioning is now default in many platforms, which blurs the distinctions.
What to do instead
Memorize the distinct requirements and when each applies: transcript for audio-only pre-recorded content; synchronized captions for pre-recorded video with audio; live captions for live audio; audio description (or a descriptive transcript/media alternative) for visual information not conveyed in the audio track. Machine captions only count after human review and correction for accuracy, punctuation, speaker identification and meaningful sound.
Assuming assistive technology renders a page the way the browser displays it - e.g., that a screen reader follows visual left-to-right layout, or that adding ARIA roles will make a div behave like a native control.
Candidates test almost exclusively with a mouse, a visual browser and dev tools, so the accessibility tree and AT output are never observed directly.
What to do instead
Learn and apply 'the first rule of ARIA': use the native HTML element that already has the semantics and behaviour, and only add ARIA to fill genuine gaps. Reinforce it by doing hands-on testing - navigate with keyboard only, then with a screen reader - and observe that reading order follows DOM order, and that broken ARIA is worse than no ARIA.
Carrying digital-only thinking into built-environment questions - e.g., defining an accessible facility as 'wheelchair access' or a ramp, and evaluating it against WCAG rather than accessibility standards for buildings.
Digital accessibility dominates study material and job experience, so the physical domain gets skimmed, and 'accessible = wheelchair' is a widespread shorthand.
What to do instead
Study the built-environment construct as a set of measurable features: an accessible route connecting site arrival points, entries, and all functional areas; clear floor space and turning space; reach ranges; operable parts; protruding objects; surface and slope tolerances; and equivalent experience for people with sensory and cognitive disabilities. Keep the governing documents separate in your head (e.g., ADA Standards for Accessible Design / ABA standards, not WCAG).
Treating a vendor's completed VPAT/ACR as proof of conformance and closing the procurement review once the document is received.
An ACR is a familiar, standardized-looking deliverable that satisfies a checklist step, and procurement staff often lack the technical background to challenge it.
What to do instead
Treat the ACR as a self-reported claim, not evidence: check that it names the correct WCAG version/level and product version, look for 'Partially Supports' and 'Not Applicable' entries (the real risk sits there), request the test methodology and dated audit report, require a demos/keyboard walkthrough, and encode remediation timelines, acceptance criteria and termination rights in the contract.
Running 'accessibility testing' sessions only with screen-reader users recruited from personal networks, and reporting the results as a conformance verdict.
Screen-reader testing is the most visible and easiest to describe form of disability user testing, and convenience recruiting is faster than structured recruitment.
What to do instead
Separate the two activities in design and reporting: conformance evaluation is measured against WCAG success criteria by trained evaluators, while usability testing with people with disabilities asks whether real tasks can be completed. Recruit across disability types relevant to the product (vision, hearing, motor, cognitive, speech), include people who use different AT and different proficiency levels, compensate participants, and report findings as task-level usability evidence alongside - not instead of - conformance results.
Proposing a single annual 'accessibility awareness' session for all staff as the organizational-change remedy.
Training is the most familiar lever and a one-off session is easy to budget and tick off, so it becomes the default answer to any culture or capability question.
What to do instead
Design role-based, recurring capability building with measurable outcomes: different curricula for designers, developers, content authors, QA, procurement and executives; embedded checkpoints in existing processes (definition of done, design review, acceptance criteria); onboarding plus refresher cadence; and evaluation through behaviour indicators such as defect rates, audit findings and process adoption rather than attendance counts.