WAS study plan

Map the four WCAG 2.2 principles (Perceivable, Operable, Understandable, Robust) to their guidelines and state how many success criteria sit under each principle

Classify each Level A success criterion by conformance level and write a one-sentence plain-language summary of what it requires

Distinguish conformance levels A, AA, and AA-plus-targeted criteria, and explain which level most legal and procurement policies reference

Identify the five WCAG 2.2 criteria new since 2.1 and state what each one adds

Explain the difference between conformance, partial conformance, and statement of partial conformance for third-party content

Apply the text alternatives and non-text content criteria to decide when alt text is empty, descriptive, or redundant

Evaluate color contrast ratios for normal and large text and for non-text UI components against the AA thresholds

Write semantic HTML for headings, landmarks, lists, tables, and forms that satisfies the relevant structure criteria without ARIA

Diagnose common markup failures such as skipped heading levels, layout tables, unlabeled inputs, and div-based buttons

Explain how reflow, text spacing, and resize-text criteria affect page structure choices

Select native HTML elements over ARIA roles whenever a native equivalent exists, and justify each exception

Construct an accessible modal dialog, disclosure widget, and tab set using the appropriate ARIA roles, states, and properties

Implement the five rules of ARIA use and identify markup that violates each rule

Manage focus and keyboard interaction patterns for composite widgets according to the ARIA Authoring Practices patterns

Define accessible names and descriptions using aria-label, aria-labelledby, and aria-describedby, and predict the computed name

Build a screen reader test script covering headings, landmarks, forms, tables, dynamic updates, and error handling, and run it with at least one desktop screen reader

Compare what the accessibility tree exposes for a native control versus a custom ARIA widget, and document the differences

Test keyboard-only operation including focus order, visible focus, skip links, and keyboard traps

Contrast the medical, social, and biopsychosocial models of disability and explain how each model frames an accessibility failure

Match categories of assistive technology (screen readers, magnification, switch access, speech input, braille displays) to the user needs they serve

Run automated scans and triage the results, separating confirmed failures from false positives and manual-check-required items

Apply the accessibility tree, computed role, and computed name checks in browser developer tools to debug ARIA defects

Design focus indicators and focus-visible styles that meet the non-text contrast and focus appearance requirements

Implement responsive layouts that satisfy reflow at 320 CSS pixels and 400 percent zoom without two-dimensional scrolling

Use CSS to respect prefers-reduced-motion, prefers-color-scheme, and forced-colors mode without breaking content

Evaluate motion, animation, and auto-updating content against the pause, stop, hide, and flashing thresholds criteria

Apply the target size, dragging movements, and pointer gestures criteria to interactive components

Assess media alternatives: captions, audio description, transcripts, and media player keyboard accessibility

Diagnose content that fails on text spacing overrides, orientation lock, or hover and focus content dismissal

Explain how CSS-only techniques can hide content from assistive technology and when that is a failure

Draft an accessibility policy that names the conformance target, scope, roles, and exception process

Define a remediation workflow with severity ratings, ownership, and service-level targets for each severity

Design an accessibility statement that meets the transparency expectations of the relevant criteria and legal frameworks

Plan how accessibility gates enter design review, code review, and release checklists

Outline a training and role-based onboarding plan for designers, developers, and content authors

Assemble a full practice exam across all seven domains and score it by domain to expose weak areas

Re-drill the three weakest domains using the criteria index and defect log from earlier weeks

Produce an executive summary that translates audit findings into business risk and prioritized remediation

Verify recall of the conformance levels, the WCAG 2.2 additions, and the ARIA rules without notes