Slashdot Mirror

← Back to Stories (view on slashdot.org)

Cynthia Says... Create Accessible Web Sites

Posted by michael on from the or-else dept.

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.

5 of 35 comments (clear)

  1. Not very usable by Enrico+Pulatzo · · Score: 2, Interesting

    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)

  2. Re:Yet another Web Accessibility article by krs-one · · Score: 2, Interesting

    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.

    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 .swf file.

    That's just one example I am familiar with.

    -Vic

  3. Might want to mirror the results. by Anonymous Coward · · Score: 1, Interesting

    Given that slashdot forbids validator.w3.org from validating its pages (must have something to hide), I expect this new thing to get frozen out soon enough as well.

  4. Her own medicine by bertilow · · Score: 3, Interesting

    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?

  5. Re:Yet another Web Accessibility article by Anonymous Coward · · Score: 2, Interesting
    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.

    • Pages depending on Java/Javascript (if you're testing with a text-based browser that supports JS, you might not realize the problem). No HREF tag should ever point to "#" or "javascript:...". Many sites use this for popups. You can add an ONCLICK element to a link to open a new window if you want, or use TARGET="_blank" (IIRC), but make sure you leave the HREF pointing to a valid page. If your javascript function returns a specific value (possibly 0, but I don't remember for sure), the browser won't follow the link after opening the popup. Ideally, don't use popups - if the user wanted a new window, they would have used their browsers "Open in new window" function (or maybe they want a tab, and will use that function).
    • Browser detection, and pages that think they need Java or Javascript when they actually don't. Some sites look at your user-agent string and tell you to fuck off if they don't recognize that browser (that's the impression the user gets anyways - usually the actual message is something like "You need browser X to view this site, download it here"). Some pages do the same thing if they detect Java/Javascript/cookies are disabled, even if they don't need these functions. It would be fine to give a warning that certain features won't work, but you should never block access completely (for example, disabling cookies might block access to the members-only section of a site, but you should be able to see all the other pages).

    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.