This is a searchable reference for WAI-ARIA roles — the role tokens that describe what an element is to assistive technology. It groups them into landmark roles (page regions), document-structure roles (lists, tables, headings), widget roles (buttons, checkboxes, comboboxes, tabs) and live-region roles (alerts and status messages), and for each shows the attributes or context it requires and where its accessible name comes from.
How it works
A role is applied with the role attribute and tells the accessibility tree how to expose an element. Most native HTML elements already carry an implicit role — <button> is button, <nav> is navigation — so you rarely need to set role explicitly. When you build a custom widget from generic elements, the role brings obligations: many roles require specific attributes (a checkbox needs aria-checked, a slider needs aria-valuenow/aria-valuemin/aria-valuemax, a heading needs aria-level) and composite roles require a child contract (a tablist must own tab children). The name-from column captures how the element’s accessible name is computed: some roles derive it from their text contents, while others require an explicit aria-label, aria-labelledby or associated <label>.
Tips and notes
Follow the first rule of ARIA: prefer the native element. ARIA changes only how an element is announced — it never adds keyboard behaviour, focus management or pointer handling, all of which you must implement yourself for custom widgets. role="presentation" (or its synonym none) strips an element’s implicit semantics, useful for layout tables. Keep landmark roles unique where the spec expects it (main, banner, contentinfo) and label repeated landmarks (multiple navigation regions) so users can tell them apart.
Example
<!-- Native is better than ARIA -->
<button type="button">Save</button>
<!-- A custom toggle done correctly -->
<span role="switch" tabindex="0" aria-checked="false" aria-label="Dark mode">
</span>Everything runs in your browser; nothing you search is uploaded.