Someone asked me what someone should know/read as a crash course on web accessibility. This seemed like too good a question not to blog about so he can read the answer here!
There are three main areas of web accessibility:
- W3C’s WAI (web accessibility initiative) has WCAG 2 (Web content accessibility guidelines) which are summarized on one page. There’s a lot more to it than the one page, but it does represent the spirit.
- WAI also has ARIA (accessibility rich internet applications). This is my favorite description. Mozilla also has a good guide as does Opera. In a nutshell, ARIA solves the problem of “how does a blind user know something on the page has changed.” With AJAX and even DHTML, just because you made something available isn’t enough. Be forewarned that older browsers have lousy ARIA support if any at all.
- Section 508 is in the same space as WAI except for government website. It is part of the American with Disabilities Act. It is more specific in some ways than WAI. If you aren’t working on a government website, I’d focus on WAI. Note that Section 508 is an OLD law and in theory they are working on a refresh. I say in theory because I haven’t seen updates in a while. There is a mapping in section 1194.22 between Section 5098 and the WCAG 1.0 guidelines. Yes, 1.0. Did I mention that Section 508 is old? The government has free training.
The least you need to know for testing:
- Make sure your application works without using a mouse. Seriously, actually navigate your application without a mouse. (Remember tab changes fields and space selects a checkbox.) If it isn’t possible to use the application without the mouse, you have failed accessibility miserably.
- Make sure you aren’t using color alone to convey information. Blind people will be using a screenreader and need alternate textual ways to derive this info. Colorblind can’t see the difference between red and green and won’t be using a screenreader so won’t see your alternate text.
- Until you are REALLY familiar with how text only navigation works, use a screenreader emulator like the Fangs Firefox plugin and/or turn off stylesheets to see what your page looks like.
- If you can afford a license for Jaws, it is helpful in testing that your application is accessible in practice and not just theory.
The least you need to know for coding:
- For any image that conveys information, have an alt attribute.
- Use form labels for all form elements so a screenreader can read what the form element is all about.
- Use row and or column headers for all data tables so a screenreader can provide assistive text on where the user is in the table. (And for the love pete, don’t complicate things with the navigation tables of the 90s)
- I recommend automation to ensure you KEEP compliant. It’s a pain to test this all once manually. You don’t want to have to make sure the new person on your team remembered his/her alts.
- Watch how you use JavaScript: Remember we need to work without a mouse. That means an onchange handler in a pull down is the path to madness. I want the fifth element so I tab to the field, choose the second, watch the page refresh, tab to the field again, choose the third, watch the page refresh and then decide never to do business with you again.
- Some JavaScript libraries have accessible widgets.