Components that work with a keyboard and a screen reader.
Seven common building blocks as live demos to try out, each with the ARIA and keyboard requirements, code to reuse and the mistakes we see most often in audits.
Three rules first
Native HTML first
A button, details or dialog element comes with role, state and keyboard support built in. ARIA is for the cases HTML does not cover.
Keyboard is a must
Everything you can do with a mouse must also work with Tab, Enter, Space and, where expected, the arrow keys.
Expose the state
Open or closed, selected or not: what people see, a screen reader must be told as well.
All patterns
Accordion
Show and hide sections, state exposed with aria-expanded.
Tabs
One panel of several, arrow keys switch between tabs.
Modal dialog
Focus moves in on open, Escape closes, focus returns.
Navigation with submenus that does not need a mouse
Submenus behind buttons, Escape closes, plain links.
Carousel
Pause button, previous/next, slide labels, no forced autoplay.
Error messages that help instead of confuse
Errors as text, linked, with a fix and an error summary.
Status messages that get through without stealing focus
Announce messages via a live region, focus stays put.