What this module should change
You will be able to define accessibility as a set of responsibilities and testable behaviors across the complete product experience.
Module guide
Four decisions to understand
Keyboard and focus
Keyboard access requires operability, visible focus, logical order, and intentional focus movement after changes.
Complete a key task using only the keyboard and record every point where focus becomes hidden, trapped, or surprising.
Text and visual adaptation
Contrast, zoom, text resize, reflow, forced colors, and reduced motion expose assumptions in visual foundations.
Test at 200% zoom and 320 CSS pixels wide without losing content or requiring two-dimensional scrolling.
Names, roles, and states
Assistive technology needs the purpose, type, current value, and changes of an interactive element.
Compare the visible label, accessible name, role, state, and description for a complex control.
Accessible patterns
The page must preserve headings, errors, status, focus, and recovery across the entire task—not only inside components.
Trigger every validation and loading state with a screen reader and keyboard.
Working principles
Built in does not mean complete
A component can provide semantics and keyboard behavior, while product teams still own labels, order, content, and end-to-end testing.
Preferences are inputs
Reduced motion, color modes, text scaling, and platform settings should influence system behavior through explicit modes.
Test with people
Automated checks find classes of defects; they do not establish that a workflow is understandable or usable.
Saved in this browser
Practice and check your understanding
Explore next