A couple of days ago over Twitter I asked what people’s opinions were on the use of a website name as an H1 in pages and opinions on the use of multiple H1’s within a page. Without knowing it, the day before I tweeted this, a poll had been launched asking what do you use an H1 for? Like microformats versus accessibility and layout tables versus CSS , these types of debates tend to raise their heads every once and a while confirming that opinion is splintered.

Part of the reason why this debate doesn’t seem to be reconciled is because neither WCAG 1.0 or WCAG 2.0 explicitly say (either in the normative or supporting documentation as far as I can see but do double check) that using the site name as an H1 or multiple H1’s are not allowed. There’s probably good reason for this as there may well be edge cases where it makes sense but it does concern me when I see multiple H1’s on a page or the website name being used as an H1 on all pages in the website. To me it’s always been clear that the main heading of a page should be the H1 and not the website name and multiple H1’s should be rarely, if ever, be used. I’m not setting out to answer these two questions but thought them worth airing again to see if our collective thinking has moved on and if there is anything that can be learnt from it.

What’s all the fuss about?

So what’s the issue here, why do we need headings? Structure of a web page is needed for software such as screen readers to parse information so that users can both understand where they are in a page and also navigate between headings (h1 to h6). If you’re blind, for example, there are certain key strokes in screen readers that allow you to list the heading structure in a web page (a bit like a contents list) that you can in turn use to jump to where you want to go in the page. If no headings have been coded then all you are left with is text, images and form element information that is not neatly grouped in a way that’s understandable. It’s a bit like reading a newspaper with no visual headings – you’re left guessing where one section starts and another ends.

The image above shows a dialogue box listing headings in a page using the screen reader Jaws. A simple keystroke when on the page will pull up the dialogue box that the user can listen to and decide what heading level they want to navigate to.

Using the website name as an H1

The fact that the heading structure acts as a contents list of a page is a bit of a clue here. A page needs to be as logical and navigable as possible in order for the end user to access information and comfortably find what they want. As such I’d argue that, a page should only have one H1 and that it should be the heading of the page itself and not the website heading. The website name should be contained within the page TITLE in the HEAD of the document and of course can be reiterated in the logo or any other branding that exists on the page. You’ll no doubt have already spotted that under the hood of this site the template sets the site name as the H1 within all pages.

H1 coded around the site name and H2 around posts

This is a WordPress template and not my design (an HTML5 and WCAG 2.0 redesign is planned) however there are some interesting things to note here. On the home page of this blog, having the site name coded as H1 and post headings (with H3’s within them) coded as H2 make sense as the page structure flows logically. However when you move through the site to the About page, for example, this logic doesn’t follow through. Having the site name as an H1 doesn’t make sense as the natural H1 of the page is “About”.

So there is wriggle room it seems and possible edge cases for when the site name can be used as H1, such as on the home page, but in general however, I’d advise against this.

The SEO camp, often hit back with “But we want to have the site name as H1 so we can improve on our web page rankings”. I’m no expert on the inner workings of search engines but I’d argue that using the site name on each page as the H1 could in fact be damaging to SEO. As Andy Ronksley says, given the site name is already referenced in the TITLE the biggest boost you can do for for your rankings is use the  H1 to reflect the individual page and as such get the page indexed more accurately.

Using multiple H1’s within a page

I said above that there is “rarely” a use for multiple H1’s within a page. Generally speaking the page makes logical sense (to me at least but admittedly I only use screen readers to test pages) when it degrades gracefully from the site name in the page TITLE to the page name as the H1 and subsequent sections as H2 after that. As Jared Smith points out, if you use multiple H1’s when the user expects only one H1 there is a danger of missing subsequent content under the next H1 entirely.

Blah

With that in mind I have seen uses of multiple H1’s in pages where frames have been used to bundle related content. A supermarket website may want to have information about the aisle you are in, your basket, promotions and navigation all collected separately within a FRAME (an old school example but stick with me). If each of these FRAMES has a lot of content organised into it’s own hierarchy then it makes sense to perhaps use an H1 for each.

HTML5 and headings

While the H1 debate rumbles on there are interesting changes afoot in HTML 5 that could, in time, contribute to resolve the H1 debate. The draft new specification sets out to define areas of web pages with the introduction of new elements: <head>, <nav>, <article>, <section>, <aside> and <footer>.

Image courtesy of A List Apart - An introduction to HTML 5 by Lachlan Hunt

Image courtesy of A List Apart - An introduction to HTML 5 by Lachlan Hunt

Using HTML5, each element can have it’s own H1 and in turn, the hierarchy and nesting of each sectioning element determines the heading level of each H1. Looking at the example above, an H1 within the <article> will rank higher than the H1 in the <section> contained within it. This is not an entirely new concept as XHTML2 uses the <h> within sections however <h1> is see as equivalent as <h> in HTML5. These changes in HTML5 wont mean that heading levels as we know it (H1 to H6) become defunct, if that were the case all legacy content would simply fall apart after all. Instead, according to the current working draft of  HTML5, it is designed to be backwards compatible so that H1 to H6 are still supported.

Sections may contain headers of any rank, but authors are strongly encouraged to either use only h1 elements, or to use elements of the appropriate rank for the section’s nesting level.

A large benefit of using H1 for all first headings in sections in HTML5 is that it allows web pages to include content from other sources that already have a heading level defined. So for example blog posts can be listed in say a page listing all posts in one category or on the home page and the heading levels neatly realign themselves dependent on the hierarchy of sections in whatever page they are in.

This offers great benefits to developers and screen reader users alike. For developers it removes the headache of working out a heading structure (which can be complex and tricky at the best of times on large sites) and also saves on the headache of having to rethink structure if content is pulled in from elsewhere. For a screen reader user there is a stronger likelihood that a logical and useful heading structure is given.

However this is all theoretical on my part as support for HTML5 is only just starting out. Browsers are already building in support for HTML5 with Opera leading the pack however screen readers are trailing behind and are not participating in the W3C HTML5 Working Group. This should not prevent you, the page author from discounting implementing HTML5 (although for commercial projects I’d hold off for a bit). As the W3C Web Accessibility Initiative clearly outlines in it’s essential components of accessibility the user agents, authoring tool and web authors all play a part in accessible content each with their own responsibility.

One possible downside I can see is that search engines may not be able to index pages that have multiple H1’s. It’s not really possible to say at this stage but presumably search engines will instead work with the new section elements and their ordering within the page when ranking web pages.

I’m only just starting to find my way with HTML5 so may well have oversimplified the issues here. My colleague, Bruce Lawson has some excellent posts on his newly redesigned site using HTML5. In particular read about how headings and sections work together in HTML5, headings and accessibility. I’ll also be following up this post with looking into accessibility issues around HTML 5 and screen reader support as things evolve.

To wrap up

Navigating web pages using headings is essential to screen readers as WebAim’s recently published screen reader survey showed. What’s interesting to see is that while HTML5 may have serious flaws with regards to accessibility in other areas it may be working to support accessible content in others. What is essential to its success however is that  screen reader vendors step up and work to include support for HTML5 to complement efforts being made by browsers as well as the web development community. Hopefully then we may see an end to the groundhog day debate about H1’s (although I suspect another can of worms will be opened).