Design System Glossary

ARIA Roles

ARIA roles define what an element is — its semantic meaning — to assistive technology. <button> has an implicit role of "button"; <div role="button"> has an explicit one. Screen readers announce the role so users know what they're interacting with.

Common roles in a Design System:

button: An interactive element that triggers an action. Space or Enter activates it.
link: Navigates to a URL. Enter activates it.
menuitem, menuitemcheckbox, menuitemradio: Items in a menu. Arrow keys navigate; Enter or Space selects.
checkbox, radio: Form controls. Space toggles them.
tab: In a tab list. Arrow keys navigate; Enter or Space selects.
tabpanel: Content associated with a tab.
dialog: A modal or non-modal dialog. Escape should close it; focus should be trapped (for modals).
alert, alertdialog: Messages that demand attention.
textbox: A text input. Works like a native input.
combobox: A select-like control (dropdown, autocomplete). Complex — keyboard handling varies.

The principle: use semantic HTML first. <button> is better than <div role="button">. <input type="checkbox"> is better than <div role="checkbox">. ARIA patches gaps when you can't use semantic HTML (rare in well-designed systems).

A Design System documents which roles its components use. A Button component should document that it has the implicit role of "button" and what keyboard interactions it supports. A Menu should document the "menu" role, the "menuitem" roles of its items, and the expected keyboard behaviour (arrow keys move focus, Enter activates).

ARIA is not a replacement for semantic HTML. It's a supplement. The order of preference:

1. Use semantic HTML (button, input, dialog).
2. If you can't, use ARIA roles and attributes.
3. Never use ARIA to make semantic HTML behave differently (don't hide a button and give a div role="button").