As a very general response: JavaScript and accessibility (in the WCAG
2.0 sense) are not necessarily incompatible. Where WCAG 1.0 stated
explicitly that sites need to work without JavaScript, WCAG 2.0 makes no
such hard and fast restrictions. Any technology is allowed, as long as
it's "accessibility supported".
See http://www.w3.org/TR/WCAG/#new-terms ,
http://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-accessibility-support-head
, http://www.w3.org/TR/WCAG/#accessibility-supporteddef
(note that the "baseline" idea used to be in older draft versions of
WCAG 2.0, when it went to its first last call before being thrown back
quite violently for a rewrite...from what I can see now, the whole
"baseline" idea is now missing in WCAG 2.0, replaced by the
"accessibility supported" one).
JavaScript is undoubtably "accessibility supported", as there are user
agents that work perfectly with it that are readily available to users.
Now, *how* JavaScript is being used on specific pages/sites is of course
important, as - similar to any other technology, including plain old
HTML/CSS - it's quite easy to build something with it that is *not*
accessible. (i.e. the two points about the technology being used in an
accessible way AND the technology itself having available user agents).
Sure, if users come along with a user agent that does not support the
technology (in this case JavaScript), that's a problem...but it's not a
problem in the WCAG 2.0 sense if there are alternatives they can readily
use.
P
--
Patrick H. Lauke
______________________________________________________________
reÂ·dux (adj.): brought back; returned. used postpositively
[latin : re-, re- + dux, leader; see duke.]
www.splintered.co.uk | www.photographia.co.uk
http://redux.deviantart.com | http://flickr.com/photos/redux/
______________________________________________________________
twitter: @patrick_h_lauke | skype: patrick_h_lauke
______________________________________________________________