Computer accessibility Study Guide

📖 Core Concepts Computer accessibility (a11y) – Designing computers so anyone, regardless of disability, literacy, or digital fluency, can use them. Assistive technology – Specialized hardware/software (e.g., screen‑readers, braille displays) that works with mainstream systems to aid users. Accessibility API – Programming interface (MSAA, IAccessible2, UI Automation) that lets applications expose UI information to assistive tools. Open Accessibility Framework – Structured process (creation + use steps) for building platforms, UI elements, and authoring tools that support accessibility. Section 508 / WCAG 2.0 Level A‑AA – U.S. legal requirement; federal sites must meet these web‑content success criteria. ISO 9241‑171 – International ergonomic standard; defines “Required” vs. “Recommended” accessibility features and a testing checklist. --- 📌 Must Remember a11y = “accessibility” (11 letters omitted). Key built‑in features: Keyboard shortcuts, MouseKeys, Sticky Keys, bounce‑key, high‑contrast themes, customizable pointer. Visual aid hierarchy: large fonts → high‑DPI display → high‑contrast theme → screen magnifier → screen‑reader / braille. Motor aid hierarchy: keyboard shortcuts → alternate input devices (switches, joysticks) → speech‑recognition → barrier‑pointing UI. Hearing aid: replace system sounds with visual cues; provide closed‑captioning. API lineage: MSAA → IAccessible2 (ISO/IEC 13066‑3) → UI Automation (modern Windows). Section 508 rule: must meet WCAG 2.0 Level A + AA; four non‑web exceptions (Bypass Blocks, Multiple Ways, Consistent Navigation, Consistent Identification). ISO 9241‑171 priority: “Required” features must be implemented; “Recommended” are best‑practice extras. --- 🔄 Key Processes Implementing an Accessibility API (Windows) Identify UI elements → expose properties via MSAA/IAccessible2 → migrate to UI Automation for newer apps → test with screen‑reader. Creating an Accessible UI (Open Framework – Creation) Define platform‑wide accessibility requirements → provide stock, accessible UI controls → build authoring tools that enforce metadata (labels, roles, states). Deploying Assistive Tech (Open Framework – Use) Verify platform implements API → develop/apply accessible apps that use stock UI → distribute assistive devices (screen‑reader, magnifier, voice input). Designing for Visual Impairments Use scalable fonts & high‑DPI → add high‑contrast theme → enable screen‑magnifier → ensure all content reachable by screen‑reader (proper labels, ARIA roles). Designing for Motor Impairments Provide keyboard shortcuts for all actions → enable MouseKeys & Sticky Keys → support alternate input (switches, joysticks) → minimize precision needed (large hit targets, barrier‑pointing). --- 🔍 Key Comparisons Screen‑reader vs. Screen‑magnifier Screen‑reader: converts text to speech / braille; essential for blind users. Screen‑magnifier: enlarges on‑screen content; helps low‑vision users. Keyboard shortcuts vs. MouseKeys Keyboard shortcuts: direct key combos for specific commands. MouseKeys: numeric‑keypad emulation of mouse movement/clicks for users who cannot use a physical mouse. Sticky Keys vs. Bounce‑key Sticky Keys: lets modifier keys be pressed sequentially. Bounce‑key: filters rapid repeat presses of the same key. MSAA/IAccessible2 vs. UI Automation MSAA/IAccessible2: older Windows accessibility API (ISO/IEC 13066‑3). UI Automation: newer, richer API that replaces MSAA for modern Windows apps. --- ⚠️ Common Misunderstandings “Color‑only cues are accessible.” – False. Color alone fails for color‑blind users; always add shape, text, or icons. “Screen‑readers replace all visual needs.” – Not for low‑vision users who still need magnification or high‑contrast themes. “Sticky Keys automatically enable all shortcuts.” – Sticky Keys only changes how modifiers are entered; shortcuts still must be defined. “Section 508 only applies to web pages.” – Wrong; it covers all federal electronic and information technology, with limited non‑web exceptions. --- 🧠 Mental Models / Intuition “Layers of assistance” – Think of accessibility as stacking layers: visual (fonts, contrast) → magnification → auditory (screen‑reader). If one layer fails, the next must pick up the slack. “One UI, many adapters” – Build a single, well‑labeled UI; assistive technologies act as adapters that translate the same underlying information into speech, braille, or enlarged graphics. “API as a bridge” – Accessibility APIs are bridges; if the bridge is missing or broken, assistive tools can’t cross, no matter how good the UI looks. --- 🚩 Exceptions & Edge Cases Section 508 non‑web exceptions – Bypass Blocks, Multiple Ways, Consistent Navigation, Consistent Identification do not require WCAG compliance for PDFs, Office docs, etc. High‑DPI displays – Some legacy apps may not scale UI elements correctly; need explicit DPI‑aware coding. Switch‑accessible software – Works with a single switch only if UI follows a linear navigation order; random UI layouts can break it. --- 📍 When to Use Which Choose screen‑reader vs. magnifier – Use a screen‑reader when the user is blind or has severe vision loss; use magnifier when vision is reduced but not absent. Keyboard shortcuts vs. MouseKeys – Offer shortcuts for power users; enable MouseKeys when a user cannot operate a physical mouse but can manage a keypad. Sticky Keys vs. Bounce‑key – Enable Sticky Keys for users who cannot press multiple keys simultaneously; enable Bounce‑key for users who inadvertently repeat a key (e.g., tremors). MSAA/IAccessible2 vs. UI Automation – Use UI Automation for new Windows applications; fall back to MSAA/IAccessible2 only when supporting legacy software. --- 👀 Patterns to Recognize Color‑only alerts → always flagged as non‑compliant. Missing ARIA roles/labels in web‑based UI → screen‑reader will read “button” without purpose. Sequential keyboard focus order → indicates good tab navigation; broken order signals a navigation issue. Repeated keypresses without debounce → likely a bounce‑key problem for motor‑impairment users. --- 🗂️ Exam Traps “All assistive tech is hardware.” – Wrong; many are software (screen‑readers, speech‑recognition). “If a UI has high contrast, it’s fully accessible.” – Misleading; must also avoid color‑only cues and provide text alternatives. “Section 508 only cares about WCAG Level A.” – Incorrect; it requires both Level A and Level AA success criteria. “UI Automation automatically fixes accessibility.” – False; the API only exposes information; developers must still supply proper labels and states. ---