Web accessibility Study Guide

📖 Core Concepts Web Accessibility – Inclusive design that removes barriers for people with physical, situational, or socio‑economic disabilities. POUR Principles – The four WCAG foundations: Perceivable: content can be seen or heard. Operable: interface can be used with keyboard, switch, voice, etc. Understandable: information and UI are clear. Robust: works with current and future assistive technologies. Semantic HTML – Proper element choice (<nav>, <button>, headings) gives screen readers the meaning they need without extra code. Assistive Technologies (AT) – Tools that read, magnify, or control the web for users: screen readers, refreshable braille displays, screen magnifiers, speech recognition, keyboard overlays. WAI‑ARIA – A set of attributes (role, aria‑pressed, aria‑label, etc.) that add semantic info to custom widgets where native HTML is insufficient. Success Criteria – Testable statements (e.g., “Provide text alternatives for non‑text content”) that define compliance levels (A, AA, AAA). --- 📌 Must Remember WCAG 2.0 = ISO/IEC 40500:2012; WCAG 2.1 adds mobile & cognitive criteria. US Legal Backbone: Section 508 (federal e‑tech). Section 504 (federal‑funded entities). ADA Title III – DOJ endorses WCAG 2.0 AA as the standard. EU Directive – Public‑sector sites must meet WCAG 2.1 AA. Key POUR Goal Statements – “All users can perceive, operate, understand, and remain robust with the content.” ARIA Rule of Thumb – Use native HTML first; add ARIA only when no native element exists. --- 🔄 Key Processes Accessibility Audit Workflow Run automated scanner → collect quick violation list. Conduct expert manual review → verify scanner results, catch context‑specific issues. Perform user testing with real disability users → uncover practical barriers. Prioritize fixes by severity and compliance level (A → AA → AAA). Implementing ARIA for a Custom Widget Identify missing native semantics. Add appropriate role (e.g., role="button"). Attach state attributes (aria‑pressed, aria‑expanded). Provide an accessible name (aria‑label or aria‑labelledby). Manage focus: set tabindex="0" if needed and ensure logical tab order. Creating Text Alternatives For every non‑text element, write concise alt text describing function. If the image is decorative, use empty alt="". Provide captions & transcripts for audio/video. --- 🔍 Key Comparisons WCAG 2.0 vs WCAG 2.1 2.0: baseline web content. 2.1: adds criteria for mobile gestures, low‑vision, and cognitive needs. Screen Reader vs Refreshable Braille Display Screen Reader: converts text/UI to synthesized speech. Braille Display: renders text as tactile Braille; often paired with a keyboard. Native HTML vs ARIA Native HTML: built‑in accessibility, no extra code. ARIA: supplemental when native semantics are unavailable. --- ⚠️ Common Misunderstandings “Color alone marks links.” – Links must be underlined or otherwise differentiated, not just colored. “Automated tools catch every issue.” – They miss context, keyboard focus problems, and many cognitive barriers. “Adding ARIA fixes everything.” – ARIA cannot replace missing native elements and may introduce new bugs if misused. “WCAG 2.2 is required.” – The outline only covers WCAG 2.0 & 2.1; 2.2 is outside current source material. --- 🧠 Mental Models / Intuition “Missing Ability” Lens – Imagine what a user cannot do (see, hear, move mouse) and ask how your site works without that ability. POUR as a Checklist – Scan each page for Perceivable, Operable, Understandable, Robust items before moving on. --- 🚩 Exceptions & Edge Cases ARIA Use – Do not apply role="button" to a <button>; it creates redundancy. Flashing Content – Any animation that flashes >3 times/second must be optional or have a pause control. Large Click Targets – Minimum target size ≈ 44 × 44 px (or equivalent CSS rem units) for motor‑impaired users. --- 📍 When to Use Which Automated Scan – Quick, early‑stage identification of obvious violations (missing alt, contrast). Expert Manual Review – Complex interactive widgets, ARIA implementation, focus order. User Testing – Validate real‑world usability, especially for cognitive or situational disabilities. ARIA vs Native – Choose ARIA only when a widget cannot be built with a native element that already provides the needed semantics. --- 👀 Patterns to Recognize Missing Alt Text – without alt or with generic text. Insufficient Color Contrast – Text/background ratio < 4.5:1 (normal text). Keyboard Traps – Elements that can receive focus but lack a way to exit or are skipped in tab order. Non‑Descriptive Links – “Click here” without context; should convey purpose. Unlabeled Form Controls – Inputs without <label> or aria‑label. --- 🗂️ Exam Traps Distractor: “Using only a different font color for links satisfies WCAG.” – Wrong; links need visual distinction beyond color. Distractor: “If a page passes an automated tool, it is fully compliant.” – Wrong; manual and user testing are required. Distractor: “ARIA can be added to any element to make it accessible.” – Wrong; native HTML is preferred; ARIA misuse can break AT. Distractor: “Section 508 applies to all private websites in the US.” – Wrong; it applies to federal agencies and contractors. Distractor: “WCAG 2.1 is optional for mobile sites.” – Wrong; it adds required criteria for mobile accessibility.