I need a crash course in the current best-practice website accessablity standards.

October 14, 2009 6:42 AM

Give me a crash course in making our nonprofit website accessible. What are the best practices/standards? What's the lingo?

I'm not building the site, but I have a meeting with the developers who are, today. They are doing this pro-bono for us (we're a community nonprofit with a goodly number of disabled users). Its important to our CEO that the website be accessible, but she hired me because she doesn't really understand the web.

I get the web fine, but I've never had to deal with this particular issue before. My first meeting with the developer is this afternoon. Help me talk with them about this issue and not sound like a N00b!

posted by anastasiav to technology (7 answers total)

In the USA you want to meet the criteria for Americans with Disabilities Act Section 508.

New York State Information Technology Policy (launches a PDF download) has a pretty straightforward list of things to do in regards to 508 and WAI Guidelines.
posted by furtive at 7:00 AM on October 14, 2009

Okay, here's the thing: published standards do exist, but if you read the rules on the standards, some specific rules are so fuzzily defined that not only can the tests for that rule not be automated, but you sometimes aren't sure whether or not you pass. I scratched my head for a while over these until I said, "You know what, this is about people, not standards."

There's a great site called "Dive Into Accessibility." Basically, it points out that there's all kinds of profiles of people with disabilities, and you need to consider each in turn.

Here is a partial list of my tests:

1) Can I navigate the site using lynx? This is a text-only web browser, runs off of the command line. If you can get around the site with lynx, that is good.

2) Can I use the website with Javascript turned off? This is less and less of an issue, but it is still important.

3) Can I use text resizing and the site doesn't break until after the third enlargement? The elderly and those with low vision often turn up their font sizes.

4) Screw with your mouse for a while and make it completely oversensitive, then hit your mouseovers. If you can't use your site, you're ticking off people with shaky hands or poor coordination.

5) Can I use the site with Flash blocked?

6) Can you hit the various colorblindness tests and use the site?

7) Can I use Opera's small screen emulator and use the site?

8) Can I pass XHTML 1.0 Transitional validation? Can I pass CSS validation?

Then the other thing I hammer home to everyone, like I am a cheerleader: search engines read your site just like someone with really serious disabilities. Almost every bit of help you give the disabled goes to giving additional help to search engines. Sadly, this seems to go a lot further in convincing people to do it than anything else I say.

If you can, get together a broad spectrum of your disabled users who are also not super computer-savvy. They are your test group. If they cannot use it, or find it unpleasant to use, then it's back to the drawing board.
posted by adipocere at 7:05 AM on October 14, 2009 [1 favorite]

Accessibility basics:

• accesskeys (keyboard shortcuts, a feature of HTML) built into everything: site navigation, forms, etc, with a clear explanation of how they are used on the site.
• Title attributes for everything, most especially images.
• Summary attributes on tables (which should only be used for tabular data).
• Good, clear, high-contrast use of fonts and colors.
• Fluid design, so the page can be resized and magnified easily (possibly with JavaScript buttons to do the same, loading alternate CSS stylesheets).
• On forms, use of the for attribute to link labels to their associated inputs.

I hope this helps!
posted by Bora Horza Gobuchul at 7:08 AM on October 14, 2009 [1 favorite]

Also try to remember, you;re not trying to reproduce the site as a sighted person would see it.

So if you have a lame clipart image of some people on a beach before your article about visiting the ocean, give it a blank alt attribution (alt=" "). There' no need to waste the person's time by making them listen to "A beautiful sunset with two people in the foreground looking at each other wistfully."

And same thing goes for bullets. I attended a 508 compliance lecture given by a blind man. He hit a website with his aural browser.

"List item. Bullet. Truck. Next list item Bullet. Car." It was funny and annoying.
posted by cjorgensen at 7:22 AM on October 14, 2009

I think one important thing is to try not to get too stuck on the idea of adjusting the site for 'disabled users'. It's more about ensuring the site is well-built and well-designed so that it's broadly compatible with a wide range of browsing software and clear and easy-to-use for humans. There are some specific things that can help/hinder people who access the web in specific ways, but 90%+ of it is simply about having a good site.

Also be aware that some things listed on checklists are either of dubious merit or potentially problematic. For example, it can be hard to make accesskeys genuinely useful, and over-labelling things with titles etc. can make web pages unnecessarily 'noisy'. So the developers need to apply common sense rather than blindly following crude checklists.
posted by malevolent at 7:23 AM on October 14, 2009

The RNIB's useful links on making websites accessible are pretty damn comprehensive.
posted by Coobeastie at 7:48 AM on October 14, 2009 [1 favorite]

Why not see if any of your disabled users would be interested in consulting on this? It could be a very valuable experience for your pro-bono developers, plus you'd all learn a ton by talking to people who actually use the web with these kinds of conditions. I guarantee you'll discover something that's not in any written standards document, and your developers will even become more marketable.
posted by amtho at 8:49 AM on October 14, 2009