The CPACC domains reward contrast, not memorized lists. For every term you study, write what it is not, one contrasting example, and the category of barrier it addresses. Classify barriers under the correct POUR principle, name the model of disability a statement assumes, match conformance levels to their cumulative meaning, and pair each testing method with what it can and cannot detect. Then verify your understanding with a keyboard-only walkthrough and a written self-check rubric. This comparison-first structure turns vague familiarity into usable discrimination you can apply to unfamiliar scenarios.
Why POUR Is a Classification Tool, Not a Slogan
POUR organizes WCAG into four principles: Perceivable, Operable, Understandable, and Robust. The practical skill is assigning a barrier to the correct principle, because the assignment determines the category of fix you look for.
Treat each principle as a diagnostic question. Perceivable: can users sense the content through sight, hearing, or touch, including via assistive technology? Operable: can users complete every interaction with whatever input method they have? Understandable: are content and behavior predictable and comprehensible? Robust: does the code let diverse user agents and assistive technologies interpret the content reliably? Running a barrier through these four questions in order turns an open-ended problem into a bounded one.
Now contrast adjacent problems. Low-contrast text fails Perceivable even though the text exists on screen. A form that only responds to mouse clicks fails Operable, not Perceivable, even though a blocked keyboard user describes the outcome similarly. Dense jargon without definitions is Understandable. Micro-scenario: an icon-only button has no accessible name. The plausible mistake is filing it under Perceivable because users cannot tell what it does; the stronger classification is Robust, because the fix is exposing a programmatic name and role in the markup. Practice stating the principle before stating the fix.
- Perceivable — can the content be sensed through at least one channel, including assistive technology?
- Operable — can every function be reached and triggered without requiring a specific input device?
- Understandable — would meaning and expected behavior be clear on first encounter?
- Robust — does the code communicate purpose to browsers and assistive technologies, not just to human eyes?
Medical, Social, and Economic Models: Which Lens a Statement Assumes
The medical model locates disability in a person's condition; the social model locates it in environmental and attitudinal barriers; economic and functional lenses frame it through costs or task limits. Naming the lens clarifies which solutions follow.
Under the medical model, the impairment is the problem, so responses center on treatment or individual adaptation. The social model locates disability in the mismatch between a person and an environment built for a narrow default, so the response is removing the barrier. A functional lens asks which tasks someone can complete in context; an economic lens frames accessibility through market reach or productivity. Apply the lens test to any sentence: 'the website lacks keyboard support' is social-model phrasing; 'she cannot use it because of her tremor' is medical-model phrasing that implies the person should adapt.
Worked scenario: a manager proposes solving an inaccessible intranet by assigning a staff member to read documents aloud to a blind colleague. The plausible mistake is treating the impairment as the problem, which creates a permanent dependency and a staffing bottleneck. The better decision is fixing document structure so screen readers navigate it independently. Why it matters: the social-model framing produces a scalable fix that benefits every future reader, while the medical-model framing produces one fragile, human-dependent workaround. Name the lens a proposal assumes before judging its solution.
Universal Design, Accessible Design, and Assistive Technology Compared
Accessible design makes a specific product usable by people with disabilities; universal design serves the widest range of users from the start; assistive technology is equipment the user brings. These operate at different layers and should not be conflated.
The layers answer different questions. Accessible design asks whether a specific artifact works for people with disabilities, often measured against a standard. Universal design asks whether it serves the broadest range of people without special versions. Assistive technology — screen readers, switch devices, magnification software — is the user's own equipment; the product's job is compatibility, not replacement. An accessible product cooperates with assistive technology; a universal product often needs less of it in the first place.
Check the direction of effort in scenarios. Replacing stairs with a ramp helps wheelchair users and also people with strollers and luggage: universal design thinking. Retrofitting a PDF with tags and alt text is accessible design applied late. A refreshable braille display is assistive technology, which only receives meaningful content if the markup is semantic. For planning: universal approaches reduce retrofit work but demand earlier investment; retrofits are targeted and fast but leave design assumptions unexamined. Neither is superior by default — life-cycle position decides, which is why the organizational domain builds on this vocabulary.
| Concept | Core question it answers | Who primarily benefits | Concrete example |
|---|---|---|---|
| Accessible design | Does this artifact work for people with disabilities, often against a standard? | People with disabilities using this specific artifact | Adding heading structure and alt text to a report |
| Universal design | Can this artifact serve the widest range of users without special versions? | Everyone, including disabled and non-disabled users | Captioned video aiding deaf viewers, language learners, and noisy rooms |
| Assistive technology | Is the product compatible with the equipment the user brings? | The individual using that equipment | A screen reader navigating only if markup is semantic |
WCAG Conformance Levels: What 'Meets AA' Actually Claims
WCAG is structured as principles containing guidelines containing success criteria, with levels A, AA, and AAA. Conformance is cumulative: meeting AA means satisfying every Level A and Level AA success criterion, not merely passing a scanning tool.
Read the structure in both directions. Top-down, the four POUR principles organize the document; bottom-up, each success criterion is a specific, testable statement assigned to a level. Internalize the cumulative rule: satisfying every AA criterion automatically satisfies every A criterion, so an AA claim requires all Level A failures resolved too. AAA criteria are enhanced targets with their own conditions, and 'some AAA features were applied' is not the same as full AAA conformance.
Worked scenario: a team runs an automated audit, the tool reports zero violations, and they declare Level AA conformance. The plausible mistake is treating a clean scan as the claim. Automated tools catch code-detectable issues such as missing alt attributes or low contrast, but many Level A and AA criteria need human judgment: whether alt text is meaningful, whether focus order is logical, whether headings describe real structure. The better decision is mapping every criterion at the target level, marking each as passing only after a human check or a documented exception. Why it matters: conformance is a claim about a defined scope, and a tool-only claim covers a subset of criteria at best. POUR then becomes your audit skeleton: walk the four principles and ask which criteria at the target level apply, surfacing items no scanner mentions, such as whether page titles describe their topics.
Matching Disability Categories to Barrier and Adjustment Patterns
Visual, auditory, motor, cognitive, speech, and vestibular or seizure-related needs each predict characteristic barriers. The applied skill is reasoning from category to barrier to adjustment, rather than memorizing an unstructured list of accommodations.
Work the chain in one direction: category, then barrier, then adjustment. Blindness and low vision create barriers with visual-only information, so adjustments supply non-visual equivalents: alt text, semantic structure, sufficient contrast. Deafness and hearing loss create barriers with audio-only information, met by captions, transcripts, and visual alerts. Motor impairments that limit precision or endurance create barriers with small targets and drag-only interactions, met by full keyboard operability and flexible input methods. Cognitive and learning differences create barriers of complexity, memory load, and unpredictability, met by plain language, consistent layouts, and error tolerance.
Two contrasts deserve explicit care because they blur easily. Vestibular conditions involve balance and spatial orientation: motion-triggered animation can cause dizziness, so the adjustment respects reduced-motion preferences. Photosensitive seizure risk involves intense flashing, so the adjustment limits flash sequences. A third: speech disabilities affect producing spoken output, so voice-only interfaces are the barrier and text channels are the adjustment. Exercise: pick three sites you use weekly and name one barrier per category, or record that you could not. Expected observation: visual and motor barriers surface quickly, while cognitive barriers such as inconsistent navigation require comparing pages over time — an asymmetry that predicts what a quick surface review misses.
- Visual: visual-only information is the barrier; text alternatives, structure, and contrast are the adjustments.
- Auditory: audio-only information is the barrier; captions, transcripts, and visual alerts are the adjustments.
- Motor: input precision and endurance demands are the barrier; keyboard operability and flexible input are the adjustments.
Automated, Manual, and User Testing: What Each Method Can and Cannot Find
Automated tools verify code-detectable criteria quickly and repeatedly. Manual evaluation, especially keyboard and assistive-technology walkthroughs, catches interaction failures. Testing with people with disabilities reveals task-level usability. Each method needs the others.
Assign each method its strength. Automated scanning is fast and repeatable, valuable for regression checks, but it evaluates markup, not meaning: it can confirm an alt attribute exists without judging whether the text is accurate. Manual evaluation brings judgment to focus order, meaningful labels in context, and whether interactive components announce their state. Usability testing with people who use assistive technology adds what neither reaches: whether a technically compliant flow is actually efficient and comprehensible to complete.
Worked scenario: a scanner reports no violations on a checkout flow, but a keyboard-only tester opens the confirmation modal and cannot move focus into it; Tab cycles behind the overlay and Escape does nothing. The plausible mistake is trusting the zero-violation report and shipping, since modal focus management is a runtime interaction no static scan exercises. The better decision is a keyboard-only pass through every interactive flow before sign-off, checking that focus enters the modal, stays inside while open, and returns to the trigger on close. Why it matters: the failure blocks keyboard users at the most consequential step, and only a method that operates the interface like a keyboard user can surface it.
- Keyboard-only form walkthrough rubric — score each row 0 fail / 1 partial / 2 pass:
- Every field reachable and operable by keyboard alone.
- A visible focus indicator present at all times.
- Tab order matches the visual layout.
- Custom controls are operable and their state perceivable.
- Error messages are obvious without mouse hover.
- Eight or more of ten suggests your manual evaluation skills are solidifying; treat it as a learning milestone, not a prediction, and repeat across menus, tables, and dialogs.
Organizational Accessibility: Governance, Procurement, and Life-Cycle Position
The organizational domain covers policy, roles and training, procurement, and maturity over time. The core insight is that life-cycle position changes the right intervention: prevention during design, correction during development, remediation after release.
Anchor this domain in the life cycle. Requirements set before design make accessibility a default condition; the same fixes after release cost more because design assumptions, markup, and content all change. Procurement is the leverage point before code exists: asking vendors how their products support accessibility standards, and requiring that support contractually, keeps inaccessible tools out of the environment. Governance then sustains it through named responsibility, defined roles across design, development, content, and quality assurance, and ongoing training that outlives any single champion.
Contrast two postures. A reactive organization discovers problems through complaints or legal exposure, fixes them ad hoc, and has no shared internal definition of accessible. A mature organization has a policy naming its target standard, integrates checks into existing workflows, measures progress over time, and treats disabled users' feedback as routine input. A policy alone is not maturity; policy, roles, training, measurement, and procurement together capture it. Readiness checks before the exam: you can classify an unfamiliar barrier under the correct POUR principle and say why adjacent principles fail, state the cumulative meaning of each conformance level from memory, name the model a scenario assumes, and describe one thing each testing method finds that the others cannot. For administrative details about the credential itself, consult the issuer, the International Association of Accessibility Professionals, at accessibilityassociation.org.
- Week 1: master POUR classification and the disability models with ten self-written examples.
- Week 2: work WCAG structure and conformance logic; write out what an AA claim does and does not assert.
- Week 3: practice barrier-to-adjustment chains and run the keyboard rubric on three component types.
- Week 4: study organizational scenarios; write a paragraph each on policy, procurement, and maturity, then close gaps your rubric exposed. Adjust pacing to your schedule; preserve the ordering from classification to application to organization.
References and further reading
Use these references to explore the concepts and check the latest information from the relevant organizations.