Accessibility and the <main> element

Accessibility and the <main> element

By Léonie Watson on | 5 comments
  • Knowledge needed: Basic HTML and CSS, plus intermediate JavaScript (for legacy compatibility)
  • Requires: Text editor/IDE
  • Project time: Couple of hours

The First Public Working Draft of the
element was published yesterday. Léonie Watson tells us more about the proposal

HTML5 has a set of elements that make page structure more accessible to assistive technologies (ATs). The <header>, <footer>, <nav>, <article>, <aside> and <section> elements make it possible for ATs such as screen readers to identify the purpose of chunks of content on the page. But a growing school of thought says that there is one element missing from this set of semantically important tags.

In September 2012, Steve Faulkner proposed adding the <main> element to the HTML5 specification. The new element would represent the main content area of a web page. Conforming pages would include one <main> element, and it would contain content unique to that page. In other words the <main> element wouldn’t contain content that is typically repeated across pages (such as primary navigation, logos and banners, or copyright information).

The <main> element would formalise the common practice of using id="main" or id="content" on the containing element of the main content area. It would also map the semantics and function of the role="main" ARIA landmark.

  1. <body>
  2. <!-- Other content -->
  3. <main>
  4. <h1>Tequila</h1>
  5. <p>Tequila makes you happy...</p>
  6.  
  7. <h2>Types</h2>
  8. <p>There are two types of tequila...</p>
  9. </main>
  10.  
  11. <!-- Other content -->
  12. </body>

The reasons for proposing this new element are compelling. HTML traditionally provides elements for marking up specific semantic structures. There is an established pattern of mapping those elements to roles, states and properties in browser accessibility APIs. It’s the availability of information via the accessibility APIs that enables ATs to identify the element and inform the user about its purpose.

The practice of defining a main content area by applying id="main" or id="content" is commonplace on websites, and existing developer practices have been cited as reasons to introduce elements such as <header>, <footer> and so on.

The <main> element would have multiple uses. It could be used to navigate to (and recognise) the main content area of the page. For example, screen readers could provide a shortcut that moves focus to the start of the main content area, informing the user with a short announcement. This behaviour is possible with role="main", but building the capability into HTML makes life easier for developers. The <main> element could also provide a more consistent hook for ‘skip to content’ links, and a reliable mechanism for styling the main content area of the page.

Another school of thought says that the main content area of a page can be determined by a process of elimination. It’s the first piece of content that isn’t inside the <header>, <nav>, <aside>, or <footer>. While this algorithm is OK, it isn’t as robust as a specifically defined element would be.

5 comments

Comment: 1

I love the idea. I generally end up using a div with the ID of "main" in all my sites...generally as a container.

Comment: 2

Nice idea, I adopted the class="main" technique years ago, after finding it useful with Magento/Wordpress theming. In theory, if the element does become a HTML5/w3c standard, it could also be used as a reliable search ranking alorithm for distinguishing unique page content from indented templated areas such as headers, footers and sidebars.

Comment: 3

I use it, but... Why over complicating the thing we already do and it works?
Are we are going to start putting tags for every class we ever wrote.

Comment: 4

I like the idea to be honest. Will ease coding a bit. I dont think this is complicating things. Rather it is simplify them.

Comment: 5

Cliff
Léonie, you mention that "(a)nother school of thought says that the main content area of a page can be determined by a process of elimination." Wow, what a complicated approach! My browser, AT, or both must first go through a list of all the elements that might be used on that page but *aren't* marked one of these ways:
- class="content"
- class="main"
- id="content"
- id="main"
- role="main"
- role="content"
- class or id or role="whatever-i-choose-to-call-it-that-isn't-some-other-standard-class-or-id-or-role"
- oh, and let's not forget not marked at all
and then cross those elements off the list and assume that whatever is left over is the main content of the page.

This reminds me of the approach Microsoft Word used to use—in Windows, "used to" means in any versions earlier than Word 2010—to guess the structure of a document that had no content styled as headings. It would latch onto items that seemed too short or too bold or too capitalized to be regular content and present them as headings in its Document Map feature. And I never encountered a document in which it guessed all headings correctly. I also never encountered a document where it didn't incorrectly include in its Document Map content that wasn't a heading at all.

All of which is to say that authors of Web content should clearly state their intended structure for that content. We shouldn't leave it to some algorithm to guess at roles the author left unmarked.

To my way of thinking, assigning standard markup to an essential role isn't cluttering up code. It's how we keep code clean.

So I'll finish by stating clearly the message I've implied: I wholeheartedly endorse Steve Faulkner's proposal that we add the element to HTML5. By doing so we will make the specification closer to being as robust as it should be.
July issue on sale now!

The Week in Web Design

Sign up to our 'Week in Web Design' newsletter!

Hosting Directory
.net digital edition
Treat yourself to our geeky merchandise!
site stat collection