HTML5 ranked headings for screen readers

HTML5 ranked headings for screen readers

  • Knowledge needed: Basic understanding of HTML
  • Requires: Text editor and a browser
  • Project time: 20 minutes

Léonie Watson of Nomensa talks you through getting ranked headings in HTML5 right for screen readers

One of the challenges of moving to HTML5 is headings. With HTML4 it was all quite straightforward. You sequentially nested <h1> through <h6> tags to create a logical hierarchy of content on the page. Screen readers reported each heading exactly as they found it, and that was that. For example:

  1. <h1>Heading 1 (reported as level 1)</h1>
  2. <div>
  3. <h2>Heading 2 (reported as level 2)</h2>
  4. <p>...</p>
  5. <h3>Heading 3 (reported as level 3)</h3>
  6. <p>...</p>
  7. </div>
  8. ...
  9. </body>

HTML5 introduces the concept of relatively ranked headings. The level of a heading in HTML5 depends on its location within one (or more) sectioning elements – specifically the <nav>, <section>, <article> and <aside> tags. The HTML5 outlining algorithm makes it possible to use only <h1> headings on a page. The level of the heading is then redefined based on the nesting of the sectioning elements it’s wrapped in:

  1. <h1>Heading 1 (reported as level 1)</h1>
  2. <nav>
  3. <h1>Heading 1 (reported as level 2)</h1>
  4. ...
  5. </nav>
  6. <section>
  7. <h1>Heading 1 (Reported as level 2)</h1>
  8. <article>
  9. <h1>Heading 1 (reported as level 3)</h1>
  10. ...
  11. </article>
  12. ...
  13. </section>
  14. ...
  15. </body>

Although the HTML5 specification encourages the use of <h1> only, it does allow explicitly ranked <h1> through <h6> headings to be used as well. This is where it can start to make your head spin if you’re not careful:

  1. <h1>Heading 1 (reported as level 1)</h1>
  2. <nav>
  3. <h2>Heading 2 (reported as level 2)</h2>
  4. ...
  5. </nav>
  6. <section>
  7. <h2>Heading 2 (Reported as level 2)</h2>
  8. <article>
  9. <h3>Heading 3 (reported as level 3)</h3>
  10. ...
  11. </article>
  12. ...
  13. </section>
  14. ...
  15. </body>

The two HTML5 examples above effectively create the same heading hierarchy on the page. This leaves us with the question: which is the best technique to use?

As it so often does, the answer relies on browser and screen reader support. Those browsers and screen readers that support the HTML5 outlining algorithm will present a sequentially nested hierarchy of headings to the user when the <h1> only technique is used.

This means that those browser/screen reader combinations that don’t support HTML5 headings will simply present the user with a page full of level one headings when the <h1> only technique is used. Not the best experience!

To date, Jaws 13 is the only screen reader to have introduced support for HTML5 headings. The public beta includes good support for the <h1> only technique, but still has some difficulty handling explicitly ranked HTML5 headings.

The upshot is that for the time being you should use explicitly ranked headings in HTML5. You’ll need to be on your game when it comes to working out the heading hierarchy, but if you need to get back to basics, there’s a useful guide here.

5 comments

Comment: 1

So you're asking us to step back and ignore the (awsome) new possibilitys of structuring modern websites the way they are (complex applications with multiple (independent) hierarchical sections)?
And you're suggesting this because because screenreader producers have problems with parsing them?
I don't think so. Actually: It's their (softwares) job to get those standards correctly. Just force them to do updates by using / sticking with standards.

Comment: 2

@felixw: As a web developer in public higher education, it's impossible for me to ignore the fact that screen reader software has not caught up with these new standards. (Personally, I find these headings standards flawed).

It's my job to make sure visually impaired visitors can access my website regardless of what standards their screen reader of choice supports. To me this means I have to ignore the HTML5 headings standard. If I went with a "you are on your own because you don't have the right screen reader" attitude, I'd be out of a job pretty fast.

Comment: 3

@felixw wrote:

"So you're asking us to step back and ignore the (awsome) new possibilitys of structuring modern websites the way they are (complex applications with multiple (independent) hierarchical sections)?"

Note that the of all the user agents, the ONLY implementation of the HTML5 outline algorithm is by the JAWS screen reader. None of the major browser implement the algorithm (which is why it is considered an 'at risk' feature in HTML5. So it is rather a case of not jumping in and using a feature that is not interoperably implemented and where it is implemented well. For all we know it may never be implemented by mainstream browsers or its specification may change markedly before implementation.

@leonie

some testing I have done with JAWS 14 recently appear to show that the JAWS implementation is borked. For example:

the following code produces a 'HTML5' outline of h1, h2, h2, h2:

JAWS conveys as h3, h2, h4, h6

<h3>heading</h3>
<section>
<h1>level 1</h1>
</section>
<section>
<h3>level 3</h3>
</section>
<section>
<h5>level 5</h5>
</section>

Comment: 4

@SteveFaulkner
"Some testing I have done with JAWS 14 recently appear to show that the JAWS implementation is borked."

Confirmed here. I believe this was first reported to Freedom Scientific when Jaws 13 went to public beta, and it doesn't seem to have been resolved in the latest Jaws 14 beta either.

credit to FS for attempting to implement support for HTML5 headings, knowing that headings are an important mechanism for screen reader users to navigate by, but it's incredibly frustrating that the implementation is broken.

Comment: 5

I agree that in the case of mainstream browsers, it's good practice to use new coding techniques as they are released (with fallbacks as necessary), as it pushes the browser vendors to keep abreast of developments. But screen readers are quite different. They are very expensive pieces of kit, often used by people on a limited income who can't afford to update them regularly.

If we are to ensure our sites remain accessible for the majority of users, we have to work with the reality of the technology they have at their disposal.
July issue on sale now!

The Week in Web Design

Sign up to our 'Week in Web Design' newsletter!

Hosting Directory
.net digital edition
Treat yourself to our geeky merchandise!
site stat collection