Thread Subject: Re: functional performance criteria

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: Debbie Cook
Date: Mon, Jul 23 2007 3:10 PM


This is why a substantial number of people on the Closed subcommittee want
to make a distinction specific to Closed functions or products. We certainly
may decide not to use it in the end, but we want to keep a placeholder for
it.
----- Original Message -----
From: "Peter Korn" < = EMAIL ADDRESS REMOVED = >
To: "TEITAC General Interface Accessibility Subcommittee"
< = EMAIL ADDRESS REMOVED = >
Sent: Sunday, July 22, 2007 12:39 PM
Subject: Re: [teitac-general] functional performance criteria


Hi Allen,

Your handheld MP3 player is an example of a device that "falls through
the cracks" of the flowchart/decision tree of the July 6 draft, as
identified by Alex Li of SAP in his TEITAC presentation last Monday. It
contains software, but doesn't "run on a platform with Operating System
and AT Support" (section 3.4 of 6July07 draft). Essentially this is
part of the stuff we used to deal with in the closed section, but as we
have largely taken that section away and put its provisions other
places, we have this identified "hole".

I would like us to continue to work through our drafts with real
products and real procurements, to find and fix these holes in the
technical specs. Given how difficult it is to make the FPC testable, I
think this is the best course of action for us.


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

(the "other Peter")

> Peter:
> I believe that from a software development perspective the standards
> generally do work as you describe, but for other areas it is
> potentially less hard-and-fast.
>
> For example:
>
> 1. Handheld MP3 player.
> generally not usable by the blind to view menus;
> may not work for low vision menus too small;
> songs won't have synchronized lyrics probably for the deaf;
> people with motor disabilities may have issues definitely;
>
> Even, if the vendor has mechanical keys, makes menus enlargeable,
> problems may arise.
>
> If we go back to the original functional performance criteria
> language, I think testability may be more helpful.
>
>
>
> Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
>
>
>
> ------------------------------------------------------------------------
> *From:* = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] *On Behalf Of *Peter
> Wallack
> *Sent:* Wednesday, July 18, 2007 12:28 PM
> *To:* TEITAC General Interface Accessibility Subcommittee
> *Subject:* Re: [teitac-general] functional performance criteria
>
> I sure hope I haven't been doing this incorrectly all these years, but
> my take on the FPC's as a software vendor has always been that to meet
> any particular one I simply follow all of the technical provisions
> that appear to apply to that particular disability (bearing in mind
> that I am a software vendor, thus there are specific technical
> requirements for me to follow, so this is not a catch-all provision
> for me). I've never understood (or I've just never found) why there
> was no official mapping by disability between the FPCs and the
> technical provisions.
> Peter Wallack
> Accessibility Program Director
> Oracle Corporation
>
>
> Hoffman, Allen wrote:
>> If, functional performance criteria are only outcomes of technical
>> conformance, the untestability is not true.
>>
>> Can we explore this as a way to come to grips with the testability of
>> functional performance criteria?
>>
>>
>>
>> Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
>>
>>
>>
>> ------------------------------------------------------------------------
>> *From:* = EMAIL ADDRESS REMOVED =
>> [mailto: = EMAIL ADDRESS REMOVED = ] *On Behalf Of *Baker,
>> Robert C.
>> *Sent:* Wednesday, July 18, 2007 11:56 AM
>> *To:* TEITAC General Interface Accessibility Subcommittee
>> *Subject:* RE: [teitac-general] functional performance criteria
>>
>> With all due respect, the best meets selection is supportable in
>> court only if the agency adheres to a systematic well defined
>> evaluation process to make a selection. Anything otherwise is
>> subject to a protest. The functional performance criteria, given
>> that they are not testable, cannot be used to make a selection
>> without significant risk to the Procurement Official and the agency.
>>
>> Robert Baker
>>
>> ------------------------------------------------------------------------
>> *From:* = EMAIL ADDRESS REMOVED = on behalf of Hoffman,
>> Allen
>> *Sent:* Wed 7/18/2007 11:27 AM
>> *To:* TEITAC General Interface Accessibility Subcommittee
>> *Subject:* Re: [teitac-general] functional performance criteria
>>
>> Expanding FPC may make far more items less-than fully conforming, yes,
>> which will increase for some time the "best meets" selection. "best
>> meets" is the vast majority of selections anyway, so the change won't be
>> that significant.
>>
>> Also, what was the conclusion about dealing with multiple disabilities?
>> I don't feel we can really do this effectively. I'd love for us to
>> include low-vision/hard-of-hearing as that is the largest group of
>> people with multiple disabilities by far, and then deaf/blind. I don't
>> think we have unique requirements for people, for example, blind,motor
>> limitations, and deaf that are accepted requirements.
>>
>>
>>


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