Using HTML5 headings

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

Updated: 26th November 2015.

The Jaws screen reader briefly introduced support for the HTML5 outline algorithm in version 13. The implimentation was broken however, and subsequently removed in Jaws 15. No browsers currently support the outline algorithm.

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.

Updated: 26th November 2015.

Originally I recommended using a flat h1 heading structure. Four years later the HTML5 outline algorithm is still not supported in browsers, and without that an h1 only heading structure is meaningless. Better to use explicitly ranked HTML headings and take care to get the heading hierarchy right!

9 comments on “Using HTML5 headings”

Skip to Post a comment
  1. Comment by AlastairC

    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.

  2. Comment by Léonie Watson

    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.

  3. Comment by Léonie Watson

    Thanks Lewis.

    I wrote this post back in 2011, and nearly three years later no browsers have implemented support for the HTML5 outline algorithm. Jaws was the only AT to implement support (although it was broken), and it has since removed support entirely.

    If I were to write this post today, I’d advise sticking to explicitly ranked headings in web pages. Using all h1 is ok at the technical/code level, but from a UX point of view a flat heading hierarchy is meaningless – and without good UA support, that’s all we’re left with.

  4. Comment by Gavin

    HI Léonie,

    Do you still advise to use explicitly ranked headings? I notice gov.uk has 3 heading 1’s on their navigation page but don’t use the html 5 sectioning content elements.

    I thought multiple h1’s on a page is bad for screenreader users?

    1. Comment by Léonie Watson

      @Gavin

      No, I don’t recommend the h1 only approach anymore. It seems clear that browsers are not going to support the outline algorithm anytime soon and without it an h1 only structure is meaningless.

      Jaws did attempt to support the outline algorithm at one point, but its implimentation was broken. Its since been removed.

  5. Comment by chaals

    Here we are in 2016. While a number of browsers use a CSS trick to make the headings look right visually, it seems *none* of them actually interpret the semantics. So any custom presentation, such as a screenreader, is still completely un-usable 🙁

    How should the HTML spec handle such situations, where for a known population *all* implementations are broken?
    – Put a warning in the spec?
    – Remove the example?

    1. Comment by Léonie Watson

      @Chaals

      Given that the outline algorithm itself has no browser implimentations, I think that examples like this are things we should look at in HTML5.1.

Comment on this post

Will not be published
Optional

This site uses Akismet to reduce spam. Learn how your comment data is processed.