Evaluating website accessibility

My recent article series on evaluating website accessibility became a series of articles because I felt all that information would just be too much for a single article. The drawback to splitting it into several articles is not having everything collected in one document. By reader request, here is a summary of the series, with links to each checkpoint.

If you haven’t read any of the articles I am referring to, they are intended to make it easier for web developers and website owners to perform a basic accessibility evaluation. Developers and designers can use these techniques to make sure the sites they build don’t contain any huge accessibility problems, and website owners can use them to assess the quality delivered by their web consultancy.

The “Evaluating website accessibility” series consists of the following articles:

  1. Evaluating website accessibility part 1, Background and Preparation provides a bit of 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.

    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
  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.

    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

The techniques described in these articles are by no means all there is to evaluating website accessibility. They do, however, provide a good start.

Posted on April 24, 2006 in Accessibility


  1. Great work, Roger! You’re the most thorough guy I can think of.

    This will be a great resource for me and many others.

  2. April 24, 2006 by Johan Sjostrand

    Soo bookmarked. Thanks!

  3. Thanks for providing a better bookmark ;)

  4. great post to bookmark.

    ps. add ‘title=….’ to ‘Bookmark this at Del.icio.us’ link :)

  5. The series on accessibility was very nicely written like rest of your articles. Thank you for putting this together. This will help a lot of us produce more accessible sites. The checklist from accessites is also a handy list to get started with evaluating websites for accessibility.

  6. April 25, 2006 by Digi

    This may be off topic but does someone know good wiki system that passes these accessibility checks?

  7. Thanks Roger—and expanding on it with a table of contents. I’m beginning to wonder if you’re considering publishing a book of your own. ;-)

  8. April 26, 2006 by Roger Johansson (Author comment)

    Olav: Thanks. Sometimes I can get a bit too thorough, but most of the time I think it’s a good thing.

    jakub: Good idea about the titles.

    PK: Thanks, I hope it helps. That’s why I wrote the articles after all.

    Douglas: As a matter of fact, I am. But don’t tell anyone ;-).

  9. The hard equation is how to make a professional looking, PSD based website, and at the same time accessible, loads quickly, and functional. After buying a $63 nice looking template from a famous website, I decided to give it up, since discovering that as much pretty the design is, as much isn’t practical at all.

  10. @Mag

    Your comment is quite a popular misconception about accessibility; accessible sites must be of a standard and boring design.

    In my experiences, you can still achieve even the most complex look and structure while still keeping the integrity of accessibility standards. The trick to it is proper planning in the structure of the site, from a design perspective.

    What I usually do is structure the content semantically into it’s proper markup without any CSS applied. (ie: h1, h2, p, ul, ol, etc.)

    Next, I take into consideration some of the common accessibility practises. (ie: accesskeys, skip to content links, reading out the order of the content for screen readers, etc.)

    Then, I look at the visual mock up of a design and see how I can section it off accordingly. (ie: areas for the header, content, subcontent, footer, etc.)

    From this point, I match up my semantic markup (h1, for example) with my sectioned off plan (header area) and match them up accordingly.

    I know I make it sound like a piece of cake here and this is quite summarized. Make no mistake. I end up pulling my hair out trying to get a design to work and tweaks are needed here and there, but I can usually get things to work. The key is the planning of how you’re going to tackle it.

    Basically, a good way to start is to look over the links Roger has provided in this article as the order dictates a good work flow to tackle the issue.

    My $0.02 CAD.

  11. This was a really great information source. Thank you for writing it! I’ll pass it to me coworkers here at our web development studio. This is a must-read information.

  12. Most of us are aware of the issues of Web accessibility, but do not know where to begin implementing accessibility. If we want to create an accessible Web site it is evaluating the current accessibility level of the existing site we should start from. That’s why your articles are of so vital importance!

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.