- From: David Poehlman <poehlman1@comcast.net>
- Date: Thu, 13 Mar 2003 12:37:04 -0500
- To: Charles McCathieNevile <charles@sidar.org>, Phill Jenkins <pjenkins@us.ibm.com>
- Cc: w3c-wai-ig@w3.org
I'm not sure who david is here but If I have not yet weighed in on this thread, It is important to note that the us is a small part of the world and in the view of the world, has to live in the world rather than the other way round. It is also important to note that wcag is not a standard but something on which standards are based and if we let the bar slip, how far will the standards slip in a knee jerk response or for other reasons? ----- Original Message ----- From: "Charles McCathieNevile" <charles@sidar.org> To: "Phill Jenkins" <pjenkins@us.ibm.com> Cc: <w3c-wai-ig@w3.org> Sent: Thursday, March 13, 2003 11:59 AM Subject: Re: 508 rule L and WCAG 6.3 I agree that 508 and WCAG are different. 508 would seem to allow, according to the letter, text like "this applet is inaccessible" as an appropriate replacement, with the proviso that there is a system wihch meets 508's user agent requirements and which could have dealt with the script. WCAG requires that people can use the content without the script. It also requires that for people whose user agent can handle the technology, the onject is written so it is compatible with the user agent. As an example, it is possible in an interactive SVG image to include audio descriptions of the visual rendering, which can be triggered with voice commands. Under 508 it seems OK to simply have "you can't see this" provided to people without an accessible SVG viewer, so long as such a thing exists. Under WCAG 6.3 there needs to be some way to operate the functionality without an SVG viewer (although as Anthony said this seems counter to the spirit). It is also required by WCAG 8.1 that the SVG in question does have accessibility features used - it is not clear that this is required by 508 either. So I agree with David that the Section 508 requirements seem a little underspecified here in terms of ensuring actual accessibility to people. just my 2 cents worth... chaals -- Charles McCathieNevile Fundacion Sidar http://www.sidar.org Phill Jenkins wrote: >I would also summarize by saying that WCAG 1.0 Checkpoint 8.1 (see note 1) >is more the same as 508 paragraph L, in fact I agree with Jim that 508 and >WCAG are more like exact opposites here. WCAG 1.0 is much older and focused >on removing the need for JavaScript while 508 is more forward thinking and >is focused on making JavaScript directly accessible. WCAG 8 says: >"Guideline 8. Ensure direct accessibility of embedded user interfaces." >Ensure that the user interface follows principles of accessible design: >device-independent access to functionality, keyboard operability, >self-voicing, etc. >Checkpoint: > 8.1 Make programmatic elements such as scripts and applets directly > accessible or compatible with assistive technologies [Priority 1 if > functionality is important and not presented elsewhere, otherwise > Priority 2.] > >WCAG 1.0 is a little contradictory here, if the web site meets 6.3, i.e., >runs with JavaScript turned off, then there would be no need to meet 8.1 >and make the JavaScript directly accessible. In my opinion, the need to be >able to run without JavaScript is not a pure accessibility requirement now >that assistive technologies have and can be made to directly support >JavaScript. Use of JavaScript may still be of concern to some due to >security fears and older technology that doesn't support JavaScript, but >the important thing is to get it right in WCAG 2.0 by better defining what >directly accessible JavaScript is. > >Removing this difference between 508 and WCAG 1.0 is a very important part >in harmonizing the standards. > >Note 1 WCAG 8.1 checkpoint http://www.w3.org/TR/WCAG10/#gl-own-interface >Note 2 WCAG 8.1 techniques >http://www.w3.org/TR/WCAG10-TECHS/#tech-directly-accessible > >Regards, >Phill Jenkins, >IBM Research Division - Accessibility Center >11501 Burnet Rd, Austin TX 78758 http://www.ibm.com/able > > > >
Received on Thursday, 13 March 2003 12:37:09 UTC