Learn to love accessibility

By now just about every web designer knows about accessibility in some form or other. Whether it's from noticing high-profile legal cases in the US or reading web development blogs, most people accept that it's a good thing and should be part of any site design.

So why is it that whenever the usability of various sites is checked, they usually come up short? Nomensa was commissioned by the United Nations to conduct the first ever global audit of web accessibility - after testing 100 sites from 20 different countries, only three completely passed basic accessibility checkpoints. None passed them all. Some high-profile, long-standing websites don't seem to apply the basics, issues that have been covered in the World Wide Web Consortium's (W3C) accessibility guidelines since the last century.

The key stumbling block in the early days (until 2003) was creating attractive and usable sites. The dominant development methods were using tables and spacer gifs to create pixel-perfect layouts, and even website owners who were concerned about accessibility would not consider a basic-looking site. The gateway technology was CSS, which allows the separation of content and styling, so you could have your cake and eat it - an accessible and attractive site.

However, in the rush to adopt this 'new' technology, not everyone has really understood what it enables. For the purpose of this article, I'm going to assume you've joined the Web Standards revolution so I can focus on how to make your websites barrier-free for all.

Ideally, accessibility considerations are included from the beginning, when you define the content, structure and navigation of a site. If navigation is not thought about from the start, you may get pages with hundreds of links - and hearing a screen reader announce over 200 links on a page can give you a real sinking feeling. Though there are ways around the issue (such as using headings to separate the page into sections), only providing the options the user needs at the time is beneficial to everyone. If you create a sitemap, check that none of the main sections have too many options. There isn't a hard and fast rule, but you should avoid having more than 20 items at once in your main navigation. I use an expanding hierarchical navigation that shows the top level and local navigation, but the principle is a usability one: don't give too much choice.

Another check you can do at the sitemap stage is that links don't clash. Some people will get link names out of context, so check for duplicate names. A common one is 'contact', where you may have several different sets of contact pages. With a global 'contact' link you will get clashes unless you alter the links for the other contact pages.

If you produce page sketches or wireframes before the design stage, you can check the sign-posting for pages. You may think knowing what the current page is and how you got there is obvious, but for people with memory issues, or using a screen magnifier, it isn't. The main page heading should strongly relate to the link the person used to get there. The title element should also match - I use the format: Page name: Site name>Section name. This puts the important information first, and the page name would be the same as the main heading. This consistency of navigation is important for usability and accessibility; it also happens to be great for search engine optimisation (SEO) when used with good HTML code.

The front-end code is where the action is, and where most accessibility issues are created and solved. Separating style and content is the basis of usability, and combined with valid, meaningful (X)HTML is the best foundation.

Defining your underlying code by the meaning of the content is essential. Although HTML doesn't have elements to use for every situation, there are plenty to learn about and extend using 'XHTML compounds' as Tantek Celik explained at Web Essentials '05.

One of the main problems recently is that many people have 'got' CSS, but not semantic (X)HTML. So instead of styling a heading, they will add <div class="mainheading"> rather than <h1>. When translating from design to code, it is important to know what you're trying to achieve, which isn't pixel perfection - even slight differences in how browsers render a font mean you'll never get pixel perfection in all circumstances. As Nate Keochley of Yahoo said at @Media 2005, "Expecting two users using different browser software to have an identical experience fails to embrace or acknowledge the heterogeneous essence of the web." Yahoo's graded browser support is a practical approach, and fits nicely with accessible web development.

Before applying the design, you need to establish the order of the page sections within the HTML document. Ideally, you'd put the content first (after the logo and perhaps search box). The exception would be when the main navigation is text-based and intended to be displayed across the top visually, in which case I'd put navigation at the top of the source order. People can increase the font size, and it's virtually impossible to absolutely position things dependant on words wrapping, so here the navigation must go first. Whichever is first, make sure you include a skip link to either the main content, or navigation (whichever is last).

At the coding stage, flexible layouts are key. The range of possible methods are far too wide to cover here, but a flexible layout should cope with a resolution of 800x600 at the largest font size in Internet Explorer, with accessibility options set to ignore font sizes; 1024 at regular and large font sizes; and 1600 at regular and large font sizes. There are no clear rules for layout, but if your layout is usable under those conditions, you've made the best effort to make it accessible. If you're prevented from using a flexible layout (if, for example, your client insists), consider providing a style switcher to allow switching to a flexible layout.

With a good HTML document and flexible layout, the biggest hurdles are over. As you use CSS to convert that document into the desired design, the main problems will be cross-browser issues. Dan Cederholm's Bulletproof Web Design is an invaluable book, as he covers many CSS techniques needed for flexible designs in a variety of situations.

If your site uses JavaScript to add behaviour, there are a couple of things to consider. JavaScript is not evil, nor is it intrinsically inaccessible; however, it is a powerful tool that is easily misused. The aspects to look out for are that a website's content and functionality do not rely on JavaScript, and that it does not rely on mouse input. In general, if you follow the separation of behaviour from style and content, you won't go far wrong. Christian Heilmann wrote the original "Unobtrusive Javascript" article, which was written with accessibility in mind. The tests are to check are whether it works without JavaScript, and whether it works with a keyboard only.

We can't cover accessibility without mentioning alternative texts. At the template stage, images tend to be place-holder images, logos and perhaps spacers. Logos are something of a special case as they tend to be on every page, so should be very concise, often just the name. Spacer images in templates aren't needed with a CSS-based layout. For place-holder images, ensure the alternative text you use is either what it should be, or checked before going live! Jim Thatcher has a great alternative text tutorial online at www.jimthatcher.com/webcourse2.htm.

If you're hand-crafting your own website, handing it over to the client won't be a problem, but many of us have to hand over the site to regular (non-technical) people and, with it, the responsibility for maintaining usability. How much the author needs to know will depend entirely on the system you are using. Ideally, the program would prevent people from creating inaccessible markup, but in practice very few do.

Anything you can do to prevent inline or custom markup will help; for example, if you're using a 'What You See Is What You Get' (WYSIWYG) editor, can you customise it? Remove items such as the font-chooser or colour picker, and add custom styles the author can select. This is also useful for keeping to a style guide.

Also make sure that authors know to use list-buttons rather than just dashes at the beginning of lines, that blockquote is for quotes rather than indentation, and bold isn't a replacement for headings. If you can't enforce things through the editor, you can set up some styles to highlight problems, such as:

blockquote blockquote {background: #f00;} /* highlight double-quotes */

img {border: 2px #f00 dotted !important} img[alt] {border: none !important;} /* set to default style. */
img[alt=""] {border: 2px #00f dotted !important}

The CSS above could be applied in the editing environment to highlight images without alternative text, and even with blank alternative text, which would help in the content area. Ideally, contextual help in the editing interface would support authors choosing the best alternative text.

A common sight for homepages and overview pages is the 'More' link, where an overview finishes with "Read more >". Tabbing through a page and just getting "more, more, more", isn't very helpful, so these tend to be better re-phrased as "Read more about this subject". Meaningful link names are important for usability, but they also help most people scan through a page. It can be a difficult habit to break, but you should always try to think how the linked page's title would fit into a natural sentence.

The best thing to drill into a new web-author is the importance of writing usable content for the web. Everyone has horror stories of offline materials being dumped onto websites, but a good, concise writing style will help more people than any of the other tips so far. The Plain English guidelines at www.plainenglish.co.uk/guides.htm are a good resource for helping people, and there are training courses available as well.

To conclude our whirlwind tour of accessibility, I hope you take away the importance of using HTML for meaningful structure and CSS for style. There are a host of resources referenced, but if you still have questions head over to Accessify's forum at www.accessifyforum.com, where there are plenty of knowledgeable folks only to happy to help, including myself.