HTML Guides for aria

The <dialog> element was introduced to provide a native way to create modal and non-modal dialog boxes in HTML. As defined in the WHATWG HTML Living Standard and the ARIA in HTML specification, every <dialog> element automatically carries an implicit dialog role. This means assistive technologies like screen readers already recognize it as a dialog without any additional ARIA markup.

When you explicitly add role="dialog" to a <dialog> element, you're restating what the browser and assistive technologies already know. This violates the first rule of ARIA use: do not use ARIA if you can use a native HTML element or attribute with the semantics already built in. While this redundancy won't break functionality, it clutters your markup and signals to other developers (and validators) that the author may not understand the element's built-in semantics.

This principle applies broadly across HTML. Many elements have implicit ARIA roles — <nav> has navigation, <main> has main, <button> has button, and so on. Adding the matching role explicitly to any of these elements produces a similar validator warning.

How to fix it

Simply remove the role="dialog" attribute from the <dialog> element. The built-in semantics handle everything automatically. If you need to provide additional context for assistive technologies, consider using aria-label or aria-labelledby to give the dialog a descriptive accessible name — that's genuinely useful supplementary information rather than a redundant role.

Examples

Incorrect: redundant role attribute

<dialogrole="dialog">

<h2>Confirm action</h2>

<p>Are you sure you want to delete this item?</p>

<button>Cancel</button>

<button>Delete</button>

</dialog>

This triggers the validator warning because role="dialog" duplicates the implicit role of the <dialog> element.

Correct: relying on implicit semantics

<dialog>

<h2>Confirm action</h2>

<p>Are you sure you want to delete this item?</p>

<button>Cancel</button>

<button>Delete</button>

</dialog>

Correct: adding a descriptive accessible name

<dialogaria-labelledby="dialog-title">

<h2id="dialog-title">Confirm action</h2>

<p>Are you sure you want to delete this item?</p>

<button>Cancel</button>

<button>Delete</button>

</dialog>

Using aria-labelledby to associate the dialog with its heading is a meaningful enhancement — it gives the dialog an accessible name that screen readers announce when the dialog opens. This is the kind of ARIA usage that genuinely improves accessibility, as opposed to redundantly restating the element's role.

The role="button" attribute tells assistive technologies like screen readers that an element behaves as a button — a widget used to perform actions such as submitting a form, opening a dialog, or triggering a command. When a <button> element appears inside an element with role="button", the result is a nested interactive control. The HTML specification explicitly forbids this because interactive content must not be nested within other interactive content.

This nesting causes real problems. Screen readers may announce the outer element as a button but fail to recognize or reach the inner <button>. Keyboard users may not be able to focus on or activate the inner control. Different browsers handle the situation inconsistently — some may ignore one of the controls entirely, others may fire events on the wrong element. The end result is an interface that is broken for many users.

This issue commonly arises in a few scenarios:

• A <div> or <span> is given role="button" and then a <button> is placed inside it for styling or click-handling purposes.
• A component library wraps content in a role="button" container, and a developer adds a <button> inside without realizing the conflict.
• A custom card or list item is made clickable with role="button", but also contains action buttons within it.

The fix depends on your intent. If the outer element is the intended interactive control, remove the inner <button> and handle interactions on the outer element. If the inner <button> is the intended control, remove role="button" from the ancestor. If both need to be independently clickable, restructure the markup so neither is a descendant of the other.

Examples

❌ Incorrect: <button> inside an element with role="button"

<divrole="button"tabindex="0"onclick="handleClick()">

<buttontype="button">Click me</button>

</div>

This is invalid because the <button> is a descendant of the <div> that has role="button".

✅ Fix option 1: Use only the <button> element

If the inner <button> is the actual control, remove role="button" from the wrapper:

<div>

<buttontype="button"onclick="handleClick()">Click me</button>

</div>

✅ Fix option 2: Use only the outer role="button" element

If the outer element is the intended interactive control, remove the inner <button>:

<divrole="button"tabindex="0"onclick="handleClick()">

Click me

</div>

Note that when using role="button" on a non-<button> element, you must also handle keyboard events (Enter and Space) manually. A native <button> provides this for free, so prefer option 1 when possible.

❌ Incorrect: Clickable card containing action buttons

<divrole="button"tabindex="0"class="card">

<h3>Item title</h3>

<p>Description text</p>

<buttontype="button">Delete</button>

</div>

✅ Fix: Separate the card link from the action buttons

<divclass="card">

<h3><buttontype="button"class="card-link">Item title</button></h3>

<p>Description text</p>

<buttontype="button">Delete</button>

</div>

In this approach, the card's main action is handled by a <button> on the title, while the "Delete" button remains an independent control. Neither is nested inside the other, and both are accessible to keyboard and screen reader users.

Many HTML elements come with built-in ARIA roles that assistive technologies already recognize. The <fieldset> element is one of these — its implicit role is group, which tells screen readers that the contained form controls are related. When you add role="group" to a <fieldset>, you're telling the browser something it already knows.

This redundancy matters for a few reasons:

• Code cleanliness: Unnecessary attributes add clutter, making your markup harder to read and maintain.
• ARIA best practices: The first rule of ARIA 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." Adding role="group" to <fieldset> violates this principle in spirit — it suggests the developer may not understand the element's native semantics.
• Potential confusion: Explicitly setting roles that match the default can mislead other developers into thinking the role is doing something special, or that removing it would change behavior.

This same principle applies to other elements with implicit roles, such as role="navigation" on <nav>, role="banner" on <header>, or role="button" on <button>. If the element already carries the semantic meaning natively, there's no need to duplicate it with an explicit ARIA role.

To fix this, simply remove the role="group" attribute from the <fieldset> element. No replacement is needed — the browser and assistive technologies will continue to treat the <fieldset> as a group automatically.

Examples

Incorrect: redundant role="group" on <fieldset>

<form>

<fieldsetrole="group">

<legend>Shipping Address</legend>

<labelfor="street">Street:</label>

<inputtype="text"id="street"name="street">

<labelfor="city">City:</label>

<inputtype="text"id="city"name="city">

</fieldset>

</form>

The validator will report that the group role is unnecessary for the <fieldset> element.

Correct: <fieldset> without explicit role

<form>

<fieldset>

<legend>Shipping Address</legend>

<labelfor="street">Street:</label>

<inputtype="text"id="street"name="street">

<labelfor="city">City:</label>

<inputtype="text"id="city"name="city">

</fieldset>

</form>

The <fieldset> element inherently communicates the group role to assistive technologies, so no ARIA attribute is needed.

When role on <fieldset> is appropriate

There are cases where you might legitimately set a different role on a <fieldset> — for example, role="radiogroup" when the fieldset contains a set of related radio buttons and you want to convey more specific semantics:

<form>

<fieldsetrole="radiogroup"aria-labelledby="color-legend">

<legendid="color-legend">Favorite Color</legend>

<label><inputtype="radio"name="color"value="red"> Red</label>

<label><inputtype="radio"name="color"value="blue"> Blue</label>

<label><inputtype="radio"name="color"value="green"> Green</label>

</fieldset>

</form>

This is valid because radiogroup is a different role that provides more specific meaning than the default group. The validator only warns when the explicit role matches the element's implicit role.

HTML heading elements (<h1> through <h6>) have built-in semantic meaning that browsers and assistive technologies already understand. According to the WAI-ARIA specification, each of these elements carries an implicit heading role with a corresponding aria-level — <h1> has aria-level="1", <h2> has aria-level="2", and so on. When you explicitly add role="heading" to one of these elements, you're telling the browser something it already knows, which clutters your markup without providing any benefit.

This pattern is part of a broader principle in ARIA authoring known as the first rule of ARIA: don't use ARIA when a native HTML element already provides the semantics you need. Redundant ARIA roles can cause confusion for developers maintaining the code, as it suggests that the role might be necessary or that the element might not otherwise be recognized as a heading. In some edge cases, adding an explicit aria-level that doesn't match the heading level (e.g., aria-level="3" on an <h1>) can create conflicting information for screen readers, leading to an inconsistent experience for users of assistive technologies.

The role="heading" attribute is designed for situations where you need to give heading semantics to a non-heading element, such as a <div> or <span>. In those cases, you must also include the aria-level attribute to specify the heading's level. However, whenever possible, using native heading elements is always preferred over this ARIA-based approach.

How to fix it

1. Remove role="heading" from any <h1> through <h6> element.
2. Remove aria-level if it was added alongside the redundant role and matches the heading's native level.
3. If you genuinely need a non-standard element to act as a heading, use role="heading" with aria-level on that element instead — but prefer native heading elements whenever possible.

Examples

❌ Redundant role on a native heading

<h1role="heading"aria-level="1">Welcome to My Site</h1>

<h2role="heading">About Us</h2>

<h3role="heading"aria-level="3">Our Mission</h3>

All three headings will trigger the validator warning. The role="heading" and aria-level attributes are completely unnecessary here because the elements already convey this information natively.

✅ Native headings without redundant roles

<h1>Welcome to My Site</h1>

<h2>About Us</h2>

<h3>Our Mission</h3>

Simply removing the redundant attributes resolves the issue while preserving full accessibility.

✅ Correct use of the heading role on a non-heading element

In rare cases where you cannot use a native heading element, the heading role is appropriate on a generic element:

<divrole="heading"aria-level="2">Section Title</div>

This tells assistive technologies to treat the <div> as a level-2 heading. Note that aria-level is required here since a <div> has no implicit heading level. That said, using a native <h2> is always the better choice:

<h2>Section Title</h2>

❌ Conflicting aria-level on a native heading

Be especially careful with this anti-pattern, where the explicit level contradicts the element:

<h1role="heading"aria-level="3">Page Title</h1>

This sends mixed signals — the element is an <h1> but claims to be level 3. Screen readers may behave unpredictably. If you need a level-3 heading, use <h3>:

<h3>Page Title</h3>

Every HTML element has an implicit ARIA role defined by the HTML specification. The <img> element's implicit role is img, which means assistive technologies like screen readers already recognize it as an image without any additional ARIA attributes. Adding role="img" explicitly doesn't change behavior — it just adds unnecessary noise to your markup and signals that the author may not understand how native semantics work.

The W3C validator flags this because it violates the first rule of ARIA: don't use ARIA if you can use a native HTML element or attribute that already has the semantics you need. Redundant roles clutter your code, make maintenance harder, and can confuse other developers into thinking the role is there for a specific reason.

The role="img" attribute is genuinely useful in other contexts — for example, when you want to group multiple elements together and have them treated as a single image by assistive technologies. A <div> or <span> has no implicit img role, so adding role="img" to a container is meaningful and appropriate.

How to fix it

Simply remove the role="img" attribute from any <img> element. The image semantics are already built in. Make sure you still provide a meaningful alt attribute for accessibility.

Examples

❌ Redundant role on <img>

<imgsrc="photo.jpg"alt="A sunset over the ocean"role="img">

The validator will warn: The "img" role is unnecessary for element "img".

✅ Fixed: Remove the redundant role

<imgsrc="photo.jpg"alt="A sunset over the ocean">

No explicit role is needed. The browser already communicates this element as an image.

✅ Legitimate use of role="img" on a non-image element

The role="img" attribute is appropriate when applied to a container that groups multiple elements into a single conceptual image:

<divrole="img"aria-label="Star rating: 4 out of 5">

<span>⭐</span>

<span>⭐</span>

<span>⭐</span>

<span>⭐</span>

<span>☆</span>

</div>

Here, the <div> has no inherent image semantics, so role="img" is meaningful — it tells assistive technologies to treat the entire group as a single image described by the aria-label.

✅ Another legitimate use: CSS background image with role="img"

<divrole="img"aria-label="Company logo"class="logo-background"></div>

Since a <div> styled with a CSS background image has no image semantics, role="img" paired with aria-label ensures the visual content is accessible.

The listbox role is the implicit ARIA role for a <select> element only when it has a multiple attribute or a size attribute greater than 1. A standard single-selection <select> (dropdown) has an implicit role of combobox, so explicitly assigning role="listbox" to it creates a conflict.

When a <select> element has no multiple attribute and no size greater than 1, browsers render it as a collapsed dropdown — a combobox. The listbox role describes a widget where all options are persistently visible, which matches the behavior of a multi-select or a select with a visible size greater than 1. Applying role="listbox" to a standard dropdown misrepresents the control to assistive technologies.

You have a few options to fix this: remove the role="listbox" entirely (since the browser already assigns the correct implicit role), add the multiple attribute, or set size to a value greater than 1.

Incorrect Example

<selectrole="listbox"name="color">

<optionvalue="red">Red</option>

<optionvalue="blue">Blue</option>

<optionvalue="green">Green</option>

</select>

Fixed Examples

Remove the explicit role and let the browser handle it:

<selectname="color">

<optionvalue="red">Red</option>

<optionvalue="blue">Blue</option>

<optionvalue="green">Green</option>

</select>

Or, if you genuinely need role="listbox", use multiple or size greater than 1:

<selectrole="listbox"name="color"multiple>

<optionvalue="red">Red</option>

<optionvalue="blue">Blue</option>

<optionvalue="green">Green</option>

</select>

<selectrole="listbox"name="color"size="3">

<optionvalue="red">Red</option>

<optionvalue="blue">Blue</option>

<optionvalue="green">Green</option>

</select>

In most cases, simply removing role="listbox" is the best fix. The implicit ARIA roles already convey the correct semantics to assistive technologies without any extra attributes.

Many HTML elements have built-in (implicit) ARIA roles defined by the WAI-ARIA specification. The <li> element natively carries the listitem role when it is a child of a <ul>, <ol>, or <menu> element. Adding role="listitem" explicitly doesn't change behavior, but it clutters your markup and signals a misunderstanding of how semantic HTML and ARIA interact. This falls under the first rule of ARIA use: "If you can use a native HTML element with the semantics and behavior you require already built in, do so, instead of re-purposing an element and adding an ARIA role."

Redundant ARIA roles create several problems:

• Maintenance burden — Extra attributes add noise to your code, making it harder to read and maintain.
• Potential confusion — Other developers may wonder if the explicit role was added intentionally to override something, leading to uncertainty during code reviews.
• Validator warnings — Tools like the W3C HTML Validator flag these redundancies, and accumulating unnecessary warnings can obscure real issues that need attention.

The ARIA listitem role is designed for situations where you cannot use semantic HTML — for instance, when you need to create a list-like structure from generic elements like <div> or <span>. In those cases, you would pair role="list" on the container with role="listitem" on each child. But when you're already using <ul>, <ol>, or <menu> with <li> children, the ARIA roles are built in and should not be repeated.

To fix this, simply remove the role="listitem" attribute from your <li> elements. If you also have role="list" on a <ul> or <ol>, remove that too — it's equally redundant.

Examples

❌ Redundant role on <li> elements

<ulrole="list">

<lirole="listitem">Apples</li>

<lirole="listitem">Bananas</li>

<lirole="listitem">Cherries</li>

</ul>

Both role="list" on the <ul> and role="listitem" on each <li> are unnecessary because these elements already carry those roles implicitly.

✅ Clean semantic HTML without redundant roles

<ul>

<li>Apples</li>

<li>Bananas</li>

<li>Cherries</li>

</ul>

The <ul> and <li> elements provide all the accessibility semantics needed without any explicit ARIA attributes.

✅ Using ARIA roles on non-semantic elements (when necessary)

If for some reason you cannot use native list elements, ARIA roles are appropriate on generic elements:

<divrole="list">

<divrole="listitem">Apples</div>

<divrole="listitem">Bananas</div>

<divrole="listitem">Cherries</div>

</div>

This is the intended use case for role="listitem" — adding list semantics to elements that don't have them natively. However, using semantic <ul>/<ol> with <li> is always preferred when possible.

The ARIA specification defines a set of roles that convey the purpose of an element to assistive technologies like screen readers. Many HTML elements have implicit ARIA roles — built-in semantics that map directly to ARIA roles without any extra markup. The <main> element is one of these: it automatically communicates the main landmark role to assistive technologies.

When you write <main role="main">, you're explicitly stating something the browser and assistive technologies already know. The W3C validator warns about this redundancy because it can signal a misunderstanding of how native HTML semantics work. While it won't break anything, unnecessary attributes add noise to your markup and can make code harder to maintain.

This principle applies broadly across HTML. For example, <nav> implicitly has role="navigation", <header> implicitly has role="banner" (when not nested inside a sectioning element), and <button> implicitly has role="button". Explicitly restating these roles is discouraged by both the W3C and the ARIA in HTML specification, which states: "Setting an ARIA role and/or aria-* attribute that matches the implicit ARIA semantics is unnecessary and is NOT RECOMMENDED."

Why this matters

• Code clarity: Redundant attributes make your HTML harder to read and can confuse other developers into thinking the attribute is necessary.
• Standards compliance: The W3C validator raises a warning, which can obscure more important issues in your validation reports.
• Best practices: Following the principle of using native HTML semantics without redundant ARIA keeps your code clean and aligns with the first rule of ARIA: "If you can use a native HTML element with the semantics and behavior you require already built in, do so, instead of re-purposing an element and adding an ARIA role."

How to fix it

Remove the role="main" attribute from any <main> element. The semantic meaning is already provided by the element itself.

If you're working with a <div> or another generic element that needs the main landmark role (for example, in a legacy codebase that cannot use <main>), then role="main" is appropriate and necessary on that element.

Examples

❌ Redundant role on <main>

<mainrole="main">

<h1>Welcome to my site</h1>

<p>This is the primary content of the page.</p>

</main>

The role="main" attribute is unnecessary here because <main> already implies it.

✅ Using <main> without a redundant role

<main>

<h1>Welcome to my site</h1>

<p>This is the primary content of the page.</p>

</main>

✅ Using role="main" on a non-semantic element (when necessary)

<divrole="main">

<h1>Welcome to my site</h1>

<p>This is the primary content of the page.</p>

</div>

This approach is valid when you cannot use the <main> element — for instance, due to framework constraints or legacy browser support requirements. In most modern projects, prefer the <main> element instead.

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:

<navrole="navigation">

<ul>

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

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

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

</ul>

</nav>

Correct: nav without the explicit role

Simply remove the redundant role attribute:

<nav>

<ul>

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

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

<li><ahref="/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:

<divrole="navigation">

<ul>

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

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

<li><ahref="/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:

<navaria-label="Main">

<ul>

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

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

</ul>

</nav>

<navaria-label="Footer">

<ul>

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

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

</ul>

</nav>

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

<sectionrole="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:

<sectionaria-labelledby="contact-heading">

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

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

</section>

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

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

<navrole="navigation">

<ahref="/">Home</a>

</nav>

<mainrole="main">

<p>Page content</p>

</main>

<asiderole="complementary">

<p>Related links</p>

</aside>

Correct: landmark elements without redundant roles

<nav>

<ahref="/">Home</a>

</nav>

<main>

<p>Page content</p>

</main>

<aside>

<p>Related links</p>

</aside>

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

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

<inputtype="email"id="email">

Valid Example

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

<inputtype="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:

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

<inputtype="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:

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

<inputtype="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:

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

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

<datalistid="cities">

<optionvalue="Amsterdam">

<optionvalue="Berlin">

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

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

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

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

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

<inputtype="text"id="username">

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

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

<inputtype="text"id="color"list="colors">

<datalistid="colors">

<optionvalue="Red">

<optionvalue="Green">

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

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

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

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

<inputid="search-field">