Remove redundant WAI-ARIA role attributes from <main>, <nav>, <aside>, <header>, and <footer> elements

I do agree 100% with

-    <main role="main">
+    <main>

Would like confirmation that all <aside> are role="complementary".

and <header> makes role="banner" redundant.

Thanks @BarisW

The latest patch no longer applies.
Reroll against 8.4.x

Answering the questions from comment #3:

Would like confirmation that all <aside> are role="complementary". and <header> makes role="banner" redundant.

Regarding the <aside> element, https://www.w3.org/TR/html5/sections.html#the-aside-element says:

Allowed ARIA role attribute values:
complementary role (default - do not set), note, search or presentation.

Regarding the <header> element, https://www.w3.org/TR/html5/sections.html#the-header-element says:

Allowed ARIA role attribute values:
banner role (default - do not set) or presentation.

fwiw, the information about the default role of the <main> element can be found here:
https://www.w3.org/TR/html5/grouping-content.html#the-main-element

@dimaro, thanks for the reroll. The patch applies and looks good for the most part. However, there is still a

const header = document.querySelector('header[role="banner"]');

in core/themes/seven/js/mobile.install.es6.js after applying the patch. I guess that we need to remove the banner role for this query selector as well?

Also, I'm changing the category to markup since I guess your reassignment of the issue to the ajax subsytem was by accident.

Fixed #9.
Check once for it's correctness.

Interdiff for last patch.

Thanks for working on this @pk188. By looking at the interdiff, I see you're changing the query selector from header[role="banner"] to header[]. Unfortunately, the latter is not a valid query selector, so you'll get a SyntaxError: 'header[]' is not a valid selector. You need to remove the square brackets as well to make it work (see the change in core/themes/seven/js/mobile.install.js for an example). Would you like to submit an updated version of your patch?

Thanks for reviewing.
Here is new patch.

Thanks for re-rolling and checking this patch everyone.

We need to postpone this change, until we stop supporting Internet Explorer.

The issue is that IE does not pass the implicit ARIA landmark role to the host OS accessibility APIs. It only passes the landmark role if it is made explicit via the role attribute.

The good news is that it is fixed in Edge now. Firefox, Chrome, Safari, and Opera have handled implicit roles correctly for a long time already. I don't expect it to ever be fixed in IE 11.

The redundant value for the role attribute produces validation warnings, but not errors. It's clear from the HTML5 rec that is permitted valid markup. The "Do not set" advice is on the assumption that browsers will set the implicit ARIA role (emphasis mine):

In the majority of cases setting an ARIA role and/or aria-* attribute that matches the default implicit ARIA semantics is unnecessary and not recommended as these properties are already set by the browser. .

The point here is that Internet Explorer does not behave correctly. I've confirmed that users IE11 + NVDA screen reader will be adversely affected; the main/aside/header elements are not included in landmark navigation without the explicit role attribute.

I marked #2862904: Remove unneeded role="main" attribute from <main> element as a duplicate of this issue. The patch here is more comprehensive.

@andrewmacpherson @FeyP I only tried to bump this since the WAI-ARIA topic is a general "problem". The parent issue #2467827: [META] W3C validation for Drupal Core says the following:

Many clients, particularly administrations are paying attentions to following standards and may impose their site to be W3C compliant.

Regarding the above mentioned:

We need to postpone this change, until we stop supporting Internet Explorer.

Perfect! Thanks :)

By my count we have at least 4 separate issues about this. I've been closing the others in favour of this one, which remains postponed until we drop IE support.

Updating the title to bring the nav & footer elements into scope here, because it's the same story for all of them. The implicit ARIA landmark roles have been mapped by all the browsers we support, except for IE.

+1

Ready for status + version (issue metadata) update, now that IE11 support is officially being dropped with Drupal 10, ya?

(🎉🎉🎉🎉🎉🎉🎉)

Looks like it's time to revive this issue.
We should update Olivero and Claro templates as well.

related #3117230: Remove redundant role="article" from <article> html tags

Removed redundant WAI-ARIA role attributes. Attached patch for 10.1.x. please review

Here is new patch.

Fixed failed tests. Attached interdiff for same. please review

Changes for header and main look good

But title mentions footer and nav so I think the issue summary should be updated for what is being addressed

Also according to https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/co... if there are multiple asides aria-label may be neded Do not implement yet as could be wrong assumption

Copying over @andrewmcpherson's comment from #3117230-28: Remove redundant role="article" from <article> html tags

#26: Thanks for adding that WebKit issue. Indeed, IE11 isn't the only browser that has accessibility bugs. We certainly shouldn't remove these while we still support IE11, but even when we drop support for IE11, these role attributes will still need to be reassessed for the other browsers. Apple seem to have a lot of trouble keeping Safari and VoiceOver stable, particularly on iOS. Each new release of iOS has a different batch of accessibility bugs. I haven't kept a close watch on them all, but AppleVis has a good collection of them. That particular contentinfo bug is interesting, because it isn't clear whether the fault lies with WebKit, VoiceOver, or Apple's AX API.

The webkit issue is https://developer.mozilla.org/en-US/docs/Web/HTML/Element/footer#accessi...

I have opened a merge request with changes based on patch #38. The patch is old, so the code should be checked to see if there are any more attributes that need to be removed. Before doing this work, there should be agreement that this change should be made at this time or this issue should be postponed based on some criteria.

heck yeah. There were lots that were missed, I pushed a fix for that.

Will ping @mgifford in Slack to see if he can signoff on the implementation.

Great stuff. Looks great to me. Hopefully we can get it in before it's 10th anniversary – 24 Jan 2026 at 15:26 EST

I made a small test update and they are now passing.

I have drafted a change record.

I wanted to review this as someone who finished writing a custom theme from scratch in the last year and had to remove some redundant roles.

The MR looks great and in the end it's just a bunch of small removals. I have no notes.

I did a search of Core for @role and role=["']. The remaining instances are not duplications of default roles.

What I'd personally like to see in the CR is a quick reference list of impacted templates. Here are some suggestions:

• List only templates from the core modules, stable9, and the starterkit - any one that was likely to be extended and overridden.
• Only list the impacted template names, since they're repetitive.
• Just link to the MR change list.

I have added the template list to the change record.

Yeah, that's good. Thank you. Now I know exactly what I need to go check in my themes. LGTM.

I updated the title, and added reasoning to the CR. Thanks!

Wondering if we should be changing stable9 here? If someone is using stable9 and has CSS rules that include the role, this is a BC break for them. Even if this is considered a bug fix, I'm not sure we should be breaking stable9 in this way - it's only a redundancy and keeping it doesn't cause any actual issues that I can see.

Good point. We should check with a framework manager.

Asked in Slack at https://drupal.slack.com/archives/C0D5GJZ8B/p1770901027037749

Wondering if we should be changing stable9 here? If someone is using stable9 and has CSS rules that include the role, this is a BC break for them. Even if this is considered a bug fix, I'm not sure we should be breaking stable9 in this way - it's only a redundancy and keeping it doesn't cause any actual issues that I can see.

Good call. These changes should not be made in Stable 9 as they could result in user-impacting regressions. While the changes here could be categorized as a bug fix as it might appease some html validators, it does not improve any user facing or assistive tech functionality and does not seem to justify disrupting the Stable theme promise.

Needs work per #55 and #58.

Easy enough change! Stable9 changes are now reverted.

I verified that the changes to stable9 were reverted.

Let's do it. Not eligible for backport to 11.3.x just in case this breaks someone's CSS or JS somewhere.

Committed and pushed 3fd5767ae80 to main and 75a55279cc0 to 11.x. Thanks!

Also published the change record.