Confirming a Web Site’s Accessibility

Posted July 25th, 2007 by Mike Cherim

Is your site accessible? How sure are you? You know why web accessibility makes sense and understand the benefits. Because of this you’ve made your web site so it’s valid and compliant with current web standards. You’ve tried your best to use semantic mark-up and all that which gets poured into the very foundation of a quality web site. You’re pretty sure you’ve removed the barriers to accessibility and that any functionality is a progressive enhancement. But you’re human, and you know in your heart, deep down inside, that you’re not infallible. So what do you do? How do you launch your site knowing with absolute confidence you’ve done a good job?

Well, this is what I do, or have done, when trying to make sure my stuff is up to par.

Testing tools

I’ll get this out of the way first because it’s sort of a given. There are several automated testing tools on the web. For example, sites such as WebXact and Cynthia Says are right at the top of the list and you should use them (Cynthia is more convenient for me, accessed via my developer tool bar, but I like WebXact better). It costs nothing more than a little of your time. During which you may discover you used the same alt text on two linked images or some other obscure faux pas. These tools are great for odd-ball stuff like that. Want more? We have several listed on our Resources page. Remember, though, when it comes to automated testing tools and validators, do hold reservations and question their value. Sometimes common sense is required and should prevail — and web site usability should always be taken into consideration.

Peer review

I rarely do this anymore because I have gotten comfortable with the craft I suppose, plus I have developer friends I can contact privately, but if you’re a web developer you probably belong to a mailing list like the one for the Web Standards Group or maybe a web developer forum like SitePoint or Accessify Forum. If this is the case, don’t be shy about using these resources. Both mailing lists and forums are full of critical eyes and you’ll get some brute honesty, and if you take it all the right way, it can be immensely helpful. If you have to explain the site’s usability or start having to justify this or that, you need to realize you’ve probably done something wrong. It’s really as simple as that.

These fellow developers you’re asking are web-savvy human users. They all use different machines, screen resolutions, and user agents, so their feedback is invaluable. Some might cut into you a bit, but that’s their problem, not yours. Be warned, if you get defensive or find yourself arguing your points, someone may ask why the heck you asked for feedback in the first place and ignore you the next time you need help. Appreciate — and try to make a little time to give something back to said communities (which is the main reason I rarely use this avenue myself any more — no time to do it right).

Plain folk

I have people to call on for this and you may, too. Average “plain folk” users are another testing tool, so to speak. Have someone you know who isn’t in the industry look at your creation (or abomination) and try using it. Don’t guide them. Give them the web address and wait for feedback. Only have them ask you questions or provide feedback after they’re through. If you can, if you can resist the urge to point stuff out, and you won’t be asked how-do-I questions, you may observe quietly. Watching a user struggle with a feature on your web site is very telling. Bear in mind it doesn’t mean the feature is counter-intuitive and needs to be changed. There is, after all, a small learning curve on any site, and you shouldn’t feel compelled to make your site idiot-proof. Moreover, your user or user-group might behave uniquely so be careful to not put too much emphasis on their peculiarities. Look for the obvious problems that may affect lots of users. If they really struggle, you know you need to investigate. If they exhibit any of the following behaviors, it’s back to the drawing board.

  • A bout of Tourette’s syndrome-like swearing.
  • User heaves monitor out kitchen window.
  • Stands on chair looking for a usable viewing angle.
  • Exclaims surprise over blinking headings.
  • Has convulsions or a seizure.

Developer tools

Of great importance to me as a web developer is my stable of browsers and web developer browser add-ons. This is what I happen to have followed by what I do with them:


These are Windows-compatible browsers that I actually use to check my work. I have others, but they aren’t needed. I don’t own a Mac so… I get by with a little help from my friends.

Browser Add-ons

I use the first tool on the following list daily. The rest on an as-needed basis only. There are other tools out there, but I really don’t find myself in need of more tools.

Using the Tools

Having tools is all fine and good, but using them is where it counts. Using the tools above, as indicated, and in addition to mark-up and cascading style sheet (CSS) validation, and visual contrast testing, what I test on every site/blog/application I make are these down-to-earth basics (all done with Chris Pederick’s Web Developer Toolbar unless otherwise marked):

  • CSS on, images off.
  • CSS off, images on.
  • CSS off, images off.
  • JavaScript off.
  • Eyes closed, voice on (with Opera).

Final Thought

I also do other things like use my creations with a keyboard and check other media-type style sheets, and I find that between these additional practices, the browsers, the tools, and the five conditions above, I get a really good overview into the sheer accessibility and usability of the work at hand. The longer I do this the easier it gets and the testing seems less necessary, but I have found that what I have mentioned above is an invaluable collection and strategy.

But that’s me. What’s on your short list? What are the tools you use daily to keep your sites ship shape? You know, the real testing tools, the ones you strap on every morning.

9 Responses to: “Confirming a Web Site’s Accessibility”

  1. Gert Van Heghe responds:
    Posted: July 26th, 2007 at 2:00 am

    Nice article, Mike. I really need something like this now and then to keep me motivated to accessibility. And I know I still have a lot to learn and a lot of work to do… Thanks !
    I hope you don’t mind me drawing your attention on the misspelling of Chris Pederick ’s name twice ;-)

  2. Jermayn Parker responds:
    Posted: July 26th, 2007 at 2:19 am

    Normally I do about half of that but kinder feeling guilty in reading that, so I may have to lift my game a bit.

  3. Blogg: Hur säkerställer man tillgängligheten? | digital venues. responds:
    Posted: July 26th, 2007 at 2:55 pm

    […] Hur gör du för att testa att den webbplats du skapat verkligen är tillgänglig? Mike Cherim tipsar om hur han gör i artikeln »Confirming a Web Site’s Accessibility«. […]

  4. All in a days work… responds:
    Posted: July 26th, 2007 at 9:03 pm

    […] Confirming a Web Site’s Accessibility You’re pretty sure you’ve removed the barriers to accessibility and that any functionality is a progressive enhancement, but you’re human, and you know in your heart, deep down inside, that you’re not infallible. So what do you do? […]

  5. Mel Pedley responds:
    Posted: July 27th, 2007 at 6:34 am

    Personally I couldn’t manage without the Colour Contrast Analyser which I use constantly whilst designing.

    Other resources on my Useful Tools list include the Opera Mini simulator for reviewing sites on a mobile phone, Tidybot for XHTML syntax-checking of whole sites, Juicy Studio’s Readability Test and the Web Page Analyzer which highlights any downloading issues.

  6. Koen Willems responds:
    Posted: July 29th, 2007 at 8:46 am

    On top of my list is the Web Guidelines QuickScan.
    It will test that part of the Dutch Webguidelines for Governmentsites that can be automaticly tested.

  7. Adam responds:
    Posted: August 3rd, 2007 at 5:21 am

    I use most of the same tools Mike and a couple of extra ones. The additional ones are aids to developing. I use the HTML Validator plugin which helps me maintain valid html while i’m developing and Dust-Me Selectors to analyse the your css to find redundant selectors. For testing I like using Truwex as well as webXact.

  8. Confirming a Web Site’s Accessibility ( / Web Words / WizarDev responds:
    Posted: August 7th, 2007 at 8:50 am

    […] Read Confirming a Web Site’s Accessibility […]

Sorry. Comments are closed.

Note: This is the end of the usable page. The image(s) below are preloaded for performance only.