Weblogs: Web Accessibility

Ian Lloyd is the web designer behind accessify which is one of the most popular accessibility sites in the UK. He was a major driving force behind Nationwide's push towards an accessible website. His presentation is available online (via dotjay).

An accessibility culture has taken hold of web design. This involves making accessibility an integral part of what you do. The hardest part is to get buy in and budget, which largely depends on building a business case.

There are a multitude of reasons to build an accessible website, including social responsibility, a legal obligation and as a sales or marketing competitive edge.

Noticing good and bad accessibility

Bad accessibility is an unseen problem by a majority of users. Without demonstrating the problem, people don't comprehend the necessity of accessibility. What Ian did in Nationwide was to bring in a blind screen-reader user to demonstrate to management how he would use the web. After hitting problem after problem on the Nationwide site, managers were convinced of the pressing need to make their website accessible.

Good accessibility is equally transparent to the majority of people, or should be. Good accessibility reaps its rewards in terms of good word of mouth, which is an exceptionally powerful communication mechanism. News of an accessible website, especially one that meets the needs of a disabled individual, gets passed on as information as well as recommendations to other disabled users. This forms a powerful advertising mechanism, since given the choice between an accessible website and one they cannot use, obviously the accessible one is far more likely to deliver.

Accessibility and developers

An important factor for Nationwide's accessibility was summarising the Web Content Accessibility. By boiling down the salient points into a laminated card, one for every developer, it raised the importance of accessibility to other web developers, The laminated card covered important points for developers.

Automated testing can be done, but its very difficult to interpret the results, so should not be fully relied on to ascertain whether a website is accessible.

Handling images

The accessibility of images is the easiest obstacle to fix, and one that has the most impact. Its also easy to get wrong.

The alt attribute on an image is to provide alternate equivalent content, it is not for information information expected to show up as a tool-tip.

Too much information is also an obstacle, so its important to keep the alternative text short and succinct.

When using sliced images, use an alternative text for the main image, and a blank alternative text for the other images ( alt="" ).

The longdesc attribute is badly supported in assitive technologies. Older suggestions included the use of a D-link, which provides a link immediately after the image to a page that provides the equivalent content to the image. However, its probably a better idea to include that sort of text as a caption to the picture, so include it immediately before or after the image on the very same page.

Links

The difference between good links and bad links include the inability to bookmark bad links. Links using javascript: pseudo-protocol, as well as links with an href="#" are bad links, and should be avoided.

Don't break the well-understood concept of links, which are:

• Links should be underlined
• Links should be blue

The only exception to this are links used for navigation. There's a different rule for navigation in that it looks different to content.

Pop-up windows are confusing. Sites need to warn the visitor when a new window is opened, and when a link does not link to an html page.

Tables

Tables need to linearise properly. [Ian gives a demonstration of a table linearising, using Opera's use mode. The output shows all the table data being displayed starting from top-to-bottom left-to-right. Shows a few tables out in the wild that lose vital information when linearised.]

Complex tables need to have headers and id attribute specified so that a screen reader can associate the data cells of the table to the headers of those cells.

Forms

There are two rules that should be followed in implicitly linking field labels with their field elements:

• For text fields, text areas and select boxes, the label should be immediately before the field.
• For radio buttons and checkboxes, the label should be immediately after the radio / checkbox widget.

A quick CSS style that makes it clear to visual users that a field has the focus:

 input:focus {
  background-color: Yellow;
 }

This doesn't work in Internet Explorer, but it doesn't create new problems.

Testing tools

• Firefox Web Developer toolbar (and the Internet Explorer equivalent: Nils Accessibility toolbar).
• Favelets (JavaScript bookmarks), for example Tantek's, accessify and Jeffrey Zeldmans favelet lists.
• Opera - its user mode allows a lot of accessibility options, like linearising tables.

Online resources

• accessifyforum
• access matters
• WebAIM website and their email discussion lists.

---

[ Weblog | Categories and feeds | 2011 | 2010 | 2009 | 2008 | 2007 | 2006 | 2005 | 2004 | 2003 | 2002 ]