This content originally appeared on TPG and was authored by David Swallow
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.
This content originally appeared on TPG and was authored by David Swallow
David Swallow | Sciencx (2020-03-17T20:26:46+00:00) Heading off confusion: When do headings fail WCAG?. Retrieved from https://www.scien.cx/2020/03/17/heading-off-confusion-when-do-headings-fail-wcag/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.