Mainlining Mains

Consider this an update to my 2015 post Use Only One <main> on a Page, which details the overall concept and a bit of the history getting WHATWG on board with the infamous issue 100. That post was a follow-up to my 2012 post New Main Element Approved, then Blocked.

Two Ways

There are two ways you can programmatically identify the main content of a page:

The <main> Element

The WHATWG HTML specification makes it clear there can only be one non-hidden <main> element:

A document must not have more than one main element that does not have the hidden attribute specified.

A hierarchically correct main element is one whose ancestor elements are limited to html, body, div, form without an accessible name, and autonomous custom elements.

Essentially it lives at the root or as a descendant of an unnamed form or div with no other intervening roles.

The main Role

If, for some reason outside the scope of this post, you cannot use the correct HTML element, then you can use ARIA to add role="main" to the appropriate generic element to provide the same features.

The author SHOULD mark no more than one element on a page with the main role.

Note

Because document and application elements can be nested in the DOM, they can have multiple main elements as DOM descendants, assuming each of those is associated with different document nodes, either by a DOM nesting (e.g., document within document) or by use of the aria-owns attribute.

You may have noticed some differences in this definition. Which I’ll try to explain.

Differences

The ARIA specification says there should be only one main landmark. This deviates from the HTML specification saying there must be only one main landmark. But these address different contexts.

The note that follows the ARIA statement acknowledges that using a document or application role creates a new document. That’s how you can have more than one main role on a page (each page can have multiple documents).

This aligns with the HTML spec that there can be only one non-hidden <main> element in a document (and multiple documents can be in a page thanks to iframes).

This wording can be confusing, particularly if you are mixing HTML and ARIA in your head. It can also make it easy for someone to get around the HTML prohibition by scattering role="main" all over the page. After all, add a role="document" or role="application" to a node and you can legit stuff a role="main" as a descendant node on the same HTML page.

We are now at the part of this post that you can consider it to be an extension of my 2016 missive Be Wary of Nesting Roles.

Example

Perhaps the easiest way to demonstrate how this can be confusing is to build a quick, non-exhaustive test case and report the outcomes. After all, while you may have found a technically correct approach allowed by the specs, how users experience it can prove to be, at best, useless. If the embed doesn’t work, hit the debug version.

See the Pen Testing Multiple Mains by Adrian Roselli (@aardrian) on CodePen.

Key:

<main>

dotted light blue border

role="main"

dashed dark yellow border

role="document"

single line gray border

role="application"

double line gray border

Results

I’m starting with the automagical stuff before I look at the things that actually impact humans.

Validator

The HTML Nu Checker does not abide the multiple <main> elements. It doesn’t care that they are nested in role="document" or role="application". It especially doesn’t like a <main> within a <main>, regardless of intervening roles.

Of course, an HTML validator would be silent on ARIA roles. As would your HTML linter. So the ARIA versions could sneak by undetected unless you create some custom rules.

Accessibility Checkers

Given ARIA is an accessibility feature, you can try using your favorite automated code checker. When I say “main landmark” in the following paragraphs, I use that to encompass both <main> and role="main".

You can’t trust your automated checkers to catch these constructs. The following three paragraphs provide evidence and details. I don’t care if you read them, but if you leave a comment without having read them, then I shall frown at you.

The axe DevTools does not flag anything on that page as an error. If you turn on the “best practices” rules, then it flags everything but the first main landmark under its rule landmark-no-duplicate-main. Separately, the main landmarks that are in role="document" and role="application" get caught under its rule landmark-main-is-top-level. We’ve already established some of those constructs are legit per ARIA, however.

ARC Toolkit flags all of them as errors under its rule “Multiple main landmarks” and leaves it for you to figure out the rest. It identifies all nine (9) on the page, so it also makes no distinction between those that are in role="document" and role="application". Interestingly, it fails them under WCAG SC 2.4.1 Bypass Blocks. This is probably because Technique ARIA11:Using ARIA landmarks to identify regions of a page is considered a Sufficient Technique to pass 2.4.1, despite the fact that browsers don’t natively support that as discussed since 2021 in WCAG issue 1712: Are ‘Headings’ enough to pass 2.4.1: Bypass Blocks.

Equal Access Accessibility Checker failed to flag the second and third main landmarks at the document root. It did flag the remainder of main landmarks, but did so because they didn’t have unique names. It failed them under SC 1.3.1 using rule aria_landmark_name_unique and aria_main_label_unique. It also flagged aria_main_label_visible as a recommendation. It made no distinction between those that are in role="document" and role="application", though it did insist I name the applications.

Screen Readers

This is the easy part. You can test this yourself. But I did it already. Assume latest releases of each as of the time of this writing.

NVDA / Firefox

Navigating by landmarks allows me to get to the main landmarks that are not in role="application".

JAWS / Chrome

Navigating by landmarks allows me to get to all of the main landmarks.

Narrator / Edge

Navigating by landmarks allows me to get to all of the main landmarks, but Win+N (jump to main) only exposes the first main landmark.

VoiceOver / macOS / Safari

Navigating by landmarks allows me to get to all of the main landmarks.

TalkBack / Chrome

Navigating by landmarks allows me to get to all of the main landmarks.

VoiceOver / iPadOS / Safari

Navigating by landmarks allows me to get to all of the main landmarks.

Takeaway

Use only one (non-hidden) main landmark per HTML page.

This means it’s ok to have an <iframe> with its own main landmark because that is a standalone page. It’s not ok to use application or document roles to add more to the current page.