Evaluating website accessibility part 2, Basic Checkpoints

This is the second article of three in a series of articles explaining how to perform a website accessibility evaluation. For a bit of background and to make sure you have the tools I refer to installed, I recommend reading Evaluating website accessibility part 1, background and preparation before starting on this article.

The checkpoints provided in this article cover certain accessibility aspects that can be tested with automated tools and others that are relatively easy to check manually.

A full accessibility evaluation is more thorough and involves more checkpoints, some of which will be covered in the third article in this series. However, these basic checkpoints are a good start:

  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

1. Validate HTML and CSS

Use the W3C validators to check if the HTML and CSS used is valid. It is very convenient to use the Web Developer extension toolbar for this: Tools - Validate CSS and Tools - Validate HTML. I recommend that you set up shortcut keys for these two since you will be using them a lot.

Of course you can also use the W3C validator sites:

Note that the HTML of many badly built websites is difficult to validate because there is no DOCTYPE or character encoding specified. For these sites you may need to do a manual override in the validator interface.

Even worse are the sites that completely block access from the validators. Yep, I've seen sites do that. Why you would want to hide a site from validators is beyond me. Anyway, for those cases you will need to use Tools - Validate Local CSS and Tools - Validate Local HTML in the Web Developer extension toolbar. Depending on how invalid the HTML is, you may also need to use Tools - Validate Local CSS for some sites that do not block the validators – certain markup errors will make the CSS validator refuse to do its job.

The HTML Validator extension will also let you validate sites that block the W3C Markup validator. It does this without sending anything to a server, so this is a good option for sites that are behind a firewall or require a login.

The HTML Validator extension will automatically alert you to any errors and warn you of possible accessibility issues for every page you load in the browser. You can customise the level of the accessibility warnings in the "Options" dialog. You should keep in mind that the HTML Validator extension is based on Tidy, which means that there are cases where it will not report certain errors that the W3C markup validator catches.

Be aware that validity does not equal accessibility. I have seen plenty of sites that use valid markup but still are far from being accessible. This scenario is particularly common on sites based on certain content management systems whose developers seems to have misunderstood the purpose of using web standards.

Why? Because valid markup is important to ensure device independence, one of the fundamental building blocks of the web. Using valid markup is as close as you can get to guaranteeing that the information can be interpreted correctly by as many browsing devices as possible.

2. No frames, please

In Firefox, context click on the page or view source to find out if the site uses frames. If the page contains frames, the contextual menu in Firefox will contain an option called "This Frame". Iframes are a little more tricky to find since you'll need to context click within the area occupied by the iframe for the "This Frame" option to appear in the contextual menu. Fortunately the Web Developer extension's Outline - Outline Frames command will outline any iframes on the current page.

Why? While frames (and iframes) aren't necessarily completely inaccessible, they generally do make a site less accessible and usable, and should be avoided. Frames are also an indication that the site was built by a web developer with a lack of understanding of both accessibility and usability. Read my article Who framed the web - frames and usability for more info on how frames affect usability.

3. Automated accessibility checking tools

Automated accessibility checking tools tend to be used mainly by accessibility novices. It is prefectly understandable – wouldn't it be great if checking how accessible a document is was as easy as validating it? The problem is that the existing automated accessibility evaluation tools are far from perfect and should not be relied upon.

These tools will help reveal some issues, and can be used as a guide to get a quick and very general overview of the accessibility of a website. That's why I think checking for their opinion on the site is worthwhile. Just be aware that there are many possible accessibility problems that these tools will not be able to find, and they will occasionally report problems that aren't really problems. A manual follow-up is always needed.

So, the following automated tools are not to be fully trusted, but at least they can give you a hint at whether the site is accessible or not, and which areas may be more problematic:

And just to make it clear: A site that passes all automated accessibility checks is not necessarily accessible.

Why? Automated tools help you spot accessibility problems that would take much longer to find by manually going through the markup. Make sure you evaluate the automatically generated report and manually inspect the areas that are flagged as problematic.

4. Images and alternative text

The HTML validator and the accessibility checking tools mentioned here will tell you if any images or image maps are missing alternative text since the alt attribute is required. If the validator does not report any missing alt attributes, you know that any images in the document have an alt attributes. However, there may still be problems, so you need to check how the alt attribute is used.

Use the Web Developer extension to show the alternative text of any images in the document: Images - Replace Images With Alt Attributes. Then try making sense of the site. Also check that the alternative text is actually visible when images are turned off – many browsers use the text colour specified for the image (or one of its ancestors) to display the alternative text. If that colour is too close to the background colour that appears when the image is missing, the alternative text will be very hard or impossible to read. This is mostly encountered on sites that use a lot of background images.

Many people misunderstand the alt attribute. It is meant to provide meaningful, informative text that should be used as an alternative when an informational image or other graphical object cannot be displayed. It is not intended to provide text that is displayed in a tooltip. The alt attribute is required for img and area elements.

Informational images should have a short description of the image. Decorative images should have an empty alternative text. I have seen sites that in a misguided attempt to be helpful take great care to describe every decorative image and spacer GIF in detail. You only need to visit a site like that once with a screen reader or text-only browser to realise how annoying it can be.

For a more in-depth description of the alt attribute and its relative, the title attribute, I suggest reading my article The alt and title attributes. Some help on deciding whether an image is informational or decorative can be found in Dimitri Glazkov's article Keeping "pretties" out of content.

Why? Because if no alternative text is specified, or if it is specified improperly, anyone who cannot see the images will either miss out on information or get flooded by useless information.

5. Obtrusive use of JavaScript

Time to put that Web Developer Extension to use again. Turn off JavaScript (Disable - Disable JavaScript), then try using the site. Some sites are impossible to use when JavaScript is not available. Among public sector websites the most common problem I've seen is navigational links that require JavaScript to function. Many also use JavaScript to load stylesheets (after first doing some browser sniffing, 20th century style), which means you'll get an unstyled document with JavaScript disabled.

I also use Lynx, which has no JavaScript support, to test if a site is possible to use without JavaScript.

Why? A decent number of people have JavaScript support switched off or are using a browsing device that doesn't support JavaScript. They should still be able to use the site.

This does not mean that you cannot use JavaScript. You definitely can. You do, however, need to make sure you use it sensibly and unobtrusively, and provide for graceful degradation if JavaScript is not available.

6. Increase text size

To check this one you will need to fire up IE/Win or take a look at the CSS used on the site. What you are looking for is how font size is specified.

Font size specified in a relative unit like em or percent lets text resizing work in all browsers. If font size is specified in pixels, users of Internet Explorer for Windows cannot change the font size without first changing settings in their browser, which very few people do.

So, load the site in IE/Win if you have it and try resizing the text (Ctrl + Scroll wheel or View - Text Size - Largest). If nothing happens, the site is probably using pixels to specify font size.

If you don't have access to IE/Win, take a look at the CSS. Time for the Web Developer extension again: CSS - Edit CSS. Look for the unit used in any font-size declarations. If all you see is px, the site does not use relative units (technically they do, but not for the purpose of this document). You want to see em or %.

Whether browsers should resize text specified in pixels or not is a whole different question, and one that has been debated for years. One such discussion can be found in my article Setting font size in pixels.

Even if font size is specified in a relative unit there could still be problems related to changing the text size. The layout needs to be designed to take into account the possibility of the visitor bumping up text size a few notches. Many layouts quickly become unusable as text size increases. Obviously all layouts will break eventually, but a good layout should be able to hold up reasonably even if text size is increased a few hundred percent. It doesn't have to look as good as it does at the normal text size, but no content should disappear or become unreadable.

If you decide to add font sizing widgets to the site (which I do not recommend), make sure the largest setting is really large. Not just a little bit larger than the default font size, but much larger. What's the point in spending time on building those widgets if the end result isn't much different from the default?

Why? Because many people need or want larger text to be able to read it comfortably. They may have a visual impairment, be over the age of 40 or like to lean back in their chair while browsing the web.

7. Look for semantic markup

To determine if the site uses semantic markup, view source and look for headings (<h1> - <h6>), lists ( <ul>, <ol>, <dl>), quotations (<blockquote>, <q>), and emphasis (<strong>, <em>). You can usually spot this pretty quickly since sites that don't use semantic markup tend to have constructs like <span class="bigboldreadheading">Heading</span> where a semantically marked up document would have <h1>Heading</h1>.

Why? Semantic markup is important since it gives browsing devices a chance of interpreting and presenting the content in a way that is suitable for the meaning it has. As an additional benefit, search engines also tend to favour semantic markup.

Proper use of headings will also let assistive devices create a document outline which can be very useful for screen reader users.

Even though all assistive devices do not use all semantic information they are provided with, if a website doesn't use semantic markup to begin with it is impossible for any device to derive any meaning from the text.

8. Disable CSS

Disable CSS by using the Web Developer extension again: Disable - Disable Styles - All Styles. This will let you see the structure of the underlying HTML with your browser's default styling.

If very little happens when you disable CSS, you are probably looking at a document that uses tables for layout and lots of presentational markup. You probably won't get to this checkpoint without already finding a lot of accessibility problems with a document like that.

Why? An accessible document should be well-structured, meaningful, and readable without CSS.

9. Use Fangs to emulate a screen reader

If you don't have access to a screen reader application, a good way of getting a reasonable feel for how the site you are evaluating will sound to someone using a screen reader is to use Fangs. Fangs is a Firefox extension (that I recommended you to download and install in part one of this article series) that emulates one of the most widely used screen readers, displaying the output as text instead of using speech.

Why? Screen readers are an important assistive technology. Knowing how a screen reader would speak the contents of the site you are testing will help you determine things like if the order of the content makes sense, if links and headings are used well, and if alternative text is used properly.

Evaluate the results

When you have gone through this checklist you will have found many of any really serious technical accessibility problems the site might have. If you are the developer, do what you can to fix any problems you found and run through the checklist again. If you are not the developer, contact whoever is responsible for developing the site and let them know that you have found some issues that need to be looked at.

There are still many potential accessibility problems though. In Evaluating website accessibility part 3, Digging Deeper, the third and final article in this series, I'll take a look at things that are difficult to test with automated tools and require a little more time to evaluate manually, as well as discuss something that is often overlooked when accessibility is discussed: content.


This article has been translated into the following languages:

Posted on March 16, 2006 in Accessibility