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

219 scenarios

Continue learning →

Module · Operable

2.1.1 — Keyboard

All functionality available with a pointer must also be operable through a keyboard interface without requiring specific timings for individual keystrokes.

A 0 / 24 Open lesson

Feature That Only Responds to Mouse Events, Not the Keyboard

2.1.1 A F54

A feature only responds to mouse-specific events (mousedown, hover, gestures) — keyboard users cannot trigger it at all.

Element That Loses Focus the Instant It’s Reached by Keyboard

2.1.1 A F55

As soon as an element receives keyboard focus, a script throws focus away (blur) — keyboard users can never actually reach or use it.

Clickable Element Acting Like a Link With No Real Keyboard Role

2.1.1 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 With No Keyboard Focus or Key Handling at All

2.1.1 A

Clickable div/span/icon with click handler, no tabindex="0" (code making it keyboard-focusable), no key handling.

Focusable Element That Enter and Space Don’t Actually Activate

2.1.1 A

Element focusable but Enter/Space do nothing (no keydown/keyup activation).

Custom Dropdown That Can’t Be Operated by Keyboard Arrows

2.1.1 A

Custom dropdowns/comboboxes not operable via arrows/Enter/Esc.

Drag-and-Drop Feature With No Keyboard Alternative

2.1.1 A

Drag-and-drop as the only way to reorder/upload/move (no keyboard alternative) where endpoints — not path — matter.

Slider or Carousel Operable Only by Swipe or Mouse Drag

2.1.1 A

Sliders/carousels operable only by swipe or mouse-drag.

Hover-Only Menu With No Way to Open It by Keyboard

2.1.1 A

Hover-only menus with no keyboard-open equivalent (submenu items unreachable).

Date Picker Grid That Can’t Be Navigated by Keyboard

2.1.1 A

Date pickers where the grid isn't keyboard navigable and manual text entry is blocked.

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.