Evaluating website accessibility part 1, Background and Preparation

In more and more countries across the world it is becoming required for government and other public service websites to be based on standards and follow accessibility guidelines. That in turn is making it necessary for the people involved in building and maintaining these sites to be able to build accessible websites and evaluate website accessibility.

Many people, web developers as well as website owners, are new to website accessibility and find it difficult to evaluate. This three-part article series is intended to make it easier for non-experts to perform a basic accessibility check. I hope it will be helpful enough to make at least a few websites more accessible.

The series consists of the following articles:

  1. Evaluating website accessibility part 1, Background and Preparation (this article) provides some background and suggests some useful tools for the evaluation process.
  2. Evaluating website accessibility part 2, Basic Checkpoints explains accessibility aspects that can be tested with automated tools as well as some relatively easy manual checks.
  3. Evaluating website accessibility part 3, Digging Deeper takes a look at things that are difficult to test with automated tools and require more time and/or experience to evaluate manually.

Note that running through the checkpoints described in this article series does not make testing with actual disabled persons using screen readers and other assistive devices unnecessary. But if you do not have the means to do that, going through the checkpoints described in this article series will give you a very good indication of the accessibility status of the website you are evaluating.


A common definition of web accessibility is access to the Web by everyone, regardless of disability. That definition implies that accessibility is only about people with disabilities. It may or may not be the official definition of accessibility, but either way I find it way too narrow, and I'm not the only one. Robert Nyman, for instance, ponders the subject in What is Accessibility?.

When I mention accessibility in this article (and elsewhere), I mean accessibility in a wider sense that also includes device independence – universal access, regardless of disability, user agent or platform. The web should be accessible to all.

A quick look around at various public service websites here in Sweden (and in most of the rest of the world) reveals a sad fact. The developers who have built many of those sites have failed to ensure that their sites are based on web standards and are accessible to all. Even very recently redesigned and rebuilt sites fail miserably at this. If you didn't know any better, you could think the year was 1997 again by looking at the markup used on many of these sites. That includes sites redesigned in 2006. Pathetic.

For more info on the current state of web standards usage of public service websites around the world, I suggest reading the articles Government web standards usage: USA, Government Web Standards Usage: New Zealand, Government Web Standards Usage: People's Republic of China, and Mätning av grundläggande tillgänglighet (in Swedish).

Web standards do not equal accessibility, but using web standards is an integral part of building an accessible website, and the validation results usually indicate if any effort at all has been spent on making a site accessible.

When you look at the results from the mass validations of Swedish public sector websites performed by Verva (Swedish Administrative Development Agency), an unfortunate side effect of the validation effort can be seen. Since the first round of validation several sites have tweaked the markup of their front page to make it valid, but keep using presentational markup, massive amounts of inline CSS, layout tables, and spacer GIFs with useless alt texts. This kind of lip service disgusts me, and I have more respect for those who do nothing than for those who cheat their way to validation just for the sake of having no errors in Verva's mass validation.

The low accessibility and general low quality of most public sector websites is clearly not acceptable. To some extent it is understandable – unless you have some knowledge of website accessibility it is difficult to determine whether a site is accessible or not. Many public sector organisations hire a web agency to build their websites because the organisations themselves do not have any in-house knowledge of HTML. This makes it very hard for those responsible to determine if their website is accessible and if the company they have hired to build it are doing their job properly.

Unfortunately, many web agencies do not seem to be interested in building high-quality websites, using best practices, or making sure the sites they build are accessible to all. Why this is, I do not know. It is easy to assume that people working in the web industry take pride in doing a good job and always strive to do their best. This is clearly far from always the case.

Another major problem is the marketing used by certain CMS vendors. Marketing in which they falsely and knowingly claim that sites based upon their software are fully accessible and adhere to web standards, when all they are really interested in is wowing prospective buyers with WYSIWYG editors, fly-out menus, drag-and-drop integration with Microsoft Office and other bling-bling. As long as CMS vendors are allowed to market their products with false information I'm afraid we won't see a whole lot of improvement, since there are very few web agencies that will ensure that the CMS they are using produces valid, semantic, and accessible code.

Ok, now that I'm done ranting about that I'll get to the point of this article: to explain how you can do a basic website accessibility evaluation.

Preparation: install some tools

First of all I recommend downloading and installing some very useful tools that will make accessibility evaluation much easier:

Many of you will already have one or more of these tools installed, but if you don't, now is the time to download and install them.

The checkpoints

The checkpoints in these articles cover a lot of areas that typically cause accessibility problems. Some of these are more commonly encountered than others. There are 18 checkpoints in total:

Basic checkpoints

  1. Validate HTML and CSS
  2. No frames, please
  3. Automated accessibility checking tools
  4. Images and alternative text
  5. Make sure that JavaScript is unobtrusive
  6. Increase text size
  7. Look for semantic markup
  8. Disable CSS
  9. Use Fangs to emulate a screen reader

Digging deeper

  1. Colour contrast
  2. Document titles
  3. Link text
  4. Non HTML formats
  5. Platform discrimination
  6. Keyboard navigation
  7. Data tables
  8. Form controls and labels
  9. Use a screen reader
  10. Don't overlook the content
  11. Further reading

Evaluating website accessibility part 2, Basic Checkpoints will be out soon. Until then maybe we could discuss ways of convincing CMS developers to improve the accessibility and web standards compliance of their products. Anyone have any bright ideas?


This article has been translated into the following languages:

Posted on March 6, 2006 in Accessibility, Web Standards