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

Live Value Update With No Way for Screen Readers to Detect It

4.1.2 A

Live-updating values (counters, cart totals) changing without any programmatic notification path where the control's value is the thing changing.

Iframe Embedded With No Title Describing Its Content

4.1.2 A

Iframes without title (embedded functional content unnamed).

Rich Text Editor With No Role, Name, or State Exposed

4.1.2 A

contenteditable (editable-area code) rich editors with no role/name/state exposure.

Web Component Whose Shadow DOM Hides All Its Semantics

4.1.2 A

Web components with closed shadow DOM (hidden internal code) leaking no semantics (no ElementInternals/ARIA reflected).

Toggle Button Showing State Only Through Color or Icon Change

4.1.2 A

Toggle buttons using color/icon change only, no aria-pressed (the pressed state in code).

Progress Bar Built as a Styled Div With No Real Role

4.1.2 A

Progress bars as styled divs without role="progressbar" + values.

Rating Widget With No Name or Value Semantics at All

4.1.2 A

Rating widgets with no name/value semantics.

Duplicate Element IDs Causing a Control’s Name to Resolve Wrong

4.1.2 A

Duplicate IDs making aria-labelledby (code pointing to the element that names it)/for resolve to the wrong node (name wrong).

Disabled Control That’s Only Disabled Visually, Not in Code

4.1.2 A

Disabled conveyed visually only (class="disabled") while control stays enabled to assistive technology — state mismatch.

Complex Widget Relying on a Title Attribute for Its Name

4.1.2 A

title-only names on complex widgets where assistive technology support gaps make the name unavailable in practice (risk-level failure logged against name robustness).

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.