RE: 508 rule L and WCAG 6.3

Hi Folks,

I eventually concluded that the wording "functional text" in Rule L refers
to the output of the script. In this respect, I think 508 L is closer to
WCAG 8.1.

However, that's my "eventual" interpretation and to a degree, I interpret it
that way because I want the script to be accessible. My initial thinking was
that the functional text was basically what Charles has described.

The real problem here, is that the standard is not that clearly defined.
It's open to interpretation.

Sorry if this adds to the confusion but such is life.

Cheers

Anthony

-----Original Message-----
From: Larry G. Hull [mailto:Larry.G.Hull@nasa.gov]
Sent: Friday, March 14, 2003 9:00 AM
To: charles@sidar.org
Cc: David Poehlman; Phill Jenkins; w3c-wai-ig@w3.org
Subject: Re: 508 rule L and WCAG 6.3


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."

Regards,

Larry

>----- 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
>>
>>
>>
>>