WAS cheat sheet
WAS · Keep the key ideas within reach.
Accessibility Fundamentals and Disability Models
Medical model locates disability in the individual and aims to cure or fix; social model locates it in barriers created by environment and attitudes.
Biopsychosocial model (WHO ICF) combines health condition, activity limitations, participation restrictions, and contextual factors including environment and personal traits.
ICF components: body functions and structures, activities, participation, environmental factors, personal factors; functioning is the interaction, not a single trait.
Impairment categories relevant to WCAG: visual (blindness, low vision, color vision deficiency), auditory, motor/dexterity, cognitive, learning, neurological, speech, vestibular, and seizure-related.
Legal anchors: ADA Titles I-III (US), Section 508 (US federal procurement, incorporates WCAG 2.0 AA by reference), EN 301 549 (EU procurement), European Accessibility Act, AODA (Ontario).
Section 508 refresh (2017) requires WCAG 2.0 Level A and AA success criteria for web content; Revised 508 also covers software, hardware, and support documentation.
POUR is the organizing framework of WCAG: Perceivable, Operable, Understandable, Robust; each principle contains guidelines, then testable success criteria.
Temporary and situational limitations (broken wrist, bright sunlight, noisy train) follow the same design constraints as permanent disabilities; the curb-cut effect describes benefits to all users.
Person-first vs identity-first language is a preference, not a rule; follow the individual's or community's stated preference rather than assuming one form.
WCAG 2.x Principles, Guidelines, and Success Criteria
WCAG 2.x has 4 principles, 13 guidelines, and 78 success criteria in WCAG 2.1 (87 in WCAG 2.2 after adding 9 and removing 4.1.1 Parsing).
Conformance levels: A is the minimum, AA is the common legal and policy target, AAA is enhanced and not required as a blanket level because some criteria cannot be satisfied for all content.
Conformance requires full pages (not partial), all content on the page, and complete processes; a page with one Level AA failure cannot claim AA.
WCAG 2.2 removed 4.1.1 Parsing because modern browsers and parsers handle markup robustly; duplicate IDs remain a best-practice concern, not a 2.2 failure.
New in WCAG 2.2: 2.4.11 Focus Not Obscured (Minimum, AA), 2.4.12 Focus Not Obscured (Enhanced, AAA), 2.4.13 Focus Appearance (AAA), 2.5.7 Dragging Movements (AA), 2.5.8 Target Size (Minimum, AA, 24x24 CSS px), 3.2.6 Consistent Help (A), 3.3.7 Redundant Entry (A), 3.3.8 Accessible Authentication (Minimum, AA).
New in WCAG 2.1: 1.3.4 Orientation, 1.3.5 Identify Input Purpose, 1.3.6 Identify Purpose, 1.4.10 Reflow, 1.4.11 Non-text Contrast, 1.4.12 Text Spacing, 1.4.13 Content on Hover or Focus, 2.1.4 Character Key Shortcuts, 2.2.6 Timeouts, 2.3.3 Animation from Interactions, 2.5.1 Pointer Gestures, 2.5.2 Pointer Cancellation, 2.5.3 Label in Name, 2.5.4 Motion Actuation, 4.1.3 Status Messages.
Contrast thresholds: 1.4.3 Contrast (Minimum) requires 4.5:1 for normal text and 3:1 for large text (18pt or 14pt bold); 1.4.6 (AAA) requires 7:1 and 4.5:1; 1.4.11 Non-text Contrast requires 3:1 for UI components and graphical objects needed to understand content.
1.4.10 Reflow: content must reflow to 320 CSS px width without two-dimensional scrolling, except content requiring two-dimensional layout (maps, data tables, video).
1.4.12 Text Spacing: no loss of content when line height is 1.5x, paragraph spacing 2x, letter spacing 0.12em, and word spacing 0.16em.
2.2.1 Timing Adjustable requires turn off, adjust, or extend for time limits, with exceptions for real-time events and limits over 20 hours; 2.2.2 Pause, Stop, Hide applies to moving content over 5 seconds.
2.5.8 Target Size (Minimum) requires 24x24 CSS px, with exceptions for spacing (24 px circle not intersecting another target), inline text links, user-agent control, and essential presentation.
3.3.8 Accessible Authentication (Minimum) forbids requiring a cognitive function test (memory, puzzle, transcription) unless an alternative or mechanism to assist is provided; password managers and paste must be supported.
Semantic HTML and Accessible Markup
Use native elements first: button for actions, a href for navigation, input with label for form fields; native elements carry role, state, and keyboard behavior for free.
One h1 per page is a convention, not a WCAG rule; heading levels must not skip (h2 to h4) because assistive technology users navigate by heading hierarchy.
Landmark elements: header (banner), nav, main, aside (complementary), footer (contentinfo), section with accessible name (region), form with accessible name (form); multiple instances of the same landmark need distinct labels.
Every form control needs an accessible name via label for/id, aria-label, or aria-labelledby; placeholder is not a label and disappears on input.
Tables: use th with scope=col or scope=row for simple tables; use caption for the table title; complex tables need headers/id associations or a described alternative.
Images: alt text for informative images, alt="" for decorative images, and no alt attribute only when the image is not yet available; never put essential text only inside an image.
Lists: ul/ol/li for grouped items, dl/dt/dd for term-definition pairs; CSS list-style:none can remove list semantics in Safari, so add role=list when needed.
Page language: html lang attribute is required (3.1.1); lang on inline elements marks language changes within content (3.1.2).
Skip links must be the first focusable element and target a main content region with a valid id; they must become visible on focus.
Accessible Rich Internet Applications (WAI-ARIA)
First rule of ARIA: do not use ARIA if a native HTML element or attribute already provides the needed semantics and behavior.
ARIA changes the accessibility tree only; it does not add keyboard behavior, focus management, or event handling. Custom widgets need JavaScript.
Roles fall into categories: landmark, widget, document structure, and live region; abstract roles (widget, input, range) must never be authored.
States and properties: aria-expanded, aria-checked, aria-selected, aria-pressed, aria-disabled, aria-hidden, aria-current, aria-describedby, aria-labelledby, aria-controls, aria-haspopup.
aria-hidden="true" removes content from the accessibility tree but does not remove it from the tab order; never apply it to focusable elements.
Live regions: aria-live="polite" waits for idle, aria-live="assertive" interrupts; role=status implies polite, role=alert implies assertive; aria-atomic and aria-relevant control announcement scope.
Live regions must exist in the DOM before content is injected; adding the region and its content at the same time often produces no announcement.
Accessible name computation order: aria-labelledby, then aria-label, then native labeling (label, alt, title), then contents; aria-labelledby wins over aria-label.
Widget patterns require roving tabindex or aria-activedescendant for composite widgets (tabs, menus, grids, listboxes); only one item in the tab order at a time.
Roles requiring required owned elements: list requires listitem, tablist requires tab, menu requires menuitem, radiogroup requires radio; missing children break the pattern.
Assistive Technology Compatibility and Testing
Screen reader and browser pairs to test: NVDA with Firefox or Chrome (Windows), JAWS with Chrome (Windows), VoiceOver with Safari (macOS and iOS), TalkBack with Chrome (Android).
Automated tools (axe, Lighthouse, WAVE) detect roughly 20-40 percent of issues; they cannot judge alt-text quality, reading order, focus order logic, or cognitive load.
Manual keyboard test: Tab through the page, confirm visible focus, logical order, no keyboard trap, and that Enter/Space activate controls and Escape closes overlays.
Screen reader test flow: headings list, landmarks list, link list, form field list, table navigation, and reading order of dynamic updates.
Zoom and reflow test: 200 percent browser zoom, 400 percent zoom at 1280 px width (equivalent to 320 CSS px), and 200 percent text-only spacing overrides.
Accessibility tree inspection via browser DevTools shows computed role, name, and states; use it to verify ARIA results rather than guessing from the DOM.
Windows High Contrast Mode and forced-colors media query: test that borders and focus indicators survive when background images and colors are stripped.
Reduced motion: prefers-reduced-motion media query and 2.3.3 Animation from Interactions; also test 2.2.2 for auto-playing content.
Regression testing: add automated checks to CI, but gate releases on manual test scripts for new components and interactive patterns.
Accessible Design, CSS, and Responsive Layout
Use relative units (rem, em) for font sizes and line height so text resizes to 200 percent without loss of content (1.4.4 Resize Text).
Never set outline:none without a replacement; use :focus-visible to style focus for keyboard users and keep a visible indicator with at least 3:1 contrast against adjacent colors.
Reflow: use flexbox, grid, and max-width rather than fixed pixel widths; avoid horizontal scrolling at 320 CSS px.
Color alone must not convey information (1.4.1); pair color with text, pattern, icon, or underline for links and error states.
Touch targets: aim for 44x44 CSS px (Apple HIG) or 48x48 dp (Material); WCAG 2.2 minimum is 24x24 CSS px with spacing exceptions.
Text spacing overrides must not clip content: avoid fixed heights on text containers and use min-height instead of height.
CSS-generated content (::before/::after) is read inconsistently by screen readers; do not use it for meaningful text or form labels.
Responsive tables: allow wrapping, use responsive patterns (stacked cards with labels) rather than horizontal scroll where possible; data tables may scroll per the reflow exception.
Dark mode and contrast: verify contrast ratios separately for each theme; a passing light theme does not guarantee a passing dark theme.
Accessibility Program Governance and Remediation
Maturity stages: reactive (fix complaints), planned (audits and backlog), proactive (design and code standards in the SDLC), and embedded (accessibility is a definition of done).
VPAT and ACR: a VPAT is the template; an Accessibility Conformance Report is the completed document, typically citing WCAG 2.x A/AA and Section 508.
Remediation prioritization: fix blockers first (keyboard traps, missing names, contrast failures on critical flows), then high-traffic templates, then long-tail content.
Accessibility statement should list conformance target, known limitations, feedback contact, and enforcement or escalation route; keep it dated and versioned.
Design system ownership: accessible components built once and reused reduce defect volume; publish usage rules, do/don't examples, and test coverage per component.
Procurement: require a current ACR, ask for the test methodology and date, and request a remediation roadmap for known gaps before purchase.
Training roles: designers need contrast, focus, and target-size rules; developers need semantics, ARIA, and keyboard patterns; authors need alt text and heading structure.
Metrics that matter: percent of critical user journeys passing manual tests, defect age, component coverage, and audit re-test pass rate; page counts alone are weak signals.
Legal risk management: document audits, remediation decisions, and exceptions with owners and dates; an undocumented known barrier is harder to defend than a tracked one.