This page lists reference pages covering all the WAI-ARIA roles discussed on MDN. For a full list of roles, see Using ARIA: Roles, States, and Properties
ARIA roles provide semantic meaning to content, allowing screen readers and other tools to present and support interaction with object in a way that is consistent with user expectations of that type of object. ARIA roles can be used to describe elements that don't natively exist in HTML or exist but don't yet have full browser support.
By default, many semantic elements in HTML have a role; for example, <input type="radio"> has the "radio" role. Non-semantic elements in HTML do not have a role; <div> and <span> without added semantics return null. The role attribute can provide semantics.
ARIA roles are are added to HTML elements using role="role type", where role type is the name of a role in the ARIA specification. Some roles require the inclusion of associated ARIA states or properties; others are only valid in association with other roles.
For example, <ul role="tabpanel"> will be announced as a 'tab panel' by screen readers. However, if the tab panel doesn't have nested tabs, the element with the tabpanel role is not in fact a tab panel and accessibility has actually been negatively impacted.
The ARIA states and properties associated with each role are included in the role's pages, with each attribute also having a dedicated page.
There are 6 categories of ARIA roles:
Document Structure roles are used to provide a structural description for a section of content. Most of these roles should no longer be used as browsers now support semantic HTML element with the same meaning. The roles without HTML equivalents, such as presentation, toolbar and tooltip roles, provide information on the document structure to assistive technologies such as screen readers as equivalent native HTML tags are not available.
For most document structure roles, semantic HTML equivalent elements are available and supported. Avoid using application, article (use <article>), cell (use <td>), columnheader (use <th scope="col">), definition (use <dd> in a <dl>), directory, document, figure (use <figure> instead), group, heading (use <h1> thru <h6>), img (use <img> or <picture> instead), list (use either <ul> or <ol> instead), listitem (use <li> instead), meter (use <meter> instead), row (use the <tr> with <table>), rowgroup (use <thead>, <tfoot> and <tbody>), rowheader (use <tr col="row">), separator (use <hr> if it doesn't have focus), table (use <table>), and term (use <dfn> or <dt> in a <dl>). These are included for completeness, but in most cases are rarely, if ever, useful.
The various widget role are used to define common interactive patterns. Similar to the document structure roles, some of these roles duplicate the semantics of native HTML elements that are well supported, and should not be used. The difference between the two lists is that, generally, the widget roles require JavaScript interaction and the document structure roles don't necessarily.
Avoid using button, checkbox, gridcell, link, menuitem, menuitemcheckbox, menuitemradio, option, progressbar, radio, and textbox, which we've included for completeness. For most, semantic equivalents with accessible interactivity are available and supported. See the individual role documention for more information.