Accessibility semantics & keyboard

Core details

• Prefer native controls (button, a with real href, inputs). Custom widgets owe explicit roles, states/properties, and a predictable keyboard map.
• Names derive from visible text, aria-label, or labelled-by relationships—no unnamed icon-only actions.
• Focus order mirrors reading flow unless using justified patterns such as toolbar/grid roving tabindex.
• Dialogs: trap focus, restore on close; default Escape closes unless forbidden—then expose another documented exit path.
• Live regions (aria-live): choose polite vs assertive for async statuses (Saving…, “Failed”).
• Reduced motion: respect prefers-reduced-motion—provide meaningful still alternatives instead of stripping information.

Understanding

Assistive technologies consume the semantic tree, not pixels. Roles/names regressions silently delete functionality for screen-reader and voice-control users—even if screenshots look unchanged. Keyboard navigation surfaces affordances accidentally coupled to hover or fine-pointer precision assumptions.

Keyboard navigation surfaces assumptions that pointers hide—broken focus traps or missing names block entire tasks.

Focus management is part of your API contract, not polish after mock approval.

Senior understanding

Use automated audits (axe-class scans) as a baseline, not the whole story—they rarely catch nuanced focus regressions alone; complement with scripted keyboard walkthroughs.

Diagram

See also

• Rendering pipeline
• Hub: /frontend