Use Only One <main> on a Page

That’s it. That’s the meat of the post. The title covers it all. You don’t need to read any further. You are, of course, welcome to continue since I spent all this time writing it.


For those who aren’t familiar with <main>, the element is intended to be a container for the primary content of your page. It’s already implemented in browsers, so you can use it today. The W3C HTML 5.1 draft specification describes it thusly:

The main content area of a document includes content that is unique to that document and excludes content that is repeated across a set of documents such as site navigation links, copyright information, site logos and banners and search forms (unless the document or applications main function is that of a search form).

Richard Clark explains the element in more human-readable detail over at HTML5 Doctor.

Multiple Content Areas

If you are in a scenario where you have a blog index, or an article index, you don’t need multiple <main> elements. You can wrap the overall index in the <main> and each abstract can be wrapped in <article>:

			<h2>Locally-Sourced Cupcake Flavor Profiles</h2>
			<h2>Artisanal Cocktail Mixers</h2>
			<h2>Beard Waxing Tips</h2>

Why It Matters

You may wonder is why it’s important to keep the <main> to one instance per document.

For Users

As an element, <main> exists to provide a direct mapping for the ARIA landmark role of the same name. The other landmark roles already have corresponding elements with matching native semantics, but the main role did not.

If you’ve read my blog long enough, you may know that ARIA is a spec designed to add important accessibility information to a page for users, both with and without assistive technology (AT). In this case it allows a user to jump to the meat of the page with a single keystroke, much like a “skip navigation” link does on many sites.

Having more than one <main> can be confusing to users of AT. While the element is relatively new, anecdotal examples show a potential trend of confusing users. Screen readers don’t announce the number of <main> elements, so if there is more than one a user may not know if he/she is in the first, the second, or even that there are more.

This means landmark navigation can prove problematic if a user presses a key to go to the <main>, assumes he/she is on the only one, and then pops back into the navigation area to move to another page. In this scenario, entire swaths of also-primary content would be missed by the user.

The Spec

While the ARIA spec says you should not use more than one role="main" on your page, the HTML specification takes this a step further and says you must not use more than one <main>:

Authors must not include more than one main element in a document.

Authors must not include the main element as a descendant of an article, aside, footer, header or nav element.

The HTML validator will also throw an error if there is more than one <main> on a page.

Potential for Confusion

The WHATWG spec differs from the W3C spec in that not only does it allow multiple <main> elements on a page, it encourages it.

For the reasons outlined above you should disregard this. There is an open bug report to have the WHATWG definition align with the W3C definition.


In the interests of full disclosure, I am an invited expert to the W3C HTML Working Group and I voted in favor of <main> as originally proposed (with only one instance per page). I also wrote about my frustrations with the different approaches by WHATWG, W3C and browsers on implementing it back in 2012.

Update: April 20, 2016

It looks like Microsoft Edge is also expecting a single <main> per page, based on the wording, though I doubt the browser will break if multiples are erroneously used.

For example, using the <main> element, developers can provide a hint to assistive technology indicating where the primary content is. This makes it easier for their users to get to this content quickly from anywhere on the page. This experience will light up in Microsoft Edge and Narrator, and in other browsers, with assistive technologies supporting those roles.

Update: April 9, 2017

HTML 5.2 will likely tweak the use of <main> a bit to allow more than one on a page:

What is important to note is that this change only allows one <main> to be visible at a time. The others must be hidden.

Update: January 5, 2018

WHATWG issue 100, Consider aligning WHATWG main element definition with W3C definition, which has sat untouched since October 2015, got some activity this morning.

First, the accessibility tag was added.

Second, there appears to finally be some acknowledgment that, two years on, accessibility practitioners are not changing their informed opinion to align with WHATWG assertions:

FWIW, I created #3326 to take some steps in a direction that I hope is more agreeable. Hopefully we can iterate from there; it’s not meant to represent the endpoint here, just an improvement.

I think there is something to be said for being able to use <main> in <article>/<section> similar to how <header> and <footer> work there, but if AT is not going to play ball I’m not sure that’s really worth pursuing. This might be worth investigating a bit though, as it would satisfy end users and the needs of styling without having to resort to a <div> with a class or some such.

I also agree that the dominant advice (unless we can get AT to change per above) should be to have a single <main> per document. Otherwise the user experience is just not great, as pointed out by many in this thread. The argument that ease of styling also matters is valid, but ultimately end users trump web developers so they’ll have to use another <div>.

It does seem like there may be a case for multiple <main>s when combined with hidden, as W3C’s fork of HTML already acknowledges (though I’m less clear on if the exact enforcement there is correct).

Note the assertions that assistive technology refuses to play ball with WHATWG’s definition, that styling needs are still a concern, that the dominant, not correct, advice is to avoid multiple <main>s, and the closing swipe at the W3C.

Even the related pull request (Align <main> a bit with contemporary AT) frames an interesting reason for the update: …there’s no reason to believe AT will change…

Update: January 15, 2018

Per this morning’s comment, a new pull request has been made (Restrict the main element to be used once per document #3354).

Update: January 23, 2018

It took six years (and well over two years of an open bug), but WHATWG issue 100 is closed with this commit:

Update: January 31, 2018

A star on the Walk of Fame with the name Main Jackson. I helped Léonie Watson craft a brief survey about what screen reader users expect when visiting a page. It was to be the start of gathering information for WHATWG Issue 100, but then it closed and all was right in the world.

Léonie posted the results of the survey and I made this totally sweet graphic to go along with it. It is from a source image by R-E-AL, which I modified and used under CC BY-SA 3.0. So you can use it too if you want, though it’s not that sweet.

Update: February 28, 2019

Some good news in the WebAIM Million (an accessibility analysis of the top 1,000,000 home pages):

Pages with a <main> element present averaged 1.1 of them per page, whereas pages with a <nav> element present averaged 2.1 of them per page, and pages with a <header> averaged 3.2 of them per page.

The presence of a <main> element was an indicator of better accessibility—those pages averaged 3 fewer errors than pages lacking a main region.

They found <main> is mostly used correctly (once per page), and it is also a good signal for users about how accessible a page may. This is a win for users.



[…] Используйте только один <main> на странице […]

Дайджест интересных материалов из мира веб-разработки и IT за последнюю неделю №177 (14 — 20 сентября 2015) -; . Permalink

the biggest mistake of web was making browsers silently work around broken websites, this encourages (by not discouraging) laziness carelessness

if page declares that it’s build according to spec X then not adhering to that spec should immediately stop parsing and display huge red error message along the lines of “I’m sorry, creator of this website is incompetent, I refuse to display this mess”

zakius; . Permalink
In response to zakius. Reply

I don’t agree with you, for me the AT approach is not the best to have. For me, instead of having a pre-built accessibility policy in HTML, we should rather provide developers with a distinct semantics that they can integrate into their HTML code. Thus we would not curb the structural creativity of developers, and moreover we would allow the emergence of new ways of reading websites. I think we are stuck in an archaic pattern, from the time when the web was only used to transmit scientific documents. I find it absurd that using multiple [main?]s reduces the accessibility of a website. Similarly, there is no separate mark in the tag name for structure elements, texts and interactive elements. Struct elements should all behave like [??]. I think we need to review things on that side rather than continuing to accumulate limiting concepts.

Rudolphe; . Permalink
In response to Rudolphe. Reply

Edit note: There were HTML elements in the comment to which I am replying, but they were stripped by WordPress. I used square brackets to indicate where I saw the gaps. If embedding code, remember to escape the < & > with &lt; & &gt;. Or use square brackets.


I *assume* a page with [main] and a [div role=”main”] on the same page at the same time neither hidden, is as much of a fail as [main][main]. But I cannot find a W3 or similar authoritative resource confirming that.

Do you happen to know of such a page?

PS: Thanks for all the valuable knowledge here.

Alan Bristow; . Permalink
In response to Alan Bristow. Reply

I do not know of such a page, but since <div role="main"> maps the same as <main> in the browser’s accessibility tree and is then handed off to AT as such, then yeah, that also counts as a problem.

Leave a Comment or Response

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>