Re: is javascript considered good wacg 2.0 practice?

Its funny you would bring up pdf.
this is apart of the bell complaint too, but for different reasons...and 
bell agrees that pdf is a problem.  Even their non-disabled users complain 
about their making bills available in this format, or program guides, 
because many many people use different platforms other than windows, the 
Adobe readers can be buggy, and pdff files  are  confusing to navigate.
One way I felt avoided the test everything with everything requirement 
was to insure a simple cascading style sheet, say in HTML that provides 
the same basic functionality.  In the case of this telecommunications 
company, the ability to log into your account, learn basically about 
services, and get routine information.  what they choose to put on top of 
the sidewalk is their own affair.  Also to their credit, bell is the only 
telecommunications provider with a fully staffed accessability center 
giving people a place to go...even if they do not tell the general public 
about this center.
Things like pdf create the suggestion again that if it works in Jaws it is 
accessible, never mind nothing could be further from the truth.
Karen

On Thu, 13 Dec 2012, Ramón Corominas wrote:

> Hi, Andrew and all.
>
> Although I basically agree with you in terms of the "accessibility support" 
> in the case of JavaScript, I am not sure that we can simply say "I'm relying 
> on this technology, so if there is not full support it is not my problem".
>
> Indeed, for certain technologies it is clear that there is a lack of 
> accessibility support that would affect disabled users differently than 
> non-disabled users. For example, although PDF documents can be made 
> "accessible", for now they are only accessibility supported on Windows using 
> Adobe Reader (and I think only fully supported with JAWS). For Mac or Linux 
> users, PDF will NOT be accessible even if the document is properly tagged, 
> etc. Therefore, web owners cannot simply say "we rely on Adobe PDF, so if you 
> are using another OS is not our problem".
>
> Of course, in the case of PDF none of the conditions of the "accessibility 
> support" are met, so we cannot claim "accessibility support" unless the 
> documents are used in a closed environment. Nevertheless, with other 
> technologies it seems sometimes that we simply consider that forcing the 
> users to change their normal tools is fair, Apparently, users are guilty for 
> not using "the right tool".
>
> That said, I agree that we must be realistic, too. We cannot pretend that 
> developers test every combination of OS, browser and AT, but there should 
> also be a limit to the "it's your fault by not using the appropriate tool" 
> excuse.
>
> Regards,
> Ramón.
>
> Andrew wrote:
>
>>  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.
>>  Thanks,
>>  AWK
>>
>>  Andrew Kirkpatrick
>>  Group Product Manager, Accessibility
>>  Adobe Systems 
>
>
>