JAWS, IE and Headings in HTML5

If you use explicitly ranked h1 to h6 headings nested in HTML5 sectioning elements, as opposed to using exclusively h1 elements, JAWS 12.0.1170, as well as the JAWS 13.0.171 beta, will misrepresent the heading hierarchy.

Headings in HTML5

The HTML5 outline algorithm allows us to use the h1 element for every heading on a page, and depending on the nesting of the sectioning element in which the h1 is found, the heading's rank will be redefined accordingly. While the HMTL5 specification encourages us to use only h1 elements, we are permitted to use [h1 to h6] elements of the appropriate rank for the section's nesting level.

The sectioning elements are article, aside, nav, and section. As such, according to the algorithm, the following two structures create identical outlines:

Using h1s Only

<h1>Level 1</h1>
   <h1>Level 2</h1>
   <h1>Level 2</h1>
      <h1>Level 3</h1>
         <h1>Level 4</h1>

Using Explicitly Ranked Headings

<h1>Level 1</h1>
   <h2>Level 2</h2>
   <h2>Level 2</h2>
      <h3>Level 3</h3>
         <h4>Level 4</h4>

Use Explicitly Ranked Headings For Now

It's a good thing that we have a choice of which approach to take, as support for the HTML5 outline algorithm in current browsers and assistive technologies is not quite there yet.

Where only h1 elements are used, a non-supporting browser or assistive technology will find nothing but h1 headings, which does not help a user understand the document's structure or heading hierarchy. For now, it is probably best to continue using explicitly ranked h1 to h6 elements as appropriate.

However, at least one screen reader in one browser is now supporting the h1-only approach to using headings in HTML5. But as good as this sounds, the particular support it has introduced is problematic.

JAWS 12 and 13 in Internet Explorer

If you use an h1 for every heading, JAWS 12 and 13 beta will, in Internet Explorer but not Firefox, correctly rank the heading in accordance with its section's nesting level. For example, an h1 nested two sectioning elements deep will effectively become a third level heading. JAWS appears to be simply adding the required number of levels to the heading as appropriate.

At the same time, and this is the problematic part, JAWS appears to be doing this even if you've taken the alternative approach and have used explicitly ranked h1 to h6 elements. That is, if you've correctly used an h3 element nested two sectioning levels deep, it becomes an h5 as far as JAWS in IE is concerned. Obviously, this can significantly alter the page's document outline or heading hierarchy as represented to the user.

If we take the second HTML5 structure we saw above, where the heading levels are explicitly set using appropriately ranked heading elements, JAWS in IE effectively interprets it as follows:

<h1>Level 1</h1>
   <h2>Level 3</h2>
   <h2>Level 3</h2>
      <h3>Level 5</h3>
         <h4>Level 7</h4>

Not only does the heading hierarchy now jump from a level one, to a level three, to a level five heading, the h4 heading in the aside element, nested three sectioning elements deep, becomes a 7th level heading. Since there is no such thing as an h7 element, JAWS does not even identify it as a heading. When moving from heading to heading through the page, as JAWS permits using the h key, this heading is simply skipped over. Nor does the heading appear in JAWS' headings list dialog.

Update: If you want to check for yourself, here are the actual test pages I used:

All Versions of IE Affected

Interestingly, this behaviour occurs in all versions of IE, from IE6 and above. With IE6 to IE8, which have no native support for HTML5, this behaviour depends on those versions of IE being forced to recognise the HTML5 elements through a now common JavaScript hack, e.g., the HTML5 Shiv. Without it, JAWS presents each heading at a level defined by the heading element used. So every h1 remains a level one heading, every h2 a level two heading, and so on, regardless of the relevant sectioning element's nesting level. Of course, without the JavaScript shim, there's no styling of HTML5 elements in IE8 and below, so this scenario is rather moot, unless the page's developer has decided to not bother supporting those browsers.

Update (Oct. 17, 2011): JAWS 13 in Firefox

The latest release of the JAWS 13 beta, 13.0.241, behaves the same in Internet Explorer, but now also incorrectly represents explicitly ranked headings in Firefox. In fact, it's even worse.

In Firefox, the h4 nested three sectioning levels deep in the aside from our example is identified as a second level heading. If you use an h1, it is properly considered a fourth level heading, since one plus three equals four. If you use an h2, you get a fifth level heading, and an h3 gets you a sixth level heading. The h4 to h6 elements, however, all become second level headings.

This behaviour is wrong. According to the HTML5 spec, no matter what explicitly ranked heading element is used, a user agent that supports the HTML5 outline algorithm should assign an appropriate level for the heading based on the nesting of sectioning elements in which the heading is found.

A Bug and a Dilemma

I'm happy calling this behaviour a bug. While it's great that JAWS now supports the h1-only approach to headings in HTML5, it's hardly reasonable to start misrepresenting properly ranked h1 to h6 elements. Using explicitly ranked heading elements is clearly permitted by the HTML5 specification, and remains the only way to provide most current user agents a representative and meaningful document outline.

The dilemma is that using only h1 headings to provide a meaningful document outline for users of what is possibly the most popular screen reader and browser combination today means providing users of all other current screen reader and browser combinations effectively no meaningful heading hierarchy. Or, conversely, where headings in HTML5 are concerned, supporting most screen readers and browsers means not supporting JAWS 12 and 13 in Internet Explorer.

These are the sorts of decisions we don't want and shouldn't have to make when building accessible web pages, but they are a reality that we unfortunately get used to. On the other hand, screen reader and browser development is moving very quickly these days, so this particular problem may not exist for long.

You'll have to make up your own mind on how you deal with this issue. For me, until there's broad support for the h1-only approach across most screen readers and browsers in use, I'll take the more backwards-compatible route and use appropriately ranked h1 to h6 elements in my HTML5 pages.


Note: The translations below are listed with no guarantee of their accuracy (or the accessibility of their content).

13 Responses to JAWS, IE and Headings in HTML5

  1. 1. Roger Hudson:

    Thanks for the article Jason. Very interesting (if a little worrying and perplexing) information.

  2. 2. Jesper Allermand (@allermand):

    Thanks for bringing us up to date on this Jason!

    Its not a new dilemma and from my point of view there is only one way to go – Forward.. Vendors need to catch up here and better yesterday than today. We (developers) can not plan and build future-safe websites making exceptions for non-savvy software.

    I believe we should continue pushing HTML5 as the standard markup language it actually is – the current HTML version.

    Regards – love this site!

  3. 3. Stomme poes:

    @Jesper: until we can have complete and utter control over all users and their chosen (or forced) user agents, actively blocking these users is not something to advocate.

    And while HTML5 is the most recent version of HTML, calling it the standard while it’s still DRAFT in big red letters and subject to change every time a squirrel farts, I think goes a little far. Do you use <hgroup>? The way it bounces in and out of the spec is almost entertainment.

    Beyond that, what’s in the spec today does not say using explicit h1-h6’s should screw any user agents up, only that using one (preferably the h1) will be preferred when the document outline sets heading levels. This is just the spec writers trying to get as close to XHTML2’s <h> tag as possible: a single heading tag for all headers.

  4. 4. steve faulkner:

    Hi Jason, interesting that JAWS have implemented the outlining algorithm or more correctly a version of the algorithm. The implementation has nothing to do with IE’s implementation of the HTML5 elements as you have observed (it works in older versions of IE). JAWS has a DOM module (FsDomNodeIE.dll) for IE and a seperate one for Firefox (FsDomNodeFirefox.dll), so looks like they have implemented an algorithm in the IE DLL but not the FF DLL. note that hrgoup is not yet supported.
    It is unfortunate that the use of Hx in conjunction with the HTML5 section elements results in misnesting…
    I think the more general issue is the current lack of suport across AT and what we can be sure of is future interopability issues as other AT implement their own take on the algorithm. The saner approach would be for the browsers to implement the algorithm, providing the structure via the accessibility tree and the AT to pick up the structure from the accessibility API output. This would result in a lot better chance of interop.

  5. 5. Jason:

    @Jesper, @Stommepoes

    Thanks for your comments. They highlight another aspect to the dilemma. Knowingly giving some users a poor or less than accessible experience is never a fun decision to make, and if there’s a way to still use a technology, whether it’s the addition of a hack or certain approach to markup, that’s the preferable route for the sake of access.

    However, I’ve come to resist catering to blatant bugs that prevent me from using technology according to spec (even, within reason, if unfinished). The JAWS 10/11 header bug in Firefox was important to my deciding this way. Vendors (and users) do need to take some responsibility, and developers (and users) continuing to cater to the really nasty bugs in some AT doesn’t help the situation IMO. But such a decision always needs to be informed by the market or audience within reach and that one wants to reach.

    While things like hgroup and longdesc are perhaps special cases where their status in the spec is concerned, I don’t really expect the HTML5 outline algorithm and approach to heading elements to change. But as you suggest, @Stommepoes, if a squirrel farts in a forest…


    Yeah, it was fairly clear that JAWS is just working straight from the DOM, so even more curious that it doesn’t behave the same way with Firefox. I didn’t know about those specific modules for each browser, so thanks for that info. I, too, long for that more robust and interoperable working relationship between browser, API and AT πŸ™‚

  6. 6. Rob:

    @allermand: “I believe we should continue pushing HTML5 as the standard markup language it actually is – the current HTML version.”

    Actually its not – HTML5 has not yet been standardised (although its been development for over 10 years). Browser vendors commonly implement new features differently. Unfortunately, this means living with multiple versions of HTML and disparate browser support for a while yet.

    It seems to me best to work with the subset of HTML5 currently well supported by most browsers and readers. This article sadly illustrates one case where this may not be possible.

  7. 7. Kirk:

    First, for the record, JAWS is only one of several means of blind people accessing the web. It is significant because the manufacturer spends huge amounts of money leading accessibility “experts” astray. But they aren’t the only ones out there.

    Perhaps it is time for Freedom Scientific to stop relying so heavily on the off screen model and allow the browser to render the HTML.

  8. 8. Jason Megginson:

    Great article. To avoid this in IE 8 and 9 with (applicable) JAWS versions, it can’t hurt (for now) to implement the role of “heading” and appropriate aria-level along with the Explicitly Ranked Heading approach.


  9. 9. Jason:

    @Jason Megginson

    Great suggestion, and nicely solves the problem with JAWS in IE:
    <hx role="heading" aria-level="x">

    Dilemma mitigated.


  10. 10. Jesper Allermand (@allermand):

    Ok, sorry – I did a brutal post, written way too fast and I (partly) regret. By all means – I do NOT want to advocate ignoring this or any other issue resulting in a behavior so wrong (it being in AT or browser) that its turns a webpage into unstructered blah blah. That part I regret..

    I’ve read this article twice again and now I’m even more frustrated.. As you @Jason write as a closing remark – we don’t want to take these decisions!

    As for use of HTML5 I still believe that developers should and need to embrace it as the furure (and current) standard. Yes it has grown into an almost mature version and it took some years. HTML5 has lots of benefits, the maybe most important around the document structure; Intentions are good and done right (by all parts) it will be a relief for everyone not to decide where the h2, h3 etc. should go (because semantic structure is set by the new document outline). And it will be easier to re-use content in varying content (for the same reason).

    @Jason and Jason M: As for the suggested model using role and aria-level – I guess that would mean that either developer or editor would still have to decide what aria-level a given heading-element should have? But isn’t that exactly what HTML5 is trying to avoid by letting the new document outline take over..?

    Regarding HTML5 being the current version or not; I want to advocate HTML5 as the standard people should use from now. Building big solutions for the web is time consuming and expensive. The sites I’m involved in has an average development time range round 6+ months. HTML5 specs are evolving and I feel that not making use of the solid part for the specs would be wrong. Especially the document outline structure, which (from my point of view) is the very backbone of HTML5, would be hard to ignore.. Wouldn’t it be odd to create a solution that would outdate after a short period?

    Target segment also matters – most projects I’m involved in are within the public sector and has high focus and demands for accessibility. So every serious issue (in browsers and/or AT) is my issue, and dilemma.

    I do not make use of hgroup, mostly because I don’t see the point and necessity, but its not to compare with the document outline structure – which (hopefully) isn’t going to change. That part is so mature that vendors DO need to prepare for its coming, not to say presence..

    As a last remark; Big thumbs up for Jason and everyone involved and participating in this blog and similar.. I come here as a web site developer and I try to catch as much information as possible to avoid conflicts between AT and the sites I’m involed in. Hope to succeed in that and I hope that vendors do the same – understand and respect the web as it evolves..

  11. 11. Jason:


    Thanks for your second post. I’ve been there πŸ™‚ Writing, it seems, no matter the medium, can be so often open to (mis)interpretation.

    Regarding the ARIA solution, yes, if hard-coded the setting of role and aria-level could lead to problems in browsers/AT that support the HTML5 outline algorithm. I suppose one possibility might be to use JavaScript to add the attributes and set the appropriate value for aria-level depending on the heading’s nesting.

    In any case, while I appreciate the opportunity to use explicitly ranked heading elements to support current browsers and AT that don’t do the HTML5 algorithm, and still support JAWS in IE using role and aria-level, it is definitely extra work. I certainly don’t meant to suggest that the dilemma is completely mitigated; only that there is a way out, for now. But who ever said that supporting un-interoperable AT was easy? πŸ™‚

  12. 12. Stomme poes:

    I agree mostly with using the more stable parts of the HTML5 spec, though I fear there will never really be a “Finished!” ending for HTML5 as there kinda was for HTML4 (two for that one, with the 4.01 update).
    Right now I’m using the HTML5 stuff I know has trouble breaking (new form inputs, leaving out MIME types no browser reads anyway) but leaving out the big new semantic elements like <header> and <nav> for now (until AT and browsers are more stable with those… I especially cringe at the idea of needing scripting just to make some browsers read markup). And I’m probably not going to bother with adding aria heading roles for all my headers because one version of one screen reader in a single browser has problems… what will JAWS14 do? etc. Though I sure would like to know what the upgrade rates are for people likely to come across the kinds of sites I build, which could possibly convince me to change my mind. Or I’d add in the role but not the level, since JAWS is completely skipping the fact that there’s a header there entirely.

    I’m sure other developers are in the boat. We don’t have stats for screen readers or other assistive software. We’re guessing a lot. One reason I love Jason’s site is that at least I can be made aware of what bugs are out there in multiple screen readers.

    I don’t disagree with the HTML5 writers’ idea of XHTML2’s <h> tag; for syndication situations it’s brilliant. There was a lot of good ideas in XHTML2 and I see the WHATWG tried grabbing many of them, which I think is good.

  13. 13. Ryan Hemphill:

    I like some of the comments made about fixing bugs related to screen readers.

    It’s interesting to look at the comparisons between the browser wars and the ‘screen reader wars’ in terms of behaviors, functionality and esp. interpretation of ARIA-assisted content. I am currently in a situation where I have to make my company’s web app accessible at all costs, including painting over ARIA and other a11y ‘conventions’ to make the thing truly accessible. I know that there is a push for screen reader companies and other tech providers to take more responsibility for their products and I can understand that.

    However, I think there is a simple reality here that some of them are simply not able to commit to the kind of quality I would (and our app) need to get things humming. I won’t argue that it is a pain-in-the-you-know-what…but I’m worried that having seen the ARIA behavior adoption, it may be up the web developer community to fill that gap until these Screen Reader companies are ready to step up to the HTML5 plate.

    Does anyone have any thoughts on this?

Comments are now closed.