HTML5 Structural Elements—Sectioning Elements

Posted: 23 Feb 2015 05:30 AM PST

Are you using any of the new HTML5 structural elements in your work? Have you replaced div class=”nav” with the nav element? Do you know when to use elements like article, section, and aside?

I’ve been asking similar questions the last few weeks. First I provided some context by looking at the document outline we’ve been working with for years and then I walked through how the HTML5 document outline was meant to work.

So far in the series, I’ve kept talk the new elements in check to focus on the document outline. I’ve used only the <section> element in examples. It’s time to talk about the other elements.

Today I want to talk about the new sectioning elements (section, article, nav, and aside). Next week I’ll talk about some non-sectioning elements (header, footer, and main). First, let’s talk a little about how these specific elements came to be.

The Origin of the New Structural Elements

According to Luke Stevens, author of The Truth about HTML5, the new elements were chosen somewhat arbitrarily. Ian Hickson and other contributors in the Web Hypertext Application Technology Working Group (WHATWG) noticed that many developers added classes to divs with similar names.

class=”header”
class=”footer”
class=”nav”
class=”sidebar”

I’m guessing you’ve written each of the above at least a time or two. I know I have. They’ve been a part of most every website I’ve built for the last 10 years.

The contributors thought why not turn these classes into HTML elements. It certainly makes sense and seems like a good idea. A couple of years later they did some research into how often these classes were used in order to justify the decision to create the new elements.

I’ve seen others suggest that you shouldn’t use any of these elements because of their arbitrary origins, but seriously who cares. Do you avoid using post it notes, because the inventor was trying to make a super strong glue and accidentally ended up with the opposite? Of course not.

I write class=”header” all the time. I don’t mind using an element named header instead. I think it made perfect sense to create these elements, no matter how the initial idea was formed. However…

While I think the new elements make sense, there are some problems with them.

The element definitions are sometimes different than how we’ve all used the classes and ids that inspired them.
The new document outline suggests some less than clear uses cases for how the elements might be used.
The new elements are confusing to use in practice.

I think the latter two issues arise from the first. Had the definitions stayed truer to how we used the classes, most of us would probably be using the new elements in practice all the time. It seems to me the new structural elements are a good idea poorly executed.

HTML5 Structural Elements and Assistive Technologies

Each of the new elements maps to an ARIA role. For example the nav element maps to ARIA role=”navigation” and it communicates the same thing as the role to assistive devices.

The topic of ARIA roles deserves it’s own post or series of posts, so I won’t go in-depth here. However I do want to look at the definitions of the ARIA roles that the new elements map to in order to see if they offer more about using the elements. I’ll save the deeper look at ARIA roles for another time.

Here are the four sectioning elements and the ARIA role each maps to by default. You can see some of the elements and roles have the same name and others don’t.

section maps to role=”region”
article maps to role=”article”
aside maps to role=”complementary”
nav maps to role=”navigation”

You can override the defaults, but if you don’t add a role to any of these elements, know they’ll communicate the semantics of their default roles.

You should also know the not every browsers maps the new element to an ARIA role. For example IE11 supports none of these mappings. You shouldn’t count on the element communicating the semantics of the role just yet. Recommended practice is to use both if you want to communicate to assistive devices.

1	<nav role="navigation"></nav>

We’re looking at ARIA roles here not so much for how to use them. Again I’ll save that talk for another time. What we want here is to understand how the roles are defined so we can better understand how and when to use the new elements.

Sectioning Elements

You use one of the four sectioning elements (section, article, aside, and nav) when you want to start a new section in the document outline. Each of the sectioning elements has a specific purpose beyond creating a new section, though.

The section Element

As we saw last week, the section element is meant to enclose a chunk of related content. It’s the most generic sectioning element and at first glance you might think of them as a more semantic div.

It sounds easy enough. Where you might have previously wrapped a div around some related content, you might now use a section element instead.

You wouldn’t just replace all your divs with sections as some divs are structural and some are presentational. More likely you would use the section element as we did in examples last week.

1  2  3  4  5  6  7  8  9  10  11

<section>    <h1>Heading 1</h1>    <p>Some text</p>    <p>Some text</p>  <section>    <section>    <h2>Heading 2</h2>    <p>Some text</p>    <p>Some text</p>  <section>

The section element maps to the ARIA role=”region” and a region is defined as:

A large perceivable section of a web page or document, that is important enough to be included in a page summary or table of contents

The role is defined more specifically than the element. A section can wrap any related content, but a region should only be for content that would also find it’s way into a table of contents or page summary. It suggests that sections shouldn’t be used as generically as they first appear.

There’s also a recommendation to add a heading to every region and reference the heading with an aria-labelledby, which connects the section with the text that refers to it. In other words there should be a header inside every section and at least one heading inside that header.

Until seeing the definition of the region role, I wondered why it was recommended to add a heading to each section, but now I see its goal is to help assistive devices understand and navigate content. If we limit sections to the importance described by the region role, placing a heading inside makes more sense.

The article Element

An article is similar to a section in that it should enclose a chunk of related content, however, the content inside an article should also be self-contained and independent.

You should be able to reuse an article and have it make sense if it were published elsewhere. Publishing a blog post in an RSS feed is one example.

However, the article element isn’t specifically for articles as written pieces of content in a magazine or on a website. An article in HTML5 is anything self-contained and independent. It’s an article as in an article of clothing.

Comments on a blog or posts in a forum thread are examples where you might use an article element. In the case of comments you might have one article wrapping both the written post and all the comments and then each individual comment would also be an article.

1  2  3  4  5  6  7

<article>    main text here with multiple sections, headings, etc.      <article>Comment</article>    <article>Comment</article>    <article>Comment</article>  </article>

I find this definition, or at least the examples, confusing. I wonder how independent something can be if it first exists nested inside something else. How many comments make sense when removed from the blog post? How many forum posts make sense when removed from the thread?

The independence of a comment has more to do with the content of the comment and not that it is a comment. I think the majority would lose their meaning and not be so independent.

The article element maps to the article role, which is easy to remember. The role is defined similarly to the element in that it’s meant to be something independent. According to the role definition, independence is meant in the sense that an article’s content can stand alone, however, the element in question could still have associations with it’s ancestors.

This helps explain why a blog comment or forum posts can be an article. It also allows you to add meta information such as the name of the author and a timestamp to a blog post without that meta information also applying to the comments on the post as the comments are independent articles.

I’m still not 100% on board with the idea of nesting articles, but the definition of the role at least helps me understand it more.

The aside Element

An aside is meant to wrap a chunk of related content that is tangentially related to the content in the main outline, but not actually part of it. For example a call out in an article, that’s nice to know, but not essential for understanding the article.

The spec offers examples like pull quotes and sidebars, but also suggests wrapping groups of nav elements, which I have a harder time seeing. I understand why a table of contents is considered tangential and related, but I question the need to wrap a nav element with another element as opposed to adding a role.

The aside element maps to the ARIA role=”complementary” and it’s defined as a supporting section of a document, meant to be complementary to the main content. Content with a role of complementary belongs at a similar level in the DOM hierarchy as the main document, but still remains meaningful when separated from the main document.

Examples might include widgets like show times, weather, sports scores, and stocks on a portal page. Yahoo or MSN home pages for example.

If the complementary content can be completely separated from the main content, it might not be complementary and it might be better to use a more general role.

This suggests that an advertising block, often given as an example of an aside, might be better structured as something else. I suppose given today’s online advertising that any ad appearing on a page is probably related to the content of the page, but since those ads can easily be separated from the content something else probably makes more sense.

Given ad blocks are both self-contained and independent, an article might be the better choice, though it feels wrong to mark up a block of ads as an article. Then again with today’s native advertising, the two aren’t as different as they should be.

The nav Element

The nav element is meant to wrap groups of links that form navigation linking to different parts of the page or other pages on the site. However, just because you have a group of links it doesn’t mean it belongs inside a nav element.

Global navigation is a good fit. A section menu or table of contents are also a good fit. Footer and utility links are probably good fits as well, though the spec specifically mentions footer links as not belonging inside a nav element and being fine inside the footer element only.

The nav element maps to role=”navigation” and the definition of the role is pretty much the same as the definition of the element, a collection of links for navigating either the document or related documents.

The nav element is probably the easiest element to understand and use. It’s definition (both element and role) is what you’d expect it to be.

Closing Thoughts

That takes us through the four new sectioning elements. The nav element seems straight forward, but I have some questions and reservations about the definitions and suggested use cases for the other three.

I don’t know if the ARIA definitions played any part in the definitions of the new elements, but I find the ARIA definitions more specific and helpful. They seem to provide details lacking in the element definitions and use cases.

I’m still not 100% sold on everything about the HTML5 sectioning elements, but I do feel better prepared to make a decision about them in practice (mostly because of the role definitions). I’ll let you know in a couple of weeks when I present a demo where I try to use these elements.

Next week though, I’ll continue with the non-sectioning elements (main, header, and footer) and the ARIA roles associated with them to see if we can sort out how we’re supposed to use them.

Download a free sample from my book Design Fundamentals.

The post HTML5 Structural Elements—Sectioning Elements appeared first on Vanseo Design.