Evaluating website accessibility part 3, Digging Deeper

In Evaluating website accessibility part 1, Background and Preparation, I provided some background and suggested some useful tools for the accessibility evaluation process. In the second article in the series, Evaluating website accessibility part 2, Basic Checkpoints, I covered accessibility aspects that can be tested with automated tools as well as a couple of relatively easy manual checks.

In this final article of the series I will explain some aspects of website accessibility that are difficult to test with automated tools and require more time and/or experience to evaluate manually. Some of the checkpoint descriptions in this article assume you have read the first articles, so if you haven't read them, please do so before you continue.

This article contains the following checkpoints:

  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

1. Colour contrast

An easy way to check that the difference in hue and lightness between foreground and background colours is good enough is to use Jonathan Snook's excellent Colour Contrast Check tool. Either enter the hexadecimal numbers for the foreground and background colours or pull the sliders and get live feedback on the contrast and colour difference.

Gez Lemon's Colour Contrast Analyser is a similar tool, which is also available as a Firefox extension.

Both of these tools use an algorithm provided by the W3C to calculate colour visibility.

You can also change your display to grayscale or monochrome to verify that all text is still readable. If you are using Mac OS X there are great options for this in the "Universal Access" preference panel. It lets you invert the colours, set the display to monochrome or grayscale, and change the contrast. If you know of similar tools for other operating systems, please post a comment and let us know.

Why? If there is not enough difference in hue and brightness between foreground and background colours many people will have trouble reading the text. This can be because they have a colour deficiency or because they are using a monochrome or grayscale screen. Or, like me, they have perfect eyesight, a really good monitor displaying 24-bit colour, and still have problems because the site is using light gray text on a white background.

For the same reason it is important not to rely on colour alone to convey information. Links, for instance, should differ from surrounding text not only in colour, for example by also being bold or underlined.

2. Document titles

Check that each document has a unique and descriptive title and that the title does not use excessive punctuation.

There are no clearly defined rules for which characters to use as title separators. However, document titles should definitely not contain punctuation used for decorative purposes, for instance ":: Title ::" or "...== Title ==...". Each punctuation character may be read out loud by screen readers, which will make listening to the titles very tedious. For some examples of what certain characters sound like in JAWS, check out The Sound of the Accessible Title Tag Separator.

Another screen reader, Apple's VoiceOver, reads "»" as right pointing double angle quotation mark. That rules out that character for use not only in document titles, but also in links, where it unfortunately is quite popular.

A discussion on different title separators can be found in Document titles and title separators.

Why? Document titles are important for several reasons: it is often the first thing an assistive device will render when loading a new page, it is used in the browser's title bar, in bookmarks, and when printing a document. Descriptive document titles are very useful for everybody. They are also extremely important for search engine visibility.

Links should make sense when read out of context. "Click here" or "here" does not make for good link text since there is no information at all about the link's target. Link text that consists of an entire paragraph, which is common on newspaper websites, contains too much information and should also be avoided.

In general, the same link text should not be used for links that lead to different destinations. Ideally each link should be able to stand on its own and make sense out of context. Some automated accessibility checking tools will warn you of this.

There are exceptions to this. Link texts like "Read more" or "Continue reading" may be ok in a news listing or similar, as long as the title attribute is used to differentiate the links. Joe Clark explains why in his Web Standards Group interview from May 2005.

To get an overview of all links in a document you can either load the document in Opera and open its Links window, or use the "Links list" feature of the Fangs extension.

Why? Links are more useful to everybody if they consist of descriptive text. Most sighted people scan web pages to get a quick idea of their content, and links are often an important part of that content. Clear links make scanning faster. Blind and severely vision impaired people can't scan a page the same way, and instead tab from link to link or bring up a list of links, so using descriptive link text really helps. Descriptive links are also important for search engine visibility, so this is one more case of accessibility being good SEO.

4. Non HTML formats

If the site makes important information available in PDF, Microsoft Word, Microsoft Excel, or other proprietary formats, HTML alternatives should also be provided. Note that there is nothing wrong with making information available in non-HTML formats as long as it is also available as HTML.

Why? While it is possible to make the content of PDF files reasonably accessible to people who have the required software, HTML is still the most widely supported format and should always be the preferred choice. Additionally far from everybody has Microsoft Word or Excel or any means to open documents in those formats. If information is only available in a proprietary Microsoft format (which is often the case), many people are effectively shut out.

5. Platform discrimination

By platform discrimination I mean partially or completely limiting access to information or functionality for users of minority operating systems or web browsers. For this checkpoint you should ideally have access to several different operating systems with multiple browsers installed. That kind of setup is not practical for many, so you may have to settle for faking the user agent string of the browser you use for testing.

Since you're using Firefox (which I recommended in Evaluating website accessibility: Part 1, Background and Preparation, remember) you can install the User Agent Switcher Extension, download a list of user agents, and you're all set.

Check if the site lets user agents other than Internet Explorer for Windows enter. This obviously only checks whether the site uses some kind of browser sniffing that is based on the User Agent string. If the discrimination is based on features that only exist on a specific platform faking the user agent string will not help.

Platform discrimination may be unintentional, but all too often it is completely intentional. It is extremely rare to find a site that discriminates against users of Internet Explorer for Windows. Most Mac and Linux users, on the other hand, have probably experienced being denied access to several sites because they are using an "unsupported" operating system or browser. That is completely unacceptable.

I often argue that web accessibility is a much broader issue than catering to disabled people. Platform discrimination is an excellent example of that, and actually the single most important factor that made me realise how important it is for the web to be accessible to all. Few things are as annoying as being unable to access information just because I am using a Mac.

Why? Because one of the fundamental properties of the web is that it should be independent of the hardware or software you use to access it. One web for anyone, everywhere, on anything.

6. Keyboard navigation

Put away your mouse for a while and try navigating the site using only your keyboard, by tabbing through links and form controls. Note that you may need to adjust the settings of your browser to be able to do this. Neither Firefox nor Safari have this enabled by default. Does it work? If there are dropdown or flyout menus, check if they can be activated without using a mouse.

Why? Screen reader users do not use a mouse to navigate the web, so this is very important to them. There are also many people who are keyboard users by choice, because they find it faster and more convenient than using a mouse.

Depending on the source order and size of the document it may also be very beneficial to non-mouse users if skip links are available. If the document contains a large number of navigational links before the main content, an in-page link that leads to the start of the main content will save keyboard users a lot of keypresses.

An accessible site is required to be device independent and not rely on visitors to use a particular input device, in this case a mouse.

7. Data tables

Time to check for the use or misuse of tables. The Web Developer extension comes in handy again. Use it to highlight any tables by selecting Outline - Outline Table Cells and Outline - Outline Tables. If the page you are viewing does not contain any tabular data, nothing should happen. If parts of the page that do not contain tabular data are highlighted, tables are being used for layout and the site fails this test.

If the page does contain tabular data, check that it is marked up as a table and uses correct and accessible markup. For information on how to use HTML tables the right way I refer you to my article Bring on the tables.

Why? There should be no tables used for layout, and tabular data should be properly marked up with tables that make use of the available accessibility enhancing elements and attributes.

8. Form controls and labels

For this checkpoint you obviously need to find a page that contains at least one form. When you do, check that each form control has a label associated with it, that labels are properly marked up with label elements, and that labels and controls are in the right order (label first, then the control, except for radio buttons and checkboxes which should be control first, then the label).

If the form uses select boxes for navigation check if the form is automatically submitted (with JavaScript) when an option is selected. For cases where JavaScript is not available, make sure that the form can be submitted and that any client-side validation of the entered data is handled by the server.

Automated accessibility tools will normally alert you of form controls that do not have an associated label. You can also use the Web Developer Extension: Forms - View Form Information and make sure that all visible form controls have an associated label.

Why? Proper labels help everybody since it makes the clickable area larger. Each visible form control should be explicitly associated with a label element.

Automatically submitting a form when the selected option in a select box is changed causes problems for keyboard users. Requiring JavaScript to submit the form obviously makes it impossible to submit it when JavaScript is not available. Relying on JavaScript for input validation may lead to unexpected values being submitted and stored in the database.

9. Use a screen reader

First of all I really want to stress that accessibility is not just about screen readers. Far from it. Equating web accessibility with "works in screen reader X" is a very common mistake, and accessibility is much more than that.

Now, about screen readers. If you are sighted, it is very hard to imagine what it is like to use the web without seeing it. You can try, but it's very hard to stop yourself from cheating. You should still try though, and to do that you need a screen reader.

If you are a Mac user you may already have a screen reader – Mac OS X 10.4 and later includes VoiceOver, Apple's screen reader software. It is not as advanced as some of the other screen readers that are available, but it is good enough to give you a decent idea of what a website sounds like to somebody who cannot see it. I have written an article that explains the basics of using VoiceOver to browse the web: VoiceOver and Safari: Screen reading on the Mac.

If you don't have a Mac with Mac OS X 10.4 or later, you will need to install a screen reader. Most screen readers are very expensive though, so you will probably have to settle for using a demo version. Here is a list of screen readers that are available as demo versions:

Why? all of the other checkpoints in this article series will get you very far accessibility-wise. However, experiencing what the web is like to somebody who cannot see is important since it will make you realise the importance of many of the various problematic areas I have listed.

10. Don't overlook the content

If the site you are checking has passed all checkpoints in this article series, it is quite safe to assume that the site is technically accessible to all. That, unfortunately, does not necessarily mean that its content is understandable to all.

Writing or otherwise creating and presenting content that truly is accessible to all can be very difficult, and evaluating that aspect of accessibility is outside the scope of these articles. Keep in mind that badly or incoherently written content can be difficult to understand even for highly intelligent people.

Obviously understanding a website's content can be even more problematic if you have some kind of cognitive impairment or a learning difficulty. One article on that subject that I recommend reading is Developing sites for users with Cognitive disabilities and learning difficulties. In that article Roger Hudson, Russ Weakley, and Peter Firminger discuss some problematic areas and provide some suggestions on how to improve accessibility for people with cognitive impairments and learning difficulties.

11. Further reading

I also recommend reading the Web Content Accessibility Guidelines 1.0 and the accompanying Techniques for Web Content Accessibility Guidelines 1.0. They are large documents and can be a bit, uhm, inaccessible, but there's a lot of information in there.

You should also read the working drafts of WCAG 2.0 and its companion document Techniques for WCAG 2.0. Again, note that the WCAG 2.0 documents are working drafts and are likely to change before they are finalised.

And finally, remember that accessibility is not a case of all or nothing. Doing something to improve accessibility is much better that doing nothing and hoping that nobody will notice.

Translations

This article has been translated into the following languages:

Posted on March 27, 2006 in Accessibility