Ask an Expert About Web Site Accessibility
Joe Clark is an expert on handicapped accesibility for movies, TV, the WWW, and other media. The launch party for his new book, Building Accessible Websites , is Dec. 3, which is also the International Day of Disabled Persons, so this a perfect time to ask questions about how to make a Web site -- or a TV show or movie -- accessible. As usual, we'll send 10 of the highest-moderated questions to Joe, and run his answers verbatim when we get them back.
Dive In To Accessibility
WAI
Colour blind checker
ISU
- Nice looking in modern browsers
- Accessible
- Usable in older browsers
- Standards compliant
If you use CSS right. Wired did a pretty good job of it.Check your web site for accessibility using Bobby. I've found Bobby to be an invaluable tool when trying to design accessible web sites.
$SIG{__DIE__};
For advice on making weblogs more accessible my favorite resource has been Mark Pilgrim's "Dive Into Accessibility" series:
http://diveintoaccessibility.org/
The specific customization techniques he demonstrates are aimed at the most popular weblogging packages like movable type, and greymatter. But most of the tips are easily applied to any web site, weblog or not.
Aural Cascading Style Sheets (ACSS), part of the new CSS 2 working draft, promises incredibly simple integration of speech output in web pages. Web developers will easily be able to have their web pages speak to the visually impaired in multiple voices, volumes, and even position the voice! Why then, are there no implementations of this for any commercial browser, and why aren't developers embracing this powerful technology?
The ONLY implementation of any sort is Emacspeak!
To put it bluntly, in this regard, Slashdot sucks.
The site is absolutely littered with horrible, nonstandard HTML, broken tags, tables, markup hacks, and other things that would confuse the bejesus out of any web accessibility tools.
Of course, the first step to solving this problem would be to overhaul Slashdot to resemble SOME form of web standards-compliance. That single step would improve accessibility tenfold. Instead, Slashdot has decided to ignore the problem and pretend it doesn't exist. I noticed they actually went so far as to block the w3c's validator from accessing Slashdot. (When you try to validate it, the validator complains that it received a 403.)
For such a widely popular website, Slashdot is poorly constructed, and has made no effort whatsoever to rectify the problem. For an example of a really nicely created site, take a look at Wired sometime. Run a page or two of theirs through the validator. View their source. They've learned to favor div tags over tables for formatting, and their pages actually validate properly.
The first step to accessibility is valid HTML. If you want to go further, there are some good resources available.
-- Give him Head? Be a Beacon? :P)
(If you can't figure out how to E-Mail me, Don't.
I don't think you full understand the goals of W3C specs. They're actually aimed towards accessibility.
If you make your site "accessible", you're helping everyone access the content of your site, even if they're using screen readers, have poor eyesight or have a legacy browser such as Netscape 4 or even Mosaic.
Just because it's a "newfangled" CSS layout based website means it's somehow less accessible. In fact, it's the other way around. All your content is still there. If coded properly (proper semantics, and use of structure... not just endless amounts of DIVs with CSS classes), it's even a lot easier for, say, screen readers to use since they'll see the structure (Hn tags, ULs, etc...). That's a lot better than wading through a bunch of TD tags and spacers gifs that are used for layouts. In fact, you should only use table tags for tabular data.
Check out Wired.com for instance. It has a table-less layout. If you remove the CSS (Opera's user pages, or one of many CSS toggle bookmarklets for Moz) all the content remains easy to read and is accessible.
Now is the time to pursue full compliance with W3C specs.