Heading off confusion: When do headings fail WCAG?

Posted on Tuesday, 17 March 2020 by David Swallow

Moai stone head statues at Rano Raraku, Easter Island.

Headings convey the organization of the content on a webpage or screen. Good heading structures make it easy for people to quickly scan a web document and understand its structure, much in the same way they might scan a printed document. Headings also let screen-reader users and other assistive-technology users navigate within webpages and screens.

Headings are one of the fundamentals of web markup, having been in the HTML specification since the very beginning. Despite their longevity, there’s still some confusion and ambiguity over the correct use of headings, particularly when it comes to accessibility.

While accessibility guidelines will always be subject to some degree of interpretation, this note is an attempt to head off any confusion and clarify our position on what counts as a WCAG failure when it comes to headings.

Relevant WCAG Success Criteria

WCAG touches on headings across all three levels of conformance:

What ISN’T a WCAG failure?

Let’s begin with what isn’t a WCAG failure…

A lack of headings

WCAG success criteria relating to headings only apply if a page or screen actually has headings or heading-like text. This is clarified in Understanding Success Criterion 2.4.6: Headings and Labels, which states: “This Success Criterion does not require headings or labels. This Success Criterion requires that if headings or labels are provided, they be descriptive.” Similarly, Understanding Success Criterion 1.3.1: Info and Relationships recommends that headings be identified using semantic markup, not that they must exist in every page or screen.

Success Criterion 2.4.10: Section Headings does require the use of headings to organize content, but this is a Level AAA criterion, acknowledging that headings cannot be applied to all types of content, and it’s arguably more subjective to evaluate.

So although a lack of headings may feel wrong (and likely reflects a lack of semantic structure), it does not represent a failure of WCAG 1.3.1 Info and Relationships or 2.4.6 Headings and Labels (but it may fail 2.4.10: Section Headings).

Missing <h1>

On a similar note, although beginning a heading hierarchy with an <h1> is a logical and common approach to structuring web content, it’s not a requirement of either WCAG or the HTML 5.2 specification. While such a heading hierarchy may be unusual, the absence of an <h1> does not represent a WCAG failure.

More than one <h1>

The converse is also true: a top-heavy heading hierarchy is unusual but not incorrect. Users typically expect only a single <h1>, which is used to represent the main heading or title on the page. As long as the visual presentation of multiple <h1>s doesn’t imply a hierarchy (such as the first <h1> being styled visually to be larger or bolder than the second <h1>), then having more than one <h1>—while potentially confusing—does not represent a WCAG failure.

Skipped heading levels

Missing a heading level (such as having an <h2> followed by an <h4>) doesn’t help to convey a logical heading structure, and it should be avoided where possible—but it doesn’t fail WCAG.

In this example, the heading level skips from an <h2> (“Bacon and mushroom risotto”) to an <h4> (“Instructions”), and this isn’t a WCAG failure:

<h2>Bacon and mushroom risotto</h2>
<p>To cook a perfect risotto, it is essential to […] </p>
<h4>Instructions</h4>
<ol>
    <li>Heat the stock. Peel and finely chop the […] </li>
</ol>

WCAG techniques, such as H42: Using h1-h6 to identify headings and ARIA12: Using role=heading to identify headings, recommend that heading markup indicate the appropriate heading level for the content, but they don’t go so far as to define what’s “appropriate”—an issue that has been the subject of considerable discussion. So although hierarchical heading structures reflect a best practice, skipping heading levels does not represent a WCAG failure.

Multiple headings with the same text

Headings should be clear and descriptive. According to Understanding Success Criterion 2.4.6: Headings and Labels, headings help users understand the content and organisation of a page. It may be argued that multiple duplicate headings cannot accurately describe the content, but this is very much a context-dependent judgement call.

For instance, a page of recipes with multiple <h1>s that all have the text “Instructions” is arguably confusing:

<h1>Instructions</h1>
<p>To cook a perfect risotto, it is essential to […] </p>
<ol>
    <li>Heat the stock. Peel and finely chop the […] </li>
</ol>    
<h1>Instructions</h1>
<p>A coq au vin is a classic French stew in which […] </p>
<ol>
    <li>Heat the olive oil in a large, heavy-based […] </li>
</ol>

But multiple <h3>s with the text “Instructions”, each coming under an <h2> describing the recipe name, is less likely to cause confusion:

<h2>Bacon and mushroom risotto</h2>
<p>To cook a perfect risotto, it is essential to […] </p>
<h3>Instructions</h3>
<ol>
    <li>Heat the stock. Peel and finely chop the […] </li>
</ol>    
<h2>Coq au vin</h2>
<p>A coq au vin is a classic French stew in which […] </p>
<h3>Instructions</h3>
<ol>
    <li>Heat the olive oil in a large, heavy-based […] </li>
</ol>

So while using the same text across multiple headings may be a sign of an illogical heading structure, it does not necessarily represent a WCAG failure.

What IS a WCAG failure?

So what does count as a WCAG failure?

Heading-like text that isn’t marked up as headings

WCAG requires that the most appropriate semantic structure be used to convey information and relationships, which extends to headings. While this doesn’t make headings compulsory, it does mean that if you use text to denote the start of a section of content (generally styled visually to be larger or bolder than regular body text), then that text must be marked up as a heading.

In this example, <p>s have been styled to have the visual appearance of headings, and in doing so, this represents a WCAG failure:

<p style="font-weight:bold; font-size:1.5rem;">Bacon and mushroom risotto</p>
<p>To cook a perfect risotto, it is essential to […] </p>
<p style="font-weight:bold; font-size:1.5rem;">Coq au vin</p>
<p>A coq au vin is a classic French stew in which […] </p>

Not marking up heading-like text semantically does represent a failure of 1.3.1 Info and Relationships.

Illogical heading order

In addition to requiring the use of heading markup where appropriate, WCAG requires that heading markup have an appropriate hierarchical relationship with other headings. That’s not to say that heading levels can’t be skipped (as noted above, an <h2> may be followed by, for example, an <h4>) but rather that heading levels must reflect the content’s hierarchy. Or in other words: A heading that’s visually less important must be assigned a heading that’s lower in the hierarchy.

In this example, the heading “Instructions” is assigned a heading level (<h2>), wrongly implying that it’s more important than the heading “Bacon and mushroom risotto” (an <h3>).

<h3>Bacon and mushroom risotto</h3>
<p>To cook a perfect risotto, it is essential to […] </p>
<h2>Instructions</h2>
<ol>
    <li>Heat the stock. Peel and finely chop the […] </li>
</ol>

Specifying heading levels in reverse order (such as an <h2> that comes under an <h3> or presenting the main page heading as an <h6> instead of an <h1>) does represent a failure of 1.3.1 Info and Relationships.

Non-descriptive headings

Even the most semantic, logical heading structure is made ineffective if the individual headings don’t accurately describe the section of content they head up.

In this example, both recipes arguably have non-descriptive headings:

<h2>Recipe</h2>
<p>To cook a perfect risotto, it is essential to […] </p>
<h2>Recipe</h2>
<p>A coq au vin is a classic French stew in which […] </p>

Of course, determining whether heading text is sufficiently “descriptive” is subjective and context dependent. Nevertheless, using headings that don’t appropriately describe their related content does represent a failure of 2.4.6 Headings and Labels.

Heading forward

To bring this article to a head, these scenarios do not represent WCAG failures:

  • A lack of headings (unless you’re striving for Level AAA)
  • Missing <h1>
  • More than one <h1>
  • Skipped heading levels
  • Multiple headings with the same text

On the other hand, these scenarios do represent WCAG failures:

  • Heading-like text that isn’t marked up as headings
  • Illogical heading order
  • Nondescriptive headings

This article aims to precisely describe what counts as a WCAG failure when it comes to headings, but we mustn’t lose sight of the overall aim of web accessibility, which is to make the web a more inclusive place for everyone. While not every issue mentioned here may count as a WCAG failure, they all potentially cause some confusion and pose potential barriers for people with disabilities.

About David Swallow

David is a senior accessibility engineer at The Paciello Group. He joined the company in 2016, and before that, he was an academic researcher in human-computer interaction at the University of York in the UK, where he specialised in designing, developing, and evaluating usable and accessible interfaces. There he gained a PhD in computer science by investigating how to integrate accessible web development into the existing workflows of professional web developers.

Comments

  1. Great post, though I’m not following your logic on skipping heading levels. How can skipping a level not be considered an illogical order? The structure doesn’t make sense.

  2. I'm working on a website project that requires AA conformance, but also demands creativity in text and design. We want to use creative, brand-focused headlines that may not necessarily be descriptive, and so I'm interested in your opinion to see if this this work-around headings solution would meet or fail WCAG.

    For example, we want to promote events where our audience can meet us, so we want to use a fun, informal heading, like "Come hang out." We've programmed this text to be large, <p> styled text. I'm worried that this heading is not sufficiently descriptive, so above it, in smaller 16px text marked as a heading, we have "Tech events." Visually, "Come hang out" looks like the heading, but programmatically, "Tech Events" is the heading.

    For the most part, we've done this consistently throughout our site so that we visually have a headline that's more creative, but the actual section heading is smaller and descriptive. Another example is "What do you want to explore here?", which is our large <p> styled text. Above this is our smaller 16px heading "Roles & Opportunities." (In the context of this page, the entire page is talking about career opportunities.) Do you think this is an acceptable solution to meet the headings criteria?

  3. Regarding the skipping of heading levels, which seems to cause a lot of consternation: yes, in an ideal world, headings levels would never have gaps, but being pragmatic, there are situations where for whatever reason – e.g. for consistency across various parts of a page or site, where some sections may have subsections while others don’t; or for technical reasons, as a chunk of the page is an include file with a heading that may be included/imported into various contexts, and not necessarily always at the same hierarchical/nesting level – gaps in heading levels can occur.

    As noted in the article here, the Accessibility Guidelines Working Group has officially deemed skipped heading levels not to be a failure – purely for pragmatic/realistic reasons. See https://github.com/w3c/wcag/issues/655. And in light of that, when assessing a site against WCAG, we have to be guided by this assessment. Of course, nothing stops anybody from also mentioning in an audit, as a best practice, that heading levels really shouldn’t be skipped. And developers/companies can go beyond the pure minimum that is required by WCAG. But for consistency in how sites are passed/failed in an audit, we have to abide by the consensus position expressed by WCAG.

  4. Myron, regarding descriptive headings…this is a highly subjective SC to evaluate, and I can understand the doubts and confusion from authors/developers. I have to admit that even if the headings were just “Come hang out” and “What do you want to explore?” I’d have said they’re appropriate. These headings likely also reflect your writing style and “brand feel”…and that’s another aspect that is important to consider I’d say. Don’t feel that the SC demands clinical/sterile descriptive headings. What matters is that they’re not completely misleading or wrong, or completely devoid of any information. I would posit that most users would understand that “Come hang out” has some sort of event/get-together connotation. Similarly, that “What do you want to explore here?” will list some content or opportunities.

    The change/solution that you describe also sounds reasonable to me. Or, you could even make both parts a single heading, with a line break and some visual styling – so for instance making “Tech Events – Come hang out” the heading, and breaking it up visually. These would all seem appropriate choices to me, personally.

    Of course, opinions may vary (if you ask 10 other accessibility experts, you’ll likely get 11 different answers). Pragmatically I’d say: don’t stress too much over this, use your common sense/judgement.

  5. Good article/good discussion.
    One scenario not mentioned which would require headings (in certain situations) is WCAG 2.4.1 (a page must have one of, a skip link, ARIA landmarks, or headings as a navigation mechanism).
    A page without the 3 fails this success criterion.
    This is dipping way deep into the wicked weeds of WCAG so maybe it was left out of the article on purpose, but it is a point to note.
    Re heading text, I think it is most important that the heading marks the start of the section and gives at least some hint as to its content. WCAG does not define “descriptive” and there are branding guidelines and the like to consider, and there should be space for creativity and artistry in accessibility.
    I think there are legitimate reasons why a webpage may skip heading levels.
    Picture an accounts overview webpage with a promotional section.
    At the top you have “my accounts” h1
    Then there is a little blurb that says “Coronavirus promotion”
    with text about some free perks or “no late fees”.

    Then you have category headings such as “my checking accounts” “my savings accounts” and “my crdit cards” and underneath those there are headings for individual accounts.
    Obviously the category heading should be h2s and individual account headings h3s, but I don’t really think the virus update heading that marks a small blurb of text with no sections should be at the same level as account category headings, certainly not if it is not displayed with the same visual weight as those headings. I think an h3 or h4 is just as valid and probably more consistent with the visual weight of the heading text.

    This is why accessibility is 2 quarters science and 3 quarters art, (no quarters mathematics).

Leave a Reply

Your email address will not be published. Required fields are marked *

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