Re: 508 rule L and WCAG 6.3

I agree that with the overall commentary and exegesis 508 is clarified - 
although it does show that the attempt to create something that would 
not need such clarification was unsuccessful. (I believe that is a 
problem with the difficulties of explaining complex information to 
humans, not a problem with 508 per se).

Both 508 and WCAG require accessbile Javascript - WCAG via checkpoint 
8.1 whose value Phill claimed was nil. WCAG requires, in addition, a 
working fallback, for situations which arise in the world like "there is 
an accessible plugin in english, but the content of the page is in 
hebrew", or "the plugin which meets the 508 requirements unfortunqtely 
doesn't meet the requirements of a particular user".

Comparing the two side by side I think there is little evidence to 
sustain the argument that 508 is more forward thinking. It is narrower 
in focus, removing many of the backward-compatibility provisions of WCAG 
among other things.

cheers

chaals
--
Charles McCathieNevile          Fundacion Sidar
http://www.sidar.org

Larry G. Hull wrote:

> Based upon the overall Section 508 and Access Board comments, I 
> believe your literal reading is incorrect. Specifically, I seem to 
> recall an example where a script performs a login and the NOSCRIPT 
> can't simple say "This is the login page" but has to provide the 
> functionality (i.e., allow the user to actually login).
>
> In your example, where an accessible SVG viewer exists, my 
> understanding is that the page needs to provide the URI to download 
> the plugin and not simply say "sorry but you can't see this".
>
> That said, I agree with Phil's comment, "508 is more forward thinking 
> and is focused on making JavaScript directly accessible."
>

Received on Friday, 14 March 2003 03:48:41 UTC