HTML Guide

<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>

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>

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>

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">

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 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:

1. 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>

2. 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>

3. 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.

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.