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


  1. Nice Roger, I’ve been waiting for this follow up hoping it would be as good as the first, and it is. My only comment is that as good as Fangs is, Jaws is available for download to developers at no cost from here and here although they are limited versions (can only run for 30 mins at a time)

  2. I think, that Fangs can’t read the title atribut in abbr and acronym elements.

    Then is important to know, how much is Fangs works with text distinct from normal screen reader. I think, that there are some important differents.

  3. Too bad I can’t GET a working version of fangs. The link above goes to a 403 page. I went to the FF extensions page, where they list a version for FF 1.0, but the comments say you can get it from sourceforge, so I go there, download it, and it doesn’t work.

  4. Thanks for the excellent part 2 of this ‘series’. Though I already do this when validating sites, I did learn something I hadn’t checked before: the image alt text color (if it inherits the color from a previous declaration). It’s a good day when you learn something new.

    Great read.

  5. March 16, 2006 by Daniel

    What about the most important part: real usability testing? There is always a user context you have to take into consideration.

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

    Scrambled: Real screen readers will be mentioned in Part 3.

    Baxter: The problem is temporary and is being looked into.

    Daniel: Of course. I made a note of that in Part 1.

  7. Scrambled: I agree that it is better to test with a real screen reader like Jaws. However, it takes ages to do the “code, listen, fix”-cycle with Jaws. On top of that Jaws installs features in your operating system you may not want (remember that Jaws is not for web only).

    Fangs emulates Jaws 4.51, the most widely used version. Screen reader users typically upgrade less often compared to people who use visual browsers. One reason is that an upgrade may set you back $300.

  8. March 16, 2006 by Phil Evans

    I still use Fangs in preference to the free Jaws downloads - I find that since I don’t use a speaking browser frequently, I don’t know my way around well enough to test efficiently. Fangs gives a reasonable overview for my purposes.

    Of course what I should do is get properly au fait with Jaws so I can use it efficiently … but there are never enough hours in the day ;)

    Excellent follow up to an excellent first article, Roger!

  9. March 16, 2006 by Daniel

    Roger, I saw your note. But I still think that usability testing is far more important than this checklist. Of course it’s good with checklists/guidelines but too often it’s used just as an alibi.

    Hey we comply to the WCAG - this site is accessible!

  10. Nice article Roger. Informative as always. I hadn’t heard of Fang, so will have to check it out. Looking forward to part three.

  11. March 16, 2006 by Marc Luzietti

    As I recall, accessibility requires that you make “your best effort” to make pages accessible without scripts, etc. Obviously for some stuff, alt-text and so on, there is no excuse for anything less than 100% compliance.

    On the other hand, some functionality simply may not work without scripts. I recall one client’s medical web-based app which had a script which kept track in the background whether or not someone had updated a patient’s file. That’s something a medical person needs to know immediately, and can’t simply hit refresh every ten seconds to find out if that is the case.

    Accessibility is also a two-way street. You simply can’t account for every possible situation and have a right to require a user to have either sufficiently modern accessibility software or use the right tools. In the case of the aforementioned medical web-app, users would have to use IE with Windows’ accessibility options and sound enabled. Thus a musical tone could alert someone to a change to a medical file.

    The point is, accessibility means more than absolute adherence to a set of standards. It means actively thinking about the usability of the page, about functionality, and what is called for in each specific situation. If you use standards to force you to jetison necessary functionality, it will be useless. Worse, it won’t be accessible to anyone.

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

    Daniel: This list is just one part of the quality assurance process. Nowhere am I saying that this is all you need.


    If you use standards to force you to jetison necessary functionality, it will be useless.

    Of course. That’s why you have to provide an accessible alternative if it is impossible to “Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported” (WCAG 1.0, Checkpoint 6.3).

    It doesn’t say that you have to abstain from adding that important functionality.

  13. This is a great addition to Part 1 and I’m really looking forward to reading Part 3. It’s great how you emphasized how useful the Web Developer extension is in testing any particular site.

    Unfortunately as of late I’ve been having some difficulty with Fangs, an extension I’ve been using for quite some time. Recently many pages show no output when using Fangs for one reason or another. Some work and some don’t and I’m not sure why — any ideas?

  14. March 16, 2006 by Marc Luzietti

    Roger, I think the more important checkpoint relative to my point is 11.4 (http://www.w3.org/TR/WCAG10/wai-pageauth.html#tech-alt-pages). Some way of accessing the information needs to exist, just in case you can’t degrade gracefully.

    In the example I used earlier, a link could have been added which refreshed the page with newly added information emphasized and at the beginning. In that case, “strict” accessiblity would be enhanced, but it wouldn’t be as usable as requiring particular software on the user’s part (in a captive environment, I’m not thinking of a casual web user).

    Another client made contact lenses. This is one of those situations that requires you to think. At first this seems like a no-brainer, but; blind people don’t need contact lenses. They aren’t their market. On the other hand, it is a product for people with [i]some[/i] level of visual impairment. They probably could have made a very good case for skipping alt-text since the only people impacted wouldn’t be accessing their site anyway. In the end they chose to include it.

    My main point, I guess, is that the most important tool in the accessible designer’s kit isn’t a checklist, validator, etc., but the brain.

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

    Jon: Are you sure you have the latest version of Fangs? I haven’t had any problems since updating.

    Marc: I’d just like to add a point about alternative text: it is not meant just for blind or visually impaired people. It is there for anybody who cannot access the image for whatever reason. That includes perfectly sighted dial-up or mobile phone users that disable images to speed things up. And there’s a good chance your client has at least some customers in that group. Plus I’m pretty sure that if you’re in the contact lense business you want every search engine visitor you can get, so…

    Other than that, we’re saying the same thing I think ;-)

  16. March 16, 2006 by Jachinls

    For those of you complaining about Fangs, the latest version (Firefox 1.5+ compatible) is available at Standards Schmandards

  17. Roger - good news about Part 3 and I’m eager for it, I will be sure to forward the links for essential reading for our Developers. Peter - Sorry I was trying (and failing I guess) to say that a screen reader is useful as an addition to Fangs, for actual page per page development its just not reasonable to use a screen reader which is why Fangs is so good.

    ps one nice to have for it would be a comparison of what differences there are between its (Fangs) rendering and Jaws (if any I remember there was one?)

  18. March 17, 2006 by Matthijs

    Great series Roger, thanks. Looking forward to the next. One question: I know the next article will talk about non HTML formats, but can anyone already tell me about the accessibility of word or txt documents? For a website in which pdf and word-files can be downloaded, I was thinking that adding the same documents in txt format as well would be better?

  19. To answer [18] HTML is typically more accessible than generic plaintext or pdf. Though I expect that will be expanded upon, so I won’t go into any further depth about the pros and cons.

  20. This is an excellent article. It’s very useful to have a straight-forward step by step guide to what to look for when auditing a site for accessibility.

    I hope in the next part you may look at interface design and the more asthetic elements (although I’m aware this may be heading down an unrelated path, but it’s just as important to accomodate for completely able persons, as well as those on dated machines/alternative methods of browsing in my opinion), as well as keyboard navigation and other such things most people would never consider.

    If you feel up for it, it’d be great to have some follow up articles on designing with accessibility in mind, and still creating really beautiful, functional, sites. eh?

    Good stuff. :) I really enjoy your guides!

  21. March 18, 2006 by Anura

    Another great things these articles show is the tight fit between accessibility and web standards.

    One of the things that always bugged me was getting stuff from so-called professional web developers who didn’t even check the basics. All of Roger’s suggestions are (1) easy to do and (2) free. Nice, standards-based sites and accessibility must be wins for everyone.

  22. ehm, seems that blank comment without name and email will be posted as well…sorry, I just trying out something ^^

    back to the topic, thanks for your 9 checkpoints, I will have to check each of them on my site, your article is well structured, and have great explaination.


  23. March 19, 2006 by Roger Johansson (Author comment)

    alenn: Oops. Guess I’ll have to check my comment submission script.

  24. Emma, in the first paragraph, where Roger says “I recommend reading Part 1…”, the title of part 1 is also a link to it (Maybe it should be in the red-brown linnk colour to make this more obvious?).

    Roger, excellent article as usual. Looking formward to part 3…

  25. March 20, 2006 by Roger Johansson (Author comment)

    Chris: I believe that comment was spam. It looked spammy enough for me to delete it anyway.

    And thanks. Got a bit of polishing to do on that third part.

  26. I like to read another great series posting from you, thanks.

  27. April 10, 2006 by Johan

    I have noted an irritating problem with text-sizes that I think you should add a warning about to your text. A lot of sites uses some kind of settings screen for letting the visitor choose a text-size. All fine by me, but a lot of them thinks that normal, large, and largest/~er doesn’t have to be much different from each other! Probably in a very questionable attempt to keep the layout nice even with “large” text-sizes. You should add to your list that if you allow visitors to change the text-size they should be able to change it to a MUCH larger size. If they really need the option of having somewhat larger texts they need to add more choices (like normal, slightly larger, larger, much larger).

  28. Hej Roger!

    First off, thank you for your insights. I am, and have been a daily readerfor almost a year now. Now, the purpose of this comment is to inform you that I plan on translating this very article into French and, before proceeding, request your permission to do so.

    The translation would be posted (with original author information of course) on the Pompage website (see pompage.net/about/for a quick presentation in English).

    Should anyone else have already made your article available in my language, please let me know!

    Also, I find this second article “richer” than the first in the series, I hope to find time to translate the whole series should this enterprise prove manageable. All requests/suggestions/etc are welcome, of course.

    Thank you for your attention.

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

    Johan: Yes, that is a valid point. Will look into updating the article.

    Goulven: Nobody has offered to translate this into French yet, so you hereby have my permission to do so :-).

  30. August 10, 2006 by collin

    I have a question about pt. 4, Images and Alt Text.

    “Also check that the alternative text is actually visible when images are turned off”

    I have a design that I must implement with links that have white text and a dark background image that changes on :hover. I clearly need to set the background color of the link as a “backup” for when the images are not visible. Here’s the problem: When the background image is switched on :hover in IE, there is a brief moment where the big, rectangular background color shows through, which looks terrible. I’ve tried Pixy’s Fast Rollovers 2 but it doesn’t work for me. Does anyone have a solution that keeps IE from going flicker-crazy?

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.