Headings can be tricky to implement so I thought I’d pull together some quick tips on accessible headings. This isn’t a full explanation but rather a checklist to look at when you are building or testing web pages.
First a quick explanation. Heading mark up, H1 to H6, is wrapped around headings in a page to give the page structure. When headings are coded correctly voice input users, screen reader, refreshable braille display and some browser (Opera) users benefit by being able to use voice and keyboard commands to navigate between headings. This makes pages more scanable and less restrictive for users as they don’t have to navigate content linearly, which can be very time consuming. Some search engines also use headings to index pages.
So without further ado here are our top tips:
- All visual headings in web pages must have a heading structure applied using H1 to H6.
- Headings must be used to describe a page’s structure and not used for visual effects.
- Pages should only have one main heading, H1, which is the main title of the page and should be positioned at the start of unique page content.
- Headings are like a contents overview of a page. Sub headings of the H1 must be coded as H2 and subheadings of an H2 must be coded as H3.
- Heading levels can’t be skipped i.e. you can’t jump from H1 to H3.
- Headings should not be coded around content that is by itself, they should always be followed by associated content.
- Headings should not be coded around form labels i.e. the text label “Search” that comes before an input field.
- Heading structure should be consistent throughout the site.
- Add in headings to break up large chunks of text.
- Keep headings short and succinct and therefore easy to scan and understand.
You can test all the above by looking at the heading structure on this page. If you have the Web Accessibility Toolbar installed select Structure then Headings or Heading structure. Alternatively you can go to View, then Source and do a search for H1, H2 and so on.
For a really clear demo of how screen readers intereact with headings and allow users to navigate check out this video on the Importance of HTML headings for accessibility (8 mins and 41 seconds)
Got a tip you want to share? Then leave us a comment.
Martin Kliehm | 04/07/2008 at 11:05 | Permalink
Thanks Henny for sharing that. But how do you handle when the h1 is not the first headline in a document?
Usually there’s the header with a navigation before the content, sometimes a breadcrumb path. Some people like to add hidden headlines for those, but then you have h2 h2 h1…
Or in other cases there’s no real h1 on a home page. There’s a logo and a bunch of equally important boxes / applications, so we ended up embedding the logo in a h1.
What do you/em> recommend in those cases?
smitty | 04/07/2008 at 13:54 | Permalink
Th’at’s a cool article. We usually don’t think enough about titles and headers. My practice to handle accessible headers:
- With a flash header: give your #page element a padding or margin-top. Include your flash at the bottom of the page (after the usual footer links), then place it with an absolute position on top, with a higher z-index. Place your h1 at the first place of the page, then give it following CSS: “height:0; padding:my_padding_top; background:my_flash_animation_rendered_in_gif; z-index: lower_value;”. It works perfectly.
- Without a flash header, do it the same way: you place your banner in the background of the h1 element and hide the h1’s text with the CSS. And hop: you have a h1, an image, and it’s accessible.
Excuse my bad english ;)
Jim | 04/07/2008 at 16:13 | Permalink
I was really confused when you said:
> Headings should not be coded around content that is by itself, they should always be followed by associated content.
I had to re-read it a few times to figure out what it meant. “Coded around” isn’t exactly normal lingo, I first assumed it meant “coded in the vicinity of”, but that didn’t make sense because you can’t code in the vicinity of something that is by itself, it wouldn’t be by itself then, would it?
You mean “around” in the sense that and are “around” the element’s contents, right? Those are the tags, not the heading. The heading isn’t “around” the content, or anything else for that matter. The content and the tags together *are* the heading. A reasonable way of wording it would be to say something like:
> Headings should not be on their own, they should always be followed by associated content.
Two other things:
There is absolutely no indication on this form of what input it accepts. Do I have to escape the less-than signs above? Do I have to add paragraph tags? There’s not the slightest hint.
Why is a random “Why PDFs suck!” link below this comment box?
naud | 05/07/2008 at 10:44 | Permalink
hi,
good article.
Though I don’t agree with you when you say :
“Pages should only have one main heading, H1, which is the main title of the page and should be positioned at the start of unique page content.”
The HTML specifications never say that. They only say that a heading should be used to entitle a section of a page.
That means that you should always put the title in the…TITLE tag, not the h1.
It also means that you can have many h1 tags in your page.Screen reders (Jaws…) deal with it whithout any problem.
JF NAUD
Jim | 06/07/2008 at 22:00 | Permalink
I submitted two comments here the other day.
The first was mangled because apparently this comment box expects quasi-HTML, where it isn’t plain text because you have to escape less-than signs, and it isn’t HTML, because whitespace is preserved between paragraphs.
The second noted that the first was mangled and corrected the escaping. Sadly, the moderator for this page deleted the second one and approved the mangled first one. Is it too much to ask that the person in charge of approving these comments actually reads them before deleting them?
For the record, when I said:
> You mean “around” in the sense that and are “around” the element’s contents, right?
I actually meant:
> You mean “around” in the sense that <h1> and </h1> are “around” the element’s contents, right?
Henny | 07/07/2008 at 19:40 | Permalink
Hi Folks,
Many thanks for your comments; questions raised have flagged some interesting points about the nitty gritty of applying headings which is great. So without further ado I’ll address these chronologically:
@Martin Kliehm, Yes, the placement of an H1 in the code and hidden headings for navigation can be a tricky one and often needs to be thought about on a case by case basis. With regards to having the H1 appearing first in the code you could consider, where feasible, moving things around in the underlying HTML code so that the H1 heading comes first. Then you can use CSS to position things the way you want them visually. This will also solve the problem of having hidden headings for navigation coming before the H1 in the overall structure. Have a look at this page for example. Visually you see content in a traditional layout with the main navigation at the top, section navigation at the left-hand side and main body of content to the right of the section navigation and under the main navigation. In the underlying code however the H1 in the main content follows immediately after the two “Skip links” and all other content then follows sequentially. The result is a logical underlying structure for those who rely on it while it makes visual sense for those who rely on layout and positioning to understand content.
You’ll notice that we also have headings for section navigation (visible rather than hidden). Again if you check the underlying code you’ll see that they are coded as H2 but are clearly separate from the main content and so can’t be mistaken for subtopics of the main content’s H2 or H3 (if there were any H3’s in the main content on this page) headers.
Your point about home pages is also a very good one. A home page often has a unique layout to the rest of the site making “traditional” rules hard to apply. It’s not always obvious what the main heading is so frequently the site logo is wrapped up in a heading. On the home page and only the home page, it’s acceptable to code a logo as H1, this is semantically logical, as the home page is about the whole site. But we would not encourage it throughout the site as a logo has nothing to do with the structure of a page. Ideally, though, a natural H1 should be added to the start of the main part of the page and coded as H1 even if it’s then hidden using CSS absolute negative positioning. This lets screen reader users know when they’ve reached the readable part of the page.
@smitty, thanks for sharing this. Using CSS to place Flash at the foot of the page and making use of a hidden H1 is one solution as long as it is truly accessible.
@Jim, I can see how point 6 “Headings should not be coded around content” may have been a bit misleading. As you’ve identified this refers to is the practice of coding a piece of text as a heading when it is not followed by any content that relates to it. This might have been done to give a piece of text visual emphasis or the text is a heading but no content has been added under it yet. But until it heads up some subordinate content, it isn’t a heading. So saying “headings should not be coded on their own” is exactly right.
Apologies for your comment being mangled. We have had problems and are continually fixing what we unearth on an ongoing basis. I think adding some instruction beside the comment box as to how to input text is a good one so it’s now on the list of things to do so watch this space, thank you :-). Our Web Team is also looking into the escape issue when submitting comments (we have no control over the blog).
Finally there is a link to “Why PDFs suck at the foot of the page because it refers to the previous post. We have this feature added at the foot of all pages so people can browse chronologically if they want to.
@naud, you are correct in that WCAG does not state, one way or another, how many H1’s are on the page and this is a debate that is still out for discussion. At RNIB we don’t encourage the use of multiple H1’s, as our experience of working with screen reader users is that multiple H1’s can be confusing and misleading. Headings are often the only feedback screen reader users have to let them know how a page is structured. They can’t see how many columns there are, how wide the margins are, what colours are used or what size the text is. Imagine a page with no visual structure at all, a solid block of edge-to-edge text. How would visual users know where the meat of the page starts?
Visually users have positioning, column widths, white space, text size and colour and background shading to guide their eye to help them recognise where the unique page content starts. If there’s more than one H1 heading it’s not clear to a screen reader user where the content starts sequentially, especially if the headings are not sequential in the code (see my response to Martin’s comments).
In addition screen reader users with conditions like autism may find it impossible to overcome the illogicality of having more than one top level heading.
It’s worth noting that W3C only use one H1 in their web pages. I’d also say that if you had a page that had multiple H1’s then you may need to review your content and perhaps think about breaking it out into multiple pages.
HTML 5 has a proposed set of new elements that will address this issue to some extent. The specification is proposing adding header, nav, section, article, aside and footer elements which will introduce a whole new way of structure web pages. See A Preview of HTML 5 on A List Apart by Lachlan Hunt for more details.
Overall I would say that as with all of the guidelines they are just guidelines and need to be applied pragmatically with the end user in mind. It seems to me that it would be worth expanding some of the discussion here and the original “Tips post” into a longer post if that would help.