Should you use HTML5 header and footer?

Matt Wilcox asked “I still don’t bother with <header> <footer> etc. I assume all widely used browsers support them now. But, do they do anything more than div?”.

It’s a good question. The answer I gave is “yes”. These two elements (and <nav> and <main>) give value to users of some assistive technologies on some browsers.

In the HTML5 spec, HTML elements are mapped to ARIA information. Some of those may be over-ridden by authors, but if they aren’t, they have default implicit ARIA semantics. A <header> element that is not a descendant of an article or section element maps to ARIA role=banner, for example. You don’t need to add any ARIA information; it’s included, free, in the HTML element.

These aren’t necessarily implemented everywhere; Steve Faulkner’s excellent keeps tabs of implementation. As an example, <footer> causes Chrome to expose the element with a footer role in IA2, and Firefox to exposes as ARIA landmark role=”contentinfo” (when not a child of article or section elements).

These are useful to people, as we can see in WebAIM’s 5th annual screenreader users’s survey (which encouragingly tells us “For the first time in 5 years of surveys, respondents are more positive about web accessibility progress than in the previous survey”).

When asked “How often do you navigate by landmarks/regions in your screen reader?” (such as “contentinfo”, “banner”, “main”, “navigation”), 26% said “whenever they are present”.

20% thought 1-3 landmarks/regions per page is optimal; 29% thought 4-6 is the right number.

So my advice is: yes, use them – especially the main <header>, <footer>, <nav> and (once per page) <main>. On browsers/ ATs that don’t support them they do no harm. But don’t use billions.


Added 13 May to clear up confusion:

19 Responses to “ Should you use HTML5 header and footer? ”

Comment by Matt Wilcox

Thanks for the post Bruce. Here’s a quick follow-up question, as I’ve yet to do my homework (sorry sir!) – would I be right in thinking that if the browsers are mapping these HTML elements to ARIA actions, we should not be adding ARIA attributes to them? Even if the behaviour between browsers is slightly different?

Comment by Bruce

If you go belt-and-braces as I do (main role=”main”, nav role=”navigation”) you get ARIA benefit in browsers that haven’t implemented default mapping (eg IE). Can’t hurt – and, realistically, the couple of dozen extra bytes per page don’t matter, regardless of what perf people say.

Comment by vernonk

Great read, accessibility doesn’t get enough attention at times. Often, it’s purely out of a lack of understanding. Seeing that 26% of users say they use those as navigable landmarks is awesome.

Comment by Jon

Thanks Bruce!
I think the “role” attribute has been a godsend for both accessibility (as it should be) but also for hooking specific css to the element types that are repeated without having to overload classes and abuse id’s! It’s nice to know that taking those extra bytes back for the attribute isn’t such a sin! ;-)

Comment by Bruce

Jared, ehaubold

yes; use as many footers, headers as you want. I’d go easy on nav – too many, and the user can’t see the primary nav. Only one main per page.

Comment by Richard

Just to chip in, thanks for the clarification Bruce. We’ve been teaching the students the ‘belt and braces’ approach for a few years now. No bad thing I think until the mapping between the HTML5 semantics and ARIA Roles is fully implemented. I got to see the benefit when I did this little talk with my pal DR. D showing the Rotor in iOS.

As a teacher I was also relieved to see the introduction of ‘main’ for the core content. Trying to get beginners to decide between article and section (especially when EVERY example is a blog page) is tricky. Starting with main (and role main) and then letting the student work out if article or section are relevant to their content later is much more straight forward.

Comment by Laurence Cope

Shouldn’t use HTML elements until the browsers that do not support it are no longer used. I know theres JS to make it work, but many corporate and public bodies disable Javascript and still have old browsers. Do you really want your websites not working for them??

Comment by Bruce

“Shouldn’t use HTML elements until the browsers that do not support it are no longer used.”

why? what’s your definition of “no longer used”? There are still some IE5.5 installs out there.

Comment by Laurence

“what’s your definition of “no longer used” – Hmm, its hard to define, but generally I would say anyone who could be a customer of mine, and my customers customers (we are web developers). So while corporations and public bodies/universities/governments etc are still using older IE’s and have JS disabled, I would not use HTML5 because it means I, or my customers, will lose sales due to their websites having no styling.

Comment by Laurence

There are not enough advantages for me to use HTML5 compared to the disadvantages of the sites not working. The sites we build are not Gmail or Facebook by the way, they are business brochure sites, so in those case HTML4 can do everything we need, so its not worth the risk using HTMl5 tags older browsers dont understand.

Comment by Bruce

That’s fair enough. When I first started doing talks about HTML5 at conferences etc, I always said “if your site is basically text, images and links, you probably won’t need to convert from HTML4, which will be supported forever (as it’s a subset of HTML5)”. But if you don’t use the HTML5 elements, you need to add the ARIA roles to the HTML4 elements you use.

You might benefit from browser-based validation of a contact form, eg with input type=url or type=email.