Thread Subject: Re: FAQ info and URL

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: Peter Korn
Date: Fri, Aug 17 2007 10:30 AM

Hi Gregg,

I really like your two line summary below:

> FPC - The overall goal -what should be achieved.
>
> Technical - Some things we want done specifically.
>

We know how to explicitly test whether a specific thing was done: e.g.
does the product have 20dB gain? is there programmatic exposure of focus
and text and...? does the video include verbalized descriptions for the
blind?

We have major difficulties in creating explicit tests for the over all
goal: e.g. does the video description do a good job of explaining what
is going on in the video? is any potential problem with AT compatibility
because of a bug in AT vs. a failure of programmatic exposure of
information?


In Section 255, we have explicit language directing telecommunications
vendors to behave in certain (non-testable) ways. E.g. 1193.23(a):
"Manufacturers shall evaluate the accessibility, usability, and
compatibility of telecommunications equipment and customer premises
equipment and shall incorporate such evaluation throughout product
design, development, and fabrication, as early and consistently as
possible". 1193.33(c): "...In developing, or incorporating existing
training programs, consideration shall be given to the following
factors: ...".

An agency isn't in a position to test whether or how much a manufacturer
did this; but the standard gives clear guidance on what is expected.

I think it is reasonable for an updated 508 to give clear guidance that
the FPC is the overall goal. Further, to give clear guidance that:
a. If the product fails to meet one or more of the technical provisions,
the agency shall note the impact of this on the FPC (or describe why in
their case there is no impact - e.g. known AT reverse-engineers their
product such that they don't need to to the work because the AT already
does the work for them) [and I expect the agency will transfer noting
requirement to industry]
b. If the product uses equivalent facilitation to meet one or more of
the technical provisions, the agency shall note how the product approach
is equivalent, and how the FPC goals are met with it [and I expect the
agency will transfer noting requirement to industry]
c. If the product accepts input or provides output in a manner not
specifically mentioned in the technical provision, the agency shall note
how the FPC goals are met [and I expect the agency will transfer noting
requirement to industry]

I agree with Randy's summary of "how it should work" - with industry
doing a final check via the FPC to assure itself that is has met those
goals to the best of its ability. Since 508 is a burden on agencies (who
through contract language, FAR, and VPATs, transfer that burden onto
industry in various ways for the products they acquire), I'm not sure
how to write a (d) into the my examples above. Something that directs
industry to do such a final check would make sense, along the same lines
as what I cited in the two excerpts from Section 255 above. I just don't
know how to craft that here.

Perhaps industry might have a "sidebar" conversation with Terry Weaver
and others well versed in gov't procurements, to see if we can't find a
way to build that into the conversation that industry has with
purchasing agencies, since it is the agencies who have the ultimate
responsibility under 508 to purchase products that meet the FPC goals.


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

> Their order was reversed during rulemaking. But they were still meant
> to apply the same basic way. Some quotes from the 508 standards
> pre-amble.
>
> "Section 1194.2 Application
>
> This section specifies what electronic and information technology is
> covered by the standards. Electronic and information technology
> covered by section 508 must comply with each of the relevant sections
> of this part. For example, a computer and its software programs would
> be required to comply with §1194.26, Desktop and portable computers,
> §1194.21, Software applications and operating systems, and the
> functional performance criteria in §1194.31.
>
> {From SubPart B preamble}
>
> âAlso, the provisions in the proposed rule under §1194.27 (Functional
> Performance Criteria) have been redesignated as Subpart C (Functional
> Performance Criteria) in the final rule. Subpart C provides functional
> performance criteria for overall product evaluation and for
> technologies or components for which there is no specific provision in
> subpart B.â
>
> {From SubPart B preamble}
>
> âAlso, the provisions in the proposed rule under §1194.27 (Functional
> Performance Criteria) have been redesignated as Subpart C (Functional
> Performance Criteria) in the final rule. Subpart C provides functional
> performance criteria for overall product evaluation and for
> technologies or components for which there is no specific provision in
> subpart B.â
>
> Gregg
>
> -- ------------------------------
>
> Gregg C Vanderheiden Ph.D.
>
> > -----Original Message-----
>
> > From: = EMAIL ADDRESS REMOVED =
>
> > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
>
> > Weinstein, Michael
>
> > Sent: Friday, August 17, 2007 8:55 AM
>
> > To: = EMAIL ADDRESS REMOVED = ; TEITAC Subpart A Subcommittee
>
> > Subject: Re: [teitac-subparta] [teitac-general] FAQ info and URL
>
> >
>
> > My understanding is that the functional performance criteria
>
> > in subpart c was included as a means of encouraging
>
> > innovation. Does this criteria
>
> > need to be revised?
>
> >
>
> >
>
> > Michael Weinstein, Esq.
>
> > Contracts
>
> > Systems Research and Applications Corporation
>
> > 3434 Washington Boulevard
>
> > Arlington, VA 22201
>
> > Ph: 703-284-6165
>
> > Fax: 703-284-3170
>
> >
>
> > This electronic message transmission contains information
>
> > from SRA International, Inc. which may be confidential,
>
> > privileged or proprietary. The information is intended to be
>
> > for the use of the individual or entity named above. If you
>
> > are not the intended recipient, be aware that any disclosure,
>
> > copying, distribution or use of the contents of this
>
> > information is strictly prohibited.
>
> >
>
> > If you have received this electronic transmission in error,
>
> > please notify us by telephone at 866-584-2143 immediately.
>
> >
>
> >
>
> >
>
> > -----Original Message-----
>
> > From: = EMAIL ADDRESS REMOVED =
>
> > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
>
> > Diane Golden
>
> > Sent: Thursday, August 16, 2007 7:44 PM
>
> > To: 'TEITAC Subpart A Subcommittee'; 'TEITAC General
>
> > Interface Accessibility Subcommittee'
>
> > Subject: Re: [teitac-subparta] [teitac-general] FAQ info and URL
>
> >
>
> > So I'll ask the obvious question -- weren't the existing
>
> > technical standards (and the current draft revisions)
>
> > developed to "fully address"
>
> > the accessibility of a particular product or service? If
>
> > there are issues not addressed in the technical standards,
>
> > shouldn't additional technical requirements be developed
>
> > rather than relying on functional requirements to fill the
>
> > gap? Obviously not set of standards is ever going to address
>
> > every possible access issue or need - but it seemed in both
>
> > the original development and this current revision that the
>
> > goal was for the technical standards to be comprehensive.
>
> >
>
> > Unfortunately, application of the functional standards in a
>
> > procurement requires highly subjective judgments which must
>
> > be made without the benefit of standardized, valid, reliable
>
> > measurment protocols which renders those judgements extremely
>
> > difficult to defend, especially in a legal action. (I just
>
> > spent the day with my procurement folks and got more than an
>
> > earful about the functional performance standards . . . )
>
> > They are wonderful design guidelines and to use Peter's
>
> > teminology could be "aspirational" for EIT products, but to
>
> > include them as a core, mandatory requirement in a
>
> > procurement is very difficult.
>
> >
>
> > Diane Golden
>
> > NASCIO
>
> >
>
> > -----Original Message-----
>
> > From: = EMAIL ADDRESS REMOVED =
>
> > [mailto: = EMAIL ADDRESS REMOVED = ]On Behalf Of
>
> > Gregg Vanderheiden
>
> > Sent: Thursday, August 16, 2007 5:30 PM
>
> > To: 'TEITAC General Interface Accessibility Subcommittee';
>
> > 'TEITAC Subpart A Subcommittee'
>
> > Subject: Re: [teitac-subparta] [teitac-general] FAQ info and URL
>
> >
>
> >
>
> > Interesting point Allen.
>
> >
>
> > Another example of this was touch screens. In current 508
>
> > you can meet all the technical provisions for a phone and
>
> > create one with no physical buttons - just a touch screen.
>
> > (not 255 but 508)
>
> >
>
> > Of course it would not pass FPC. But if one felt that
>
> > technical would obviate FPC then one might conclude that
>
> > meeting the technical provisions would equate to
>
> > automatically meeting the FPC.
>
> >
>
> > The interesting thing is the words "fully address the product
>
> > or service being procured". Clearly in both your case and
>
> > the case above, they technical provisions did not fully
>
> > address the product. There were aspects of the product that
>
> > affected accessibility that were not covered by the technical
>
> > provisions.
>
> >
>
> > Interestingly, the only easy way I know of to determine if
>
> > the technical provisions "fully address the product or
>
> > service being procured" is to apply the technical provisions
>
> > to a product and then check the product or design against the
>
> > functional performance criteria.
>
> >
>
> > Does anyone know of any other way for people to determine if
>
> > the technical provisions "fully address the product or
>
> > service being procured"?
>
> >
>
> > It would seem that the statement
>
> > If there are applicable provisions in Subpart B that
>
> > fully address the product or service being procured, then the
>
> > agency need not look to Subpart C.
>
> > is easy to misread as
>
> > If there are applicable provisions in Subpart B that
>
> > address the product or service being procured, then the
>
> > agency need not look to Subpart C.
>
> >
>
> > We need to provide guidance on how to test whether the
>
> > technical (subpart B) fully address the product or whether
>
> > the FPC (Subpart C) are actually required in the process somewhere.
>
> >
>
> >
>
> >
>
> > Gregg
>
> > -- ------------------------------
>
> > Gregg C Vanderheiden Ph.D.
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > From: = EMAIL ADDRESS REMOVED =
>
> > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
>
> > Hoffman, Allen
>
> > Sent: Thursday, August 16, 2007 3:15 PM
>
> > To: TEITAC General Interface Accessibility Subcommittee
>
> > Subject: Re: [teitac-general] FAQ info and URL let me
>
> > document my interpretation here, and if folks concur, then i
>
> > concur with this language.
>
> >
>
> > For web sites or applications, almost all agree keyboard
>
> > accessibility is required, but not listed currently in the
>
> > 1194.22 provisions. This would indicate to me that
>
> > functional performance criteria must be used until keyboard
>
> > access is part of the "applicable" provisions.
>
> >
>
> > If there are applicable provisions in Subpart B that fully
>
> > address the product or service being procured, then the
>
> > agency need not look to Subpart C.
>
> >
>
> > My basic logic for considering FPC(s) applicable always is
>
> > that they are related to the disability, not the EIT, and the
>
> > disabilities, except when specifically contra-indicated by
>
> > fundamental alteration, are not changed for technical reasons
>
> > of product selection. I think saying that part C is fully
>
> > dependent upon technical adherence to part B just doesn't
>
> > reflect the complicated world we live in.
>
> >
>
> >
>
> >
>
> >
>
> > Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > From: = EMAIL ADDRESS REMOVED =
>
> > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
>
> > Baker, Robert C.
>
> > Sent: Thursday, August 16, 2007 3:02 PM
>
> > To: TEITAC General Interface Accessibility Subcommittee
>
> > Subject: Re: [teitac-general] FAQ info and URL I would concur
>
> > - "provided that a fundamental alteration would not be
>
> > required to meet the FPC." Thank you for taking the
>
> > leadership to provide clarity to the FPC language.
>
> >
>
> >

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