ARIA role
The role attribute tells assistive technology whether a custom control is a button, tab, dialog, or another kind of widget.
See it
What it is
An ARIA role tells assistive technology what kind of interface object an element represents: button, dialog, tab, checkbox, and so on. It changes the element's meaning in the accessibility tree, which is useful when a custom widget cannot be built from one native HTML element.
Reach for a role only after checking for a native element. The W3C spells this out as the First Rule of ARIA Use: if a native HTML element gives you the semantics and behavior you need, use it. A button already has the button role, keyboard behavior, focus handling, and disabled semantics. A div with role='button' gets only the announced role; you still owe it focusability, Enter and Space handling, and every state the widget exposes.
The gotcha is that a role is a promise, not an implementation. role='tab' does not add arrow-key navigation, and role='checkbox' does not toggle aria-checked. Follow the matching WAI-ARIA Authoring Practices pattern in full, and do not overwrite correct native semantics with a conflicting role.
Ask AI for it
Build this custom tab interface with the WAI-ARIA Authoring Practices Tabs Pattern. Put role='tablist' on the tab container, role='tab' on each tab, and role='tabpanel' on each panel. Connect every tab to its panel with aria-controls and every panel back to its tab with aria-labelledby. Maintain aria-selected, hide inactive panels, and use roving tabindex so only the active tab is in the Tab order. Implement Left Arrow, Right Arrow, Home, and End exactly as the pattern specifies. If a native HTML element already provides the needed semantics, use it instead of adding a redundant or conflicting role.