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

Comments

  1. Nice, I would add (as I said in the previous comments) using a Screen Reader is a definite plus in terms of really making an accessible site, though I agree its very difficult to not leave the screen turned on (or use the mouse). I would say if you have the oppurtunity try to see a Blind user, using it to give you some idea how they navigate etc (it’s an education)

  2. Great series Roger. Can I make a suggestion? Create an index page for all three:

    Evaluating Website Accessibility

    Overview…

    Markdown for comments is the only way to go! ;-)

  3. Windows developers can use GrayBit to grayscale any site for color contrast checking.

    Firefox Web Developer Extension users can enter the following URL into the Tool menu to check the page they’re currently viewing: http://graybit.com/files/graybit.php?url= .

    GrayBit currently doesn’t work with Flash movies or table-layout sites.

  4. It never occurred to me to think about the character separator in titles. With a recent site of mine which has a small but significant blind audience, I built the site around WordPress, which uses the worst possible character for screen readers according to the link you provided. Whoops! Gonna be changing that right away….

  5. March 28, 2006 by DaveMo

    I work for a state government agency that has recently converted to a CMS system and uses a state-wide mandated template for a “branded look and feel”. This thing is a nightmare of HTML tag soup and tables in tables in tables in tables for presentational structure.

    Apparently, to get around usability issues they employ a Usablenet Transcoder to allow the user to select a “Text Only” version of the site or page.

    Does anyone know how that squares with actual usability? Is this enough for “alter-abled” users to access and navigate the site?

    If you want to see what I’m talking about, check this out: http://www.oregon.gov/

    I’ve been threatened with insubordination for trying to point out the errors of this situation and trying my best to code what I can as semantically as possible instead of using tables as they insist.

    Don’t bother trying to tell me what’s wrong here, I already know only too well and it saddens me profoundly. Mostly I’m just interested in the use of the Usablenet Transcoder as an acceptable accessibility work-around in this instance.

    Thanks.

  6. Great summary. I’d imagine it’s hard to carry all these in thought while designing a page.

  7. Good point, keyboard navigation is important for web applications. Nice article.

  8. I wonder, if I’d translate the series to German. I cannot write that better myself. How about?

    One addition would be the hint creating a page competely whithout any font settings and css to compare font sizes with it. Any page is assumed to be readable at the same browser font settings which can be used to read pages without individual font settings. Unluckily it is not possible to reset Safari using defaults so I use Omniweb or Firefox most times for testing font sizes.

    DaveMo: The home page is inacceptable for me. Beside that it uses table layout, there are links not working, I cannot read the content of the left brown box and so on. If those links work in the “text version”, why don’t they on the normal home page?

    Links to “larger” and “smaller” are nonsense. Every reader has his/her default font size settings, And that just is supposed to work on every site.

    greetings

    Jutta

  9. Combined, these 3 articles was probably one of the best things I’ve read about accessibility in a long time. Very good reading, indeed.

    Seriously, Roger, have you ever considered publishing a book?

  10. @DaveMo: The Transcoder page is better than the original for low-vision users, but equally awful for blind users, because there are no skiplinks to different sections. According to the screen reader emulator I am using, it will take at least 2 minutes to get to the bottom of the page.

  11. March 29, 2006 by DaveMo

    Jutta and Dmitry Thanks. Like I said, it’s not a pretty picture I know and I appreciate your time in checking it out and giving me your feedback.

    I’m not sure that there is a lot I can do about it in the long run because of the bureaucratic heirarchy, but I’ll do my best to change things as much as I can.

    Again, I need professional and peer advice as to the actual validity of using a utility like the UsableNet Transcoder to achieve accessibility in a case like this.

    Bring it on!

    Thanks again to you all.

  12. Great set of articles, Roger. They will be very useful references to help educate the accessibility-unaware.

  13. March 29, 2006 by If I had no ID, they wouldn’t let me in

    Jutta: I don’t think ‘normal’ people change their default text sizes. So the browser default 16px might be too big for a lot of people. So there indeed is need for ‘larger’ and ‘smaller’ buttons. Of course this makes a worse experience for people who have set their default text size to something that suits them.

  14. March 29, 2006 by Roger Johansson (Author comment)

    Doug: Good suggestion. I’ve made a note of it and will try to get it done some time this year ;-p.

    mjwillis: Thanks for the tip about GrayBit. Looks useful.

    DaveMo: A text-only version is not necessarily more accessible. It can even be less accessible by removing any accessibility benefits. It is also segregating. I would consider a text-only version only as a very last resort. Further reading on this topic: Separate text-only version? No thanks!.

    Oliver: Not really. Most of these checkpoints are just common sense.

    Jutta: Thanks, but somebody else is already working a German translation.

    Erik: Yes, I have considered writing a book. I am currently looking into ways of doing that :-).

  15. hi roger, where is the articles’ trackback urls? i have traslated the part 1 into Chinese ,put it here

  16. March 29, 2006 by Roger Johansson (Author comment)

    x5: Sorry, I don’t allow trackbacks. Thanks for translating the article! I’ll add it to my list of translations.

  17. March 30, 2006 by DaveMo

    Thanks Roger.

    I sure wish I had the tools here at work to do some of this kind of testing and research on these issues. For a web coding technician I sure have to jump through some hoops just to get the basics like access to Netscape 7.0 just to check site changes.

    It can get discouraging at times, but I keep plugging along.

    If anyone else has experience or knows about the true accessibility of UsableNet Transcoder “Text Only” sites I’m still taking comments and evaluations.

    Thanks again

  18. April 2, 2006 by Roger Johansson (Author comment)

    DaveMo: Another good article about the problems of creating a text-only version and why it is not acceptable is Tommy Olsson’s Text-Only Versions.

  19. April 3, 2006 by DaveMo

    Roger,

    Thanks again! Both articles brought up excellent points that I had been wondering about.

    I’m sorry to say that the next to last paragraph in Mr. Olsson’s article is the case we’re dealing with in Oregon.

    I will add the points and concerns from both of these articles to my collection of accessability concerns and arguements for doing it right in the near future.

    Keepin’ the faith, DaveMo

  20. April 6, 2006 by Maria

    I am a totally blind university student working in the disabilities office to promote Web accessibility throughout campus and in the community. I was referred to this site by my supervisor. I just wanted to say that I thoroughly enjoyed reading these articles and even found some of the information useful. You brought up a few points that I have never actually considered in my testing. One thing I wanted to point out about non-HTML elements is specifying them as part of a link title. Especially with the increasing use of embedded document viewers, being warned in advance that a link is pointing to one of these documents saves a lot of frustration and confusion when the computer suddenly slows down trying to process the document. This is especially useful with PDF files. To DaveMo: I went to your site and found the text-only version much easier to navigate than the standard version. But I also agree with others that sending people to a text-only version feels a little discriminatory. As a note for the people using screen reader emulators, a lot of visually impaired people today navigate using headings, so it actually didn’t take long to move through the text-only site.

  21. April 10, 2006 by DaveMo

    Maria

    Thank you for your input on my request. I also appreciate your comment on warning users when they’re about to be navigated to a non-HTML document.

    For the last couple of years I have been using the TITLE attribute on links to non-HTML documents like PDFs to hopefully inform users before they click on it. It usually says something like “This link opens a PDF document” or “This link opens a PDF document in a new window”. If the PDF is over 100KB, I’ll put something like, “This link opens a large PDF document”. If it’s a humongous file - over a megabyte say - I’ll say something like, “This link opens a very large PDF document and may take a long time to download”.

    I also add similar wording if the link takes the user off site, usually in a new window, e.g.: “This link opens in a new window”.

    Hopefully this helps all users, regardless of ability, to understand what is about to happen before they click on a link that may do something other than standard or expected behaviour.

    Not all the links in our site are so coded, but every link I have done in the last couple of years has the TITLE attribute if it goes to a non-HTML document or off site.

    The specific site I work on finally went ‘live’ on a content management system last Tuesday and I have been going through it and seeing how the UseNet Transcoder handles some of the coding thrown at it. The verdict is: “Garbage in - Garbage out”.

    Unfortunately, I did not code a lot of the pages as they now appear on our site or was told to remove the semantic coding I did have there and replace it with tables, so I take no responsibility for some of the egregeous code you’re likely to encounter there. Sorry, but I did my best to warn them that it was bad.

    If the body of the page wasn’t semantically coded to begin with, the transcoder just removes any and all tables (even tables that legitimately hold tabular data and are coded semantically) and leaves all the rest of the tags and coding alone. This could be a problem because it also does NOT then replace some removed TABLE/TR/TD tags with PARAGRAPH tags or any sort of other formatting tag so that you have strings of text just sitting there on the page.

    Anyway, I don’t know if this is ultimately a big problem for users or not. But I have to think that it must be confusing without the appropriate tag for the alternative browser or assistive devise to relate to.

  22. April 24, 2006 by DaveMo

    Follow-up to my comment above.

    Upon further examination of the “Text Only” service our state uses to help it’s websites be more accessable, I have to retract my statement that it removes all table tags, as I have found several that were intact, but others, apparently ones generated by the content management system, are not, and if the content within the table cells is not formatted with another tag, like a paragraph or list, then the text just sits there untagged on the page.

    So, I think the service is doing a better job than I had originally thought it was at the time, but my earlier assessment of “Garbage in, Garbage out” is still valid.

  23. May 8, 2006 by Paul Arzul

    i rather enjoy your articles, roger — thank you.

    (1. colour contrast) This can be because they have a colour deficiency or because they are using a monochrome or grayscale screen.

    or it might turn illegible when they print as many printers are monochrome or grayscale too.

    (5. platform discrimination) For this checkpoint you should ideally have access to several different operating systems with multiple browsers installed.

    browsershots can give you an idea of different browser renderings: http://www.browsershots.org/

    - p

  24. Roger, we have a colour contrast application that uses both W3C algorithms - www.visionaustralia.org.au/ais/cca/.

    However, my personal view of the Luminosity ratio is that colour combinations also need to pass the colour difference ratio from the earlier algorithm as otherwise you can have yellow on red or even blue on blue combinations that meet the luminosity, but are very hard to read.

  25. I’ve just come accross FireVox, a Firefox extension that adds screen reading to the most “lego-like” of browsers. MathML and CSS3 included, pretty impressive on paper.

    http://www.firevox.clcworld.net/

    This information might be worth mentionning alongside other screen readers developpers could use for testing. Especially interesting is the fact that it’s just as cross-platform as Firefox itself!

Comments are disabled for this post (read why), but if you have spotted an error or have additional info that you think should be in this post, feel free to contact me.