Thread Subject: Re: 22(l) and 22(m) Scripts, applets,and plug-ins

Note

This archival content is maintained by WebAIM and NCDAE on behalf of TEITAC and the U.S. Access Board . Additional details on the updates to section 508 and section 255 can be found at the Access Board web site.

From: Truesdell Nick
Date: Wed, Feb 21 2007 10:40 AM

There may actually be two issues that need to be addressed:
1) The underlying agent that renders the content and
2) The specific content, applet, plug-in, etc. that is displayed.

Consider this situation: An interactive application is written in JAVA.
However, to run properly the app needs a specialized JAVA VM. This
particular JAVA VM does not interface with the access bridge. So, even
if the app was coded properly the information is not exposed to
assistive technology.


Nick Truesdell
Information Technology Accessibility Center - ITAC
Information Resources Accessibility Program - IRAP
Desk: 202-283-5536
= EMAIL ADDRESS REMOVED =

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Andrew
Kirkpatrick
Sent: Wednesday, February 21, 2007 9:59 AM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] 22(l) and 22(m) Scripts, applets,and
plug-ins

> The current 508 standard on scripts is insufficient and for applets
> and plug-ins, 508 refers back to the software requirements. In
> contrast, WCAG 2.0 tries to address all kinds of Web content, whether
> it is static information or interactive software. Scripts, applets and

> plug-ins must all be assessed against all WCAG 2.0 requirements. When
> we discussed scripts, applets, and plug-ins in our subcommittee, we
> ended up with a preference for the WCAG 2.0 approach as long as we
> believe that all of the current 508 requirements are covered by the
> WCAG 2.0 requirements.

The issue seems to potentially be that there needs to be additional
clarity on whether plugin-based apps are to be evaluated in 21 or 22.
If the answer is 21, this gets easier to deal with...

> 1194.21(c) A well-defined on-screen indication of the current focus
> shall be provided that moves among interactive interface elements as
> the input focus changes. The focus shall be programmatically exposed
> so that assistive technology can track focus and focus changes.
>
> - We have been discussing this ourselves. Some feel that this is a
> user agent responsibility. But for some types of content, like Flash,
> developers clearly have a responsibility to provide this. We have a
> proposal on a Web requirement for this but we did not reach consensus
> on it. [2]?

This is not just a Flash issue. This can come up any time that custom
controls are created in javascript also. Flash provides a well-defined
focus, but sometimes developers go off the path to create new types of
controls and then they need to attend to this.

AWK

WebAIM is an initiative of:
Center for Persons with Disabilities (CPD) Utah State University