Accessibility for content providers - headings
Let’s start with a spot the difference competition. Here are two web pages - version 1 and version 2 - that display the same content with the same look & feel. There isn’t an awful lot on the page to go wrong, but one would fail the Double-A accessbility criteria.
It’s that easy to create content that would fail the accessibility requirements!
What’s the problem? Well, even though the pages look the same the heading at the top is marked up in the underlying code in different ways. In the first (correct) version there is a heading level 1 tag (with an h1 tag) whilst in the second (incorrect) version the same text is just marked up as a paragraph (with a p tag).
They might look the same in your browser but if you were presented only with the HTML code then it’s a lot harder to work out where the headings and subheadings might be on a page. That can be important for someone using a screenreader where it will take much longer to take them through the content on a page - sighted readers can scan the screen to look for visual styles that imply something is a heading. (Although as well as helping with accessibility this can also be used by a search engine to work out what are the important bits of content on your page and help in its mysterious assessment of what results are most relevant.)
In the Web Content Accessibility Guidelines (WCAG) this is covered under checkpoint 3.5:
Use header elements to convey document structure and use them according to specification.
It’s a priority 2 checkpoint, so if you’re just having to conform to A rather than Double-A accessibility you don’t necessarily need to worry about it.
There are two main parts to satisfying the criteria.
The first part is to make sure that you mark-up headings properly (rather than styling them to look the same) and not to mark-up something as a heading that only requires that styling.
Quite often we’ve found when asking clients why they didn’t use the heading mark-up we’ve found that it’s because they don’t like the styling that it uses. If this is the situation that you find yourself in then the first thing to do is to decide what heading styles you require. You can then work through them with your web developers to see how they can be added to your site. There are a number of options open - the styling could be changed automatically for you depending on which section of the site the content will appear in or where on the page; the styling options might be added in a drop down menu in the editor; you might need to go into the HTML source for the content and make the change that way; or you can’t justify the cost/time involved so the styling is dropped.
The second part is that there are 6 levels of heading available on a web page (H1 - H6) and these should be used in the right way. The main heading for the page should use H1. Now there’s a whole debate about what is or isn’t a main heading, should headings in a sidebar be H2 or lower, etc. This won’t be an issue for you as someone else will have already made this decision and you just need to follow through accordingly.
The starting point is the heading level that has been designated for the title of your content - your web developers will be able to tell you what that is. Failing that you should look at the source code for a similar page in your web browser (usually by going to the View menu & selecting Source) and searching for the content title. The title might appear a number of times in the source so you’re looking for the one immediately above the content.
Once you have found out what level is being used for the title of your content you then know that any subheading below that that you create will be the next level down. So in this blog we’ve used H1 as the title for the content, so any subheading will be H2 (& a sub-subheading will be H3, etc.).
Intriguingly as I’m writing this in WordPress there’s no option to create headings from within the rich text editor toolbar by default. However I know that they’re using TinyMCE to provide this functionality and it’s available there, so unfortunately someone at WordPress has decided to take it out.
So what should you do if you find yourself in the same circumstance? Firstly you should make loud noises to your developers (hmm yes, it is on my list of things to do with this blog) as it’s highly likely that the option has been hidden. You and other content providers need to have the tools available to maintain the accessibility of your site. Secondly, in the interim period, I’m afraid you’ve got to get your hands dirty and change the underlying code yourself. It’s probably best to get your IT support to help you with that, as the exact sequence will vary from editor to editor. It’s not difficult though, it just takes you into areas that you probably don’t want to go regularly.
Summary
- Think about the structure of the content that you’re creating rather than the text style that you want to achieve
- Use the heading mark-up on heading text - don’t just make it bold and a bigger size
- Don’t use headings to implement a style for the sake of it - if it’s text that you want to emphasise then this is the time to hit the bold (& any other) button
- The heading levels should go in order, so the next level of headings after H2 should always be H3, etc.
- You may need to go to your web developers to make sure that you have the visual styles for headings
- If headings (or the right styles) aren’t available in your editor then you might need to get into the HTML source to mark them up appropriately - not a long term solution
November 16th, 2006 at 2:06 pm
Thanks for this series, Nigel.
One sentence stood out for me: “You and other content providers need to have the tools available to maintain the accessibility of your site.”
This is hard to swallow, but a fact of web editor life circa 2006. Ten years ago I got my “hands dirty” coding up web pages by hand (as you well know). Then along came the Content Mangagement System, which (in theory) permitted me and others to concentrate on creating the content - the stuff of value ;-)
The implication was - and I think this is how they are still sold - that the CMS would do the job of spewing out the appropriate (accessible) code.
Now it seems the wheels have turned back a notch or two. A web editor ought to understand some of this stuff.
That’s where you come in :)
November 16th, 2006 at 9:59 pm
Yes there probably is some overselling of the capabilities of a CMS - whether it’s a simple blogging package through to an enterprise-wide system. But I think in part it is also the need for content providers to come to terms with the shift from paper-based media into the digital world. It’s part of the maturing Internet.
When you see something in print it doesn’t really matter how you’ve managed to achieve the styling, but with web content it does matter. And it’s not just for accessibility reasons as the content could be reused in many different contexts (e.g. syndicated to other sites as a feed) and different media (e.g. converted to speech). So the underlying semantic structure of the content needs to be created so that other computer programs can ‘understand’ it better and make better use of it.
The fact that the rich text editors are trying to resemble word processors encourages the user to think in a paper-based fashion. That’s part of the current price of providing something more familiar, without which it would not be as widely adopted.
I think it’ll get easier over time. In many areas we’re still trying to determine what are the different roles required to build and maintain a web presence, and what skills and knowledge those people should have.
So in this area we’re moving on from the thrill of shifting content creation out of the world of developers & designers and into the world of the writers. The rich text editors provided the mechanism for that to happen, but now they need to mature in their general functionality and web teams need to consider how they should be configured for specific websites.