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:
- 1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. (Level A)
- 2.4.6 Headings and Labels: Headings and labels describe topic or purpose. (Level AA)
- 2.4.10 Section Headings: Section headings are used to organize the content. (Level AAA)
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.
Comments
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.
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,
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
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?
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.
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.
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).
This to me is a little like ‘forgetting the message and worshiping the creed’.
In my time working with assistive technology users, I have learnt that well-formed heading structure is crucial to accessibility and anything less can place needless burden, confusion and frustration on users who rely on headings to navigate content.
I’m concerned that advice in this article can give excuses for sloppy use of headings.
Users expect only 1 h1 heading. Skipped heading levels can confuse users and waist their time searching for a non-existent heading level.
Just because something isn’t a WCAG failure doesn’t mean it’s not an accessibility failure.
Reading this article, it seems to me WCAG needs to revise its advice on headings to lower its risk of failing users of assistive technology.
The example in the article of skipped heading levels seems to defy any accessibility logic. Yes WCAG technically allows for skipping of levels from a pragmatic standpoint. But the example doesn’t reflect that. It should have clearly been a h3, and i wonder what justification you can find for making it a h4. It’s exactly the kind of programming i need to tell developers to stop.
The example provided by Birkir Gunnarsson on the other hand is a good one. As it clearly shows how a heading level may not fit the entire page because one html-page is not always the equivalant of one document, but may in fact be a document with one or more post-it notes on it. Or it may contain chunks imported from another webpage as Patrick H. Lauke mentions. Both of those cases do not apply to the example.
Likewise: yes you can have more than one lvl 1 heading, but that clashes with how users use a page. Until assistive technologies catch up, using more than one lvl 1 heading will confuse users. And as such should be done as little as possible. Arguing the letter of the law in a case like that distracts from the goal: improving the experience for everyone.
As anybody advocating for anything can tell you: there is no better way to use a law against the intended purpose than interpreting it to the letter. Articles like these have merit, but not if you don’t make the examples realistic and supplement them with why the letter of the law can be a disservice to any user.
While I agree that ultimately, users are impacted, it’s worth noting that auditors aren’t lawyers. When doing an audit, we’re bound by WCAG’s wording (and, in some slightly vague/subjective situations, guided by the interpretations from AGWG in the understanding documents) when it comes to determining whether something is a hard FAIL of a success criterion or not. While we can then advise clients that, regardless, they should go beyond the pure letter of WCAG, for consistency (with other organisations doing audits, or even among colleagues within the same organisation) we have to be as close to the literal interpretation of WCAG as possible. It’s a fine line to walk. It’s frustrating at times. But it’s even more damaging when auditors “make up” extra requirements or tighter interpretations that aren’t strictly spelled out in WCAG, as then they’re essentially passing off their narrower interpretations as “the law”.
Thank you for your comments.
I reiterate throughout the article and again at the end that, irrespective of whether each scenario counts as a WCAG failure, they all potentially cause some confusion and pose potential barriers for people with disabilities.
My intention was not to cast judgment on the efficacy or appropriateness of WCAG success criteria (that is something to take up with AGWG). Instead, I set out to delineate the conditions under which the criteria are violated.
As Patrick points out, given WCAG’s incorporation into law, we are ultimately bound by its wording. Unfortunately, there is little room for subjective interpretation, however well-intentioned.
I guess it’s difficult for an accessibility auditor not to want to flag issues like missing headings on a page when they are so fundamental to accessibility. We have a lot of internal debates about whether something does or does not pass WCAG AA conformance criteria, sometimes because the guidelines aren’t clear enough and other times because we feel that things REALLY SHOULD be a AA requirement.
I think the point about auditors not being lawyers is the most important thing to remember here, but there is definitely some frustration when you have to “let things go” because strictly speaking it is not a violation.
Thanks for the article David, it is honest and thought provoking. If you could share your thoughts on WCAG 1.3.5 and specifically the wording of the test requirements then I’m sure the whole industry would be grateful 🙂
Nice read!
With regards to the inappropriate heading order (h3 followed by h2 example). Is that implied from the ARIA H42 example (https://www.w3.org/TR/WCAG20-TECHS/H42.html)? I haven’t found an HTML failure example for it.
In the referenced H42 GitHub issue (see https://github.com/w3c/wcag/issues/655#issuecomment-476162347), the argument is that it is possible to have an h2 element followed by the h1 element and that would be appropriate. Following this idea, the heading order doesn’t matter as long as either implicit or explicit role is applied.
It isn’t to say I think it’s right, but I’m led to believe that this is not a fail. I also don’t think that any of the F43 failure examples apply (https://www.w3.org/WAI/WCAG21/Techniques/failures/F43.html).