HTML Guide for role
There can only be one visible <main> element in a document. If more are needed (for example for switching between them with JavaScript), only one can be visible, the others should be hidden toggling the hidden attribute.
Example of 2 main elements, where only one is visible:
<main>
<h1>Active main element</h1>
<!-- content -->
</main>
<main hidden>
<h1>Hidden main element</h1>
<!-- content -->
</main>
Elements with the role tab must either be a child of an element with the tablist role, or have their id part of the aria-owns property of a tablist.
An element with the tab role controls the visibility of an associated element with the tabpanel role. The common user experience pattern is a group of visual tabs above, or to the side of, a content area, and selecting a different tab changes the content and makes the selected tab more prominent than the other tabs.
Example:
<div class="tabs">
<div role="tablist" aria-label="Sample Tabs">
<button role="tab" aria-selected="true" aria-controls="panel-1" id="tab-1" tabindex="0">
First Tab
</button>
<button role="tab" aria-selected="false" aria-controls="panel-2" id="tab-2" tabindex="-1">
Second Tab
</button>
</div>
<div id="panel-1" role="tabpanel" tabindex="0" aria-labelledby="tab-1">
<p>Content for the first panel</p>
</div>
<div id="panel-2" role="tabpanel" tabindex="0" aria-labelledby="tab-2" hidden>
<p>Content for the second panel</p>
</div>
</div>
A button element, or an element with the role=button attribute, is not allowed to be nested inside an <a> element.
When an img element has an empty alt attribute, its role is implicitly decorative, so it must not specify a role attribute.
The alert role can be used to tell the user an element has been dynamically updated. Screen readers will instantly start reading out the updated content when the role is added. The element <ul> doesn’t accept this kind of role, consider using other element like <p> or <div>.
The alert role is used to communicate an important and usually time-sensitive message to the user. When this role is added to an element, the browser will send out an accessible alert event to assistive technology products which can then notify the user about it. The alert role is most useful for information that requires the user’s immediate attention.
An element like <h1>, <h2>, etc., used to define a heading, does not accept the button role.
The following HTML code is invalid because the <h2> element can’t have role="button"
<h2 role="button">Some heading</h2>
Instead, you can nest the <h2> inside a <div> with that role. In this case however, browsers automatically apply role presentation to all descendant elements of any button element as it is a role that does not support semantic children.
<div role="button">
<h2>Some heading</h2>
</div>
A <li> element, used to define a list item, does not accept the button role.
This HTML code is invalid because the <li> elements can’t have role="button":
<ul>
<li role="button">One</li>
<li role="button">Two</li>
</ul>
There’s no role in ARIA named presentational, you probably mean presentation.
The presentation role and its synonym none remove an element’s implicit ARIA semantics from being exposed to the accessibility tree.
The content of the element will still be available to assistive technologies; it is only the semantics of the container — and in some instance, required associated descendants — which will no longer expose their mappings to the accessibility API.
An element with role="rowgroup" is a group of rows within a tabular structure. A rowgroup contains one or more rows of cells, grid cells, column headers, or row headers within a grid, table or treegrid, as in this example:
<div
role="table"
aria-label="Populations"
aria-describedby="country_population_desc">
<div id="country_population_desc">World Populations by Country</div>
<div role="rowgroup">
<div role="row">
<span role="columnheader" aria-sort="descending">Country</span>
<span role="columnheader" aria-sort="none">Population</span>
</div>
</div>
<div role="rowgroup">
<div role="row">
<span role="cell">Finland</span>
<span role="cell">5.5 million</span>
</div>
<div role="row">
<span role="cell">France</span>
<span role="cell">67 million</span>
</div>
</div>
</div>
<input> elements can’t have a search role. Instead, try with <input type="search">.
<input> elements of type search are text fields designed for the user to enter search queries into. These are functionally identical to text inputs, but may be styled differently depending on the user agent.
The search role is a landmark. Landmarks can be used by assistive technology to quickly identify and navigate to large sections of the document. The search role is added to the container element that encompasses the items and objects that, as a whole, combine to create search functionality. When a <form> is a search form, use the search role on the form.
Example of a search form:
<form role="search">
<label for="search-input">Search this site</label>
<input type="search" id="search-input" name="search">
<input value="Submit" type="submit">
</form>
A <a> tag element is missing required attributes, depending on other present attributes.
Depending on the use of other HTML attributes, an <a> tag may require additional attributes. For example, when using aria-selected to build a tab list, this is an example of valid code using role, aria-selected, aria-controls and aria-labelledby:
<div class="tab-interface">
<div role="tablist" aria-label="Sample Tabs">
<span
role="tab"
aria-selected="true"
aria-controls="panel-1"
id="tab-1"
tabindex="0">
First Tab
</span>
<span
role="tab"
aria-selected="false"
aria-controls="panel-2"
id="tab-2"
tabindex="-1">
Second Tab
</span>
</div>
<div id="panel-1" role="tabpanel" tabindex="0" aria-labelledby="tab-1">
<p>Content for the first panel</p>
</div>
<div id="panel-2" role="tabpanel" tabindex="0" aria-labelledby="tab-2" hidden>
<p>Content for the second panel</p>
</div>
</div>
The <a> element requires either a href attribute, or a role attribute.
Using aria-required on a div element requires more context about that element, by providing one of the attributes aria-expanded, aria-valuemax, aria-valuemin, aria-valuenow, role.
When possible, you should prefer semantic tags like input, select and textarea, and use the required attribute, but when form controls are created using non-semantic elements, such as a div element, the aria-required attribute should be included with a value of true to indicate to assistive technologies that user input is required on the element for the form to be submittable. In that case, other attributes might be needed to make the element valid.
For example, we could build a radiogroup using a div like this:
<div aria-required="true">
<div data-value="One"></div> 1
<div data-value="Two"></div> 2
<div data-value="Three"></div> 3
</div>
This HTML snippet would then be decorated using CSS and added functionality using JavaScript. However, the W3C validator will complain that the element div is missing one of the attributes aria-expanded, aria-valuemax, aria-valuemin, aria-valuenow, role.
We can fix that by adding the appropiate role to that div element, like this:
<div aria-required="true" role="radiogroup">
<div data-value="One"></div> 1
<div data-value="Two"></div> 2
<div data-value="Three"></div> 3
</div>
Here is an example showing how to add the “role” attribute to the “div” element:
<div role="region">
<!-- Your content goes here -->
</div>
In this example, the role attribute is added with the value radiogroup. You can choose the appropriate ARIA role based on the purpose or role of your div element.
Remember to also provide the necessary values for the specified attributes if you are adding aria-valuemax, aria-valuemin, or aria-valuenow to ensure proper accessibility and usability of your content.
An element is using ARIA attributes, but its role has not been defined. ARIA defines semantics that can be applied to elements, with these divided into roles (defining a type of user interface element) and states and properties that are supported by a role. Authors must assign an ARIA role and the appropriate states and properties to an element during its life-cycle, unless the element already has appropriate ARIA semantics (via use of an appropriate HTML element). Examples:
<!-- This div uses ARIA but its role is not clear, so it's invalid. -->
<div aria-expanded="true">...</div>
<!-- This div defines clearly its role, so it's valid. -->
<div role="navigation" aria-expanded="true">...</div>
<!-- Nav elements have an implicit navigation role so we don't need the role attribute. -->
<nav aria-expanded="true">...</nav>
The article role indicates a section of a page that could easily stand on its own on a page, in a document, or on a website, is implicit when using the <article> tag.
This role indicates a section of a page that could easily stand on its own on a page, in a document, or on a website. It is usually set on related content items such as comments, forum posts, newspaper articles or other items grouped together on one page. It can be added to generic elements like <div> to convey this role, for example:
<div role="article">
<h2>Heading</h2>
<p>Content...</p>
</div>
Instead of using this role, it’s preferrable to use the native <article> element like this:
<article>
<h2>Heading</h2>
<p>Content...</p>
</article>
The <header> HTML element represents introductory content, typically a group of introductory or navigational aids, and has an implicit role of banner, so specifying this role is redundant.
The following example represents a banner using the role attribute:
<div role="banner">
<img src="companylogo.svg" alt="my company name" />
<h1>Title</h1>
<p>Subtitle</p>
</div>
By default, the HTML5 <header> element has an identical meaning to the banner landmark, unless it is a descendant of <aside>, <article>, <main>, <nav>, or <section>, at which point <header> is the heading for that section and not the equivalent of the site-wide banner.
This example uses the <header> element instead of the banner role:
<header>
<img src="companylogo.svg" alt="my company name" />
<h1>Title</h1>
<p>Subtitle</p>
</header>
The button role is used to make an element appear as a button control to a screen reader and can be applied to otherwise non-interactive elements like <div>. If you’re already using a <button> element, then it’s redundant to apply it the role button, as that’s implicit.
<!-- Instead of this -->
<button role="button">Buy</button>
<!-- Do this -->
<button>Buy</button>
The button role is used to make an element appear as a button control to a screen reader and can be applied to otherwise non-interactive elements like <div>. If you’re already using an <input> element whose type is submit, then it’s redundant to apply it the role button, as that’s implicit.
<!-- Instead of this -->
<input type="submit" role="button">Buy</button>
<!-- Do this -->
<input type="submit">Buy</button>
The <summary> HTML element specifies a clickable summary, caption, or legend for a <details> element’s disclosure box. As the <summary> element has an implicit button role, it’s not needed to include it explicitly.
Here’s an example, clicking the <summary> element toggles the state of the parent <details> element open and closed.
<details>
<summary>I have keys but no doors. I have space but no room. You can enter but can’t leave. What am I?</summary>
A keyboard.
</details>
Using the <aside> element will automatically communicate a section has a role of complementary, so specifying the role="complementary" is redundant.
The <footer> element represents a footer for its nearest sectioning content, and has an implicit role of contentinfo, so specifying this role is redundant.
The following example marks a <div> as a footer specifying its role:
<div role="contentinfo">
<h2>Footer</h2>
<!-- footer content -->
</div>
Using the <footer> element instead is recommended:
<footer>
<h2>Footer</h2>
<!-- footer content -->
</footer>
A button element is not allowed to contain other button elements, or other elements with role=button.
The button role identifies an element as a button to assistive technology such as screen readers. A button is a widget used to perform actions such as submitting a form, opening a dialog, canceling an action, or performing a command such as inserting a new record or displaying information. Adding role="button" tells assistive technology that the element is a button but provides no button functionality
A <form> element has already a form role, so specifying role="form" in it is redundant.
Instead of:
<form role="form">
You can simply write:
<form>
The heading role defines this element as a heading to a page or section, and is implicit in tags <h1> to <h6>.
The heading role indicates to assistive technologies that this element should be treated like a heading. Screen readers would read the text and indicate that it is formatted like a heading.
This ARIA role is only needed to add that role to a generic element like <div>, for example:
<div role="heading" aria-level="1">This is a main page heading</div>
This defines the text in the <div> to be the main heading of the page, indicated by being level 1 via the aria-level attribute. Opt for using the <h1> (thru <h6>) element instead:
<h1>This is a main page heading</h1>
A single <img> element is used to embed an image, so adding the img role to it is redundant.
The ARIA img role can be used to identify multiple elements inside page content that should be considered as a single image. These elements could be images, code snippets, text, emojis, or other content that can be combined to deliver information in a visual manner, for example:
<div role="img" aria-label="Description of the overall image">
<img src="graphic1.png" alt="">
<img src="graphic2.png">
</div>