Headings and document structure conclusions

Back in January I asked for opinions on Headings, heading hierarchy, and document outlines, hoping for a discussion that could lead to a conclusive recommendation.

Unfortunately it seems very difficult to reach consensus on this topic. However, with input from the discussion in the comments on that post, along with private discussions via email and face-to-face, I see two options:

  1. Use headings for both document and site structure.
  2. Use headings only for the structure of the actual content, and use WAI-ARIA landmark roles for anything outside the content area.

Let me try to explain my reasoning.

Use headings for both document and site structure

  • Use headings for anything that looks or “feels” like a heading.
  • Use headings to identify what WCAG 2.0 calls “sections of content”, i.e. headings in the main content area, different navigational sections, etc.
  • Use only one h1 heading per document, and use it for the document’s main heading, not the site name or company logo.
  • If a document needs a heading before the main heading in the source order, for instance to identify navigational sections, start with an h2 heading.
  • Do not skip any heading levels going downwards, i.e. do not go from h1 to h3, but going from h4 to h2 is fine if the document structure needs it.

The reasons are as follows:

  • WCAG 2.0 Success Criterion 2.4.1 Bypass Blocks is Level A and requires that A mechanism is available to bypass blocks of content that are repeated on multiple Web pages.

    A sufficient technique for this SC (Success Criterion) is H69: Providing heading elements at the beginning of each section of content. One of the uses for headings that are mentioned in H69 is to demarcate different navigational sections like top or main navigation, left or secondary navigation and footer navigation.

  • WCAG 2.0 SC 1.3.1 Info and Relationships is Level A and requires that Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.

    A sufficient technique for this SC is H42: Using h1-h6 to identify headings, which has an example of an h2 heading preceeding the document’s h1 heading.

  • WCAG 2.0 2.4.10 Section Headings is Level AAA and requires that Section headings are used to organize the content.

    A sufficient technique for this SC is G141: Organizing a page using headings, which states that To facilitate navigation and understanding of overall document structure, authors should use headings that are properly nested.

  • Some people who use headings to navigate do not expect more than one h1 heading and may miss a document’s main heading if h1 is used for the site name.
  • The site name logically belongs in the title element.
  • Using only one h1 per page, and using it for the main heading, is probably better liked by search engines (though this may be hard to prove for anyone who doesn’t work at Google).

Use headings only for document structure and WAI-ARIA for other sections

The other option is to use h1-h6 headings only within the actual content of a document, and use WAI-ARIA Document Structure and Landmark roles to demarcate different navigational sections like top or main navigation, left or secondary navigation and footer navigation.

This has the advantage of focusing the heading structure on the content itself. A few possible issues:

  • ARIA is not fully supported by browsers and AT yet (though it is being implemented as we speak)
  • Will users know how to use WAI-ARIA roles to navigate?
  • How obviously are WAI-ARIA roles exposed in various user agents?

Still no single, perfect solution

There appears to be no single perfect solution that will end all discussion regarding headings and document outlines, but the two options I describe here make the most sense to me. My personal preference is to use headings for both document and site structure, but that is subject to change.

And, as with any problem that has more than one possible solution, I don’t expect everybody to agree :-).

Posted on November 10, 2009 in Accessibility, (X)HTML