HTML Guides for aria

The HTML specification defines certain elements as having implicit ARIA roles — roles that are automatically communicated to assistive technologies without any additional attributes. The nav element is one of these: its implicit role is navigation. When you explicitly add role="navigation" to a nav element, you're telling the browser something it already knows, which clutters your markup without adding any value.

This redundancy matters for several reasons:

• Code maintainability: Unnecessary attributes make your HTML harder to read and maintain. Future developers may wonder if the explicit role is there for a specific reason, creating confusion.
• Standards compliance: The W3C validator warns about this because the ARIA specification follows a principle often summarized as the first rule of ARIA: don't use ARIA if a native HTML element already provides the semantics you need. Extending this principle, don't re-declare semantics that are already present.
• No accessibility benefit: Assistive technologies like screen readers already recognize nav as a navigation landmark. Adding the explicit role doesn't improve the experience for users of these technologies — it's simply noise.

The role="navigation" attribute is useful when applied to a non-semantic element like a div or span that functions as navigation but can't be changed to a nav element (for example, due to legacy constraints). But when you're already using nav, the attribute is unnecessary.

To fix this, remove the role="navigation" attribute from your nav element. The semantic meaning is fully preserved.

Examples

Incorrect: redundant role on nav

This triggers the W3C validator warning because the navigation role is already implicit:

<nav role="navigation">

<ul>

<li><a href="/">Home</a></li>

<li><a href="/about">About</a></li>

<li><a href="/contact">Contact</a></li>

</ul>

</nav>

Correct: nav without the explicit role

Simply remove the redundant role attribute:

<nav>

<ul>

<li><a href="/">Home</a></li>

<li><a href="/about">About</a></li>

<li><a href="/contact">Contact</a></li>

</ul>

</nav>

Correct: using role="navigation" on a non-semantic element

If you cannot use a nav element, applying the role to a div is a valid approach. This does not trigger the warning:

<div role="navigation">

<ul>

<li><a href="/">Home</a></li>

<li><a href="/about">About</a></li>

<li><a href="/contact">Contact</a></li>

</ul>

</div>

Correct: labeling multiple nav elements

When a page has more than one nav, use aria-label or aria-labelledby to differentiate them for assistive technology users — but still don't add the redundant role:

<nav aria-label="Main">

<ul>

<li><a href="/">Home</a></li>

<li><a href="/about">About</a></li>

</ul>

</nav>

<nav aria-label="Footer">

<ul>

<li><a href="/privacy">Privacy Policy</a></li>

<li><a href="/terms">Terms of Service</a></li>

</ul>

</nav>

The role="presentation" on this element is ignored because the element also carries a global ARIA attribute, such as aria-label or aria-describedby.

role="presentation" (and its synonym role="none") removes an element's implicit semantics so assistive technologies treat it as if it were plain content. Global ARIA states and properties, such as aria-label, aria-describedby, aria-live, and aria-hidden, are allowed on any element regardless of its role. When one of them is present, the browser cannot silence the element, because that attribute needs a role to attach to. The ARIA specification resolves this conflict by ignoring the presentation role and exposing the element's implicit role instead.

The result is that role="presentation" does nothing here, which is almost always a mistake. Decide which of the two you actually want.

If the element should stay presentational, remove the global ARIA attribute. If you need the ARIA attribute, remove role="presentation" and let the element keep its semantics.

Invalid example

The aria-label cancels the presentation role, so the <div> is not silenced:

<div role="presentation" aria-label="Main navigation">

...

</div>

Valid example

Keep the label and drop the ineffective role:

<div aria-label="Main navigation">

...

</div>

Or, if the element was only meant to be presentational, remove the ARIA attribute:

<div role="presentation">

...

</div>

The role="radio" attribute is redundant on an <input type="radio"> element because the browser already exposes this element with the radio role to assistive technologies.

Screen readers and other assistive tools determine an element's purpose through its implicit ARIA role. The <input type="radio"> element has an implicit role of radio as defined in the ARIA in HTML specification. Adding role="radio" explicitly just repeats what the browser already communicates, and the W3C validator flags this as unnecessary.

Redundant roles add clutter to your markup without any accessibility benefit. In some edge cases, explicitly setting a role that matches the implicit one can even cause unexpected behavior in certain browser and screen reader combinations. The general rule: don't set a role on an element that already has that same role by default.

This applies to many other elements too. For example, <button role="button">, <a href="..." role="link">, and <nav role="navigation"> are all similarly redundant.

HTML examples

Before: redundant role

<label>

<input type="radio" name="color" value="red" role="radio">

Red

</label>

<label>

<input type="radio" name="color" value="blue" role="radio">

Blue

</label>

After: role removed

<label>

<input type="radio" name="color" value="red">

Red

</label>

<label>

<input type="radio" name="color" value="blue">

Blue

</label>

Remove the role="radio" attribute. The element already communicates its role to assistive technologies without it.

The HTML specification and WAI-ARIA guidelines establish that certain HTML elements carry implicit landmark roles. The <section> element implicitly maps to role="region", meaning assistive technologies like screen readers already recognize it as a region landmark without any additional ARIA markup. This principle is captured by the first rule of ARIA use: "If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so."

Adding role="region" to a <section> doesn't change the element's behavior or how assistive technologies interpret it — it simply duplicates what the browser already communicates. The W3C Validator warns about this redundancy to encourage cleaner, more maintainable markup and to help developers understand native HTML semantics.

This same principle applies to other HTML elements with implicit roles: <nav> has an implicit role="navigation", <main> has role="main", <aside> has role="complementary", <header> has role="banner" (when not nested in a sectioning element), and <footer> has role="contentinfo" (when not nested in a sectioning element). Adding these explicit roles to their corresponding elements will trigger similar validator warnings.

It's worth noting that a <section> element is only exposed as a region landmark by assistive technologies when it has an accessible name. If your <section> doesn't have an accessible name (via aria-label, aria-labelledby, or similar mechanisms), screen readers may not treat it as a navigable landmark — but this still doesn't mean you should add role="region", since the implicit role mapping remains the same regardless.

How to fix it

1. Remove the role="region" attribute from any <section> element.
2. If you want the section to be a meaningful landmark for screen reader users, give it an accessible name using aria-labelledby (pointing to a heading) or aria-label.
3. Never add explicit ARIA roles that duplicate the implicit role of a native HTML element.

Examples

Incorrect: redundant role on section

<section role="region">

<h2>Contact Information</h2>

<p>Email us at info@example.com</p>

</section>

Correct: section without redundant role

<section>

<h2>Contact Information</h2>

<p>Email us at info@example.com</p>

</section>

Correct: section with an accessible name for landmark navigation

Using aria-labelledby to associate the section with its heading ensures assistive technologies expose it as a named landmark region:

<section aria-labelledby="contact-heading">

<h2 id="contact-heading">Contact Information</h2>

<p>Email us at info@example.com</p>

</section>

Correct: section with aria-label when no visible heading exists

<section aria-label="Contact information">

<p>Email us at info@example.com</p>

</section>

Incorrect: redundant roles on other landmark elements

The same principle applies to other native landmark elements. Avoid these patterns:

<nav role="navigation">

<a href="/">Home</a>

</nav>

<main role="main">

<p>Page content</p>

</main>

<aside role="complementary">

<p>Related links</p>

</aside>

Correct: landmark elements without redundant roles

<nav>

<a href="/">Home</a>

</nav>

<main>

<p>Page content</p>

</main>

<aside>

<p>Related links</p>

</aside>

A <td> inside a <table> with no role, or with a role of table, grid or treegrid, gets its ARIA role from the table and must not have a role attribute of its own.

Browsers map table cells automatically. In a plain table, or one with role="table", each <td> is exposed as a cell. In a table with role="grid" or role="treegrid", each <td> is exposed as a gridcell. The ARIA in HTML specification doesn't let authors set any role on these cells, so the validator rejects redundant values like role="cell" and role="gridcell" as well as roles that turn the cell into something else, such as role="button" or role="presentation".

A <td> exposed as a button is no longer a cell, so screen readers can't announce its row and column headers or reach it with table navigation commands.

To make a cell interactive, put a real control such as a <button> or an <a> inside the <td>. For layout tables, which are common in HTML email, set role="presentation" on the <table> instead of on each cell. Once the table has a role other than table, grid or treegrid, its cells lose their table semantics and the rule no longer applies.

Invalid examples

Data table

<table>

<tr>

<th>Name</th>

<th>Actions</th>

</tr>

<tr>

<td role="cell">Alice</td>

<td role="button" tabindex="0">Edit</td>

</tr>

</table>

Layout table

<table>

<tr>

<td role="presentation">Logo</td>

<td role="presentation">Newsletter title</td>

</tr>

</table>

Valid examples

Data table

<table>

<tr>

<th>Name</th>

<th>Actions</th>

</tr>

<tr>

<td>Alice</td>

<td><button type="button">Edit</button></td>

</tr>

</table>

Layout table

<table role="presentation">

<tr>

<td>Logo</td>

<td>Newsletter title</td>

</tr>

</table>

The role attribute is not allowed on a label element when that label is associated with a form control (a labelable element) through the for attribute or by nesting.

When a label is associated with a form control, the browser already understands its purpose — it's a label. Adding a role attribute overrides this native semantics, which is redundant at best and confusing for assistive technologies at worst.

A label becomes "associated" with a labelable element in two ways: explicitly via the for attribute pointing to the control's id, or implicitly by wrapping the control inside the label. Labelable elements include input (except type="hidden"), select, textarea, button, meter, output, and progress.

If the label is associated, simply remove the role attribute. The native semantics are already correct and sufficient.

If you truly need a custom role for some reason and the label is not functionally labeling a control, you can disassociate it by removing the for attribute or unnesting the control — but this is rarely the right approach.

Invalid Example

<label for="email" role="presentation">Email</label>

<input type="email" id="email">

Valid Example

<label for="email">Email</label>

<input type="email" id="email">

Every HTML element carries an implicit ARIA role based on its type and attributes. For <input type="search"> elements that do not have a list attribute, the browser automatically exposes the element with the searchbox role to assistive technologies. This mapping is defined in the ARIA in HTML specification, which establishes the correspondence between native HTML semantics and ARIA roles.

When you explicitly add role="searchbox" to an element that already carries that role implicitly, the validator raises a warning because the attribute is doing nothing useful. While it won't break functionality, redundant roles clutter your markup and can signal to other developers (or future you) that something special is intended when it isn't. Following the general principle of ARIA — "don't use ARIA if you can use native HTML" — also means not restating what the browser already communicates.

Note the distinction the validator makes: this applies specifically to <input type="search"> elements without a list attribute. When a list attribute is present (linking the input to a <datalist>), the implicit role changes to combobox, so in that specific scenario the implicit role is different. However, for a plain search input without list, the searchbox role is already baked in.

Why it matters

• Standards compliance: The W3C validator flags redundant roles to encourage clean, semantic markup that relies on native HTML behavior.
• Maintainability: Redundant attributes add noise. Other developers may wonder why the role was explicitly set and whether removing it would break something.
• ARIA best practices: The first rule of ARIA is to use native HTML semantics whenever possible. Restating implicit roles goes against this principle and can mask situations where an explicit role would actually be meaningful.

How to fix it

Simply remove the role="searchbox" attribute from any <input type="search"> element that does not have a list attribute. The browser and assistive technologies will continue to treat it as a search box.

Examples

Incorrect — redundant role

The role="searchbox" is unnecessary here because <input type="search"> already implies it:

<label for="site-search">Search the site:</label>

<input type="search" id="site-search" role="searchbox" placeholder="Search...">

Correct — relying on implicit role

Remove the redundant role attribute and let native HTML semantics do the work:

<label for="site-search">Search the site:</label>

<input type="search" id="site-search" placeholder="Search...">

Correct — explicit role when implicit role differs

When a list attribute is present, the implicit role changes to combobox. If you want assistive technologies to treat it as a searchbox instead, an explicit role is justified:

<label for="city-search">Search cities:</label>

<input type="search" id="city-search" list="cities" role="searchbox">

<datalist id="cities">

<option value="Amsterdam">

<option value="Berlin">

<option value="Cairo">

</datalist>

In this case, the validator will not flag the role as redundant because the implicit role (combobox) differs from the explicitly set role (searchbox).

The role="table" attribute on a <table> element is redundant because the <table> element already has an implicit ARIA role of table.

Every HTML element carries a default ARIA role defined by the HTML specification. The <table> element's built-in role is table, so adding role="table" explicitly tells assistive technologies something they already know. The W3C validator flags this as unnecessary markup.

This applies to many other elements too. A <nav> element has an implicit role of navigation, a <button> has a role of button, and so on. Adding these explicit roles creates noise in the code without any accessibility benefit.

Incorrect example

<table role="table">

<tr>

<th>Name</th>

<th>Age</th>

</tr>

<tr>

<td>Alice</td>

<td>30</td>

</tr>

</table>

Fixed example

<table>

<tr>

<th>Name</th>

<th>Age</th>

</tr>

<tr>

<td>Alice</td>

<td>30</td>

</tr>

</table>

When you use semantic HTML elements, browsers automatically assign appropriate ARIA roles behind the scenes. An <input type="text"> element without a list attribute is inherently recognized by browsers and assistive technologies as a textbox — a control that accepts free-form text input. Explicitly declaring role="textbox" on such an element repeats information that is already conveyed natively, which is what the validator flags.

The distinction about the list attribute matters because when an <input type="text"> does have a list attribute (linking it to a <datalist>), its implicit role changes to combobox rather than textbox. In that scenario, a role="textbox" would not only be redundant — it would actually be incorrect. The validator's message specifically targets the case where there is no list attribute, meaning the implicit role is already textbox.

Why this is a problem

• Redundancy clutters your code. Adding roles that elements already possess makes HTML harder to read and maintain without providing any benefit.
• Potential for confusion. Other developers (or your future self) may wonder if the explicit role was added intentionally to override some other behavior, leading to unnecessary investigation.
• Standards compliance. The W3C and WAI-ARIA authoring practices recommend against setting ARIA roles that duplicate the native semantics of an element. The first rule of ARIA use is: "If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so."
• No accessibility benefit. Assistive technologies already understand that <input type="text"> is a textbox. The explicit role adds no additional information for screen readers or other tools.

How to fix it

Simply remove the role="textbox" attribute from your <input type="text"> element. The native semantics of the element are sufficient.

If you've added the role because the input is styled or behaves differently, consider whether you actually need a different element or a different ARIA pattern instead.

Examples

❌ Incorrect: redundant role="textbox"

<label for="username">Username</label>

<input type="text" id="username" role="textbox">

The role="textbox" is unnecessary here because <input type="text"> without a list attribute already has an implicit role of textbox.

✅ Correct: no explicit role needed

<label for="username">Username</label>

<input type="text" id="username">

✅ Also correct: input with list attribute (different implicit role)

<label for="color">Favorite color</label>

<input type="text" id="color" list="colors">

<datalist id="colors">

<option value="Red">

<option value="Green">

<option value="Blue">

</datalist>

In this case, the list attribute changes the implicit role to combobox, so the validator warning about a redundant textbox role would not apply. Note that adding role="textbox" here would be incorrect rather than merely redundant, since it would override the proper combobox semantics.

❌ Incorrect: redundant role on implicit text input

<label for="search-field">Search</label>

<input id="search-field" role="textbox">

When the type attribute is omitted, <input> defaults to type="text", so the implicit role is still textbox and the explicit role remains redundant.

✅ Correct: let the default type handle semantics

<label for="search-field">Search</label>

<input id="search-field">