Headingology; using HTML headings

Scope

When a heading is used in a document it establishes a section, the scope of this section may not be obvious since the heading element doesn't encapsulate the content like for example a div element would. The section started by a heading ends at the start of another heading of the same or higher importance that follows it, so the section established by an h2 ends at the first h2 or h1 that follows it, or when the document ends (whichever comes first).

Conveying section structure

For users it is often helpful to be aware of a document's section structure, authors should always be aware of the document hierarchy.

   <h2>Section heading</h2>
   <p>Section content.</p>
      <h3>Section heading</h3>
      <p>Section content.</p>
         <h4>Section heading</h4>
         <p>Section content.</p>
   <h2>Section heading</h2>
   <p>Section content.</p>

   <div class="section">
      <h2>Section heading</h2>
      <p>Section content.</p>
      <div class="section">
         <h3>Section heading</h3>
         <p>Section content.</p>
         <div class="section">
            <h4>Section heading</h4>
            <p>Section content.</p>
         </div>
      </div>
   </div>
   <div class="section">
      <h2>Section heading</h2>
      <p>Section content.</p>
   </div>

Consecution

The general opinion in the authoring community seems to be that heading levels should be consecutive. This means for example that "child" heading(s) to an <h2> should be <h3>(s), not "skip" one or more levels. I support this practice because it appeals to the orderly side of my character, but I am not aware of solid arguments as to why.

An automatic TOC generator may display a less orderly node tree (depending on the generator used). In some cases skipping heading levels may even cause a utility to choke such as in the case of the A Dynamic Table of Contents Script example. But it seems fair to say that such should be labelled as a flaw of this particular script.

A W3C note says this about the issue:

But it isn't backed up with argumentation. Earlier in the paragraph we find this:

But it is unclear if that is meant as an argument to the rule stated later, and regardless, I'm not aware of an AT UA in which heading levels being skipped causes a problem.

One argument used in favour of skipping heading levels is that sometimes using a heading that defaults to a larger font size like an <h2> "looks wrong" in certain places (especially when viewed sans CSS) and incorrectly represents the structure. A common counter argument to this point of view is that the font size should then be reduced using CSS for such headings. IMO this isn't a valid argument, a document should look structurally sound without CSS, if something "looks wrong" sans CSS, it is usually because it is wrong. The fact that there can be situations where certain headings "look wrong" is IMO caused by headings being used presentationally (more on that in the Pseudo headings section), or it is the result of using headings to mark up page foreign content (discussed next).

Usability problems

Foreign content is often repeated on every page of a site, this creates various usability problems.

Footers

Footers can be inadvertently placed in a section, consider the following content and code:

<h1>Widget Inc.</h1>
<p>World leading Widget manufacturer.</p>
<div class="section">
   <h2>Products</h2>
   <p>We make great Widgets.</p>
</div>
<div class="section">
   <h2>Contact</h2>
   <p>Phone us on 12345</p>
</div>
<p id="footer">© 2007 Widget Inc.</p>

In this example the likely intention is that the copyright footer should apply to the whole document, but as per the rules set out in Section - Scope, the footer is actually part of the "Contact" section. Visually it may appear outside of that section if section styling is used due to the fact that the footer has been placed outside of the wrapper div, but this has no effect on the actual sectioning.

Some authors use an <hr> element in an attempt to make clear that the main structure has ended. They seem to have assigned mythical qualities to the bizarre <hr> element in the illusion that it has structural significance. The reality is that a <hr> is 100% presentational, it has no structural significance and it has no effect on sectioning.

Within the HTML 4 vocabulary the only way to solve this problem is to place the copyright footer in its own section.

<h1>Widget Inc.</h1>
<p>World leading Widget manufacturer.</p>
<div class="section">
   <h2>Products</h2>
   <p>We make great Widgets.</p>
</div>
<div class="section">
   <h2>Contact</h2>
   <p>Phone us on 12345</p>
</div>
<div id="footer">
   <h2>Copyright</h2>
   <p>© 2007 Widget Inc.</p>
</div>

If desired the footer heading can be positioned off screen with CSS.

Native content first

The practice of placing page foreign content after the page native content in the document source is also affected by the Pringles dilemma. The arguments used in favour of placing native content first in the document source include:

• Search engines favour content found nearer to the beginning of a document, resulting in more relevant indexing and a higher place on the result pages
• Speaking browsers start by reading out the page native content instead of the page foreign content

Assuming that this technique has been used and the order in the document source is: page native content, promo panel and navbar, as with the Footer example, if the navbar and the promo panel aren't denoted by their own heading they will be incorrectly sectioned under the last heading from the page native content section.

Since neither the navbar nor the promo panel content pertain to the principle subject of the page denoted by the <h1> content above the page native content section, <h1>s should be used to denote the navbar and a promo panel. As with the Footer example, these headings can be positioned off screen by using CSS.

This is controversial as many believe that a document should only contain one <h1>, and this makes perfect sense for non compound documents. But compound documents offer significant benefits, if the puritanical ideal of not including page foreign content isn't an option, then authors need to compromise given the limited options that HTML 4 offers.

The choices are: also use <h1>s to denote things like a navbar and a promo panel, or make sure that a navbar and promo panel precede the first heading in the document source, and then add "Skip to ..." links.

Each method has it's own pros and cons. On a practical level it should be considered that using <h1>s to denote page foreign content may have an effect on search engine indexing, although it is hard to predict what that effect might be. Placing a navbar and/or promo panel content before the page native content in the source will also prevent the false sectioning, but it replaces it with another problem: un-sectioned content that deprives users of navigating the document structure via the document headings.

Users of AT UAs in particular are thought to use and appreciate heading navigation (see User behaviour research). The Heading navigation support in AT UAs found in certain popular clients allows users to directly navigate from one <h1> to the next <h1> regardless of any headings of lower importance in between the two. A plus point of using <h1>s to denote page foreign content is that the ability to skip or navigate to a navbar or promo panel section with the heading navigation method AT users already use to navigate page native content sections can be considered as a significant advantage.

*$£!%* HTML 4

Instead of blaming HTML 4 for its inadequacies that require us authors to use these less than ideal solutions for compound documents, why not read the HTML 5 proposals and get involved if you are able to, and help create something better for the future.

Heading or Pseudo heading

Based on the previous example I advocate that authors should use headings in a way that will result in a document outline likely to be useful as a Table of Contents and navigation tool, and consider using "pseudo headings" as illustrated by the previous example for situations where something merely needs to be structurally separated from adjacent content.

Site branding

It is common to use site branding where an image displaying the company or site name is displayed site wide. Doing so should create a sense of consistency and familiarity for users as they navigate across a site. Such an image of text should typically be marked up as the <h1> content on the site's home page with an appropriate real text alternative.

On pages other than the home page the same image is essentially decorative and should be coded as such. The <h1> content on for example the "About" page on such a site should be "About". Authors who wish to make such an image on sub pages link to the home page can still do so (although I do not support this convention myself).

Using the <img> element to embed the image like for example <h1><img src="widget_inc.png" alt="Widget Inc."></h1> can create a problem because search engines (wrongly) may not index the alt content. The so called "image replacement" techniques solve this problem and this could partially explain their popularity, but these image replacement techniques all introduce additional problems. There is a technique available that does not introduce additional problems. Instead of using the <img> element it uses the <object> element to embed the image. The text fall back for the image is coded as the element's content instead of attribute content, so the text will be indexed by SEs.

Alas Microsoft (MS) Internet Explorer (IE) 6 & 7 do not render images embedded with <object> properly.

This can be solved by serving IE an <img> construct instead with the help of Conditional Comments (CCs). The so called "downlevel-revealed" CC required for this as documented by MS does not validate, but this can be solved by modifying the MS code as has been done in the example that follows. Using CCs and two different elements results in slightly more verbose code, but this shouldn't significantly increase development or maintenance effort as it would only be used once on the home page.

Code example (width and height info omitted for brevity)

<h1>
   <!--[if !IE]>--><object type="image/png" data="widget_inc.png">Widget Inc.</object><!--<![endif]-->
   <!--[if IE]><img src="widget_inc.png" alt="Widget Inc."><![endif]-->
</h1>

A working demonstration that combines all the principles and techniques described: Widget Inc. Test both the home page and one of the "product" pages in turn with: CSS disabled & images enabled, CSS enabled & images disabled and CSS & images disabled (using a browser that supports this). The CSS used is placed in the HTML document's head for ease of viewing.

Promotional text

Widget Inc.
World leading Widget manufacturer

"World leading Widget manufacturer" would typically be referred to as a "subheading" in the print domain, and I don't see much wrong with that. But in HTML the phrase "subheading" means something else; "a heading that establishes a subsection". It is obvious that the "World leading Widget manufacturer" doesn't establish a sub-section, it is merely promotional sub-text. But the above effect is commonly coded as:

<h1>Widget Inc.</h1> 
<h2>World leading Widget manufacturer</h2>

This is incorrect and should be replaced by the following:

<h1>Widget Inc.</h1> 
<p>World leading Widget manufacturer.</p>

Presentational

Headingology,
using HTML headings

Using the title of this article, "Headingology" is a made up word that is paradoxically both very useful for SE indexing (it wasn't listed by Google when I searched for it), and at the same time useless because unless the phrase is used to refer to this article it is unlikely to feature in the search result for someone looking for opinions on HTML heading usage, so I added "using HTML headings". I wanted to display "using HTML headings" in a smaller font, so I decided on the following coding:

<h1>Headingology, <small style="display:block;font-size:50%">using HTML headings</small></h1> 

No content between headings

<h1>Codewallop</h1> 
<h2>Good practice</h2>
<ul>
   <li>HTML Titles</li>
   <li>HTML Headings</li>
</ul>
<h2>Points of view</h2>
<ul>
   <li>css Zen Garden, The Road to Misconception</li>
   <li>The flaws of WAI 2</li>
</ul>

I don't have an argument to suggest that the previous example is wrong, subjectively I prefer inserting a paragraph in between. Using the guidelines from the HTML Headings - Grammar section, headings should be as short and concise as possible, perhaps it is due to the resulting desire to expand on the heading that I'm partial to at least inserting a short paragraph, an example:

<h1>Codewallop</h1> 
<p>Striking a blow for quality web code.</p>
<h2>Good practice</h2>
<ul>
   <li>HTML Titles</li>
   <li>HTML Headings</li>
</ul>
<h2>Points of view</h2>
<ul>
   <li>css Zen Garden, The Road to Misconception</li>
   <li>The flaws of WAI 2</li>
</ul>

Single subsection

This is another scenario that I view with some suspicion:

<h1>Codewallop</h1> 
<p>Striking a blow for quality web code.</p>
<h2>Good practice</h2>
<ul>
   <li>HTML Titles</li>
   <li>HTML Headings</li>
</ul>

The <h2> in the previous example is used to create a single subsection, this doesn't strike me as sensible. If subsectioning is to be used shouldn't there at least be two subsections? I'd be inclined to use a Pseudo heading instead of the <h2> in the previous scenario.

Related documents

• [1] Usage frequency of different (X)HTML elements

  A crawl of over 1 million web pages reveals how underused HTML heading elements are.

• [2] Hilltop: A Search Engine based on Expert Documents

  Description of a search engine mechanism that recognizes the scope established by headings.

• Effective use of headers HOWTO (English)

  A good write up on heading usage for content authors and editors who use a WIKI.

Tools

• Firefox Document Map add-on by James Graham
• Javascript TOC builder by RobG
• The W3C QA Markup Validation Service offers an option to show the document outline if you use one of the extended interfaces

Heading navigation support in AT UAs

The following links to AT UA manuals suggest that they support heading navigation per level.

• JAWS Keystrokes
• Window-Eyes 6.0 Manual
• Fire Vox Reading Text and Navigating Web Pages tutorial

Other AT UAs.

• UK HAL Manual (zipped MSWord format)

  As far as I can tell from the HAL manual, it lists headings and moves between them, but does not distinguish levels.

• Thunder Hotkeys Manual (MSWord format)

  Thunder doesn't seem to skip or list headings.

• VoiceOver Manual

  It's not clear from the VoiceOver manual whether headings form part of its HTML grouping algorithm.

AFAIK neither Orca nor NVDA lists headings yet, but they're both still in early development.

User behaviour research

A 2003 study of 16 blind users found that most tried to scan the page in various ways, but while a few used the headings features many were unaware they existed.

• Observing Users Who Work With Screen Readers
• Observing Users Who Listen to Web Sites

(Both these links write up the same study, but somewhat differently.)

A 2005 study of 8 screen reader users found that all participants said headings for different levels of navigation were very useful: Page Source Order & Accessibility

Peter Krantz studied screen reader users in 2005 and reported that the list of headings was one of the most used features of JAWS: Browsing habits of screen reader users

Techniques

Links to pages on some of the coding techniques used in the demos.

• About Conditional Comments (Microsoft)
• IE block level element inline-block hack
• SE friendly graphic header