Authors of web content should be aware that authoring tools that claim 'compliance' may not mean compliance with their local standards. For instance, compliance with US law does not equal compliance with Australian law, that is a bit more demanding.Australian standards.
Generally, the Australian standards are based on the W3C's accessibility guidelines. See more information.
Kerry Webb presented a summary of what is being done in the various Australian goivernments about accessibility at the OzeWAI 2001 Conference in Melbourne in November 2001. See http://www.OzeWAI.org/
The US Access Board, who published the 508 rules, provided an analysis of the differences between 508 and W3C's Web Content Accessibility Guidelines (the most common reference in other legal systems), but it may be wrong in some important particulars (see below).
There is another comparison between 508 and WCAG level A done by Jim Thatcher, formerly of IBM access - http://www.jimthatcher.com/sidebyside.htm - and a further one provided as part off the AccRepair Tool from HiSoftware (this is an expensive way to get a comparison). Note that this is different to comparing double-A or triple-A.
The important difference between the US and Australia is about how the legal framework itself is set up. In the US, Section 508 is a set of rules that must be met for anything purchased by the Federal government or with their money (i.e. grants to States). In Australia, the legal requirement is "not to discriminate against people because of thieir disability". So it is more broadly applicable, and there is no absolute set of rules. The current recommendation of the Human Rights and Equal Opportunities Commisssion (HREOC - http://www.hreoc.gov.au/ ) is to implement WCAG as far as possible, but the resolution process is complaint-based - if somebody has a problem, they make a complaint and the parties are brought together to work out how the problem can be fixed. Implementing WCAG to any level is not a guarantee, but implementing to level double-A is what I believe will avoid problems arising, and is in any case evidence of good faith (which is helpful, as shown by the results of the Sydney Olympics website case).
The situation in European countries is different again (and there is the Europoean parliament plus a number of national and local governments to complicate it), but in general the standard applied is WCAG, to level A or double-A. (There are also a number of US states who use WCAG rather than Section 508).
Please note that if you need real legal advice you should get it from a real lawyer as explicit advice on the question.
Charles McCathieNevile contributed the following notes.
" (this isn't W3C policy, this is my personal 2 cents worth):
The Access Board themselves described the differences as follows:
[begin quote - heading line and 5 paragraphs]
"Section 1194.22 Web-based Intranet and Internet Information and Applications
In the proposed rule, the Board indicated that the EITAAC had recommended that the Board's rule directly reference priority one and two checkpoints of the World Wide Web Consortiums' (W3C) Web Accessibility Initiative's (WAI) Web Content Accessibility Guidelines 1.0 (WCAG 1.0). Rather than reference the WCAG 1.0, the proposed rule and this final rule include provisions which are based generally on priority one checkpoints of the WCAG 1.0, as well as other agency documents on web accessibility and additional recommendations of the EITAAC.
Comment. A number of comments were received from the WAI and others expressing concern that the Board was creating an alternative set of standards that would confuse developers as to which standards should be followed. WAI was further concerned that some of the provisions and preamble language in the NPRM were inaccurate. On the other hand, a number of commenters, including the ACB and several members of the EITAAC, supported the manner in which web access issues were addressed in the proposed rule.
Response. The final rule does not reference the WCAG 1.0. However, the first nine provisions in §1194.22, paragraphs (a) through (i), incorporate the exact language recommended by the WAI in its comments to the proposed rule or contain language that is not substantively different than the WCAG 1.0 and was supported in its comments.
Paragraphs (j) and (k) are meant to be consistent with similar provisions in the WCAG 1.0, however, the final rule uses language which is more consistent with enforceable regulatory language. Paragraphs (l), (m), (n), (o), and (p) are different than any comparable provision in the WCAG 1.0 and generally require a higher level of access or prescribe a more specific requirement. The Board did not adopt or modify four of the WCAG 1.0 priority one checkpoints. These include
WCAG 1.0 Checkpoint 4.1 which provides that web pages shall "[c]learly identify changes in the natural language of a document's text and any text equivalents (e.g., captions).";
WCAG 1.0 Checkpoint 14.1 which provides that web pages shall "[u]se the clearest and simplest language appropriate for a site's content.";
WCAG 1.0 Checkpoint 1.3 which provides that "[u]ntil user agents can automatically read aloud the text equivalent of a visual track, provide an auditory description of the important information of the visual track of a multimedia presentation."; and
WCAG 1.0 Checkpoint 6.2 which provides that web pages shall "[e]nsure that equivalents for dynamic content are updated when the dynamic content changes."
This is from http://www.access-board.gov/sec508/508standards.htm which has no internal navigation links and is large - search for the first line of the quote.
For paragraphs (a) to (j) I agree with the Access Board that they have more or less replicated the requirements and often the text itself from WCAG checkpoints. And I agree that they did not include in their requirements 4 Priority 1 WCAG checkpoints. However, I think their analysis of the relationship in paragraphs (k) through (p) is significantly wrong, and offer my own analysis here.
Paragraph (k) "A text-only page, with equivalent information or functionality, shall be provided to make a web site comply with the provisions of these standards, when compliance cannot be accomplished in any other way. The content of the text-only page shall be updated whenever the primary page changes." http://www.access-board.gov/sec508/guide/1194.22.htm#(k) According to the Access Board this is equivalent to 11.4 If, after best efforts, you cannot create an accessible page, provide a link to an alternative page that uses W3C technologies, is accessible, has equivalent information (or functionality), and is updated as often as the inaccessible (original) page. http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-alt-pages But there is a big difference between "text-only" and "accessible" (which, the way W3C uses it, generally means conforming to WCAG, in this case to the level claimed for the content that this alternative is being provided for). In general WAI does not recommend text-only pages, and in particular they are not a sufficient alternative - they are only better for a small proportion of people with disabilities and only a limited range of disabilities.
Looking at paragraphs (l) and (m) together:
(l) "When pages utilize scripting languages to display content, or to create interface elements, the information provided by the script shall be identified with functional text that can be read by assistive technology." http://www.access-board.gov/sec508/guide/1194.22.htm#(l) (m) "When a web page requires that an applet, plug-in or other application be present on the client system to interpret page content, the page must provide a link to a plug-in or applet that complies with §1194.21(a) through (l)." http://www.access-board.gov/sec508/guide/1194.22.htm#(m) These effectively replicate the collective requirements of
6.3 "Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page." but allow the provision of software meeting particular specifications as an alternative. http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-scripts
8.1 "Make programmatic elements such as scripts and applets directly accessible or compatible with assistive technologies" http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-directly-accessible
9.2 Ensure that any element that has its own interface can be operated in a device-independent manner. http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-keyboard-operable
Paragraph (n) "When electronic forms are designed to be completed on-line, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues." http://www.access-board.gov/sec508/guide/1194.22.htm#(n) This is collecting the requirements of WCAG checkpoints
10.2 "Until user agents support explicit associations between labels and form controls, for all form controls with implicitly associated labels, ensure that the label is properly positioned." http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-unassociated-labels
12.4 "Associate labels explicitly with their controls." http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-associate-labels
10.4 "Until user agents handle empty controls correctly, include default, place-holding characters in edit boxes and text areas." http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-place-holders
Paragraph (o) "A method shall be provided that permits users to skip repetitive navigation links." http://www.access-board.gov/sec508/guide/1194.22.htm#(o) This is almost exactly the same as 13.6 "Group related links, identify the group (for user agents), and, until user agents do so, provide a way to bypass the group." http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-group-links
Paragraph (p) "When a timed response is required, the user shall be alerted and given sufficient time to indicate more time is required." http://www.access-board.gov/sec508/guide/1194.22.htm#(p) This is essentially the same as
9.2 "Ensure that any element that has its own interface can be operated in a device-independent manner." http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-keyboard-operable
Cheers (and please remember this isn't WAI's opinion, it is just mine)
The law and standards: http://www.access-board.gov/508.htm
The resources website from the IT Accessibility Initiative: http://www.section508.gov/index.html
And at the Dept of Justice: http://www.usdoj.gov/crt/508/508home.html
Some resouces: A comparison with WAI WCAG: http://jimthatcher.com/sidebyside.htm
Kynn Bartlett's summary: http://access.idyllmtn.com/section508/
iCan special report http://www.icanonline.net/news/fullpage.cfm?articleid=474A9082-5811-4BC8-938483126A0A6DC3&cx=news.special_reports
eWeek article http://www.zdnet.com/eweek/stories/general/0,11011,2779500,00.html
Govt (US) Computer News: http://www.gcn.com/vol19_no14/news/2138-1.html
From DevX InfoWorld: http://www.inquiry.com/pubs/infoworld/vol23/issue02/010115calist.asp
One to amuse: http://www.inclusive.com/info_tech/magic_508_ball.htm
Last updated: 8 March 2002