So the weird and fascinating thing about this is just how murky things are when you look for correct / best-practice information on this topic. The reason seems to be that the various HTML specifications that have been released are unclear, ambiguous and contradict each other. It seems that everyone has a slightly different understanding or interpretation.

There isn’t much detailed reading material on the subject, but the best I came across can be found here.

There first interpretation is that the heading level indicates the level of importance, but nothing else. There is no implied document ‘tree’ or nested structure. Based on this approach it would be perfectly acceptable to have an H1 midway through the document.

The other interpretation is that headings imply a hierarchical document structure or tree. Therefore although they are technically siblings, and H2 following an H1 indicates a subsection of content within the main heading.

The latter is much cleaner and allows you to focus on providing a clear, organised, well-structured document. It is closest to the natural way you would author other types of document. Personally I find this a much better approach. There are some practical complications as I’ve mentioned recently – you should really have a descriptive H1 as the first thing you encounter in the page, but having worked around these issues the end result is quite pleasing.

In addition this interpretation matches with the XHTML 2 proposed changes that are under debate at the moment. In this model, the hierarchy is made explicit, with nested section elements, and a single h element is indicate a heading at any level. Personally I think have a big nested structure will overcomplicate matters, make it very easy for minor typos to build a drastically incorrect DOM structure, and generally open the doors for user agent bugs. I think bloated, deeply nested documents move too far away from how simple and easy to adopt HTML is, which is the reason for widespread publishing.

So I have to admit, if you were authoring 30 different documents, the first thing you would find in each would be a relevant title / main heading for the doc. In a similar way, if you’re consuming an XHTML document, it would be great if the very first piece of content was a very relevant level 1 heading.

This helps a couple of issues – firstly, search engines can give greater weight to what the page is actually all about. If the true page name / purpose is buried halfway through the doc as a level 2 heading among several others, there is no way to ascertain that it’s actually much more important (than Site Navigation, for example). The second is accessibility – rather than listening to the same chunk of guff at the beginning of every page, the very first thing a screenreader user will hear is a very descriptive heading, giving context to the content on the page. All good.

To have a good document structure, with sections, and subsections, it is necessary to have the root heading at the start of the document. It makes no sense to have an H2 before an H1 in the doc. Think about a tree structure as how the document is organised.

You end up with a great ‘un-styled’ document this way. The problem is when your visual design includes the page heading, and requires it to be mid-way through the document content. What can you do? You already have an H1 at the start of the doc, which means repeating yourself. Naturally you wouldn’t need the additional heading as you’ve already set the context.

This mostly comes about as it’s very unusual for it to be ok for the H1 at the very start of the document to be the first thing visually displayed on a page. Therefore, you put it in to give good document structure, but style it so it isn’t visible.

I’m not particularly happy with the best solution I’ve come up with, but it’s better than not using the H1 properly – if the design requires the title to visually appear midway down, we have to include it (again) in the document content. However it just seems wrong to have 2 headings on a page with the same text, therefore I’m using a paragraph.

This gives an overall structure like so…

• Lister’s All-time Favourite Movies
• Brand Information
• Site Navigation
• Main Content
• Specific page content (including a P re-iterating the page title, if the design requires it)
• Page Footer

I quite like having the heading ‘Main Content’ in the document structure, as it means you have a familiar, consistent place to go to for the page specific content. We can then provide a skip-to link directly under the H1.

If you can think of a better solution to this, please let me know (soon!). I’m currently changing every page in the site, and it’s a bitch.

As a quite aside on accessibility, this aids in a couple of ways that I know about directly (probably others I’m not aware of). I spent some time using Jaws a while back, and there were two main techniques I ended up using to try and navigate a document. One was the headings dialog – this brings up a list of the headings on the page, and reads each. You can then click to go directly to one of them. The other technique was hitting the ‘H’ key to skip between headings on a page. In a well structured document this made it extremely easy to skip over sections that weren’t of interest.

It’s a good idea to define each new section of your page with a heading, even if visually you don’t want to display it. Often when content is rendered, there are many visual cues that give you a good idea of what something is without an explicit heading. If you identify the headings added to aid document structure with a class name, you can style these to be hidden when the visual design is applied. Note that styling with display: none will mean that headings are also hidden to screenreaders. Instead, use absolute positioning to position the elements to the side of the visible page. These will still be treated as valid content to readers, but will effectively be hidden to everyone with CSS applied.

If you fail to identify a new section with a heading, it’s content will appear to sit in the section defined by the previous heading – think about a word document. If you have a section defined by a heading, and you start a new paragraph that isn’t related, it still appears to be within the same section.

To get a feel for how good a job you’ve done, briefly disable CSS (Ctrl-shift S in Firefox web developer toolbar). If the document makes sense without CSS applied and is simple to take in, chances are you’ve built a well-structured, accessible document.

After reading a recent post, I was thinking about Image Replacement techniques in CSS and to what degree you need to take this approach – specifically in response to a technique where you add an additional empty inline element, size it to width: 100% and height: 100%, then set the background image on this element. The thinking is that with CSS on and Images disabled, you still get the text.

That’s where I start to get edgy. CSS is about the visual presentation of content. I think it’s perfectly acceptable for a design to have dependencies on images applied via CSS to work well. Images applied via the CSS background-image are all about visual presentation of content. I can’t quite figure out who would surf now, want the visual presentation of content (i.e. CSS) but not want the images. I don’t think many people are constrained on bandwidth, and they always have the option of disabling CSS to get the raw content and nothing else.

I think attempting to get the hybrid, crippled version of a design to work well is flawed. People have the option to get just the raw content, or the content with a visual design applied. Asking for a visual design without images?? Then adding extra markup to cater for it?? Sorry, don’t get it.

I think most Jaws users develop different patterns and ways in which they use the tools, but I found by far the most frustrating thing was trying to get random access to a particular part of a page without listening to the whole document. When a page loads you visually take in a whole load of information and pointers about where to focus your attention depending on what you’re looking for. This is very difficult to do if you have to sequentially listen to each piece of content in turn.

One of the features I was using the most was hitting ‘h’ to cycle through the headings in the document (and also the headings dialog which lists the headings on the page). Pages that used proper heading markup were so much easier to navigate. You could then locate the section you’re looking for, then listen to the content.

Something I’ve started to do since then is ensure that I have a strong heading structure for my content regardless of what appears onscreen. For example, if there’s a list of navigation lists I’ll include a heading element of ‘Site Navigation’ whether or not this is included in the visual design. This improves the structure available to users cycling through the headings on your page. To find the navigation section, you can just hit ‘h’ repeatedly until the correct heading is reached.

One point to note is that depending on how the heading is hidden onscreen, Jaws may or may not be able to detect it. Using display:none is bad – Jaws will not pick it up. Using position:absolute; left: -5000px will mean that the heading is not visible onscreen but is still available to Jaws users. I don’t particularly like relying on this kind of arbritrary styling, but until there’s a decent way to style for aural consumption, it seems like a practical step that can be applied right now.

The purpose of publishing a specification like this is that everyone can arrive at a shared understanding of the measures that should be taken to ensure that web content is accessible. This makes it essential to produce a document which can be easily understood and applied by the web development community.

I would recommend reading Joe’s article for a thorough breakdown of the problems with the documents which have been made public so far. I think the fact that there is an accompanying document titled ‘Understanding WCAG 2′ is a statement in itself.

It looks like the new specification is far too cryptic to really be of benefit to anyone, and if developers cannot understand the measures they should be taking to ensure the integrity of the work they produce, then why bother publishing it?