HTML5 Structural Elements—Non-Sectioning Elements

Posted: 02 Mar 2015 05:30 AM PST

When should you use an HTML5 header element? How about a footer element? Do you use one of each per page or do you add them to sections throughout your content as the spec recommends?

HTML5 APIs — Image courtesy of Mercury99 and the Wikimedia Commons

The last few weeks I’ve been taking a look at the new structural elements in HTML5. First I discussed the HTML 4 document outline and then the HTML5 outline. Last week I walked through the definitions of the four sectioning elements as well as the definitions of the ARIA roles they map to.

Today I want to look at three more new elements, main, header, and footer. All three are non-sectioning elements. When used, they don’t create a new section in the non-supported HTML5 document outline.

If you haven’t read the post on the four sectioning elements you may want to start there and come back to this one. I explain the arbitrary origins of all the new elements as well as why I’m looking at ARIA roles to understand how to use them.

The short answer is each element maps to an ARIA role and communicates the same semantics as the role in most browsers. For more details read the previous post about the sectioning elements.

Non-Sectioning Elements

Again, not every one of the new HTML5 structural elements is a sectioning element. Elements such as main, header, and footer don’t create new sections. Non-sectioning elements do not contribute to the document outline.

As with sectioning elements, each of the non-sectioning elements is meant for a specific purpose. Each maps to an ARIA role by default, or kind of does, depending on how the element is used.

Here are the three non-sectioning elements we’ll look at and the ARIA roles each maps to (or might map to).

footer (not descended from an article or section) maps to role=”contentinfo”
header (not descended from an article or section) maps to role=”banner”
main maps to role=”main”

Notice that for both the footer and header elements, the default mapping only exists when the element isn’t inside a section or article. The mappings occur when header and footer are used how you’ve likely always used them, one header at the top of the page and one footer at the bottom. The header and/or footer inside a particular section or article don’t map to anything by default.

The main Element

The main element is meant to replace <div class="main">. It’s an element you would use to wrap all your main content, which should be everything in your main document outline.

Sidebars, navigation, logos, copyright info, and similar are not part of your main document outline and shouldn’t be included inside of main.

The main element should wrap content unique to the specific document and not include content that is repeated across documents. For example your global navigation shouldn’t be inside your main element.

You should only use one main element per page and you can probably substitute main for div class=”main” where you usually use the latter.

The main element is mapped to the ARIA role=”main,” which is easy to remember and also defined the same as the main element. It’s meant for the main content of a document. It’s also used as an alternative to “skip to main content” links. Assistive devices can find the main content without the need for the skip links.

Like the nav element I think it’s one of the easiest to use in practice. Unfortunately it’s still not supported in IE11 or older as well as Opera Mini. I think support in Opera Mini is coming soon. In IE you’ll have to create the element in Javascript and style it as a block level element in your CSS.

The header Element

The header element is meant to contain introductory content for its nearest ancestor section or sectioning root. When the ancestor element is the body, then the header element applies to the whole page and essentially replaces div class=”header.”

However, the body is not the only section on the page. You can use header elements as introductions to sections throughout the page. The header element inside a section or article will typically include one or more headings inside it.

Headers (and footers) create confusion for me as both elements have different definitions than how every developer I’ve ever known uses class=”header.” To me there is one header and one footer on a web page, but the spec says you can have as many headers on the page as you want.

I think a better choice would have been two elements. A header element to represent the header of the entire page and maybe an “intro” element for introductory content in a section.

Apparently the people behind the ARIA roles agree. Header maps to role=”banner,” though only when the header isn’t part of an article or section. The header you might use to wrap headings inside a section doesn’t map to role=”banner” or anything by default if I’ve understood correctly.

The banner role is meant for a page/site header. It’s defined as a region that contains site-oriented content rather than page-specific content, or pretty much what we all think headers are.

This furthers my thought that HTML5 writers got this wrong and the header inside a section should be a different element and I’ll again suggest an <intro> element to cover the introduction to a section.

The footer Element

The footer element is meant to contain closing content for its nearest ancestor section or section root. When that ancestor is the body the footer element replaces div class=”footer.”

Like header they’re recommended to be used for the close of sections throughout your document, though they can be used anywhere inside a section. What I said about adding a header element to every section applies to the footer as well. Both should have been two different elements.

I find the overly inclusive definition of footer (and header) confusing. I don’t see why the spec decided to change their accepted definitions.

According to the spec your footer element will usually contain meta information like author and date information, though it also says both could be placed in the header or neither as well.

Bylines and other information that could be suitable for both a header or a footer can be placed in either (or neither)

Read that quote again and then think how you’d mark up a byline? It’s not exactly helpful to say a byline could be in a header or it could be in a footer or it doesn’t have to be in either. Where exactly is the guidance?

The spec offers what is in my opinion a bizarre example using a footer at both the top and bottom of a document.

1  2  3  4  5  6  7  8  9  10  11  12

<body>   <footer><a href="../">Back to index...</a></footer>     <div>    <h1>Lorem ipsum</h1>    <p>The ipsum of all lorems</p>   </div>     <p>text removed for clarity</p>     <footer><a href="../">Back to index...</a></footer>  </body>

Why either of the links belongs in a footer at all is lost on me and footer strikes me as a poor choice for something that can both start and close a document.

The spec also suggests a footer might wrap entire sections like appendices, indexes, colophons, license agreements, and similar. I think most of these would end up as another document on another page, though I can also see how they’d find their way into a footer as well.

The footer element maps to role=“contentinfo,” though like the header element, the role only applies to footers that are outside of articles or sections. It’s footer in the way we think of footers with one per page.

The contentinfo role is defined as a large perceivable region that contains information about the parent documentation. Copyright information and privacy statements are given as examples.

The definition sounds a lot like meta information, which now has me questioning both the footer element and why only the main page footer would map to contentinfo. If anything I would think the definition applies more to how footer is recommended inside articles and sections as per the HTML5 spec.

I’d prefer a meta element that maps to contentinfo (or even a contentinfo element) and a separate element and role for the information that only applies to the entire page and not a specific section inside it.

Closing Thoughts

When I started this series I was having a hard time seeing the benefit of the new elements. I didn’t see the harm, but I didn’t see any reason I should start replacing my div class=”header” with <header> or replace other divs with sections.

Four posts laters and I have a reason. When I started this series, I wasn’t aware that the new elements map to ARIA roles (thanks Šime) and in so doing they’re communicating something to assistive devices. If using the new elements is a way into developing more accessible sites then I want to learn more about them and use them more often.

At the moment you can’t trust the semantics of the mapped role are communicated everywhere as IE and Opera Mini don’t yet map the elements to default roles. For now you want to include the ARIA role as an attribute on the element. Still it’s a way into something we should all be doing regularly, which is developing more accessible sites.

I find the definitions of the elements as provided by the HTML5 spec lacking, which leads to confusion. I also have questions about why some of the definitions redefine the classes they’re meant to replace.

However, the ARIA definitions and use cases for the roles each of the new elements maps to, provides more specifics, which helped me understand a little more about when to use the new elements.

Next week I want to put all this into practice. A few years back when I first looked at the HTML5 structural elements, I created this demo. I found it was much harder to actually decide when to use one of the new elements or at times, which one to use than it was to understand the definition of the elements.

I thought I would rebuild the same demo, or something very similar. I want to see if I make different decisions about which elements to use now that I hopefully have a better understanding of them. Next week I’ll share the demo along with my thoughts about why I decided to use an element or why I decided not to use it.

Download a free sample from my book Design Fundamentals.

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