HTML Guide for aria
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>
An a element with both an href attribute and aria-disabled="true" is invalid; either remove aria-disabled or the href attribute.
The aria-disabled attribute is used for interactive elements to indicate that the element is perceivable as disabled by assistive technologies. However, using aria-disabled="true" in combination with an href attribute on an a element is not valid, because the link remains actionable for both user agents and assistive devices. Instead, if a link should appear disabled, you should remove the href attribute, use CSS for styling, and optionally use aria-disabled="true". If you need the element to always act as a link, avoid aria-disabled and control user access through application logic.
Incorrect:
<a href="page.html" aria-disabled="true">Visit Page</a>
Correct—Option 1: Remove aria-disabled, keep link active
<a href="page.html">Visit Page</a>
Correct—Option 2: Remove href, use aria-disabled, for non-actionable item
<a aria-disabled="true" tabindex="-1" style="pointer-events: none; color: gray;">Visit Page</a>
In the second correct example, setting tabindex="-1" prevents keyboard navigation, and pointer-events: none; makes the link unclickable, while aria-disabled="true" makes the disabled state accessible.
A role="columnheader" element must be a child of or associated with a role="row" element.
In HTML, ARIA roles such as columnheader are used to improve accessibility for assistive technologies. According to the ARIA specification, a columnheader role should appear inside an element with role="row", which itself should be inside an element with role="table" or role="grid". This structure mimics how native tables are constructed with <th> elements inside <tr>s.
Correct structure:
- role="table" or role="grid" contains one or more elements with role="row".
- Each role="row" contains one or more elements with role="columnheader" (or role="cell").
Example using ARIA roles for a simple table:
<div role="table" aria-label="Sample Table">
<div role="row">
<div role="columnheader">Name</div>
<div role="columnheader">Age</div>
</div>
<div role="row">
<div role="cell">Alice</div>
<div role="cell">30</div>
</div>
</div>
Best practice:
Whenever possible, use native table elements, which have built-in roles and accessibility, reducing the chance of ARIA misuse.
Example using native table markup:
<table>
<tr>
<th>Name</th>
<th>Age</th>
</tr>
<tr>
<td>Alice</td>
<td>30</td>
</tr>
</table>
Ensure that any element with role="columnheader" is always contained within a parent with role="row". Avoid placing role="columnheader" directly inside a container without the appropriate role="row" ancestor.
To fix this issue, ensure that an element with role="listitem" is contained within an element with role="list" or role="group". Here’s how you can structure your HTML correctly:
Incorrect Example
<div role="listitem">Item 1</div>
<div role="listitem">Item 2</div>
Correct Example
<div role="list">
<div role="listitem">Item 1</div>
<div role="listitem">Item 2</div>
</div>
Alternatively, you can use role="group" if it’s a nested list.
Correct Example with Nested List
<div role="list">
<div role="listitem">Item 1</div>
<div role="group">
<div role="listitem">Item 1.1</div>
<div role="listitem">Item 1.2</div>
</div>
<div role="listitem">Item 2</div>
</div>
This ensures that the role="listitem" elements are correctly contained.
To fix the W3C HTML Validator issue stating that an element with a role="menuitem" must be contained in, or owned by, an element with role="menubar" or role="menu", you need to ensure that your menuitem elements are properly nested within a menubar or menu element. This is important for accessibility, as it helps assistive technologies understand the structure and relationship of the elements.
The menuitem role indicates the element is an option in a set of choices contained by a menu or menubar.
Here is a step-by-step guide to fixing this issue:
1. Using role="menubar"
If your menuitem elements are part of a horizontal menu (like a navigation bar), they should be nested within an element with role="menubar".
Example:
<nav role="menubar">
<div role="menuitem">Home</div>
<div role="menuitem">About</div>
<div role="menuitem">Contact</div>
</nav>
2. Using role="menu"
If your menuitem elements are part of a submenu or a vertical menu, they should be contained within an element with role="menu".
Example:
<div role="menu">
<div role="menuitem">Item 1</div>
<div role="menuitem">Item 2</div>
<div role="menuitem">Item 3</div>
</div>
Ensuring Proper Nesting
Ensure that all your menuitem elements are either directly or indirectly (via a child-parent relationship) contained within a menubar or menu element.
Complete Example with Nested Menus:
Here is a more complex example, including nested menus for a drop-down scenario.
Example:
<nav role="menubar">
<div role="menuitem">Home</div>
<div role="menuitem">
About
<div role="menu">
<div role="menuitem">Team</div>
<div role="menuitem">History</div>
</div>
</div>
<div role="menuitem">Contact</div>
</nav>
In this example, the main navigation (menubar) contains menuitem elements, and one of those menuitem elements contains a nested menu with additional menuitem elements inside it.
By ensuring your menuitem elements are contained within appropriate parent elements (menubar or menu), you will resolve the W3C HTML Validator issue and improve your web page’s accessibility.
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>
The aria-* attributes are part of the WAI-ARIA (Web Accessibility Initiative-Accessible Rich Internet Applications) suite. They are used to improve the accessibility of web pages. However, when we use an input element with a type attribute whose value is hidden, we imply that the element is invisible and has no interaction with the user. Therefore, it doesn’t make sense to add aria-* attributes to it.
To fix this issue, you need to remove the aria-* attributes from the input element with type=hidden. Here is an example:
<!-- Wrong code -->
<input type="hidden" name="referer" value="https://example.com" aria-invalid="false">
<!-- Correct code -->
<input type="hidden" name="referer" value="https://example.com">
labelledby is not a valid attribute for the <svg> element. Perhaps you meant aria-labelledby?
The aria-labelledby attribute establishes relationships between objects and their label(s), and its value should be one or more element IDs, which refer to elements that have the text needed for labeling.
Example:
<div id="myBillingId">Billing</div>
<div>
<div id="myNameId">Name</div>
<input type="text" aria-labelledby="myBillingId myNameId"/>
</div>
<div>
<div id="myAddressId">Address</div>
<input type="text" aria-labelledby="myBillingId myAddressId"/>
</div>
According to the ARIA specification, the attribute aria-rowspan is expected to have a positive integer value. A positive integer is a whole number greater than zero.
Explanation
- aria-rowspan: This attribute is used in ARIA-enabled tables to indicate how many rows a cell should span within its row group. It is often used in elements like gridcell or rowheader within roles that imply grid-like structures, such as grid or treegrid.
Example of Incorrect Usage
<div role="gridcell" aria-rowspan="0">Content</div>
In this example, aria-rowspan is set to "0", which is not a valid positive integer.
Correct Usage
To resolve the issue, you should specify a positive integer. For example, if the cell should span one row, you can write:
<div role="gridcell" aria-rowspan="1">Content</div>
If the cell should span multiple rows, adjust the number accordingly:
<div role="gridcell" aria-rowspan="2">Content</div>
Considerations
- Make sure the role attribute is correctly associated with an element that can logically have a row and grid structure, such as gridcell.
- Ensure that the aria-rowspan value aligns with the structure of your grid or table, representing the actual number of rows that the element is spanning.
Due to an issue in the W3C validator, this is identified as an error but it’s not. This issue has been notified, and we’ll update our validator as soon as there’s a fix.
According to the WAI-ARIA 1.2 spec:
The aria-setsize property defines the number of items in the current set of listitems or treeitems. Not required if all elements in the set are present in the DOM.
Authors MUST set the value of aria-setsize to an integer equal to the number of items in the set. If the total number of items is unknown, authors SHOULD set the value of aria-setsize to -1.
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.
The aria-expanded attribute can only be true, false, or undefined.
This attribute indicates whether a grouping element is expanded or collapsed.
The role attribute value combobox is not valid on an input element according to the W3C HTML standard.
The role="combobox" is valid only when applied to an element that acts as a container for the combo box widget, usually a div or similar element, and not directly to a native HTML input. Native input elements of type "text" or "search" already have implicit roles and accessibility semantics. To create an accessible combobox, wrap the input inside a container element with role="combobox" and use appropriate ARIA attributes.
Incorrect Implementation:
<input type="text" role="combobox" aria-autocomplete="list">
Correct Implementation:
<div role="combobox" aria-haspopup="listbox" aria-owns="suggestions" aria-expanded="false">
<input type="text" aria-autocomplete="list" aria-controls="suggestions">
</div>
<ul id="suggestions" role="listbox">
<li role="option" id="option1">Option 1</li>
<li role="option" id="option2">Option 2</li>
</ul>
Explanation of attributes:
- role="combobox": Applied to the container (<div>) to define the accessible widget.
- aria-haspopup="listbox": Indicates the presence of a list of suggestions.
- aria-owns / aria-controls: Connects the input and suggestion list.
- aria-expanded: Denotes whether the suggestion list is visible.
- aria-autocomplete: Defines the autocomplete behavior.
This markup ensures better accessibility and passes W3C validation.
The dialog element does not require or permit a role="dialog" attribute according to HTML standards.
The <dialog> element has an implicit ARIA role of dialog, so adding role="dialog" is redundant and not valid per the specification. Instead, simply use the <dialog> element without an explicit role attribute.
Details:
According to the WHATWG HTML standard and ARIA specification, native <dialog> elements automatically have the correct role. Adding role="dialog" can cause HTML validation errors, as the validator interprets this as a misuse or redundancy.
Correct usage:
<dialog>
<p>This is a dialog box.</p>
<button>Close</button>
</dialog>
Incorrect usage (causes validation error):
<dialog role="dialog">
<p>This is a dialog box.</p>
<button>Close</button>
</dialog>
Removing the role="dialog" attribute resolves the W3C validation issue while maintaining accessibility.
The aria-activedescendant attribute on the input element must reference a non-empty, valid ID of an existing element.
The aria-activedescendant attribute is used in accessible widgets to indicate which element is currently active or selected within a composite widget, such as a listbox or autocomplete dropdown. Its value should be the id of an element within the DOM.
The attribute value must not be an empty string and must match the id of an existing element. Using an empty string ("") is invalid and triggers the W3C validator error.
Correct usage:
- Reference a valid, non-empty element id as the value.
- Remove the attribute if no element is currently active.
Example: Incorrect usage (invalid)
<input type="text" aria-activedescendant="" />
Example: Correct usage with a referenced ID
<ul id="suggestions">
<li id="option1">Option 1</li>
<li id="option2">Option 2</li>
</ul>
<input type="text" aria-activedescendant="option1" />
To eliminate errors, do not set aria-activedescendant to an empty string. Only include the attribute when it references a valid element’s id.
Empty aria-controls attribute values are invalid; the attribute must reference the id of one or more elements.
The aria-controls attribute is used to indicate that the element controls the referenced element(s) by their id. According to the ARIA specification and W3C HTML standard, the attribute must contain at least one valid id value, and cannot be an empty string. Leaving aria-controls="" triggers a validation error.
Correct Usage:
- Assign an id to the element being controlled.
- Set the aria-controls attribute to match that id.
- Remove aria-controls entirely if not necessary.
Incorrect Example:
<a href="#" aria-controls="">Toggle</a>
Corrected Example:
<div id="details">Some details...</div>
<a href="#" aria-controls="details">Toggle</a>
If no element is being controlled:
<a href="#">Toggle</a>
Set a non-empty list of valid ID references in the aria-labelledby attribute on the <a> element, or remove the attribute and provide an accessible name another way.
The aria-labelledby attribute takes an IDREFS value: a space-separated list of one or more element IDs, each of which must be non-empty, exist in the document, and be unique. An empty value ("") violates the ARIA/HTML constraints and triggers the validator error. On an <a> element, aria-labelledby supplies the accessible name for the link by concatenating the text from the referenced elements. If you don’t have IDs to reference, use visible link text or aria-label. Avoid leaving aria-labelledby empty (common with templating when a variable is blank); either omit the attribute entirely or populate it with valid IDs. Remember that aria-labelledby overrides other naming methods, so an empty or broken reference can result in a link with no accessible name.
HTML examples
-
Invalid (what triggers the error)
<a href="/report" aria-labelledby=""></a>
-
Fixed by referencing an existing element with a valid id
<a href="/report" aria-labelledby="report-link-text"> <svg aria-hidden="true" viewBox="0 0 16 16"></svg> </a> <span id="report-link-text">View report</span>
-
Fixed with multiple IDs (space-separated)
<a href="/apples" aria-labelledby="prefix apples-text"> <svg aria-hidden="true" viewBox="0 0 16 16"></svg> </a> <span id="prefix">Learn more: </span> <span id="apples-text">Apples</span>
-
Fixed by using visible text content (no ARIA needed)
<a href="/report">View report</a>
-
Fixed by using aria-label for an icon-only link (when no separate label element exists)
<a href="/search" aria-label="Search"> <svg aria-hidden="true" viewBox="0 0 16 16"></svg> </a>
The icon value for attribute role is not a valid ARIA role.
ARIA Roles: Overview
ARIA roles are used to enhance accessibility by clearly defining the role and purpose of an element for assistive technologies. However, there are defined roles that you need to adhere to:
- Standard roles include button, checkbox, alert, dialog, img, etc.
- There is no ARIA role named icon.
Solution
To fix the issue, you need to use a valid ARIA role that accurately describes the purpose of the span element. If your intention is to convey that the span contains an icon, you might want to reconsider whether you need a role at all. Often, purely decorative elements should not have a role, or you might use an img role if it conveys a meaningful image.
Here’s how you can address this:
-
No ARIA role (if purely decorative): If the icon is purely decorative and does not add meaningful content to your page, you should remove the role attribute entirely.
<span class="icon"></span>
-
Using img role (if it represents an image): If the span represents an image or an icon that conveys meaningful information, you can use role="img" and provide a proper aria-label.
<span class="icon" role="img" aria-label="Icon Description"></span>
-
Using an appropriate role (if interactive): If the icon is part of an interactive element, you might need a different role. For instance, if the icon is inside a button:
<button> <span class="icon" aria-hidden="true"></span> Button text </button>
Here, aria-hidden="true" is used to hide the decorative icon from screen readers as the text provides the necessary context.
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.
<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>
Using role="section" on a <section> element is unnecessary and not recommended.
The <section> element is a semantic HTML5 element that is used to define sections within a document. A <section> inherently carries the semantics of a structural region, so you don’t need to explicitly declare a role attribute for it. The role attribute in HTML is mainly used to enhance accessibility by explicitly defining the purpose of an element when the element’s native HTML semantics are missing or insufficient. However, in this case, since <section> is already semantically meaningful, assigning a role="section" results in redundancy and can cause validation warnings or errors.
HTML5 and ARIA (Accessible Rich Internet Applications) guidelines suggest only using roles when absolutely necessary. Misusing roles can lead to confusion for assistive technologies, potentially impacting user accessibility.
Here’s a correct use of the <section> element without the role attribute:
<!DOCTYPE html>
<html lang="en">
<head>
<title>Document Title</title>
</head>
<body>
<header>
<h1>Website Header</h1>
</header>
<section>
<h2>Section Heading</h2>
<p>This is a paragraph within the section.</p>
</section>
<footer>
<p>Website Footer</p>
</footer>
</body>
</html>
By removing role="section", you leverage the semantic meaning that the <section> element already provides, ensuring cleaner, more accessible, and standards-compliant HTML.
sidebar is not a valid value for the role attribute according to the ARIA (Accessible Rich Internet Applications) specification.
The role attribute is used to define the purpose of an element for assistive technologies. Only certain predefined values are valid, such as navigation, complementary, main, banner, contentinfo, and others. There is no sidebar role in the ARIA or HTML specification. If you wish to indicate a sidebar, you should use the complementary role, which is intended for content that is tangentially related to the main content, such as a sidebar.
Incorrect Example:
<div role="sidebar">
<!-- Sidebar content -->
</div>
Correct Example:
<div role="complementary">
<!-- Sidebar content -->
</div>
Alternatively, you can use the aside element, which conveys the same meaning and does not require an explicit role attribute:
<aside>
<!-- Sidebar content -->
</aside>
Using either the role="complementary" on a generic container or the semantic <aside> element ensures your HTML is valid and accessible.
sidebar is not a valid value for the role attribute according to the ARIA (Accessible Rich Internet Applications) specification.
The role attribute is used to define the purpose of an element for assistive technologies. Only certain predefined values are valid, such as navigation, complementary, main, banner, contentinfo, and others. There is no sidebar role in the ARIA or HTML specification. If you wish to indicate a sidebar, you should use the complementary role, which is intended for content that is tangentially related to the main content, such as a sidebar.
Incorrect Example:
<div role="sidebar">
<!-- Sidebar content -->
</div>
Correct Example:
<div role="complementary">
<!-- Sidebar content -->
</div>
Alternatively, you can use the aside element, which conveys the same meaning and does not require an explicit role attribute:
<aside>
<!-- Sidebar content -->
</aside>
Using either the role="complementary" on a generic container or the semantic <aside> element ensures your HTML is valid and accessible.
A textbox role is not valid for a li (list item) element. If the intention is to create a textual input area, a different approach, such as using the input element or the textarea element, is recommended.
The textbox role is used to identify an element that allows the input of free-form text. Whenever possible, rather than using this role, use an <input> element with type="text", for single-line input, or a <textarea> element for multi-line input.
Here’s an example of how to use the textbox role on a <div> element:
<!-- Simple text input field -->
<div id="txtboxLabel">Enter your five-digit zipcode</div>
<div
role="textbox"
contenteditable="true"
aria-placeholder="5-digit zipcode"
aria-labelledby="txtboxLabel"></div>
The attribute aria-hidden must have a value of "true" (without extra quotes) or "false", not "\"true\"" (with double quotes inside the value).
The aria-hidden attribute is used to indicate whether an element and its children should be accessible to assistive technologies (like screen readers). Valid values are the strings "true" or "false" (without embedded quotation marks). Using extra quotation marks causes the validator to flag a bad value because the attribute’s value is interpreted literally.
Incorrect Example:
<div aria-hidden='"true"'>This is hidden from assistive tech</div>
Correct Example:
<div aria-hidden="true">This is hidden from assistive tech</div>
or
<div aria-hidden="false">This is visible to assistive tech</div>
Remove any extra quotation marks around your attribute value to resolve the error.