Slashdot Mirror
Cynthia Says... Create Accessible Web Sites
Kynn writes "The folks at ICDRI, in partnership with the Internet society and HiSoftware, bring us Cynthia Says, a free service to help you evaluate your Web pages for accessibility. In other words, it's roughly equivalent to what Bobby used to be, before it went commercial. It features what seems to be a cartoon version of my friend Cynthia Waddell, which is a bit creepy, but in all honesty it's a much better symbol than the old cartoon cop used with Bobby. I always thought there was an implied menace, as if the smiling chap would happily bludgeon you with his truncheon if you created an inaccessible Web site." If only.
Don't forget to use ALT tags!
Ok, ok, so there's more to it than that. However, in my designs, I've begun to apply the following rule of thumb in regards to web accessibility:
The page is accessible if it can be properly viewed and navigated using a text-based browser (i.e. Lynx).
Lynx forces the page creator to use ALT tags liberally, and it reduces or eliminates the page's dependency on things like Javascript and Flash.
What else, really, has to be considered outside of the limitations of a text-based browser? I'd love to read some comments from folks with more expertise in this area.
Cynthia throws the errors, but doesn't specify exactly what went wrong. For instance, the rule (paraphrasing) "every non-text element must contain an alt or longdesc tag" gets thrown, but doesn't say where the offense is coming from. In that same rule, Cynthia says that inputs must be inside forms. Why not break up the rules and show the user where they "went wrong". (by the way, I couldn't find in the page what she was complaining about--it checked out with Bobby and the validator)
Blind users or users with very limited seeing. That is also what the ALT attribute (there is no such thing as an ALT tag) is used for, to provide information about the image to the screen reader they are using. So, yes, the ALT attribute is used for things other than text browsers.
.swf file.
For example, why is Flash so bad for the web? Simple: say you have a blind user. How on earth are they supposed to navigate a Flash site when there are no ALT attributes to guide them and their screen readers can't "read" a
That's just one example I am familiar with.
-Vic
In case you have a problem with using something (at least partially) from HiSoftware (I know some Assistive Tech. Specialists who do), you might be interested in using the WAVE.
Here's a Google of some resources and info, as well.
Ultimately, the biggest problem I have, is that too many web designers utterly rely on these validators. The problem is, they can only check for a few different parts of the standard. For instance, an automated validator may only be able to verify compliance with maybe half of the W3C WAI (Web Accessibility Intiative)'s 65 checkpoints (that's in all 3 priorities). The other things have to be done manually, which is not really that bad if you understand what needs to be done and how to do it.
It's simply a matter of rearanging your design style slightly to accomodate some minor design principles. Unfortunately, most web designers think that a validation or repair tool will solve all of their problems. It won't.
I'd take advice like that with a pinch of salt, as the person dispensing it clearly demonstrates no understanding of the basic structure of an HTML document.
There is no such thing as an "alt tag". There is an alt attribute, which is a completely different thing.
That's a dangerous assumption. Take guiltless image use as an example. Works fine in lynx, but fails miserably when you use a browser that renders CSS but does not display background images.
Website accessibility is a complex topic, and there's no way you can automatically test something like this. The best you can do is provide hints on what to look for.
I'm not particularly inclined to trust Cynthia, as the report document produced uses font sizes set at 12px and 10px verdana (!), and gives horizontal scrolling at 1024x768.
One tool I have found to be of high quality is Accessibility Valet.
So, I checked my home page with Cynthia, and I got some complaints. They were reasonable. But then I saved the report Cynthia produced, and had her check her own code.
Here it is:
http://www.bertilow.com/div/cynthias_medicine/
And here's her verdict:
Verified File Name:
http://www.bertilow.com/div/cynthias_medicine/
Emulated Browser: Cynthia 1.0
Date and Time: 3/14/2003 8:34:15 PM
Failed Automated Verification
Emulated Browser: Cynthia 1.0
She failed! The reason is the crappy markup with loads of deprecated stuff. What were they thinking?
An example of a horribly designed web application is Campus Pipeline, used by some universities to provide student services. They do browser/Java/Javascript/cookie detection, and won't let you in unless you use the exact configuration they're expecting. Only portions of the site even use Java (for example, I wanted to set my email forwarding so I wouldn't ever have to use this interface again - no Java is actually used in this process, but you can't even log into the site if it's disabled). Although their web pages seem to render perfectly in Lynx/w3m/elinks/Mozilla/Konquerer/Opera, you can only log into the site with a user-agent of IE/Netscape.
For instance, I have a textual "home" link on every page that takes you to the site's home page. It also happens that I have made the graphical banner on my pages into a clickable link that will also take you to my home page. A blind person doesn't need to worry that there are two methods for getting to the home page -- there's one method that can be read aloud with speech-to-text software.
On the other hand, there may be other things on my site that really are accessibility issues. The problem is, I can't tell from Cynthia's output what they are.
It seems to me that the real need is for actual humans with disabilities to test web sites. Yes, I know that's expecting them to do something that they really shouldn't have to do, but I just don't think there's any alternative.
I've been contacted once by a blind person who was having trouble using my site. The problem, however, was with my PDF files, not with my HTML. Bobby and Cynthia don't check PDF. And in fact, it wasn't something that I was able to solve, due to the realities of the way I created the PDFs.
Find free books.
The problem is, it's not a matter of just allowing "text-only" browsers to correctly display your page; your pages should "make sense" from a semantical point of view, thus allowing semantic interpreters (such as browsers for blind persons and so on) to easily and correctly parse them. e.g. put the "title" attribute in your anchors, consider accesskeys, validate your xhtml, etc etc.
For further things, take a look at Dive Into Accessibility, a really good book.
-- Let's go Viridian.
The correct way of embedding a Flash presentation into an HTML document is to use the <object> element. Alternative representations of the embedded object should be encoded as the contents of the <object> element. This is actually far more flexible than using an alt attribute.
Unfortunately, browser bugs interfere with this quite a bit. Additionally, most flash authors are not willing/capable of producing an alternative representation of their Flash objects, so even though the capability is there, it won't make much difference in practice.
You need to return false:
<a href="alternative.html" onclick="dostuff(); return false;">...</a>For instance, argos.co.uk will refuse to handle gecko-based browsers. Idiocy.