Heading Levels: Navigation or Decoration?

Thursday, April 5, 2012  Return to Logical Structures

Heading levels represent the basic model for navigation in most web content and in PDF files as well (back in the day, PDF borrowed liberally from HTML). The practice of skipping heading levels (for example, from H2 to H5) is common in web content, and not only there.

When considering accessibility what are the rules for heading levels? Isn't effective navigation a normative requirement for accessibility? Does WCAG 2.0 adequately address the question of navigation, especially for longer documents?

This article attempts to address these questions.

Headings Have Levels

However styled, a list of items can't be considered accessible if that "list" consists of <P> tags. Accordingly, while it doesn't explicitly identify any specific tag or technology, WCAG 2.0 Success Criterion 1.3.1 is nonetheless understood to normatively require valid list structures wherever the author intends a list.

Everyone is happy with that. So what else is normatively required to enable navigation for AT users? 

Let's keep it simple with these two cases:

• Case 1: H2, H3, H4 (heading levels descend through numerical sequence)
• Case 2: H2, H5, H3 (heading levels are skipped)

Question: Can a document following Case 2 comply with accessibility standards?

What the Standards Say

Technology Standards	Accessibility Standards
HTML 4.01: Section 7.5.5 allows Case 2 but notes that skipping isn't best practice. While HTML refers to Heading Level as a matter of "importance" rather than a question of structure it's clearly implied that structure is to be inferred from heading levels.	WCAG 2.0: Ambiguous. Success Criterion 1.3.1 and Success Criterion 2.4.3 (both Level A) apply. These appear to favor exclusion of Case 2, but there's no explicit normative guidance. The supporting and informative text and examples generally prefer Case 1, however HTML Technique H42 provides an HTML-specific example of Case 2.
PDF (ISO 32000-1:2008): Ambiguous but permissive. The relevant section, 14.8.4.3, and 14.8.4.3.5 in particular, encourage explicit structure but do not exclude Case 2.	PDF/UA (ISO 14289-1): Case 2 is not permitted. (ISO 14289-1, Section 7.4.2, para. 1, bullet 3).

Assessment

PDF/UA is clear: Case 2 is forbidden. WCAG 2.0 is normatively ambiguous. SC 1.3.1 refers to "structure and relationships", and it's hard to see how "structure and relationships" can be "programmatically determined" if heading hierarchy (as opposed to simply the fact of "headings") is to have meaning.

On the other hand, maybe this distinction simply highlights the difference between web content and "other stuff".

Why isn't WCAG 2.0 clear on this Level A question?

WCAG 2.0 addresses web content. The vast majority of web content is HTML, and the vast majority of HTML pages contain only a few headings. Ignore the levels and AT users may still readily "scan" the whole page for headings and navigate accordingly. Consequently, for most web content, headings themselves may matter, heading levels matter a lot less.

"Electronic document" and "web page" are not synonymous. As HTML dominates today's web, PDF dominates in final-form electronic documents. A large part of the basic point of PDF is the ability to serve as a self-contained vehicle for documents with dozens, hundreds or thousands of pages. For effective navigation with AT on such documents, heading levels become increasingly important as a function of both the volume of headings and the number of heading levels in use.

The use cases that prompted the PDF/UA Committee to develop normative language for heading levels are those longer and more structurally complex documents. Most users don't often think of larger documents as "web content", but from government reports to legal briefs to clinical records to bank statements, billions of such documents are fundamental in every area of the economy.

PDF is not "of the web". While headings in HTML denote "importance" (HTML 4.01 7.5.5), in PDF, headings are a "...label for a subdivision of a document’s content" (ISO 32000-1 14.8.4.3.2). These are not identical concepts. It should be no surprise that WCAG 2.0 does not address Level A considerations for the many use-cases in which PDF is the dominant technology, because WCAG 2.0 is clearly rooted in HTML. Longer, structured documents are a very common use-case for PDF as they are not for HTML/CSS.

When so many use-cases and so much functionality is at stake, there's only correct normative answer. PDF/UA provides the necessary normative language specifying the means of navigationally reliable structure in PDF files.

The effect on AT users

Discussions on this precise point with real-world AT users have made it clear that failing to insist on correct document structure drains heading enumeration of navigational value. AT users are condemned to blundering from heading to heading instead of relying on heading levels to locate content.

No actual information is conveyed by skipping a heading level. In a world where heading levels are used for styling, users who depend upon structure for navigation simply cannot trust the heading levels they encounter. Longer documents are, consequently, far harder to navigate.

Why should it be the AT user's problem that many of today's document application and CSS UI implementations don't make it easy for authors to distinguish between structure and cosmetics? These are Level A criteria, after all.

I understand that there's an existing universe of sloppy documents and web-pages. Abuse of structure for style purposes is far from the only sin out there!

All I'm suggesting is that we need to recognize that skipping heading levels IS a sin; admit it, get over it, and get on to dealing with it just like any other normative requirement.

Shouldn't the experience of a WCAG 2.0 conforming document include reliable navigation?

The Bottom Line

If one considers longer documents, there's a strong case to be made that taken together, the two applicable WCAG 2.0 Success Criteria do indeed prohibit the practice of skipping heading levels. If not, what is one to make of navigation as a Level A requirement if heavily compromised navigation is understood to be normatively acceptable?

Why should we consider documents accessible when we already know they will fail reasonable performance expectations when navigated with reliance on heading levels?

That's not the right message to give developers or end users.

What's an Implementer to do?

My conversations with implementers, policy makers and others indicate general acceptance that Case 1 represents best practice at minimum whereas Case 2 is to be avoided. Microsoft Word 2010's Accessibility Checker, for example, will show a "Tip" indicating that a heading level has been skipped - but it doesn't (yet) display an "Error".

In order to make a PDF/UA conforming document, the user will have to entirely resolve this sort of "Heading Level" warning.

If WCAG 2.0 is your only standard and if it's true that WCAG 2.0 allows heading levels to be skipped, a typical 500 page PDF with 1,000 headings spread over 6 heading levels may be absurdly challenging to navigate with AT and still comply with WCAG 2.0.

That's not acceptable, right?

What's the right response for a document that does include skipped headings? All you can do is warn the user that the document has poor and potentially arbitrary structure, and that they shouldn't rely on the heading levels for navigation. It's as simple as that.

How we got here

It's commonplace to blur structure and style. A common (but by no means universal) interface paradigm has trained many users to assume structure and style are synonymous, and they will argue their point.

Some make the case that it can be "editorially correct" to go from H2 to H4, that heading levels should describe the structure of the content, not determine it. To them I say: how does skipping from H2 to H4 (or whatever) "describe" anything? What does it mean to skip more than one level? Whatever you think a given skip means, how is that knowledge communicated to the reader who is depending on heading levels?

Once the door is (normatively) open to skipping headings, navigation becomes arbitrary - surely not a good outcome for an accessibility standard. Skipping headings detracts (by way of inconsistent results and lowered expectations) from the utility of heading levels in all cases, not just in poorly structured content.

Some say there's no practical solution to the problem, that authors won't stand for software that tries to teach them how to write or to structure their documents. I don't think it's been seriously tried. Since we already require properly designed data tables, alternative text for images, sensible links and so on, I don't see why requiring a valid navigable structure is any more onerous or any less necessary.

Since the beginning of the web AT users have learned to expect that trolling from heading to heading is the only way to know how content is sectioned on the page. Trained not to trust heading levels, their experience of longer and more sophisticated content is thus heavily compromised.

Commonplace authoring software encourages the misunderstanding that structure and style are the same thing. Better implementations help authors understand that while document structure and text style are related and may certainly be associated with each other, they are also fundamentally independent.

Use headings to organize the document. Use styles to set and change appearance via classes and in-line styles. It's not rocket-science.

What's the right thing to do, really?

To be considered reliably accessible, for users to actually believe in heading levels as opposed to merely headings, proper implementation of heading levels is required (a "shall statement" in ISO vernacular) in conforming PDF/UA files.

Skipping heading levels is simply not permitted.

Obviously, there's nothing to stop users from making a non-conforming document for any number of purposes, and getting a few heading levels wrong doesn't render the document completely un-navigable in many cases. However, if the objective is PDF/UA-conforming electronic documents, then correctly sequenced (and thus navigable) heading levels are required. Authoring software developers take note!

I speculate that this is normatively required in the HTML/CSS world too (or should be), but I could be wrong. I'm a PDF expert; I would not presume to dictate norms to HTML/CSS people, ahem.

Some implementors are clearly helping users conceive of and thereby manage style and structure information independently.

TinyMCE is a very common JavaScript-based WYSIWYG HTML editor for non-techie, mouse-based users (ie, most authors). This thing boasts side-by-side support for managing structure, style class and in-line styling. It works really well.

More software could be written to examine content and suggest automatic corrections and train the user towards thinking structurally. Most current-generation software punts on this opportunity at best.

Implementing Heading Level Tags in PDF

PDF itself provides (see ISO 32000-1 14.8.4.3.5) and conformance with PDF/UA requires (ISO 14289-1 7.4) either of two means for achieving structured document headings:

• <H#> Enumerated heading tags ("Weakly Structured"). PDF/UA requires that there be no skips in heading level when descending.
• <H> tags with or without enumeration but nested correctly in the tag tree. ("Strongly Structured"). See ISO 32000-1:2008, 14.8.4.3.5 (Usage Guidelines for Block-Level Structure).

Conclusions

There is, as we never get tired of pointing out to each other in the accessibility community, a lot of educational work to be done. There's also a lot of software to be improved to help authors understand that authoring for accessibility means attending to structure, a concept quite distinct from style. This won't be easy.

Perhaps the WAI can offer some sort of clarification that WCAG 2.0 holds well structured content as a norm, or does so when the use-case or relevant technology standard requires it. Effective navigation is too great a sacrificial offering to appease sloppy implementations and lazy authors.

It's not always easy to apply web content norms to the business use-cases typically powered by PDF technology, but WCAG 2.0 and PDF/UA are entirely complimentary. By requiring applicable technology-specific standards such as PDF/UA, accessibility standards organizations and regulators can specify the clearest path to accessibility for electronic documents.

Return to Logical Structures | Read Duff Johnson's Disclaimer