24/02/2017 Update: Added discussion of illogical heading structures and refined explanation of concepts.
Accessibility professionals and people with disabilities have argued for years about the actual benefits of having a sequential heading order in a webpage, and whether or not the issue fails or should fail the Web Content Accessibility Guidelines 2.0 (WCAG 2.0). So let’s take a fresh look at the issue.
Headings are used in HTML and webpages to semantically group related blocks of content into separate sections. In HTML, headings also have a heading level, which enables the use of sub-headings to organise and define the relationships of content on the page. HTML defines six different heading levels for content authors to use, <h1> to <h6>, and this is usually more than enough for most content. Yet more can be included using WAI-ARIA techniques such as aria-level with role=heading. Headings that use these techniques are known as semantic headings, as they are marked up in a way that technology can logically understand.
Explaining heading structure
The “Heading structure” of a webpage is the structure in which heading levels are laid out on the webpage. An example of a semantic, logical and sequential heading structure may be:
<h4>Size and Weight</h4>
A semantic heading structure is one that uses the correct heading markup (HTML heading tags or ARIA heading roles). When a screen reader user reads a semantic heading, the screen reader will not only tell the user that the text is a heading, but also specify it's heading level. This is significant, as screen reader users will be able to easily understand which text is a heading and it's position in the content's structure. However, if a heading is not marked up using a HTML heading or ARIA attribute, this will cause screen readers to treat the heading text as ordinary text and will become less meaningful to the screen reader user.
A logical heading order needs to ensure that the correct heading level has been used to show how content relates to each other. In our example, we can see that "Golden Retriever" is a sub-heading of "Dog Breeds", and "Dog Breeds" is a sub-heading of "Dogs". This will help define the heading heirarchy to readers of the content.
A sequential heading order would never skip a heading level, an example being skipping from a heading level 1 element <h1> to a heading level 3 element <h3>. For sighted users, this issue will be overlooked and is unlikely to be a problem, but this non-sequential heading order will matter more for screen reader users.
The problems with non-sequential and illogical heading levels
Order of reading content
When a non-sequential or illogical heading order is used to group sections of content on a webpage, content can become more confusing to read for screen reader users. One example may be a screen reader user finding a heading level 1 element <h1>, reading some content, and then finding a heading level 3 element <h3>. This could potentially throw off or confuse a screen reader user, and they may feel inclined to navigate back up the page to ensure that a section wasn’t accidentally skipped over. If they cannot find a heading level 2, they are left wondering if their screen reader is missing content, or the content is located elsewhere on the page. An illogical heading order can make it difficult to determine which headings are sub-headings, which is especially likely if someone is reading content on a topic that is unfamiliar to them.
Another problem with having a non-sequential or illogical heading order is it removes an effective method of navigation for screen reader users. On popular screen readers like JAWS and NVDA, the 1-6 buttons on the keyboard will navigate to a specific heading level (e.g. "1" will navigate to the next heading level 1, "2" will navigate to the next heading level 2 and so on). In our “Dogs” heading structure example earlier, a screen reader user may be interested in the biology of dogs, but not their anatomy, and so the user may press the “3” button on their keyboard to skip past the entire "Anatomy" section and immediately navigate to the “Health” heading level 3. If an illogical heading order is used, navigation using these controls is limited.
Do people with disabilities really care about heading structure?
Some people may assume that the heading structure of the page isn’t all that big a deal for screen reader users, and the only important thing is to ensure that headings – no matter what level – are used to organise content. However, there is evidence online to indicate that this is simply not the case, along with anecdotal evidence from screen reader users who I’ve discussed this issue with in the accessibility industry.
What’s more, the WebAIM Screen Reader Survey #4 showed that the majority of assistive technology users benefit from heading structure. Respondents answered the following question:
‘When navigating a web page by headings, how useful are the heading levels (e.g., "Heading 1", "Heading 2", etc.) to you?’
- Very useful: 47.4%
- Somewhat useful: 34.7%
- Not very useful: 12.2%
- Not at all useful: 3.5%
- I don't know: 2.2%
I hypothesise that if sequential and logical heading structures were more common in websites, then even more screen reader users would also consider them useful. I suspect that some users may have answered “Somewhat useful” or “Not very useful” because logical and sequential heading structure in webpages are not that common, and therefore the heading levels are not that useful.
Why aren’t sequential and logical heading structures more common?
Heading structure in Content Management Systems (CMS)
The most common and understandable reason why heading structure isn’t more common is due to how content management systems place content into websites. A CMS may place blocks of content, plugins or embedded objects into a webpage, with these blocks containing their own headings. It’s likely in these cases that the headings may become out of sequential or logical order. While it may be technically possible to create an accessible heading order in these cases, it’s often very difficult or impossible to do.
How CSS stylesheets are made
Web Designers/Developers are often tempted to place a specific heading style on a heading level. This can cause the presentation of the heading to matter more than the heading’s actual level. Sometimes in these cases content authors may choose the heading level that looks best for the situation, rather than choosing heading level that would work logically and semantically. Thankfully, CSS is more flexible than this and CSS classes can be used to create many different presentations for the same heading level, but this can be tricky to implement with some WYSIWYG (What you see is what you get) authoring tools.
Lack of technical knowledge or ignorance
Many website content authors in organisations do not have significant technical knowledge but still need to upload content to websites themselves. People unfamiliar with semantic, logical and sequential heading structure may choose whichever heading level suits their fancy, or worse, change the look of the text without marking up the text as a heading. Most people do not do this on purpose, but may simply not know the implications of having a poor heading structure or not understand why it’s such a big deal. That’s why it’s important to educate content authors on why and how to apply an accessible heading structure to websites and documents.
How WCAG 2.0 handles heading structure
For headings that use non-semantic heading markup, WCAG 2.0 will fail under success criterion 1.3.1 Info and Relationships. However, despite the benefits of a including a logical and sequential heading structure, WCAG 2.0 does not specify that logical and sequential heading structure is required to comply. WCAG 2.0 does not clearly state that it’s not required either, but does contain Technique H42 (example 2) under success criterion 1.3.1 Info and Relationships. This technique shows a heading level 2 element being used before the heading level 1 element on the page, creating a non-sequential heading order. Technique G141 mentions using heading levels to organize content, but is only an advisory technique for 1.3.1 and is not required for conformance.
The main consensus why WCAG 2.0 doesn’t require a sequential/logical heading order is due complications with content management systems (CMS), as often it is not feasible to enforce a sequential and logical heading order in every scenario due to the way that some webpages can be dynamically generated.
Some accessibility professionals argue that a non-sequential heading order should fail 1.3.1 Info and Relationships as the definition of 1.3.1 states that "structure conveyed through presentation must be programmatically determined or available in text". Evidently, using heading tags semantically is enough to comply with this success criterion.
There have been calls for WCAG 2.1, the extension for WCAG 2.0 that is expected to be released in 2018, to include logical and sequential heading structure as a requirement in the guideline. The currently long-term major update for WCAG 2.0, codenamed “Silver”, may include a solution to the heading structure problem instead. Altering 1.3.1 Info and Relationships to include sequential/logical heading orders is one area where this change could be added, but others have made valid cases for an altering of level AAA’s 2.4.10 Section Headings or adding a new Success Criterion entirely.
Despite WCAG 2.0 not requiring a sequential heading structure, the HTML specification, the Web Accessibility initiative, and the vast majority of accessibility professionals, strongly recommend using a sequential heading order in webpages. As a web accessibility auditor myself, I’ll continue to mention and strongly recommend the inclusion of sequential/logical heading orders wherever possible, but with our current set of guidelines, we’re unable to enforce that recommendation.