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:
- Use headings for both document and site structure.
- 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
toh3
, but going fromh4
toh2
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’sh1
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 ifh1
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 :-).
- Previous post: New accessibility overview on the W3C website
- Next post: WebKit Web Inspector improvements