HTML5 Tips: structral elements, Doctype and ARIA

My site is well overdue a face lift flavoured with HTML5, a dash of ARIA and a healthy dose of WCAG 2.0. As you’d expect playing under the hood with all these things has made me ask a lot of questions so I thought I’d post a few tips along the way that I’ve found  have helped with the redesign process (more of which later).

So without further ado:

  1. The <header> element can be used multiple times on a page and can contain site <nav> and search.
    The <header> element is typically used on every page for the site header and contains an <hgroup> of site name as H1, site tagline as H2 and a logo. Bundled into the <header> you can also add your primary <nav> as well as search.  As the HTML5 specification says:

    The header element represents a group of introductory or navigational aids. A header element typically contains the section’s heading (an h1–h6 element or an hgroup element), but can also contain other content, such as a table of contents, a search form, or any relevant logos.

    Note that <hgroup> only really only makes sense when there is a group of heading information (site name, tagline, logo) and is not appropriate for single headings.

  2. The <nav> element and primary navigation
    In the HTML5 specification <nav> is defined as follows:

    The nav element represents a section of a page that links to other pages or to parts within the page: a section with navigation links. Not all groups of links on a page need to be in a nav element — only sections that consist of major navigation blocks are appropriate for the nav element.

    There has been a lot of discussion around what “major” navigation means (site, section, in page navigation, related links?) and what can legitimately be wrapped in the element and what can’t. General thinking is that “major” refers to global site navigation (About, Services, Products, Contact) as well as sub-navigation. Secondary navigation such as related links or grouped links of resources would not qualify for <nav>.

  3. <footer> can be used multiple times in a page.
    Typically you’d expect to use a footer at the end of a page housing your copyright and site design information and other bits and pieces. <footer> can also be used for footer information for any section you are in within a page. For example a common usage may be at the foot of a blog post – itself contained in an <article> – containing information about tags, categories, author, comments and date/time information. The HTML5 specification explains <footer> as follows:

    The footer element represents a footer for its nearest ancestor sectioning content. A footer typically contains information about its section such as who wrote it, links to related documents, copyright data, and the like.

    Note that the <footer> element can not contain any other sectioning content such as <nav>, <section>, <header> or <footer>.

  4. An <article> can appear within an <article>.
    Possibly one of the more obvious tips but worth a mention anyway. The <article> element is a container that can in turn contain many parts. For example on a blog posts contained within an <article> you may have another <article> housing comments. Designing a blog post with HTML5 from HTML5 Doctor has an excellent overview of this.
  5. Using <!DOCTYPE html>
    The new Doctype in HTML5 is much simpler – and memorable – than previous Doctypes.  <!Doctype html> will render content in standards mode by all modern browsers (IE, FireFox, Opera, Safari) while the good news is that all pre-HTML5 Doctypes are still valid.
  6. HTML5 can be used with WAI-ARIA.
    HTML5 and ARIA certainly cross over but should not be seen as contenders. At the moment there is not much know of screen reader support for HTML5 given that the screen reader vendors themselves have not been visible in the development of the spec. This may well be because they are ll racing to implement ARIA which is a priority at this point. This makes sense given that the ARIA is in Last Call – the final stage a specification goes through before it becomes a W3C specification – and as such will be a reality sooner than HTML5.
  7. (Update) HTML5, IE and Firefox 2
  8. IE and Firefox 2 lack native support for structural elements so you’ll need to add in some JavaScript to make it work. In IE you add the following to the head to get IE to behave:

    <!--[if lte IE 8]>
    <script src="html5.js" type="text/javascript"></script>

    Firefox 2 and Camino can be fixed using JavaScript or by serving Gecko XHTML. Getting HTML5 working on IE and Firefox 2 from HTML Doctor has a good article about how to do this.

    This obviously has a baring on whether you want to use HTML5 in your site or not yet. Given FireFox 2 has a tiny market share (most Firefox users upgrade fairly quickly) it’s really your call. The same can’t be said of IE however. I think this is why we are seeing more HTML5 sites in personal websites and blogs rather than corporate websites which have more at stake.

  9. Declaring HTML5 elements
    Most modern browsers (Firefox 3+, Safari 3+, Opera 9+, Chrome 1+) are yet to recognise section elements which means problems when laying them out in CSS. To get sections to display properly always use display:block in the CSS:header, nav, section, article, aside, footer {display:block;}


Being a hot topic right now there are reams of resources and tools being built that cover HTML5. This is my pick of a few that are well established, consistently useful and updated regularly:

  • HTML5 Doctor – Articles and tips covering  HTML5 and its semantics and how to use them. You’re also invited to submit questions for the HTML5 Doctors to answer.
  • HTML5 Gallery – a showcase of sites using HTML5.
  • HTML5 cheat sheet – A PDF of HTML tags and attributes together with brief explanations.
  • HTML5 differences to HTML4 – a W3C resource that does what it says on the tin.
  • Bruce Lawson – one of the brains behind HTML5 Doctor as well as the ultimate HTML5 cowboy forging ahead with implementing HTML5 and sharing his findings as he goes along. Follow @brucel on Twitter too.
  • Remy Sharp – Remy’s blog covering things HTML5.
  • HTML5  demos – set up by Remy Sharpe who focuses on JQuery and HTML5 this is a repository of demos looking at more of the application side of HTML5.
  • HTML5 Outliner – a nifty tool from @gsnedders that outlines structure in HTML5.
  • The Paciello Group blog – for the more ARIA minded developer with some HTML5 on the side.

And of course, last but not least the HTML5 Specification.

12 thoughts on “HTML5 Tips: structral elements, Doctype and ARIA

  1. Pingback: DOM vs namespace pour implémenter HTML5 sur IE6, IE7, Firefox2, Camino, etc.

  2. Pingback: html5doctor (html5doctor)

  3. Pingback: kazuhito (Kazuhito Kidachi)

  4. I’ll share two tips that I think you know, but for your readers.

    Re #2 (nav). The best rule of thumb I’ve encountered so far is this. If you today would use skip links in order to get to your navigation or pass it by to get to the content, then a nav element is perfect, otherwise not.

    Re #7 (new structural elements). You really can’t use these if FFox 2 is to be supported. (Yes you can, but it’s a major PITA, involving application/xhtml+xml hacking that in turn might break your DOM scripts) and MSIE 6 and 7 requires a snippet of JS. But if you are targeting customers behind script stripping corporate proxies, you had better not use these elements at all for a year or two.

  5. Hi Lars

    Re Nav: I’ve been wondering about the shelf life of skip links given HTML5, ARIA and better structure in web pages. I’m curious about your opinions on nav, could you go into them a bit more?

    Re Structural elements: Correct and an omission from the tips that I’ve now fixed. I’ve added this in as well as posted a link to an HTML5 Doctor article on Getting HTML5 working on IE and Firefox 2.

    I think overall that large corporate websites should probably stay clear of HTML5 for a while yet until browsers catch up but it’s something you may want to consider on personal websites and blogs.

  6. Hi

    I’d read that blog post of yours, and we are basically in agreement.

    My main point is that one should consider the effects of a particular semantic value. The end result should be usability and accessibility. And perhaps parsability (by search bots and server side scripts). Without such effects semantics will stay an academic exercise, of no further benefit than a span-element.

    When I read about the nav-element, it basically seems like something a user would like to be able to find quickly or quickly pass over to find more relevant information, i.e. it serves the same purpose as skip links do today, for vision impaired users. In addition to that, I think browsers could implement shortcuts (or gestures) that will enhance the user experience also for “normal” (or at least “power”) users. Ergo: The question “what kind of benefit will this bring to users of the site?” provides the best guidance about how to use a specific feature.

    Today that basically means add ARIA-landmarks, continue to use skip-links. Add nav-elements for personal sites.

    When ARIA-aware OS/browser/AT combinations has become the norm – and I’m not talking about fake implementations like in Safari 4 (that does not expose ARIA properly to the OS) – we can begin drop skip links. I suppose that is 2-3 years into the future, when today’s cutting edge browsers are being phased out. (I also predict faster uptake on new browsers in the future…) By then we have native support for HTML 5 structural elements in most “A-grade” browsers, I’d presume. That means phasing out a *few* ARIA features, or relegating them to those niches where HTML still is not enough.

    In principle I prefer native elements to attributes, on the “less cruft” principle. Otherwise we could just have one element and code like this ( don’t know what HTML you’ll allow. I’m trying pre and code here):

    <elem class="div">
    <elem class="p"><elem class="em">No
    way!</elem>, she said...</elem>..

    Parts of HTML 5 are usable today for corporate web sites though. How many sites do not add Flash through a JavaScript that actually inserts an embed-element? They are de facto using HTML 5, even though the doctype might say something else.

    I’ll provide this link to a blog post of mine, as it is relevant to that last point.

  7. This gave me a major headache: You can use the structural elements (header, footer, &c) in MSIE with the HTML5 shiv, but MSIE will go bonkers if it encounters a header element near the beginning if you omit the body tags (which would still validate). I’m guessing MSIE uses some tag soup parsing which assumes that “header” is a misspelling of “head”. The bug seems to occur only if the header element is the first child node or descendent of the first child node of the HTML body.

  8. First of all, the most remarkable issue of HTML5 is how simple is the label “doctyp”

    All modern browsers support HTML5, although feature support is not necessarily complete.
    HTML5 is a response to the observation that the HTML and XHTML in common use on the World Wide Web is a mixture of features introduced by various specifications, along with those introduced by software products such as web browsers, those established by common practice, together with many syntax errors in existing web documents.

  9. HTML5 is a response to the observation that the HTML and XHTML in common use on the World Wide Web is a mixture of features introduced by various specifications, along with those introduced by software products such as web browsers, those established by common practice, together with many syntax errors in existing web documents.
    Leroy Merlin

Comments are closed.