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.
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.
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).
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.
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.
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.
- Chris Pederick’s Web Developer Toolbar for Firefox
- Firebug Web Developer’s Tools for Firefox
- Paciello Group’s Web Accessibility Toolbar for Opera
- Microsoft Internet Explorer Developer Toolbar
- GrayBit Grayscale Conversion Tool
- Opera with Voice
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.
- Eyes closed, voice on (with Opera).
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.