Bad value “section” for attribute “role” on element “section”.

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>

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

Using role="article" on a <section> element is invalid because article is not a permitted value for the role attribute.

The role attribute in HTML is used to define ARIA roles that describe the purpose of an element for assistive technologies. Only specific, predefined ARIA roles are valid per the WAI-ARIA specification. article is not a recognized ARIA role—use document or other appropriate roles instead, or omit the role attribute entirely. The <article> and <section> elements already have implicit roles, so manual role assignment is rarely necessary or useful for these elements.

Valid uses:

• Use <article> without a role attribute for content that is self-contained and intended to be independently distributable or reusable.
• Use <section> for grouping related content and omit the role attribute unless a specific ARIA landmark role is needed (such as region).

Example: use <article> for standalone content

<article>
  <h2>News headline</h2>
  <p>News content goes here.</p>
</article>

Example: use <section> without a role attribute for generic grouping

<section>
  <h2>Introduction</h2>
  <p>Section content.</p>
</section>

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

Use a valid landmark or list role: remove role="list" from the section, or replace the element with a proper list (ul/ol) or a container that supports role="list".

The role attribute must use values allowed by ARIA for the given context. A section element is a landmark and must not be given role="list". If you intend to mark up a list of items, use semantic list elements: ul/ol with li. If you truly need ARIA list semantics (e.g., for custom components), use a neutral container (div) with role="list" and child elements with role="listitem". Prefer native HTML lists over ARIA roles because they provide built-in semantics and better accessibility. Examples:

• Native list: use ul + li.
• ARIA list (only if native markup isn’t possible): div role="list" containing div role="listitem".

HTML Examples

Example showing the validation error

<section role="list">
  <div>Item A</div>
  <div>Item B</div>
</section>

Fixed using native list semantics (recommended)

<ul>
  <li>Item A</li>
  <li>Item B</li>
</ul>

Fixed using ARIA roles on neutral elements (when custom UI prevents native lists)

<div role="list">
  <div role="listitem">Item A</div>
  <div role="listitem">Item B</div>
</div>