W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > October to December 2012

RE: is javascript considered good wacg 2.0 practice?

From: Andrew Kirkpatrick <akirkpat@adobe.com>
Date: Thu, 13 Dec 2012 05:34:22 -0800
To: "w3c-wai-ig@w3.org" <w3c-wai-ig@w3.org>
Message-ID: <EE43A638A0C5E34E80AF78EFE940FC2C01B7258346@nambx09.corp.adobe.com>
The way I answer this question for developers is that JavaScript is permissible under WCAG 2.0, but like any other technology it needs to correctly expose information about accessibility of the content and meet other WCAG 2.0 success criteria .

The fact that there are people who disable JavaScript and clients available which restrict JavaScript is not a factor, for the reasons Steve Faulkner stated - users have a choice of browsers and other tools to use, and this issue doesn't uniquely affect users with disabilities. There is no such thing as "technology baseline" in WCAG 2.0 but within the conformance claim required components is a need to identify the components that the site "relies on" (http://www.w3.org/TR/WCAG/#reliedupondef).  It is perfectly legitimate to indicate that a site relies on JavaScript, ARIA, and other technologies which are supported differently in different tools. 

I fully agree that progressive enhancement is the best approach, but it may not always be possible to provide the same functionality with and without JS.  


Andrew Kirkpatrick
Group Product Manager, Accessibility
Adobe Systems 


-----Original Message-----
From: Patrick H. Lauke [mailto:redux@splintered.co.uk] 
Sent: Thursday, December 13, 2012 7:25 AM
To: w3c-wai-ig@w3.org
Subject: Re: is javascript considered good wacg 2.0 practice?

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.

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 ______________________________________________________________
Received on Thursday, 13 December 2012 13:34:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:36:42 UTC