The `main` element
April 2020 note: Hi! Just a quick note to say that this post is pretty old, and might contain outdated advice or links. We're keeping it online, but recommend that you check newer posts to see if there's a better approach.
Here at Filament Group, we love us some markup. We’re the sort of nerds that can quote the HTML5 specification from memory, and we’re always champing at the bit for opportunities to work richer semantic meaning into our content. We’re also no strangers to the web standards process, and staying current gives us a chance to spot new and exciting proposals as they’re coming down the pike.
Lately we’ve been keeping a close eye on the main element extension spec championed by Steve Faulkner, which aims to provide an element that delineates the primary content on a page, independent of HTML5’s document outline.
HTML5 semantics and ARIA landmarks
ARIA roles allow us to assign additional semantic meaning to existing elements—a means of enhancing legacy markup, in a way that would be completely ignored by browsers that might not understand those role attributes. They’re supported by JAWS (10+), NVDA (2010.1+), Apple’s VoiceOver for keyboard or gesture-based navigation, and other assistive technologies.
These ARIA attributes were intended to be something of a stop-gap while we waited for HTML5’s new semantic elements to fully mature and gain wider support. For example: <div role=“navigation”> was intended to eventually be replaced by <nav>, which would have all the same meaning to browsers and assistive technologies. This way we wouldn’t end up with two disparate but redundant means of assigning meaning to our content.
| ARIA Role | HTML5 Element |
|---|---|
| banner | header |
| complementary | aside |
| contentinfo | footer |
| navigation | nav |
| article | article |
| main | N/A |
The ARIA role main is intended to serve as an alternative to a “skip to main content” link, something especially helpful to users accessing a site by way of assistive tech or navigating by keyboard alone. It provides the browser (or the users' assistive software) with a predictable landmark for the page's primary content so that “skip to main content” functionality can be built into the browsing software, rather than being dependent on the developer adding a link at the top of the document.
Up to this point, HTML5 has lacked a functional equivalent to ARIA's main, however—at least until the proposed main element came along.
Seamless accessibility, no downsides
The main proposal replaces a common markup pattern—<div id="main">, <div class="wrap">, and the like—with an element that has a much greater potential benefit to users, and no costs. Newer operating systems, browsers, and assistive technologies have begun treating HTML5's elements like their ARIA counterparts, meaning we'll start seeing all the benefits of ARIA anytime we're writing semantically-meaningful markup.
I'm a big advocate of finding ways to encourage developers to build accessible websites “by accident,” without requiring a pass at “bolting on” accessibility as a separate step. As much as I'm all about ARIA's the benefits for users, adding the extra roles is still an extra layer on the markup, and a set of concerns separate from our structure. You don't see them getting quite as much use as they should, given that additional effort—not to mention the effort involved in memorizing the whole roster of roles and the interplay between them. Adding the new 'main' element would alleviate the need for that extra markup and still identify key content on many, many web pages.
On the other hand…
There are a few opponents of this extension specification, with the reasoning being that the role of the main content can be inferred using other existing HTML5 elements— i.e., by ignoring any elements that couldn't be the main content (header, aside, etc.), we can assume that whatever remains must be the main content. It's being called the “Scooby-Doo algorithm”: by eliminating everybody who couldn't possibly be the one running around in a swamp monster mask, you're left with only one possibility: it was old man Jenkins all along. And he would've gotten away with it, too.
This line of reasoning is true in principle, but can be relied upon only as long as all the other markup on the page structured correctly—which is far more involved (and perhaps more error-prone) than simply replacing a common pattern with a single element.
Can we use this today?
At this time, the main element spec is still an unofficial extension specification. As of now, it hasn't been implemented or merged into either of the HTML specifications, so it's a bit too early to use it. Once accepted as an FPWD (“First Public Working Draft,” standards-speak for “likely to be implemented in browsers”) we'd likely want to start using it in conjunction with a redundant role="main" attribute until it saw wider adoption, for the sake of browsers that currently recognize the role but not the new element.
If the main element sounds interesting to you, get involved in the ongoing discussions on both the WHATWG mailing list and the HTML WG mailing list—or at least keep a close eye on this proposal as it evolves.