suspicious-semantics

The navigation, menubar, menu, and tablist roles tell screen reader users what to expect inside an element: links to other pages, menu items, or tabs. When one of these roles is applied to a form, such as a search box or a group of form fields with a submit button, the announcement doesn't match the content. Users expect to move through links, menu items, or tabs, and find form fields instead. They may misunderstand the content, or not know how to interact with it.

A menu, menubar, or tablist role can also change how screen readers handle keyboard input, because these widgets are expected to manage their own arrow keys. Inside one of them, form fields can be harder to reach and fill in.

Evinced reports this issue when an element has the navigation, menubar, menu, or tablist role, but it looks like a form.

To fix the issue:

• If the element is a form, remove the navigation-type role. Use a <form> element with an accessible name, or role="search" for a search form.
• If a navigation area also contains a form, for example a search field in the site header, apply the navigation role to the navigation part only, and place the form in its own <form> or search landmark.

Pass Patterns

Search form with the search role

The form is exposed as a search landmark, and its field and button keep their own roles.

<form role="search" aria-label="Site">
    <label for="site-search">Search</label>
    <input type="search" id="site-search" />
    <button>Search</button>
</form>

Navigation and search side by side

The header holds a navigation landmark for its links, and a separate search landmark for the search form.

<header>
    <nav aria-label="Main">
        <ul>
            <li><a href="/">Home</a></li>
            <li><a href="/products">Products</a></li>
        </ul>
    </nav>
    <form role="search" aria-label="Site">
        <label for="site-search">Search</label>
        <input type="search" id="site-search" />
        <button>Search</button>
    </form>
</header>

Fail Patterns

Search form with the navigation role

The element contains only a search field and a button, but the navigation role tells screen reader users it's a navigation area.

<div role="navigation">
    <label for="site-search">Search</label>
    <input type="search" id="site-search" />
    <button>Search</button>
</div>

Sign-up form with the menubar role

The form is announced as a menu bar, so users expect menu items and arrow key navigation, but find form fields.

<form role="menubar">
    <label for="email">Email address</label>
    <input type="email" id="email" />
    <button>Subscribe</button>
</form>

WCAG techniques

Sufficient techniques

• ARIA11: Using ARIA landmarks to identify regions of a page
• H101: Using semantic HTML elements to identify regions of a page

Try It Yourself

Using a screen reader

1. Load the page and open a screen reader.
2. Move into the form, and listen to what the screen reader announces.
3. Try to fill in the form fields.

Expected results: The screen reader announces a form or a search area, and then the form fields.

Actual results: The screen reader announces a navigation area, a menu, or a set of tabs, and then form fields that don't match that announcement.

Inspecting the browser dev-tools

1. In your browser's dev tools, select the element that contains the form and open the Accessibility panel.
2. Check the element's role.

Expected results: The role is form, search, or a generic role.

Actual results: The role is navigation, menubar, menu, or tablist.

FAQ

Standards and Regulations

Personas impacted by this issue

• Screen Reader
• Braille

Learn More

• HTML Landmarks
• WAI-ARIA Authoring Practices: Landmark Regions
• WAI-ARIA 1.3: search role
• WAI-ARIA 1.3: form role

Related Issues

• container-missing-semantics
• aria-allowed-role
• landmark-unique
• region