The `main` Element

Posted by Mat on 11/09/2012

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.

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.

When you have eliminated the impossible, whatever remains, however improbable, must be the truth main content.

Arthur Conan DoyleSherlock Holmes; The Sign of the Four

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.

Comments

I wouldn’t say that ARIA roles are a stop gap. For example, the roles also work in other markup languages, including SVG which will likely never have semantics. ARIA’s primary use is in HTML, but it’s not limited to HTML.

Caveat: certain aspects of the keyboard interaction (as defined in the non-normative authoring practices guide) are intended as a stop-gap.

Hi Mat, thanks for the write-up, its heartening to see that real world developers are voicing support for the ‘main’ element and recognize its utility. I am also heartily encouraged by a recent email to the WHATWG list from Maciej Stachowiak (a lead developer, responsible for the Safari web browser and WebKit Framework).

I whole-heartedly agree with adding an HTML5 “main” structural element. You cannot rely on the “Scooby-Doo” method for finding main content. And for consistency alone, it’d be beneficial to have. It’s ridiculous that the element was not added originally; it’s just common sense.

You can start using it today. I’ve begun revising my site’s pages with ‘main’ and including ‘main’ into Modernizr and/or Google’s shiv. All one needs to do is an an ID/Class name to style. It’s the same method used when new HTML5 elements first appeared.