The skipped headings myth

28 April 2019 | Ted Page

One of the most persistent myths amongst document producers is that skipping a heading level will always create an accessibility problem. Whilst many well-structured documents do follow a strictly descending hierarchical heading structure (ie without skipping a level), sometimes skipping a heading level is the only sensible thing to do.

WCAG

A good starting point in debunking this myth is WCAG (the Web Content Accessibility Guidelines). Quite simply, there is no prohibition on skipped headings in WCAG. It’s just not there, and never has been. The WCAG position was neatly summed up by Bruce Bailey, a long-serving invited expert on the W3C WAI GL working group, who explained that in the course of drafting WCAG 2.0:

requests to add skipped levels as a documented ‘Common Failure’ … had come up a few times … [but] it does not seem entirely compelling that skipping levels always creates problems and confusion … We don’t think there should be a blanket prohibition.

PDF/UA

Unfortunately, there is a blanket prohibition in the PDF/UA 1.0 standard.  However, the good news is that it has been removed from the forthcoming PDF/UA 2.0 update.

Why is the no-skipped-headings ‘rule’ so popular?

Selecting heading levels randomly or because of their visual appearance is universally accepted as an accessibility no-no. It is such practices that skipped headings bans are intended to prevent. However, there are many examples of document structures in which such unnecessarily broad rules will create, rather than prevent, problems.

Sidebars

Sidebars are a prime example. In many documents it would make sense for the main heading of each sidebar to have the same level as those in  all the other sidebars in that same document. This is so because sidebars will often have the same function or purpose, or the same level of importance as each other, within the context of a given document.

So, if the first sidebar in your document happens to come after a heading level 3 (H3), to comply with a no-skipped-headings rule, you would typically mark up the sidebar’s heading as a heading level 4 (H4). The problem is that there is no guarantee that all of your sidebars will just happen to come after H3s. If the next one came after an H2, for example, you would be forced to make the second sidebar’s heading an H3.

Thus, you are faced with the choice of following the ‘rule’ or being inconsistent in the way that you describe the structure of the document and the function or purpose of its various sections.

Examples

Update: please see The skipped headings myth debunked (PDF, 110 KB) containing the above sidebars example as well as the example mentioned in the conclusion below of an inside cover page/peripheral front-matter sub-heading.

PDF cover with white titles and an Illustration of a young man looking out of a train window

The Caption ‘workaround’

Some document authors attempt to get around this dilemma by making the sidebar’s heading a caption rather than a heading. This really isn’t a good idea either.

Firstly, screen reader users often browse a page’s content by jumping from one heading to the next. If a heading is removed and replaced with a caption this will make the content more difficult to discover, and hence less accessible.

Secondly, it is not at all uncommon for a sidebar to have multiple headings/sub-headings. Obviously, in such a case the caption ‘workaround’ would be a non-starter (there’s no such thing as a sub-caption).

Conclusion

There are numerous other examples available, including inside cover pages/peripheral front-matter, or large complex documents with differently structured sub-sections, where adherence to a rigid blanket ban on skipped headings will prevent you from describing the document’s structure as it actually is.

In sum, whilst it is easy to demonstrate that, some of the time, skipped heading levels are bad for accessibility, it is impossible to construct any kind of argument or provide any kind of evidence to show that they are always so. On the contrary, it is relatively easy to provide examples of where a blanket ban will create accessibility problems that wouldn’t otherwise exist.