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: Barrett, Don
Date: Tue, Feb 20 2007 7:30 AM

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
HTML elements.

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.

Don Barrett



-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Andi
Snow-Weaver
Sent: Monday, February 19, 2007 3:53 PM
To: = EMAIL ADDRESS REMOVED =
Subject: [teitac-websoftware] 22(l) and 22(m) Scripts, applets, and
plug-ins


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 the current
508
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
2.0.
[1].

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 standards.
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 it. [2]?

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

- 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. [3]

We also have the issue user agent issue of keyboard operation with
regard
to entering and exiting applet or plug-in content with the keyboard.

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)

Comments?

[1] http://teitac.org/wiki/Web_and_Software:_mapping
[2] http://teitac.org/wiki/Web_and_Software:_Web_Gaps#Focus_Indicator
[3]
http://teitac.org/wiki/Web_and_Software:_Web_provisions#22.28l.29_.26_22
.28m.29

Andi

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