HTML5 headings make it easy to syndicate and reuse content, without breaking the heading hierarchy. Using HTML5 headings and keeping the heading hierarchy backwards compatible proves unexpectedly complicated though. The HTML5 specification has a solution, but is it the right one?
HTML5 sections
HTML5 uses sectioning content to break a page up into chunks. The <article>, <aside>, <nav> and <section> elements can be used to explicitly create sections. Here’s what the HTML5 specification says about sectioning content:
Sectioning content is content that defines the scope of headings and footers… Each sectioning content element potentially has a heading and an outline.
HTML5 headings
This means that each section contains its own heading hierarchy. Here’s what the HTML5 specification says about it:
The first element of heading content in an element of sectioning content represents the heading for that section.
This means that you could use an h1 at the start of each sectioning element. For example:
<body> <h1>Favourite colours</h1> <section> <h1>Purple</h1> <p>Purple is my favourite colour.</p> <aside> <h1>Reasons</h1> <p>I like purple because…</p> </aside> </section> <section> <h1>Pink</h1> <p>Pink is my least favourite colour.</p> <aside> <h1>Reasons</h1> <p>I dislike pink because…</p> </aside> </section> </body>
HTML5 calculates the rank of each heading based on its location within the sectioning content elements. The above example would therefore have the following structure:
1. Favourite colours 1.1. Purple 1.1.1. Reasons 1.2. Pink 1.2.1. Reasons
If the same page were to be coded with semantically correct HTML4.01, it might look something like this:
<body> <h1>Favourite colours</h1> <div> <h2>Purple</h2> <p>Purple is my favourite colour.</p> <div> <h3>Reasons</h3> <p>I like purple because…</p> </div> </div> <div> <h2>Pink</h2> <p>Pink is my least favourite colour.</p> <div> <h3>Reasons</h3> <p>I dislike pink because…</p> </div> </div> </body>
The idea is that the HTML5 heading hierarchy is adaptable. You could pull out the <section> elements and slot them into another HTML5 website, without breaking the heading hierarchy.
HTML5 explicit and implicit headings
Things get a touch more involved when you create a heading hierarchy within a single section. The HTML5 specification goes on to say:
The first element of heading content in an element of sectioning content represents the heading for that section. Subsequent headings of equal or higher rank start new or implied sections. Headings of lower rank start implied sub sections that are part of the previous one.
This means that if you use nested headings within the same section, HTML5 will behave as though they’re explicit sub sections. For example:
<body> <h1>Favourite colours</h1> <section> <h1>Purple</h1> <p>Purple is my favourite colour.</p> <h2>Reasons</h2> <p>I like purple because…</p> </section> </body>
In the above example the <aside> element has been removed, so that section is no longer explicitly defined. The “Reasons” heading is of lower rank than the “Purple” heading though, so HTML5 implicitly assumes there is a sub section there anyway. The outline would look like this:
1. Favourite colours 1.1. Purple 1.1.1. Reasons
If the “Reasons” heading had been an h1 instead, HTML5 would automatically close the explicitly defined <section> and open an implicitly defined section at the same level. For example:
<body> <h1>Favourite colours</h1> <section> <h1>Purple</h1> <p>Purple is my favourite colour.</p> <h1>Reasons</h1> <p>I like purple because…</p> </section> </body>
The resulting outline structure would therefore be:
1. Favourite colours 1.1. Purple 1.2. Reasons
Using h1 only or explicitly ranked headings
If you wanted to conform to the HTML5 specification, and there was no need to provide backwards compatibility, the h1 only technique would be the best.
It’s going to be some while before we reach that utopia though. In the meantime, developers can use explicitly ranked headings to support the browsers and assistive technologies that haven’t implemented HTML5 headings at all. Here’s what the HTML5 specification has to say on the subject:
Sections may contain headings of any rank, but authors are strongly encouraged to either use only h1 elements, or to use elements of the appropriate rank for the section’s nesting level.
This means that the following HTML5 examples would both represent the same outline structure.
Using h1 only
<body> <h1>Favourite colours</h1> <section> <h1>Purple</h1> <p>Purple is my favourite colour.</p> <aside> <h1>Reasons</h1> <p>I like purple because…</p> </aside> </section> </body>
Using explicitly ranked headings
<body> <h1>Favourite colours</h1> <section> <h2>Purple</h2> <p>Purple is my favourite colour.</p> <aside> <h3>Reasons</h3> <p>I like purple because…</p> </aside> </section> </body>
The outline structure represented by both of the above examples would be:
1. Favourite colours 1.1. Purple 1.1.1. Reasons
HTML5 heading support
At the moment Jaws 13 supports the h1 only technique in Internet Explorer 9 and Firefox. No other screen readers support HTML5 headings at all.
It’s worth noting that as of Jaws 13.0.527, explicitly ranked HTML5 headings are completely broken in both Firefox and Internet Explorer. It takes the rank of the heading and the sectioning content hierarchy in conjunction, and the result is an extremely broken heading hierarchy.
Choosing h1 only or explicitly ranked headings
The question has been asked whether the h1 only or explicitly ranked headings technique is the best one to use.
The HTML5 specification clearly encourages the h1 only technique. The difficulty is that withbrowsers and screen readers that don’t support HTML5, the heading hierarchy is flattened out completely.
Using explicitly ranked HTML5 headings solves the flat heading hierarchy problem. The likelihood is that using this more complicated technique will result in even fewer pages with a meaningful heading hierarchy though.
My suggestion would be to use the h1 only technique unless you’re absolutely sure you’ve got your head around the way explicitly ranked headings work in HTML5. Jason Kiss recommends a different approach, and it’s good advice as well. Here’s my take on things though.
A flat heading structure certainly isn’t ideal. It’s considerably better than the (usually broken) HTML4.01 heading structures you find on every other website at the moment though.
In time browsers and other screen readers will adopt support for the h1 only technique. When they do, we’ll probably have the best chance of semantically correct, logical and usable heading hierarchies since HTML was created!
This entry was posted on November 28th, 2011, and filed under Web life.
AlastairC said on December 21st 2011 at 12:40 pm:
Do you think the sectioning on pages will be better than the current use of headings?
From an authoring point of view, sectioning is more invisible that heading level, so I’m not convinced that the flat H1 method will be better in practice, especially since there aren’t any authoring tools that support it yet (that I know of).
Unless sectioning is somehow easier to author than heading levels are now, I don’t see a practical improvement coming.
LĂ©onie Watson said on December 21st 2011 at 1:03 pm:
Good point. HTML5 sectioning won’t be easier to implement than HTML4 headings. Which is to say people who understand/care will get it right, and (unless authoring tools make it easier) everyone else probably won’t.
Sectioning content makes sense from a syndication point of view, and relative headings therefore make sense for the same reason.
It’s quite possible we’re just swapping badly implemented HTML4 headings for badly implemented HTML5 sectioning either with/without explicitly ranked headings.
Suspect sectioning with h1 only headings might be easier to get right than sectioning with explicit headings. Whichever way you look at it though, it all feels a bit awkward.