An Introduction To Accessible Web Design

Accessibility Initiatives

A number of groups around the world are working on increasing awareness and helping authors of accessible Web sites. These include the World Wide Web Consortium (W3C), the US Government and CAST/Watchfire. We will be looking at what each of these groups has done in more detail starting with the W3C.

Web Accessibility Initiative

Since 1999 the World Wide Web Consortium (W3C) (the organisation that creates the standards for the web) has been working on its “Web Accessibility Initiative” or WAI. The official mission of this initiative is:

The World Wide Web Consortium’s (W3C) commitment to lead the Web to its full potential includes promoting a high degree of usability for people with disabilities. WAI, in coordination with organizations around the world, pursues accessibility of the Web through five primary areas of work: technology, guidelines, tools, education and outreach, and research and development.

The result of this initiative so far has been three sets of guidelines:

The Web Content guidelines are designed to show Web site authors how to make their site accessible. The Authoring Tool guidelines are for people writing programs that can be used to create Web sites. The User Agent guidelines are for people who are creating Web browsers.

I will not be discussing Authoring Tool or User Agent guidelines any further as they are not the topic of this discussion and are only relevant to authors of those programs.

Web Content Accessibility Guidelines 1.0

The Web Content Accessibility Guidelines or WCAG became a W3C recommendation on the 5th of May 1999 (becoming a W3C recommendation is an extremely tough and long process).

It’s purpose is to explain accessible use of Web technologies for those who create Web sites. This is achieved through 14 guidelines with a total of 60 checkpoints to be followed to make sure a site is accessible.

To accommodate the varying levels of effort people are willing to put in to making their sites accessible the checkpoints are broken down into 3 different priority levels. The specification lays out the three priority levels as follows:[Priority 1]A Web content developer must satisfy this checkpoint. Otherwise, one or more groups will find it impossible to access information in the document. Satisfying this checkpoint is a basic requirement for some groups to be able to use Web documents.[Priority 2]A Web content developer should satisfy this checkpoint. Otherwise, one or more groups will find it difficult to access information in the document. Satisfying this checkpoint will remove significant barriers to accessing Web documents.[Priority 3]A Web content developer may address this checkpoint. Otherwise, one or more groups will find it somewhat difficult to access information in the document. Satisfying this checkpoint will improve access to Web documents.

For those who take the time to produce pages that conform to any of the above priority levels there is a matching set of conformance levels:Level ‘A’All Priority 1 checkpoints are satisfied.Level ‘Double-A’All Priority 1 and 2 checkpoints are satisfied.Level ‘Triple-A’All Priority 1, 2, and 3 checkpoints are satisfied

Pages, sites or portions of sites that conform to one of the three levels may then display a logo, linked to the appropriate W3C explanation of the claim:Level ‘A’Level ‘Double-A’Level ‘Triple-A’

For full details of the conformance logos see the W3C WCAG Conformance Logos. Alternatively, conformance can be specified through a text explanation such as:

This page conforms to W3C’s “Web Content Accessibility Guidelines 1.0”, available at http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505, level Double-A.

The text must specify:

  • The guidelines title: “Web Content Accessibility Guidelines 1.0”
  • The guidelines URI: http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505
  • The conformance level satisfied: “A”, “Double-A”, or “Triple-A”.
  • The scope covered by the claim (e.g., page, site, or defined portion of a site.).

The Web Content Accessibility Guidelines were developed by the Web Content Accessibility Guidelines Working Group (WCAG WG). The following W3C pages will be useful to you if you would like to produce pages that conform to WCAG 1.0:

The US Government – Section 508

The US Government has endorsed the W3C Web Content Accessibility Guidelines by forcing all federal Web sites and sites that are under a federal contract to comply with the guidelines. More information can be obtained from Section 508.


While it is possible to read the Web Content Accessibility Guidelines and build your site to comply, wouldn’t it be easier if there were a tool to test it for you? You’ve guessed it, there is, a product called Bobby was produced by a non-profit organisation called CAST in order to test sites to be sure they complied with the guidelines, it is also aware of the conformance levels and will tell you which level you are at (if any).

In December 2001 Bobby also began supporting Section 508, which makes it the most complete accessibility tester available. In July 2002 Bobby was purchased by a company called Watchfire, who now look after the product.

Bobby has it’s own set of logos that work in much the same ways as the W3C logos:Level ‘A’Level ‘Double-A’Level ‘Triple-A’

Or for Section 508 compliance approved by Bobby:

You can use bobby in two ways. If you only want to test a few pages here and there it is available as a free on-line tool at http://bobby.watchfire.com/ and works in much the same way as the W3C HTML validator (if you’ve used it). You enter the URL of the document you want to check and then you receive a report of where you comply and where you don’t. Because of the nature of the accessibility guidelines it is not possible to check everything through a program so you will still have to check some things yourself, Bobby tells you what to check.

If you want to check a lot of pages then the on-line tool has its limitations (you can only do a small number of checks per hour) so you would probably be best purchasing the downloadable version so that you can check as many pages as you like. At the time of this writing (November 2002) the price is $99.

A nice feature of Bobby is that for every guideline advice is readily available on how to make your document comply and why it is import for accessibility.

Over to you

That’s the end of this introduction to accessible Web Design. For more information the urls given in the article should give you a good start (listed below). Have fun making your sites accessible!


An Introduction To Accessible Web Design

Why Accessibility Is Important

Why aren’t all Web sites accessible? You may be asking yourself why this issue exists and why all Web sites aren’t already accessible to all users. There are a number of reasons that I will outline now.

Visually Disabled Users

Visually disabled users ranging from colour blind to fully blind have problems with images that do not provide a text description of what they show. Without a text description a user who can’t see an image has no way of knowing what it is or what it represents.

These users also have problems understanding sites that are not logically built when “viewed” using a non-visual browser such as a screen reader. A screen reader is a Web Browser that reads Web sites out loud so as to make them accessible to visually disabled users. Often a Web site that looks nice visually will be a complete mess when it is listened to through a screen reader.

Hearing Disabilities

In a similar way to visually disabled users not having any way of understanding an image, users with hearing disabilities have no way of understanding information that is communicated with sound, unless an alternative is provided that does not use sound, such as a text description or an image.

Physical Disabilities

If you are not physically disabled, have you tried using a Web site without your mouse? Unless you were lucky with the site you chose then you probably found it very difficult. Physically disabled users are often incapable of using a mouse. Unless these users needs are taken into account when creating Web site navigation and input methods physically disabled users will sometimes find a Web site completely inaccessible.

Cognitive and Neurological Disabilities

Web sites can be complex, and finding the information we want can be difficult for the most able of us. This is not helped by sites that use an overly complex design, navigation that works differently on different pages (inconsistent) and distracting repetitive animation. All of these problems are compounded for users with Cognitive and Neurological Disabilities and this makes some sites completely inaccessible for them.

Beyond Disabilities

As we have seen, using the Internet if you have a disability can be a difficult task. By observing and understanding the guidelines for accessible Web Design a site can be produced that serves it’s purpose and is accessible to all of it’s users, not just those without disabilities.

But it doesn’t stop there. Accessible Web Design has benefits for other users too. Let’s see who else can benefit.

The following groups will benefit from following the guidelines for making your site accessible:

  • Users of mobile phones, Web-TV and kiosks,
  • Low bandwidth users,
  • Users in a noisy environment,
  • Users with “screen glare”,
  • Users who are driving,
  • Users with a low literacy level,
  • Second-language access and
  • Users with different learning styles.

Dealing with accessibility issues also improves:

  • Page transmission and site maintenance,
  • Machine indexing of content and
  • Searching of content.

The Marketplace

There’s another reason for making your site accessible (if you need any more). According to current figures disabled users currently make up around 10% to 20% of the population in most countries. Increase that for the amount of your users who fall into the categories listed above and you’re looking at up to 30% of the market. If making your site accessible to 30% of the market doesn’t persuade you that accessible Web Design is worth it then stop reading now.

The average age of the population in many countries is also increasing. Aging results in a number of accessibility issues including vision and hearing changes and changes in dexterity and memory. If your market includes a significant number of elderly users then you can increase that 30% to a much larger percentage of users who will reap the benefits of accessible Web Design.

Legal Requirement

For certain Web sites, addressing accessibility can be a legal requirement. This is usually for government sites but can affect others, every UK Web site must be accesbile under the Disability Discrimination Act. For more information on the requirements in different countries see the W3C page Policies Relating to Web Accessibility.

> > Accessibility Initiatives

web design and development services

Random Content & Image Rotation

After reading Random Image Rotation by Dan Benjamin I thought I would share a method I recently used to rotate ‘Success Stories’. The concepts and script I will present you with in this article can be used in the same way as Dan’s to keep a page from becoming dull to repeat visitors.

The random content concept is similar but not the same; the script I will present to you here can be used to create random rotation of any (X)HTML code you choose. It is server based and not dependant on JavaScript.


You create a number of <div>s. You import a style sheet generated by a perl script. The style sheet sets all but one random <div> to display:none. Your design looks fresh, Search Engines pick all of the content up (so any links in the random content are seen every time), and screen reader users get it all too* so it keeps your content accessible. Simple, but useful.

* – As pointed out by Joe Clark some screen readers respect display:none so this does not apply to those delinquents. You can use something other than display:none if you wish.

Installing the Script

The script is written in Perl and should be usable on nearly all Web hosts around, please refer to your Web host’s support desk or help files if you do not know how to get this script working. The only line you may need to change is the first line of the script that points to the perl executable on your server.

The Example

As an example we will be using three ‘Success Stories’ that are a page of content each:

  • success1.html
  • success2.html
  • success3.html

On our homepage we only have room to point to one of these Success Stories at a time when we are displaying the page to a visual browser, but there’s no reason that screen readers and search engines shouldn’t see all three every time.

We create three sections of code that will be used on the homepage for leading users into the full success story content pages:

<div id="success1" class="success-story">
<p><a href="/success1.html"><img src="/images/success1.jpg" alt="Foo Ltd." border="0" />Foo Ltd. has been invaluable in bringing our product to market successfully.....</a></p>

<div id="success2" class="success-story">
<p><a href="/success2.html"><img src="/images/success2.jpg" alt="Foo Ltd." border="0" />Foo Ltd. delivered a highly professional service.....</a></p>

<div id="success3" class="success-story">
<p><a href="/success3.html"><img src="/images/success3.jpg" alt="Foo Ltd." border="0" />Foo Ltd. provided the project management skills we were looking for.....</a></p>

We have a <div> for each section of content that we want to be in the rotation. The content of the <div>s is not important to the script, the important part is the id of each <div>, which has two sections; a prefix and a number. The class of the <div> can be whatever you need for CSS display purposes. You can of course use the id but you would have each id in your selector, using one class makes this easier.

The Prefix

The first part of the id is the prefix, this is everything that comes before the number, in this example:


We will be passing this prefix to the script.

The Number

The second part of the id is the number; these must always start at 1 and go up in increments of 1 (1,2,3 etc.). You can have as many as you like.

We will be passing the highest number to the script.

The Script

The script uses a simple concept, it generates a style sheet which will hide all but one (random) <div> using display:none. We add it to our homepage using the standard <link> element:

<link type="text/css" rel="stylesheet" href="/cgi-bin/random_content.pl?t=3&p;=success" />

The important part here is the href that point to the style sheet:


Let’s break it up and look at each section in turn:


The path to the location of the script on your server followed by a question mark.


t for total. You should replace 3 with the total number of content <div>s you used above.


You need the ampersand to separate the two values we are passing.


p for prefix. You should replace success with the prefix you used for the ids of your divs.

And that’s it. Users that don’t make use of the CSS such as search engine crawlers and screen readers that ignore CSS will get all of the content every time. With a little imagination there are many interesting things you can do with this simple script. It worked very nicely for me; I hope it does for you too.

Changing The CSS

As I mentioned earlier you do not have to use display:none, you can change it if you wish. One alternative is to absolutely position the content so that it is off the visible screen area, say 1000 pixels to the left, to do this you would change the following line in the script:

my $css = '{display:none;}';


my $css = '{position:absolute; left:-1000px; top:0px;}';

This should make non-random content more accessible to screen readers. The choice is yours.

A Parting Comment

Thanks to the brilliance of a certain browser you may have problems if you try to view the output of the script directly in your browser. This is because it does not listen to the MIME type that the script outputs when you view the output in the browser (it works fine when it imports it as a style sheet).

If you want to view the output using this browser you will need to add &debug;=1 to the URL you use to access the script. This causes the script to output using a MIME type of text/plain instead of text/css. Don’t use debug=1 when importing as a style sheet, only add it if you are having problem viewing the output of the script in your browser for testing purposes.

The other alternative is to rename the script to .css which should also fix this problem without the debug=1 as the aforementioned wonderful browser will then believe it’s really getting css.

Random Content Related Questions

  • Can you rotate an image in HTML?
  • How do you flip an image vertically in HTML?
  • How do I rotate an image?
  • What is image orientation?

Why CSS is good for Google

Why CSS is good for Google

This article is based on part of a larger book ‘Website Findability’ by Michael Heraghty.

Cascading Style Sheets (CSS) are used to separate the stylistic elements of a page such as layout, colour and fonts from the content of the page such as paragraphs and images. We call this Separation of Content from Presentation.

If you don’t understand CSS at all then you may decide not to use it for your site. However I would suggest that the advantages to be gained from using CSS, not just for Google, are well worth the time invested in learning it. For an introduction to CSS see CSS Is Easy by Kevin Yank or see the many other quality articles over at SitePoint’s CSS Section.

So why is CSS good for Google?

  • CSS allows for smaller file sizes
  • CSS allows you greater control of page structure
  • CSS allows you to hide certain content from browsers while it still gets picked up by Google

CSS allows for smaller file sizes

By taking styles out of the HTML page and putting it into a standalone (imported) style sheet (.css file), you can reduce the overall amount of code in your web pages. Pages with less code have smaller file sizes and Google prefers pages with smaller file sizes (many other search engines do too).

Though Google doesn’t offer specific advice on this matter, the search engine optimisation community is generally agreed that 100KB is a good upper limit for page sizes.

CSS allows you greater control of page structure

CSS allows you to structure your document according to HTML standards without comprimising the look-and-feel of the page.

Google rewards pages that are well structured, though many designers choose to ignore standards and guidelines as much as possible, because they (incorrectly) believe standards lead to bland pages. Using CSS, designers can create attractive pages with much flair, while adhering to the findability design principles identified in the book (yes you’ll have to buy it to get more!).

CSS allows you to hide content from browsers while it still gets picked up by Google

Using CSS you can hide content from certain browsers in certain situations. For example you may have some content that you only want to appear in print, or you may want certain content to only be shown on screen and not in print (such as page navigation). The advantage is that Google will still index all of the content and you will still get the benefit that content brings.

For an example of this technique see my article Random Content Rotation.

Browser Compatibility

If you are new to CSS, be aware that different browsers still interpret CSS standards in different ways, while some (very) old browsers don’t read CSS at all. Ensure that your CSS is as cross-browser compatible as possible, and that your HTML pages look acceptable even without CSS.