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.

Progress 0 / 690

49 scenarios

Continue learning →

Module · Robust

4.1.2 — Name, Role, Value

User interface components must expose an accessible name, role, and current value or state that assistive technologies can determine and update.

A 0 / 33 Open lesson

Custom Dropdown or Slider With No Accessibility API Support

4.1.2 A F15

A custom-built control (dropdown, slider, dialog) doesn't tell assistive technology what it is or what state it's in, because it skips the standard accessibility hooks.

Content Changes That Never Update Their Accessible Name

4.1.2 A F20

Content changes on screen but its alt text / accessible name is never updated, so screen readers announce old, wrong information.

Scripted Link or Button With No Real Role or Keyboard Support

4.1.2 A F42

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.

Clickable Div Turned Into a Control but Given No ARIA Role

4.1.2 A F59

A div or span is turned into a clickable control with script, but is never given a role — screen readers announce it as plain text, not a button/control.

Form Field With No Programmatic Label at All

4.1.2 A F68

A form field has no programmatic label — screen readers announce 'edit text' with no idea what to type.

Assistive Technology Never Told Which Element Currently Has Focus

4.1.2 A F79

Assistive technology is never told which element currently has focus, or that focus changed — screen readers lose track of the user's position.

Multi-Part Field Where Each Box Has No Individual Name

4.1.2 A F86

Each box of a multi-part field (e.g., 3 phone-number boxes) has no individual name — screen readers announce three anonymous 'edit' fields.

Icon-Only Control With No Name Exposed to Assistive Tech

4.1.2 A F89

A link or button whose only content is an image has no accessible name — screen readers announce 'link' with no clue where it goes.

Control With an On-Screen Label but No Accessible Name

4.1.2 A F111

A control shows label text on screen but has no accessible name at all — screen readers announce nothing useful and voice control can't target it.

Custom Checkbox or Toggle With No Role or Checked State

4.1.2 A

Custom checkbox/toggle/radio with no role and no aria-checked (the on/off state in code) — state invisible to assistive technology.

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.

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