Thread Subject: Re: 22(l) and 22(m) Scripts, applets,and plug-ins
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: Hoffman, Allen
Date: Tue, Feb 20 2007 7:45 AM
- Return to this mailing list's archives
- View all messages in this thread
- Next message in thread: Andi Snow-Weaver: "Re: 22(l) and 22(m) Scripts, applets,and plug-ins"
- Previous message in thread: Barrett, Don: "Re: 22(l) and 22(m) Scripts, applets,and plug-ins"
- Messages sorted by: Author | Thread | Date
I agree with Don's assessment, but what will help is a clear definition
of "scripts" "applets", and "plug-ins". All of these are platform
related I think.
Allen Hoffman -- 202-447-0303
DHS Office on Accessible systems & Technology
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
Sent: Tuesday, February 20, 2007 9:27 AM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] 22(l) and 22(m) Scripts, applets,and
Well, with regard to 22.l, I first want to express my concern over the
combining of scripts, applets, and plug-ins in to one homogenious
construct. Scripts are primarily html extensions and as such act like
web content and not software. This distinction of 22.l and 22.m has
worked extremely well for scripts for the past six years. Scripts are
always quite easy to test in the context of web content as they are
available from the browser and act in close conjunction and synergy with
Applets and plug-ins, on the other hand, are software, and must
therefore meet a different test.
With regard to scripts, we have been so unbelievably successful in our
efforts to enforce 22.l in our testing precisely because by requiring
"functional text," the onus is on the developer to ensure that the
scripts work with AT, not the other way around. Given the many event
handlers which AT now handles, most scripts which we have encountered
which have not produced functional text and thus not worked with AT have
been modified until they in fact have ended up working with AT and
satisfying both the standard and accessibility.
If we adopt 4.1.2, all testability will go away, and any developer worth
his/her salt will be able to explain how their scripts satisfy the
"programmatically determined" rule in some theoretically plausible
fashion, and the advantage of testability we have had all along for
scripts will evaporate. The whole notion of functional text was
brilliant in its simplicity, testability, and applicability. The notion
of functional text has pushed both AT vendors and web developers
implementing 508 in the right directionk, and it has been a win-win
situation for everyone at least from our vantage point as those who must
help implement 508 and test applications against the standards.
Concepts such as "programmatically determined and programmatically set,"
and "notification of changes to these items is available to user
agents," are more intellectually satisfying because they have global
appeal and theoretically cover more scenarios. But 508 is only as good
as it is testable; take away its testability for the sake of theoretical
thoroughness, and we rob it of its power. The onus is always on the 508
proponents to prove that something is not conformant, rather than on the
IT vendor to prove that it is. All of the procurement-related inertia
at the Federal level is designed to support the assumption of
accessibility unless someone can clearly show that a given product
doesn't meet specific standards. If we make it hard to prove
non-conformance, then conformance will always be assumed.
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Andi
Sent: Monday, February 19, 2007 3:53 PM
To: = EMAIL ADDRESS REMOVED =
Subject: [teitac-websoftware] 22(l) and 22(m) Scripts, applets, and
We have not yet closed on a recommendation for 22(l) scripts and 22 (m)
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
requirements are covered by the WCAG 2.0 requirements.
In order to determine whether this is the case, Jim Thatcher and Earl
Johnson created a mapping of all of the 1194.21 requirements to WCAG
Everything that is in 1194.21 today is covered in WCAG 2.0 except for
the following four items:
21(b) Applications shall not disrupt or disable activated features of
other products that are identified as accessibility features, where
those features are developed and documented according to industry
Applications also shall not disrupt or disable activated features of any
operating system that are identified as accessibility features where the
application programming interface for those accessibility features has
been documented by the manufacturer of the operating system and is
available to the product developer.
- Jim and Earl assessed this as not applicable because Web applications
don't have access to these features of the system. Does this mean we
have a requirement in the current 508 standard that applets and plug-ins
can't meet or that this is truly not applicable to applets and plug-ins?
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
1194.21(f) Textual information shall be provided through operating
system functions for displaying text. The minimum information that shall
be made available is text content, text input caret location, and text
- Is this really an issue for applets and plug-ins? If so, then we need
to be making a proposal for an additional requirement in WCAG 2.0.
1194.21(g) Applications shall not override user selected contrast and
color selections and other individual display attributes.
- Web content does not have access to these features of the operating
system. This was identified as an issue with the current 508 standard
during our discussion of applets and plug-ins. 
We also have the issue user agent issue of keyboard operation with
regard to entering and exiting applet or plug-in content with the
There are a few other issues, as identified in the mapping table, most
of which we are already working on proposals to address. But we can't go
backwards in the 508 refresh. So, if we want to recommend that 508 take
the same approach as WCAG 2.0 for scripts, applets, and plug-ins, we
would need resolve the above issues and also recommend adding the
following WCAG 2.0 requirement to 508:
4.1.2 For all user interface components, the name and role can be
programmatically determined, states, properties, and values that can be
set by the user can be programmatically determined and programmatically
set, and notification of changes to these items is available to user
agents, including assistive technologies." (Level 1)
- Next message in Thread: Andi Snow-Weaver: "Re: 22(l) and 22(m) Scripts, applets,and plug-ins"
- Previous message in Thread: Barrett, Don: "Re: 22(l) and 22(m) Scripts, applets,and plug-ins"