WCAG, 508, AAA ... help! web access guidelines

Thats about the main ones.
Things like Bobby (watchfire) aren't true validators, unlike W3C, they can only guess what your code is being used for so can often get it wrong (same for 508 and the others).

If you are coding in tables, get yourself an older version of the Opera browser (think its version 6 and 7) as it has option to disable tables. Some screen readers can read tables though, but if site can be read with tables turned off all the better, and use table summaries in every table tag.

Design your pages without CSS, then add CSS and test your browser in IE4 or NS4 (I use NS4.7 - good browser), as this can also show what a screen reader/viewer can see/read

lynx is a good way to test them without the above, but you have to remember there are different levels of accessibility.

Wave is another validator and Jaws (not free) is a screen reader

I have another quick question on this subject. What is the importance of WCAG priority 1, 2, and 3? I have made sure that I adhere to priority 1, however some of the techniques that priority 2 and 3 ask for I can't do because I work for a design firm and there are compromises I just can't make. For example, removing a static width or putting something other than whitespace between links. Should I force the designers to make these compromises? or can these problem be somewhat ignored since they are not a 1 priority?

Thanks for the help Busy. I checked out "Wave" and that found a couple more errors. I think for the use of people in the future I'm going to list a few of those weird tags and techniques that might help out people in the future.

- a summary of any tables used (noted previously by Busy)
- use strong instead of bold
- alt tags on all id's and buttons
- labels used on input fields
- CSS - use "em" instead of "px" when determining the "font-size"
- CSS - use relative widths and heights instead of static dimensions for layouts
- CSS - if you specify a color then you must specify a background

of course this list goes on forever, these are some of the things that I found myself fixing over and over that I didn't think about so with any luck it might help to save some you out there some time.

-Ryan

Here's how the W3C define the differences between the checkpoints (am assuming you missed this amongst the myriad other information on there!)

w3.org wrote: [Priority 1]
A Web content developer must satisfy this checkpoint. Otherwise, one or more groups will find it impossible to access information in the document. Satisfying this checkpoint is a basic requirement for some groups to be able to use Web documents.
[Priority 2]
A Web content developer should satisfy this checkpoint. Otherwise, one or more groups will find it difficult to access information in the document. Satisfying this checkpoint will remove significant barriers to accessing Web documents.
[Priority 3]
A Web content developer may address this checkpoint. Otherwise, one or more groups will find it somewhat difficult to access information in the document. Satisfying this checkpoint will improve access to Web documents.

The original document is at: http://www.w3.org/TR/WAI-WEBCONTENT/full-checklist.html

It's also very important to read and understand the checkpoints, some just cannot be checked by an automated validator and need a human to check them.

You really need to pick just one and go for it if not a basic site as several of these (508, wai, aaa ...) have conflicts against one another. What will be good and validate in one will fail in another, some of the work arounds are sensible and usable, others are just impossible.

The only way you can make your site 100% accessible is to cater your site for hearing or vision impaired and design/code it using a screen reader (one type only as they also differ) to help build it.

example: not having an alt tag is bad, having an empty alt tag is good (alt="" as screen reader will skip it, if not alt tag reader will read the tag) using a badly written alt tag is worse than not having an alt tag (picture of flower causing hayfever - alt="awww but isn't it pretty"). Using a title with an alt can have it's ups and downs as well. This is also for links, 'click here for more' is bad, but can be made good with a descriptive title title="internal link going to next page

I'm all for accessibilty but the companies who make screen readers etc wont give out free versions of their products so testing is really hit and miss. Lots of people try to work within these guidelines but fail as they can't test it.

Working to XHTML Strict guidelines (with and without CSS) can be just as good as using bobby watchfire.

It's basically impossible to get AAA compliance, although many a website has the logo on of course! You're talking about having sound clips and everything.

I am a member of accessify.com, an accessibility forum. It might help to start there.

JAWS is the ultimate test really. I have seen many a compliant website which has major usability issues in different browsers. At the end of the day there are accessibility laws and accessibility guidelines. If you had an HTML and CSS valid website then it would pass any law. Ideally if you had a CSS website you could have an alternative stylesheet that strips all of the fancy content, like on the BBC website.

Cheers,

-Rob