Web accessibility: another thing to worry about

Most web designers and web developers ignore accessibility. Now that Target is being sued for not having an accessible web site, the bar is going to be raised for your own site as well. Yes, this is yet another thing to worry about. And no, you should not half-ass it.

If you cater to those with visual impairments, then you will also reap benefits from the world’s most famous blind user: Google. I kid you not.

HTML, the document format of web pages, was designed to be consumed by those with vision impairments, not just by those of us with good eyesight. Once again, everyone has gotten lazy and hasn’t learned how to truly use HTML for this purpose. I’m going to point out a few things that should be done to help improve your site’s accessibility.

Hear it for yourself in a screen reader

A lot of visually impaired people use programs called screen readers. Because they cannot see the screen, they must have the computer read the content to them, which is what screen readers do. Most of us are removed from this because we don’t need to worry about it in our daily lives. But trying out a screen reader will change your views on how the Web really works.

There is a great simulation of a screen reader on a fake website called University of the Antarctic. (Shockwave plugin required.) This site emulates the experience of using a screen reader to navigate a fictitious university site. There’s no chance for you to cheat because they don’t show you what the site looks like. It even gives you sample tasks to complete to see how hard it really is to find what you’re looking for if you must use a screen reader.

The most popular screen reader out there is called JAWS. You can download a trial of JAWS here and try browsing your site. To really get a feel for using JAWS as it was intended, turn off your monitor.

“Legal compliance” and “good experience” are not the same thing

Most people that are aware of web accessibility will immediately rattle off that you must comply with Section 508 of the Americans with Disabilities Act and the W3C’s Web Accessibility Initiative (WAI) Guidelines. Fair enough. But there’s a huge difference between complying with standards and providing a good experience.

Especially with the WAI, the standards were designed to be computer-validated. This makes sense from a time-savings perspective, but not from a human perspective. Will a computer know whether or not your web site is confusing to the vision impaired? Heck no. That’s why you should do spot checks of your site’s most important sections using JAWS.

Best practices for improving accessibility

When writing for the Web, most experts recommend that you do the following:

• Use plenty of descriptive headers to mark what each section of your content is about
• Use descriptive words in your links, which exludes the usage of the ever-vague “click here”
• Avoid use of text in images; use regular text for text!
• Use proper alternative texts for images, especially ones that must contain text in them
• Don’t be too verbose in your wording: keep it simple

Some scenarios worth considering

These writing best practices are also intended to improve accessibility. If you do get a chance to play around with JAWS or the University of the Antarctic simulation, you’ll notice that there are options for just jumping around between different key page elements.

• A blind person often chooses to just jump to each link on the page. Imagine the usefulness of the screen reader reading this: “Click here.” Out of context, does that really tell you where that link leads?
• Another option is to just have the screen reader read page headers. The more descriptive you are in your headers, the more you’re helping someone figure out if they want to read that section of the page.

Accessibility best practices are for everyone

Those of us with full vision use the web very similarly to those who must use screen readers. Our eyes are drawn to the same elements that screen reader users choose to scan. We automatically gravitate towards links and headers because we’re in a hurry. The only difference is that we don’t have to hit a key on our keyboards to have these elements read to us.

So your accessibility improvements help everyone out, not just the blind.

Practicing what I preach

Notice that all blog entries on my blog use descriptive link texts and headers where appropriate. I also try to use descriptive alternative texts on all of my images where appropriate. Those of you using Internet Explorer can check it out by hovering over the images and seeing what the tooltip says.

How about you? How are you ensuring that you’re meeting everyone’s needs? How can you improve? Need specific advice from moi? Leave it in the comments!