One of the things we focus on at Koodoz is making our sites accessible. We try to bring all our sites to a minimum standard that will make it easy for users with disabilities to access our sites.

Previously, I’ve had some of the sites that I’ve done, tested for accessibility in focus groups. Unfortunately, they were always held by third parties who were not able to technically interpret test subjects’ concerns in a way that was really helpful for us. I’d get reports with things like “User couldn’t make their way to page X”. No reasons, no detail. Nevertheless, I’d read a lot of theory regarding what to do and how to do it, and always tried to implement most of it.

Recently, however, an awesome friend from my master’s course, who is visually-impaired, needed help building a website, so I offered to help her. It was a win-win situation: she would learn to hand-code some good (x)HTML and I would get an awesome, first-hand assessment of my accessibility skills. Here’s what I learned.

It’s JAWS, stupid!

I’m a GNU/Linux person, so I tend to forget that 95% of people still use the old Windows. Turns out that blind users are no exception. Apparently Job Access With Speech, better known as JAWS, is the standard screen reader. Sure, there’s Orca and the built-in OS X screen reader VoiceOver but the fact remains that most visually-impaired users will use JAWS. So do the Adaptive Technology Rooms at Monash University. It’d be nice to see them change, but from what I can tell, it ain’t gonna happen anytime soon: not only does JAWS seem to be much more powerful (haven’t tested the other ones, but it’s what my friend and her pals say) but apparently they become used to the program’s voice which makes people hesitant to switching. Turns out we’re all resistant to change!

So, if you can, get yourself a copy of JAWS or painstakingly go through their documentation. Just know that if you support it, you’ll be OK. However, be warned that …

You may be wasting too much time where you don’t need to

Yes, you heard me! Remember all those neat <acronym>s and <abbr>s? Remember the scope attribute for tables? Remember the alternative content for standards-compliant flash? Well, JAWS doesn’t. It couldn’t care less about them. It goes right through them as if they weren’t there.

Now I’m not saying you should completely dump these things. Just be aware that if you’re doing it, so that your visually-impaired visitors feel more at home, you may be wasting your time. If you really want to make your content accessible, mention your acronyms and abbreviations inside the text at least once, make your data tables as simple as possible and provide descriptions for your non-essential flash pieces outside the object tag.

Things that really matter

OK, so the <acronym>s are not that important. There are some things, though, that you should really focus on:

Adding the old “Skip Navigation” link and keeping menus simple

Us human beings are impatient. We want stuff and we want it now! Visually-impaired users are no exception. Imagine having to go through a large menu each and every time you visit a page, when what you really want to do is get straight to the content. It can be pretty repetitive and boring. Always provide a “Skip Navigation” link at the top of your menus. You can hide it with CSS if you want, but I’ve found that keeping it visible can actually be pretty cool — and helpful. Take a look at The Web Standards Project for an awesome example of a visible “Skip Navigation” option.

Also, use <ul>s and <li>s for your menus. You can manipulate them later in any way you want, but it will make them simple and clear enough for the screen reader to interpret them correctly and read through them quickly.

Alternative descriptions for images and flash

How many times have you added empty alt attributes to your images just to trick the validator? Admit it, you’re guilty!

Now, in all seriousness, you need to be super careful with this. “A girl” is not an acceptable description for an image. It’s too vague. Remember that you’re trying to depict the content of your image to someone who can’t see it!. Vision Australia has really good examples of how images should be described. Here’s one:

Girl in front of a bowling lane. The lane has shiny polished floor, rails up and a coloured board above the two pins standing up.

See? That didn’t take too much time, did it? Same goes for flash elements. Just remember to do it outside the <object> tag.

Kosher forms

Exploit all of HTMLs form elements and do it correctly. By this, I mean use <label>s and properly link them to their inputs. Logically group stuff with <fieldset>s, naming those groups with <legend>s and make good use of tabindexes.

Well, that’s all for now. I’ll probably be doing a second installment to discuss some other things I learned from my friend, including CAPTCHAS and things specific to low-vision users. In the meantime, be sure to check out the w3C’s Web Content Accessibility Guidelines, Section 508 of the U.S. Rehabilitation act, these guidelines from the University of Wisconsin and to validate your site with the Cynthia accessibility report

By the way. My friend can now hand-code quality, standards-compliant (x)HTML code. She learned in just two sessions!

Image courtesy of Jason Pearce