audio description version linked but broken, region-blocked, or behind different auth than the main video.
learning hub
WCAG 2.2 Accessibility Scenario Learning Hub
A guided course for learning accessibility through realistic, industry-grounded product scenarios. Each scenario carries a unique real-world example, plain-language explanation, and a direct reference to the official WCAG 2.2 Understanding document.
301 scenarios
Module · Perceivable
1.2.5 — Audio Description (Prerecorded)
Prerecorded videos need an audio description track describing important visual-only content.
Player offers audio description toggle that doesn't function or resets on each chapter.
Claiming "no audio description needed" for videos that do contain meaningful visual info (talking-head exemption misapplied when slides/demos appear).
At AA, providing only a transcript and no audio description when pauses exist to accommodate description (transcript satisfied 1.2.3 but not 1.2.5).
Module · Perceivable
1.3.1 — Info and Relationships
Structure you can SEE (headings, lists, tables, labels, groups, required marks) must also exist in the code so screen readers perceive the same structure.
Text is made to LOOK like a heading or emphasized (big, bold, indented) using styling only, so screen readers treat it as ordinary text and users miss the structure.
Spaces/tabs are used to fake side-by-side columns in plain text — read aloud, the lines interleave into nonsense.
Spaces/tabs are used to fake a table in plain text — there are no real rows, columns, or headers for a screen reader to navigate.
Something is made to act like a link or button using script only (a clickable div/span) — it isn't announced as a link/button and often can't be used by keyboard.
Structural markup is used for looks, not meaning (e.g., blockquote just to indent, a heading tag just for big text) — screen readers announce false structure.
A table used purely for visual layout contains header cells or a caption — screen readers treat it as a data table and announce meaningless headers.
Glossary
- Accessible name
- The short name assistive technology uses for a control — often from a label, aria-label, or associated text.
- Alt text (text alternative)
- The written description of an image that screen readers read aloud instead of the image.
- ARIA
- A set of HTML attributes that explain roles, names, and states to assistive technologies when native HTML is not enough.
- Assistive technology (AT)
- Tools people with disabilities use to operate software: screen readers, magnifiers, voice control, switch devices.
- Contrast ratio
- A measured difference between text (or a graphic) and what sits behind it; higher ratios are easier to see.
- Focus / keyboard focus
- The single element currently 'selected' by the keyboard — where Enter/Space/typing will act. Moved with Tab.
- Focus indicator
- The visible highlight that shows which element currently has keyboard focus.
- Focus order / tab order
- The sequence elements are reached when pressing Tab repeatedly.
- Keyboard trap
- A situation where keyboard focus moves into a component and cannot move out using standard keys.
- Landmark
- A page region such as banner, navigation, main, or contentinfo that screen-reader users can jump between.
- Live region / status role
- Markup (for example aria-live or role="status") that tells screen readers to announce updates without moving focus.
- Programmatically determinable
- Available in code so software — not only human eyes — can read the information reliably.
- Reading order
- The order assistive technology reads content, which follows the DOM sequence rather than pure visual placement.
- Screen reader
- Software such as NVDA, JAWS, VoiceOver, or TalkBack that speaks or brailles interface content and controls.
- Semantic markup
- Using HTML elements that match meaning (headings, lists, tables, buttons) instead of generic styled containers alone.
- Viewport
- The visible browser area. Reflow testing often uses about 320 CSS pixels of width.
Capstone audits
Practice spotting real issues (and ignoring correct implementations) in branded product flows.
PayEase
Audit This: PayEase — A peer-to-peer money transfer flow
9 checks · 7 fails · 2 passes
Start audit →QuickBite
Audit This: QuickBite — A food delivery app’s ordering flow
8 checks · 6 fails · 2 passes
Start audit →StreamPlay
Audit This: StreamPlay — A video streaming platform
8 checks · 6 fails · 2 passes
Start audit →JobLink
Audit This: JobLink — A job board’s search and application flow
8 checks · 6 fails · 2 passes
Start audit →MedConnect
Audit This: MedConnect — A patient portal’s appointment scheduler
8 checks · 6 fails · 2 passes
Start audit →StaySpot
Audit This: StaySpot — A hotel booking site’s room search and reservation flow
8 checks · 6 fails · 2 passes
Start audit →GreenCart
Audit This: GreenCart — A grocery delivery app’s browsing and cart
8 checks · 6 fails · 2 passes
Start audit →ChatterSocial
Audit This: ChatterSocial — A social media platform’s feed and profile settings
8 checks · 6 fails · 2 passes
Start audit →LearnHub
Audit This: LearnHub — An online course platform’s lesson player and quizzes
8 checks · 6 fails · 2 passes
Start audit →CoworkNow
Audit This: CoworkNow — A coworking-space booking app
8 checks · 6 fails · 2 passes
Start audit →Final exam
Comprehensive assessment
WCAG 2.2 Comprehensive Assessment
110 questions · pass at 80% · scored by WCAG principle with remediation links
Take the final exam