dive into mark

Slashdot reviews Constructing Accessible Web Sites, by Jim Thatcher et al. The review is well-done (by Slashdot standards anyway), and very positive. I have personally read this book, and recommend it to everyone. As usual, the comments are filled with people who just don’t get it, but I am heartened to see so many highly-rated comments from people who do get it, who deconstruct the myths of web accessibility and explain them calmly and rationally.

As I tried to make clear in my online tutorial, Dive Into Accessibility, virtually all accessibility guidelines are about adding, not subtracting. Have an image? Add alternate text. Have navigation? Add a skip link. Have those wacky dynamic Javascript menus? Add regular text links. Whatever kind of exciting stuff you have now, keep it, but add this too. This addresses myth #1 (An accessible web page is dull, boring plain text).

In my day job, I am blessed with the opportunity to create a brand new web-based application that is pixel-perfect in Netscape 4. But the client is very concerned about accessibility issues. Compromises were made, tables were used, widths were fixed. But the site is Bobby level A-approved (basic accessibility guidlines), the HTML mostly validates as 4.01 Transitional (except for those Netscape 4 margin tags), and the entire site is usable in Lynx. The bulk of this effort was spent in phase 1, when we were designing the static prototype (page layouts, dummy data) that would later become our dynamic data-driven templates. For the most part, new pages we added later were accessible by default, because we started from known good templates and modified them. This partially addresses myth #2 (Accessible web authoring is expensive and time-consuming), although I will admit that this is somewhat an idealized case, since we are creating a new application from scratch. Retrofitting existing applications to be accessible is usually expensive, but retrofitting existing applications to be anything other than what they were designed to be is usually expensive.

Myth #3 is Web accessibility is too difficult for the average web designer. No no no no no. Tables are too difficult for the average web designer. Cross-browser compatibility is too difficult for the average web designer. User-centered interface design is too difficult for the average web designer. Accessibility is cake by comparison.

It was actually a lot of fun reading through the comments on Slashdot. One by one, people would come up with ridiculous examples of pointless mandated web accessibility. The Department of Motor Vehicles web site has to be accessible to the blind! That’s outrageous! And one by one, people responded by showing how the world really works, and how central the Internet is becoming. Actually, the DMV handles not just licenses, but also ID cards for people who don’t want or can’t get a license. So, if you’re blind, over 21, and want to buy a beer, you need to deal with the DMV. This addresses myth #4: Disabled people don’t use the web. Of course they use the web. In fact, the recent Southwest lawsuit brought to light how many things there are these days that you can only get on the web (in Southwest’s case, it was lower fares and special web-only deals).

The next myth (Good assistive technology can solve all accessibility problems) is trickier, because it plays on every engineer’s fantasy that technology can (and eventually will) solve all the world’s problems. If my site isn’t compatible with your screen reader, it’s not my fault; your screen reader sucks. What these people don’t realize is that screen readers are improving. Here’s a feature comparison chart of three major screen readers, plus older versions of the most popular screen reader (JAWS). You can clearly see how much progress has been made already. If you don’t provide skip links, the latest version of JAWS is even smart enough to notice similarities between pages and automatically skip repetitive navigation links and immediately start reading at (hopefully) the start of the main content. If you don’t provide a lang attribute, Home Page Reader heuristically analyzes text on the page to determine what language it’s written in. That’s wicked cool. But some things simply can’t be automated. Pages need good (and unique) titles; you can’t compensate for bad or missing titles on the client end. Images need good ALT text to describe their function; you can’t read what isn’t there. It will always be a case of meeting your users halfway.

The last myth (Web accessibility only helps people with disabilities) is the easiest, now that search engines rule the world. The next time someone stands up in a design meeting and claims that you don’t have any blind customers, ask them if they care about search engine placement. Then remind them that Google is a blind user who reads the entire Internet every month, and then reports what it sees to millions of its closest friends. Certainly there are many types of disabilities, and not all accessibility guidelines directly impact search engine placement, but I’ve broken out the ones that do. If you don’t at least implement those, you’re hurting yourself more than anyone else.

§

Respond privately

I am no longer accepting public comments on this post, but you can use this form to contact me privately. (Your message will not be published.)

§