HTML Guides for role

A span element has an implicit ARIA role of generic, and the aria-labelledby attribute is not allowed on elements with that role.

The span element is a generic inline container with no semantic meaning. Its default ARIA role is generic, and the ARIA specification explicitly prohibits naming generic elements with aria-labelledby (or aria-label). This restriction exists because accessible names on generic containers create confusing experiences for assistive technology users — screen readers wouldn't know what kind of thing is being labeled.

To fix this, you have two main options:

1. Add a meaningful role to the span that supports aria-labelledby, such as role="group", role="region", or any other role that accepts a label.
2. Use a more semantic element that already has an appropriate role, like a section, nav, or div with an explicit role.

If the span doesn't truly need a label, simply remove the aria-labelledby attribute.

HTML Examples

❌ Invalid: aria-labelledby on a plain span

<spanid="label">Settings</span>

<spanaria-labelledby="label">

<inputtype="checkbox"id="opt1">

<labelfor="opt1">Enable notifications</label>

</span>

✅ Fix: Add an appropriate role

<spanid="label">Settings</span>

<spanrole="group"aria-labelledby="label">

<inputtype="checkbox"id="opt1">

<labelfor="opt1">Enable notifications</label>

</span>

✅ Fix: Use a semantic element instead

<spanid="label">Settings</span>

<fieldsetaria-labelledby="label">

<inputtype="checkbox"id="opt1">

<labelfor="opt1">Enable notifications</label>

</fieldset>

Every HTML semantic element carries an implicit ARIA role that assistive technologies already recognize. The <article> element has a built-in role of article, which signals that the content represents a self-contained composition — such as a blog post, news story, forum comment, or any section that could be independently distributed or reused. When you explicitly add role="article" to an <article> element, you're telling the browser and screen readers something they already know.

While this redundancy won't break anything functionally, it creates unnecessary noise in your markup and goes against the W3C's guidance on using ARIA. The first rule of ARIA use states: "If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of repurposing an element and adding an ARIA role, state or property to make it accessible, then do so." Redundant roles make code harder to maintain and can signal to other developers that something non-standard is happening when it isn't.

The role="article" attribute is useful when applied to non-semantic elements like <div> or <span> that need to convey article semantics — for instance, in legacy codebases where changing the element isn't feasible. But on the <article> element itself, it should simply be removed.

Examples

❌ Redundant role on <article>

This triggers the validator warning because role="article" duplicates the element's implicit role:

<articlerole="article">

<h2>Breaking News</h2>

<p>A rare bird was spotted in the city park this morning.</p>

</article>

✅ Fixed: no explicit role needed

Simply remove the role attribute. The <article> element already communicates the article role to assistive technologies:

<article>

<h2>Breaking News</h2>

<p>A rare bird was spotted in the city park this morning.</p>

</article>

✅ Appropriate use of role="article" on a non-semantic element

If you cannot use the <article> element for some reason, applying the role to a generic element like <div> is valid and useful:

<divrole="article">

<h2>Breaking News</h2>

<p>A rare bird was spotted in the city park this morning.</p>

</div>

✅ Multiple articles within a feed

A common pattern is nesting several <article> elements inside a feed. No explicit roles are needed on the articles themselves:

<sectionrole="feed"aria-label="Latest posts">

<article>

<h2>First Post</h2>

<p>Content of the first post.</p>

</article>

<article>

<h2>Second Post</h2>

<p>Content of the second post.</p>

</article>

</section>

This same principle applies to other semantic elements with implicit roles — for example, <nav> already has role="navigation", <main> has role="main", and <header> has role="banner". Avoid adding redundant roles to any of these elements to keep your HTML clean and standards-compliant.

The HTML specification defines built-in semantic roles for many elements, and the <header> element is one of them. When a <header> is a direct child of <body> (or at least not nested inside a sectioning element), browsers and assistive technologies already interpret it as a banner landmark — the region of the page that typically contains the site logo, navigation, and other introductory content. Explicitly adding role="banner" duplicates what the browser already knows, which adds unnecessary noise to your markup.

This principle is part of the WAI-ARIA specification's guidance on using ARIA roles: 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." Redundant roles don't typically break anything, but they clutter the code, can confuse developers maintaining the project, and signal a misunderstanding of HTML semantics.

It's worth noting an important nuance: the <header> element only maps to the banner role when it is not a descendant of <article>, <aside>, <main>, <nav>, or <section>. When nested inside one of these sectioning elements, <header> has no corresponding landmark role — it simply serves as the header for that particular section. In that context, adding role="banner" would not be redundant; it would actually change the semantics, which is almost certainly not what you want.

To fix the warning, remove the role="banner" attribute from your <header> element. The native semantics are sufficient.

Examples

Incorrect: redundant role="banner" on <header>

This triggers the validator warning because <header> already implies the banner role at the top level:

<headerrole="banner">

<imgsrc="logo.svg"alt="My Company">

<nav>

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

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

</nav>

</header>

Correct: let <header> use its implicit role

Simply remove the role="banner" attribute:

<header>

<imgsrc="logo.svg"alt="My Company">

<nav>

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

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

</nav>

</header>

Correct: using role="banner" on a non-<header> element

If for some reason you cannot use a <header> element (e.g., working within a legacy CMS), applying role="banner" to a <div> is the appropriate way to convey the same landmark semantics:

<divrole="banner">

<imgsrc="logo.svg"alt="My Company">

<nav>

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

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

</nav>

</div>

A <header> inside a sectioning element has no banner role

When <header> is nested inside an <article> or other sectioning element, it does not carry the banner role. This is expected and correct — the <header> here simply introduces the article content:

<article>

<header>

<h2>Article Title</h2>

<p>Published on <timedatetime="2024-01-15">January 15, 2024</time></p>

</header>

<p>Article content goes here.</p>

</article>

Every HTML element carries an implicit ARIA role that communicates its purpose to assistive technologies like screen readers. The <button> element natively has the button role built in, so explicitly adding role="button" is redundant. The W3C validator flags this as unnecessary because it adds no information — assistive technologies already understand that a <button> is a button.

The role attribute exists primarily to assign interactive semantics to elements that don't have them natively. For example, you might add role="button" to a <div> or <span> that has been styled and scripted to behave like a button (though using a native <button> is always preferable). When you apply it to an element that already carries that role by default, it creates noise in your code and can signal to other developers that something unusual is going on — when in fact nothing is.

This principle applies broadly across HTML. Other examples of redundant roles include role="link" on an <a> element with an href, role="navigation" on a <nav> element, and role="heading" on an <h1> through <h6> element. The WAI-ARIA specification refers to these as "default implicit ARIA semantics," and the general rule is: don't set an ARIA role that matches the element's native semantics.

Removing redundant roles keeps your markup clean, easier to maintain, and avoids potential confusion during code reviews or audits. It also 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, instead of re-purposing an element and adding an ARIA role, state, or property to make it accessible, then do so."

How to fix it

Remove the role="button" attribute from any <button> element. No replacement is needed — the native semantics are already correct.

If you have a non-button element (like a <div>) that uses role="button", consider replacing it with a real <button> element instead. This gives you built-in keyboard support, focus management, and form submission behavior for free.

Examples

❌ Redundant role on a button

<buttonrole="button">Buy now</button>

<buttontype="submit"role="button">Submit</button>

Both of these trigger the validator warning because role="button" duplicates what the <button> element already communicates.

✅ Button without redundant role

<button>Buy now</button>

<buttontype="submit">Submit</button>

Simply removing the role attribute resolves the issue. The element's native semantics handle everything.

❌ Using role="button" on a non-semantic element

<divrole="button"tabindex="0"onclick="handleClick()">Buy now</div>

While this is technically valid and won't trigger the same warning, it requires manual handling of keyboard events, focus styles, and accessibility states.

✅ Using a native button instead

<buttononclick="handleClick()">Buy now</button>

A native <button> provides keyboard interaction (Enter and Space key activation), focusability, and correct role announcement — all without extra attributes or JavaScript.

Other common redundant roles to avoid

<!-- ❌ Redundant -->

<ahref="/about"role="link">About</a>

<navrole="navigation">...</nav>

<h1role="heading">Title</h1>

<inputtype="checkbox"role="checkbox">

<!-- ✅ Clean -->

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

<nav>...</nav>

<h1>Title</h1>

<inputtype="checkbox">

The WAI-ARIA specification defines implicit roles (also called "native semantics") for many HTML elements. An <input> element with type="submit" inherently communicates to assistive technologies that it is a button control. Adding role="button" explicitly restates what the browser and screen readers already know, making it redundant.

The role="button" attribute is designed for situations where you need to make a non-interactive element — such as a <div> or <span> — behave like a button for assistive technologies. When applied to elements that already carry this semantic meaning natively, it adds unnecessary noise to your markup without providing any accessibility benefit.

Why this is a problem

• Redundancy: The explicit role duplicates the element's built-in semantics, cluttering the HTML with no added value.
• Maintenance risk: Redundant ARIA attributes can mislead other developers into thinking the role is necessary, or that the element's native semantics differ from what they actually are.
• Standards compliance: The W3C validator flags this as an issue because the ARIA in HTML specification explicitly states that authors should not set ARIA roles or attributes that match an element's implicit native semantics. This principle is sometimes called the "first rule of ARIA" — don't use ARIA when a native HTML element already provides the semantics you need.
• Potential conflicts: While current browsers handle redundant roles gracefully, explicitly overriding native semantics can theoretically interfere with future browser or assistive technology behavior.

How to fix it

Remove the role="button" attribute from any <input type="submit"> element. The same principle applies to other input types with implicit roles, such as <input type="reset"> (which also has an implicit button role) and <button> elements.

Examples

❌ Incorrect: redundant role="button" on a submit input

<formaction="/checkout"method="post">

<inputtype="submit"role="button"value="Buy Now">

</form>

✅ Correct: no explicit role needed

<formaction="/checkout"method="post">

<inputtype="submit"value="Buy Now">

</form>

❌ Incorrect: redundant role on a <button> element

The same issue applies to <button> elements, which also have an implicit button role:

<buttontype="submit"role="button">Submit Order</button>

✅ Correct: let native semantics do the work

<buttontype="submit">Submit Order</button>

✅ Correct: using role="button" where it is appropriate

The role="button" attribute is meaningful when applied to an element that does not natively convey button semantics. Note that you must also handle keyboard interaction and focus management manually in this case:

<divrole="button"tabindex="0">Add to Cart</div>

Even in this scenario, using a native <button> element is strongly preferred over adding ARIA roles to non-interactive elements, since the native element provides built-in keyboard support and focus behavior for free.

The <summary> element serves as the clickable disclosure toggle for a <details> element. Because its built-in behavior is inherently interactive — clicking it expands or collapses the parent <details> content — the HTML specification assigns it an implicit button role. This means assistive technologies like screen readers already announce <summary> as a button without any additional markup.

When you explicitly add role="button" to a <summary> element, the W3C validator flags it as unnecessary. While this doesn't cause functional problems, redundant ARIA roles are discouraged by the first rule of ARIA use: if an HTML element already has the semantics you need, don't re-add them with ARIA attributes. Redundant roles add noise to your code, can confuse other developers into thinking custom behavior is being applied, and in edge cases may interact unexpectedly with certain assistive technologies.

This principle applies broadly — many HTML elements have implicit roles (e.g., <nav> has navigation, <main> has main, <button> has button). Adding the role they already carry is always unnecessary.

How to fix it

Remove the role="button" attribute from the <summary> element. No replacement is needed since the semantics are already built in.

Examples

❌ Incorrect: redundant role="button" on <summary>

<details>

<summaryrole="button">Show more information</summary>

<p>Here is the additional information that was hidden.</p>

</details>

The validator will report: The "button" role is unnecessary for element "summary".

✅ Correct: <summary> without an explicit role

<details>

<summary>Show more information</summary>

<p>Here is the additional information that was hidden.</p>

</details>

The <summary> element's implicit button role ensures assistive technologies already treat it as an interactive control. No additional attributes are required.

✅ Correct: a more complete <details> example

<details>

<summary>I have keys but no doors. I have space but no room. You can enter but can't leave. What am I?</summary>

<p>A keyboard.</p>

</details>

Clicking the <summary> toggles the parent <details> element between its open and closed states. Screen readers announce it as a button automatically, and keyboard users can activate it with Enter or Space — all without any explicit ARIA role.

Many HTML5 semantic elements come with built-in (implicit) ARIA roles defined in the WAI-ARIA specification. The <aside> element is one of these — it natively maps to the complementary role, which tells assistive technologies that the content is related to the main content but can stand on its own. When you explicitly add role="complementary" to an <aside>, you're stating something the browser already knows, which triggers this W3C validator warning.

While this redundancy won't break anything for end users, it creates unnecessary noise in your code and can signal a misunderstanding of how semantic HTML works. Keeping markup free of redundant ARIA attributes follows 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." Clean, semantic HTML is easier to maintain and less prone to errors if ARIA roles are accidentally changed or conflict with the native semantics in the future.

This same principle applies to several other HTML elements, such as <nav> (implicit role navigation), <main> (implicit role main), <header> (implicit role banner when not nested), and <footer> (implicit role contentinfo when not nested).

Examples

❌ Redundant role on <aside>

The role="complementary" attribute is unnecessary because <aside> already implies it:

<asiderole="complementary">

<h2>Related Articles</h2>

<ul>

<li><ahref="/article-1">Understanding ARIA roles</a></li>

<li><ahref="/article-2">Semantic HTML best practices</a></li>

</ul>

</aside>

✅ Using <aside> without the redundant role

Simply remove the role attribute:

<aside>

<h2>Related Articles</h2>

<ul>

<li><ahref="/article-1">Understanding ARIA roles</a></li>

<li><ahref="/article-2">Semantic HTML best practices</a></li>

</ul>

</aside>

✅ When an explicit role is appropriate

If you need to give the <aside> element a different role than its default, an explicit role attribute is valid and useful. For example, you might use <aside> for structural reasons but assign it a different ARIA role:

<asiderole="note">

<p>This feature is only available in version 3.0 and later.</p>

</aside>

✅ Labeling multiple <aside> elements

If your page has multiple <aside> elements, you don't need to add role="complementary" to distinguish them. Instead, use aria-label or aria-labelledby to give each a unique accessible name:

<asidearia-label="Related articles">

<h2>Related Articles</h2>

<ul>

<li><ahref="/article-1">Understanding ARIA roles</a></li>

</ul>

</aside>

<asidearia-labelledby="ad-heading">

<h2id="ad-heading">Sponsored Content</h2>

<p>Check out our latest product.</p>

</aside>

The HTML specification maps certain elements to implicit ARIA roles. The <footer> element, when used as a direct child of <body> (i.e., not nested inside an <article>, <aside>, <main>, <nav>, or <section> element), automatically carries the contentinfo landmark role. This means screen readers and other assistive technologies already announce it as a content information landmark without any extra markup.

Adding role="contentinfo" to a <footer> element is redundant because:

• It duplicates built-in semantics. Browsers already expose the correct role to the accessibility tree. Repeating it adds no benefit and clutters your markup.
• It can cause confusion for developers. Seeing an explicit role might suggest the element doesn't have one by default, leading to misunderstandings about how HTML semantics work.
• It violates the first rule of ARIA use. The W3C's "Using ARIA" guide states: "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."

It's worth noting that when a <footer> is nested inside a sectioning element like <article> or <section>, it does not carry the contentinfo role — it maps to a generic role instead. In that context, adding role="contentinfo" would actually change the element's semantics rather than being redundant, though doing so is generally not appropriate since each page should have only one contentinfo landmark.

If you are working with a <div> that serves as a footer (perhaps in legacy code), the best approach is to replace it with a semantic <footer> element rather than applying role="contentinfo" to the <div>.

Examples

❌ Redundant role on <footer>

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

<footerrole="contentinfo">

<p>&copy; 2024 Example Corp. All rights reserved.</p>

</footer>

✅ Fixed: <footer> without redundant role

Simply remove the role="contentinfo" attribute:

<footer>

<p>&copy; 2024 Example Corp. All rights reserved.</p>

</footer>

✅ Using a <div> as a footer (legacy pattern)

If you cannot use a <footer> element for some reason, applying role="contentinfo" to a <div> is valid and meaningful since the <div> has no implicit role:

<divrole="contentinfo">

<p>&copy; 2024 Example Corp. All rights reserved.</p>

</div>

However, replacing the <div> with a <footer> is always the preferred approach.

✅ Nested footer inside a section

When <footer> appears inside a sectioning element, it does not carry the contentinfo role. No explicit role is needed here either — it simply represents footer content for that section:

<article>

<h2>Blog Post Title</h2>

<p>Article content here.</p>

<footer>

<p>Published on January 1, 2024</p>

</footer>

</article>

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 WAI-ARIA specification defines strict rules about which elements can be children of interactive roles. An element with role="button" is treated as an interactive control, and the <a> element (when it has an href) is also an interactive control. Nesting one interactive element inside another creates what's known as an interactive content nesting violation. Screen readers and other assistive technologies cannot reliably determine user intent when they encounter this pattern — should they announce a button, a link, or both? The result is unpredictable behavior that can make your content inaccessible.

This issue commonly appears when developers wrap links inside styled containers that have been given role="button", or when using component libraries that apply button semantics to wrapper elements containing anchor tags.

Beyond accessibility, browsers themselves handle nested interactive elements inconsistently. Some may ignore the outer interactive role, while others may prevent the inner link from functioning correctly. This makes the pattern unreliable even for users who don't rely on assistive technologies.

How to fix it

There are several approaches depending on your intent:

1. If the element should navigate to a URL, use an <a> element and style it to look like a button. Remove the role="button" from the parent or eliminate the parent wrapper entirely.
2. If the element should perform an action (not navigation), use a <button> element or an element with role="button", and handle the action with JavaScript. Remove the nested <a> tag.
3. If you need both a button container and a link, flatten the structure so they are siblings rather than nested.

When using role="button" on a non-button element, remember that you must also handle keyboard interaction (Enter and Space key presses) and include tabindex="0" to make it focusable.

Examples

❌ Incorrect: link nested inside a button role

<divrole="button">

<ahref="/dashboard">Go to Dashboard</a>

</div>

This triggers the validation error because the <a> is a descendant of an element with role="button".

✅ Fix 1: Use a styled link instead

If the intent is navigation, remove the button role and let the <a> element do the job. Style it to look like a button with CSS.

<ahref="/dashboard"class="btn">Go to Dashboard</a>

This is the simplest and most semantically correct fix when the purpose is to navigate the user to another page.

✅ Fix 2: Use a real button for actions

If the intent is to trigger an action (not navigate), replace the entire structure with a <button> element.

<buttontype="button"class="btn"onclick="navigateToDashboard()">

Go to Dashboard

</button>

✅ Fix 3: Use a div with role="button" without nested interactive elements

If you need a custom button using role="button", make sure it contains no interactive descendants.

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

Go to Dashboard

</div>

When using this approach, you must also add keyboard event handlers for Enter and Space to match native button behavior.

❌ Incorrect: link inside a button element

The same principle applies to native <button> elements, not just elements with role="button":

<button>

<ahref="/settings">Settings</a>

</button>

✅ Fixed: choose one interactive element

<ahref="/settings"class="btn">Settings</a>

❌ Incorrect: deeply nested link

The error applies to any level of nesting, not just direct children:

<divrole="button">

<spanclass="icon-wrapper">

<ahref="/help">Help</a>

</span>

</div>

✅ Fixed: flatten the structure

<ahref="/help"class="btn">

<spanclass="icon-wrapper">Help</span>

</a>

As a rule of thumb, every interactive element in your page should have a single, clear role. If something looks like a button but navigates to a URL, make it an <a> styled as a button. If it performs an in-page action, make it a <button>. Keeping these roles distinct ensures your HTML is valid, accessible, and behaves consistently across browsers and assistive technologies.

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 (implicit) ARIA roles that browsers and assistive technologies already recognize. The <form> element natively maps to the form ARIA role, meaning screen readers and other tools already understand it as a form landmark without any extra attributes. When you explicitly add role="form" to a <form> element, you're telling the browser something it already knows.

This redundancy is problematic for several reasons:

• Code clarity: Unnecessary attributes make your HTML harder to read and maintain. Other developers may wonder if the explicit role is there to override something or if it serves a special purpose.
• Misleading intent: Explicit ARIA roles are typically reserved for cases where you need to override or supplement the default semantics of an element. Using them unnecessarily can signal to future maintainers that something unusual is happening when it isn't.
• ARIA best practices: The first rule of ARIA is "do not use ARIA if you can use a native HTML element or attribute with the semantics and behavior you require." Adding redundant ARIA roles goes against this principle.

It's worth noting that the <form> element's implicit form role only exposes it as a landmark when the form has an accessible name (e.g., via aria-label or aria-labelledby). If you need your form to appear as a landmark region, provide an accessible name rather than adding a redundant role.

To fix this issue, simply remove role="form" from any <form> element. If you want the form to function as a named landmark for assistive technology users, add an accessible name instead.

Examples

❌ Incorrect: redundant role="form"

<formrole="form"action="/subscribe"method="post">

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

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

<buttontype="submit">Subscribe</button>

</form>

This triggers the validator warning because role="form" duplicates the element's implicit role.

✅ Correct: no explicit role

<formaction="/subscribe"method="post">

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

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

<buttontype="submit">Subscribe</button>

</form>

The <form> element already communicates its role natively. No ARIA attribute is needed.

✅ Correct: form with an accessible name for landmark navigation

<formaction="/subscribe"method="post"aria-label="Newsletter subscription">

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

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

<buttontype="submit">Subscribe</button>

</form>

If you want the form to be discoverable as a named landmark by screen reader users, provide an aria-label or aria-labelledby attribute — not a redundant role.

Other elements with implicit roles

The same principle applies to many other HTML elements. Avoid adding redundant roles like these:

<!-- ❌ Redundant roles -->

<navrole="navigation">...</nav>

<mainrole="main">...</main>

<headerrole="banner">...</header>

<footerrole="contentinfo">...</footer>

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

<!-- ✅ Let native semantics do the work -->

<nav>...</nav>

<main>...</main>

<header>...</header>

<footer>...</footer>

<button>Click me</button>

Trust the native semantics of HTML elements. Only use explicit ARIA roles when you genuinely need to change or supplement an element's default behavior.

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 <a> element with an href attribute is one of HTML's most fundamental interactive elements. Browsers and assistive technologies inherently recognize it as a link — it's focusable via the Tab key, activatable with Enter, and announced as "link" by screen readers. This built-in behavior is part of the element's implicit ARIA role, which is link.

When you explicitly add role="link" to an <a href="..."> element, you're telling assistive technologies something they already know. The W3C validator flags this as unnecessary because it violates the principle of not redundantly setting ARIA roles that match an element's native semantics. This principle is codified in 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."

While a redundant role="link" won't typically break anything, it creates noise in your markup. It can also signal to other developers that the role is necessary, leading to confusion or cargo-cult patterns. Clean, semantic HTML that relies on native roles is easier to maintain and less error-prone.

The role="link" attribute is legitimately useful when a non-interactive element like a <span> or <div> needs to behave as a link. In that case, you must also manually implement keyboard interaction (focus via tabindex, activation via Enter key handling) and provide an accessible name. But when you already have a proper <a> element with href, all of that comes for free — no ARIA needed.

Examples

❌ Incorrect: redundant role="link" on an anchor

<ahref="/about"role="link">About Us</a>

The role="link" is redundant here because the <a> element with href already has an implicit role of link.

✅ Correct: anchor without redundant role

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

Simply remove the role="link" attribute. The browser and assistive technologies already treat this as a link.

✅ Correct: using role="link" on a non-semantic element (when necessary)

<spanrole="link"tabindex="0"onclick="location.href='/about'"onkeydown="if(event.key==='Enter')location.href='/about'">

About Us

</span>

This is the legitimate use case for role="link" — when you cannot use a native <a> element and need to make a non-interactive element behave like a link. Note the additional work required: tabindex="0" for keyboard focusability, a click handler, and a keydown handler for Enter key activation. Using a proper <a> element avoids all of this extra effort.

❌ Incorrect: multiple anchors with redundant roles

<nav>

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

<ahref="/products"role="link">Products</a>

<ahref="/contact"role="link">Contact</a>

</nav>

✅ Correct: clean navigation without redundant roles

<nav>

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

<ahref="/products">Products</a>

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

</nav>

The role="list" attribute is redundant on an <ol> element because it already has an implicit ARIA role of list.

HTML elements come with built-in (implicit) ARIA roles that convey their purpose to assistive technologies. The <ol> and <ul> elements both have an implicit role of list, so explicitly adding role="list" is unnecessary and creates noise in your markup.

That said, there's a well-known reason some developers add this role intentionally. Safari removes list semantics when list-style: none is applied via CSS. Adding role="list" is a common workaround to restore those semantics for VoiceOver users. If this is your situation, the W3C warning is technically correct but you may choose to keep the role for accessibility reasons.

If you don't need the Safari workaround, simply remove the role attribute.

Before

<olrole="list">

<li>First item</li>

<li>Second item</li>

<li>Third item</li>

</ol>

After

<ol>

<li>First item</li>

<li>Second item</li>

<li>Third item</li>

</ol>

The HTML specification assigns implicit ARIA roles to many elements, meaning browsers and assistive technologies already understand their purpose without any extra attributes. The ul element has a built-in role of list, the nav element has a role of navigation, the button element has a role of button, and so on. When you explicitly add a role that matches the element's implicit role, it creates redundancy that the validator warns about.

This principle is formalized as the first rule of ARIA use: do not use ARIA if a native HTML element already provides the semantics you need. Adding redundant ARIA roles clutters your markup, can confuse developers maintaining the code, and in rare edge cases may cause assistive technologies to announce information twice or behave unexpectedly.

This same warning applies to other elements with implicit roles, such as adding role="navigation" to a nav element, role="banner" to a header element, or role="contentinfo" to a footer element.

A note about Safari and list-style: none

There is one well-known exception worth mentioning. Safari intentionally removes list semantics from ul and ol elements when list-style: none is applied via CSS. This means VoiceOver on macOS and iOS will not announce the element as a list. In this specific case, some developers deliberately add role="list" to restore the list semantics. While the W3C validator will still flag it as redundant (since it evaluates HTML in isolation, without considering CSS), this is a legitimate accessibility pattern where the redundant role serves a real purpose. If you're in this situation, you may choose to keep role="list" and accept the validator warning.

Examples

Incorrect: redundant role="list" on ul

<ulrole="list">

<li>Apples</li>

<li>Bananas</li>

<li>Cherries</li>

</ul>

Correct: relying on implicit semantics

<ul>

<li>Apples</li>

<li>Bananas</li>

<li>Cherries</li>

</ul>

Incorrect: other common redundant roles

<navrole="navigation">

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

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

</nav>

<mainrole="main">

<h1>Welcome</h1>

</main>

<footerrole="contentinfo">

<p>© 2024 Example Inc.</p>

</footer>

Correct: native elements without redundant roles

<nav>

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

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

</nav>

<main>

<h1>Welcome</h1>

</main>

<footer>

<p>© 2024 Example Inc.</p>

</footer>

Acceptable exception: restoring semantics removed by CSS

If your stylesheet strips list markers and you need to preserve list semantics for screen readers, the redundant role is a pragmatic choice:

<!-- list-style: none is applied via CSS, which removes semantics in Safari -->

<ulrole="list"class="unstyled-list">

<li>Step one</li>

<li>Step two</li>

<li>Step three</li>

</ul>

In this case, you can suppress or ignore the validator warning, understanding that it serves an accessibility need that the validator cannot detect from the HTML alone.

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>

A <tr> element already has an implicit ARIA role of row, so adding role="row" is redundant when the parent <table> uses its default semantics or has a role of table, grid, or treegrid.

HTML tables come with built-in accessibility semantics. The <table> element implicitly has role="table", and <tr> implicitly has role="row". Browsers and assistive technologies already understand this structure, so explicitly adding these roles is unnecessary and flagged by the W3C validator.

The only time you'd need to add a role to a <tr> is when the table's native semantics have been overridden — for example, if the <table> has been repurposed with a non-table role like role="presentation" or role="none". In that case, you'd need explicit ARIA roles to restore row semantics.

Incorrect Example

<table>

<trrole="row">

<th>Name</th>

<th>Email</th>

</tr>

<trrole="row">

<td>Alice</td>

<td>alice@example.com</td>

</tr>

</table>

Fixed Example

Simply remove the redundant role="row" from the <tr> elements:

<table>

<tr>

<th>Name</th>

<th>Email</th>

</tr>

<tr>

<td>Alice</td>

<td>alice@example.com</td>

</tr>

</table>

The same fix applies if your <table> explicitly has role="table", role="grid", or role="treegrid" — the <tr> elements still don't need an explicit role="row" because the browser infers it automatically.

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

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>