Thread Subject: Re: Applicability of 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.
Return to this mailing list's archives
From: Debbie Cook
Date: Mon, Jun 04 2007 3:05 PM
Subject: Re: Applicability of Functional Performance Criteria
But what about when there is no technical standard that applies? Or what
about if you've applied them all but the product is still not useable? I
think that all the standards have to be taken in total. I think the
technical standards can be used to show in part how you propose to meet the
functional criteria. But when all is said and done, I would argue that we
could merely follow hte functional criteria and drop the technical
standards. Of course no one is really prepared to do that, but the
funcitonal standards are trying to capture what should be occurring.
----- Original Message -----
From: "Phill Jenkins" < = EMAIL ADDRESS REMOVED = >
To: "TEITAC General Interface Accessibility Subcommittee"
< = EMAIL ADDRESS REMOVED = >
Sent: Monday, June 04, 2007 1:55 PM
Subject: [teitac-general] Applicability of Functional Performance Criteria
Some of the discussions during the call today and especially the examples
seem to be incorrectly founded in the premise that the functional
performance criteria provisions always need to be applied. There were
several examples or scenarios of Web, Kiosks, and other applications that
went something like this:
"The Software and Web provisions already apply here, so why do we need to
also apply this "functional criteria" if we already meet all those
Software & Web provisions? Shouldn't the functional performance criteria
only apply when choosing not to comply with the applicable software and
web provisions for a software or web application?
If we took the view of only applying the functional performance criteria
when not choosing to comply with the other applicable provisions, then we
wouldn't be discussing the "AT used by people with disabilities" clause.
If there are some other necessary provisions, then lets discuss them. But
if we continue to promote this "catch all" provision as also applying, we
will continue to have this unproductive discussion. Why can't we just
propose to "drop" the clause that the functional performance criteria also
include AT - why not just propose that the functional performance criteria
only apply when AT is not provided and the application or product shall be
operable without additional AT for users who are blind?
Regards,
Phill Jenkins, (512) 838-4517
IBM Research - Human Ability & Accessibility Center
http://www.ibm.com/able
--------------------------------------------------------------------------------
From: Phill Jenkins
Date: Mon, Jun 04 2007 3:30 PM
Subject: Applicability of Functional Performance Criteria
Some of the discussions during the call today and especially the examples
seem to be incorrectly founded in the premise that the functional
performance criteria provisions always need to be applied. There were
several examples or scenarios of Web, Kiosks, and other applications that
went something like this:
"The Software and Web provisions already apply here, so why do we need to
also apply this "functional criteria" if we already meet all those
Software & Web provisions? Shouldn't the functional performance criteria
only apply when choosing not to comply with the applicable software and
web provisions for a software or web application?
If we took the view of only applying the functional performance criteria
when not choosing to comply with the other applicable provisions, then we
wouldn't be discussing the "AT used by people with disabilities" clause.
If there are some other necessary provisions, then lets discuss them. But
if we continue to promote this "catch all" provision as also applying, we
will continue to have this unproductive discussion. Why can't we just
propose to "drop" the clause that the functional performance criteria also
include AT - why not just propose that the functional performance criteria
only apply when AT is not provided and the application or product shall be
operable without additional AT for users who are blind?
Regards,
Phill Jenkins, (512) 838-4517
IBM Research - Human Ability & Accessibility Center
http://www.ibm.com/able
From: Gregg Vanderheiden
Date: Mon, Jun 04 2007 3:45 PM
Subject: Re: Applicability of Functional Performance Criteria
Hi Phil,
That is a not un-common misunderstanding. The performance criteria are to
be applied to all products after the technical provisions are applied.
They also apply to products or technologies for which there are no technical
requirements but that is actually a subset of the above anyway.
The following are all quotes from the final rule:
{In the preamble for section (1194.2) it says. -- }
"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} (emphasis added)
?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 Performance Criteria Preamble}
This section provides functional performance criteria for overall product
evaluation and for technologies or components for which there is no specific
requirement under other sections. These criteria are also intended to ensure
that the individual accessible components work together to create an
accessible product. This section requires that all product functions,
including operation and information retrieval, be operable through at least
one mode addressed in each of the following paragraphs.
Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.
_____
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Phill Jenkins
Sent: Monday, June 04, 2007 3:56 PM
To: TEITAC General Interface Accessibility Subcommittee
Subject: [teitac-general] Applicability of Functional Performance Criteria
Some of the discussions during the call today and especially the examples
seem to be incorrectly founded in the premise that the functional
performance criteria provisions always need to be applied. There were
several examples or scenarios of Web, Kiosks, and other applications that
went something like this:
"The Software and Web provisions already apply here, so why do we need to
also apply this "functional criteria" if we already meet all those Software
& Web provisions? Shouldn't the functional performance criteria only apply
when choosing not to comply with the applicable software and web provisions
for a software or web application?
If we took the view of only applying the functional performance criteria
when not choosing to comply with the other applicable provisions, then we
wouldn't be discussing the "AT used by people with disabilities" clause. If
there are some other necessary provisions, then lets discuss them. But if
we continue to promote this "catch all" provision as also applying, we will
continue to have this unproductive discussion. Why can't we just propose to
"drop" the clause that the functional performance criteria also include AT -
why not just propose that the functional performance criteria only apply
when AT is not provided and the application or product shall be operable
without additional AT for users who are blind?
Regards,
Phill Jenkins, (512) 838-4517
IBM Research - Human Ability & Accessibility Center
http://www.ibm.com/able
From: Phill Jenkins
Date: Mon, Jun 04 2007 3:50 PM
Subject: Re: Applicability of Functional Performance Criteria
> But what about when there is no technical standard that applies?
Then maybe the functional performance criteria (fpc) could be applicable.
Especially since there will most likely NOT be any supporting assistive
technology. Providing some suggested guidance when to apply the FPC is
needed anyway.
> Or what about if you've applied them all but the product is still not
useable?
That is exactly my point about additional provisions. If the vendor or
agency has applied them all, and it is still not usable, then is either
a. A new provision is needed?
b. Supporting assistive technology is needed?
c. End user configuration or training is needed?
> I think the technical standards can be used to show in part how you
propose to meet the functional criteria.
If we the accessibility experts in the 508 committee can't make
suggestions for additional provisions, then why should we pass the buck
and cause additional confusion with requirements writers, purchasing
teams, and testing teams trying to determine if something is compliant or
not. 'Testability' is a theme we need to address, not more vagueness with
FPC. I personally believe the "standards" should be revisited every few
(5?) years anyway.
Regards,
Phill Jenkins
IBM Research - Human Ability & Accessibility Center
http://www.ibm.com/able
"Debbie Cook" < = EMAIL ADDRESS REMOVED = >
Sent by: = EMAIL ADDRESS REMOVED =
06/04/2007 04:00 PM
Please respond to
TEITAC General Interface Accessibility Subcommittee
< = EMAIL ADDRESS REMOVED = >
To
"TEITAC General Interface Accessibility Subcommittee"
< = EMAIL ADDRESS REMOVED = >
cc
Subject
Re: [teitac-general] Applicability of Functional Performance Criteria
But what about when there is no technical standard that applies? Or what
about if you've applied them all but the product is still not useable? I
think that all the standards have to be taken in total. I think the
technical standards can be used to show in part how you propose to meet
the
functional criteria. But when all is said and done, I would argue that we
could merely follow hte functional criteria and drop the technical
standards. Of course no one is really prepared to do that, but the
funcitonal standards are trying to capture what should be occurring.
----- Original Message -----
From: "Phill Jenkins" < = EMAIL ADDRESS REMOVED = >
To: "TEITAC General Interface Accessibility Subcommittee"
< = EMAIL ADDRESS REMOVED = >
Sent: Monday, June 04, 2007 1:55 PM
Subject: [teitac-general] Applicability of Functional Performance Criteria
Some of the discussions during the call today and especially the examples
seem to be incorrectly founded in the premise that the functional
performance criteria provisions always need to be applied. There were
several examples or scenarios of Web, Kiosks, and other applications that
went something like this:
"The Software and Web provisions already apply here, so why do we need to
also apply this "functional criteria" if we already meet all those
Software & Web provisions? Shouldn't the functional performance criteria
only apply when choosing not to comply with the applicable software and
web provisions for a software or web application?
If we took the view of only applying the functional performance criteria
when not choosing to comply with the other applicable provisions, then we
wouldn't be discussing the "AT used by people with disabilities" clause.
If there are some other necessary provisions, then lets discuss them. But
if we continue to promote this "catch all" provision as also applying, we
will continue to have this unproductive discussion. Why can't we just
propose to "drop" the clause that the functional performance criteria also
include AT - why not just propose that the functional performance criteria
only apply when AT is not provided and the application or product shall be
operable without additional AT for users who are blind?
Regards,
Phill Jenkins
IBM Research - Human Ability & Accessibility Center
http://www.ibm.com/able
--------------------------------------------------------------------------------
From: Phill Jenkins
Date: Mon, Jun 04 2007 4:35 PM
Subject: Re: Applicability of Functional Performance Criteria
> The performance criteria are to be applied to all products after the
technical provisions are applied.
I am suggesting that we recommend to the committee that this be changed
this for the reasons I listed earlier. How can we say that an agency must
comply with all the applicable technical provisions and also some
additional ones that we are not going to tell them, but trust that they'll
be reasonable...
> That is a not un-common misunderstanding.
I don't view it as my misunderstanding because the current wording of the
Functional provisions has an explicit comma and an 'or', as is ", or
support for assistive technology used by people who are ... shall be
provided." Support for AT is commonly understood to be the technical
provisions. The current wording doesn't say AND support for AT, it says
OR support for AT. its either or not and. So while you need to determine
if the FPC applies, it can be met by meeting the technical provisions
alone OR by providing one mode of operation ...
Regards,
Phill Jenkins
IBM Research - Human Ability & Accessibility Center
http://www.ibm.com/able
From: Katie Haritos-Shea
Date: Mon, Jun 04 2007 5:50 PM
Subject: Re: Applicability of Functional Performance Criteria
<HEAD>
<STYLE>body{font-family: Geneva,Arial,Helvetica,sans-serif;font-size:9pt;background-color: #ffffff;color: black;}</STYLE>
<META content="MSHTML 6.00.6000.16441" name=GENERATOR></HEAD>
<BODY>
<P>Phill,</P>
<P>At the 3 agencies I have worked at, all of them required the applicable Technial Suppart B provisions, as well as all Subparts C and D provision be complied with for all procurement and in-house developed products.</P>
<P>I would consider it a step backwards to remove that requirement.</P>
<P>Katie Haritos-Shea</P>
<DIV id=compText><BR><BR><BR>
<BLOCKQUOTE style="PADDING-LEFT: 5px; MARGIN-LEFT: 0px; BORDER-LEFT: #0000ff 2px solid">-----Original Message----- <BR>From: Phill Jenkins < = EMAIL ADDRESS REMOVED = ><BR>Sent: Jun 4, 2007 6:33 PM <BR>To: TEITAC General Interface Accessibility Subcommittee < = EMAIL ADDRESS REMOVED = ><BR>Subject: Re: [teitac-general] Applicability of Functional Performance Criteria <BR><BR><BR><FONT face=sans-serif size=2>> </FONT><FONT face="Times New Roman" size=3>The performance criteria are to be applied to all products after the technical provisions are applied.</FONT> <BR><BR><FONT face=sans-serif size=2>I am suggesting that we recommend to the committee that this be changed this for the reasons I listed earlier. How can we say that an agency must comply with all the applicable technical provisions and also some additional ones that we are not going to tell them, but trust that they'll be reasonable...</FONT> <BR><BR><FONT face=sans-serif size=2>> </FONT><FONT face="Times New Roman" size=3>That is a not un-common misunderstanding.</FONT> <BR><BR><FONT face=sans-serif size=2>I don't view it as my misunderstanding because the current wording of the Functional provisions has an explicit comma and an 'or', as is ", or support for assistive technology used by people who are ... shall be provided." Support for AT is commonly understood to be the technical provisions. The current wording doesn't say AND support for AT, it says OR support for AT. its either or not and. So while you need to determine if the FPC applies, it can be met by meeting the technical provisions alone OR by providing one mode of operation ...</FONT> <BR><BR><FONT face=sans-serif size=2>Regards,<BR>Phill Jenkins<BR>IBM Research - Human Ability & Accessibility Center<BR>http://www.ibm.com/able<BR></FONT></BLOCKQUOTE></DIV></BODY><PRE>
* katie *
Katie Haritos-Shea
Section 508 Technical Policy Analyst
703-371-5545
People may forget exactly what it was that you said or did,
but people will never forget how you made them feel.......</PRE>
From: Robinson, Norman B - Washington, DC
Date: Tue, Jun 05 2007 2:15 PM
Subject: Re: Applicability of Functional Performance Criteria
Phill,
Is your concern that the functional performance criteria (FPC), by offering the "or support for assistive technology used by people who are ...shall be provided" clause, fails to define the specific technical requirements for a particular type of assistive technology?
It is often important to focus on the end goal of accessibility and the FPC language does that. If we were to choose "§ 1194.21 Software applications and operating systems: (a) When software is designed to run on a system that has a keyboard, product functions shall be executable from a keyboard where the function itself or the result of performing a function can be discerned textually." we might have situations where developers can use that as a test condition and demonstrate functions are executable from a keyboard, but requires user vision. The § 1194.31 Functional performance criteria: (a) At least one mode of operation and information retrieval that does not require user vision shall be provided,..." ensures that our goals are met in context, namely that it doesn't require user vision.
Otherwise I assure you we will have vendors and lawyers in a room asserting they met the 1194.21(a) and want to get paid, when their solution clearly didn't meet our functional requirements.
While I will agree that "...or support for assistive technology used by people who are blind or visually impaired shall be provided" can be used to the detriment of accessibility (e.g., I develop a program that *requires* an ancient version of a screen reader or a horribly expensive proprietary screen reader that only I, the vendor, sells to work with our specific software) it does allow contracting officers to evaluate through evaluation or demonstration, if a solution is accessible. Beyond explicitly stating and defining what specific assistive technology is allowed, I think this does not prevent contracting officers from exercising their right to common sense or intellect and selecting a current, usable in the current IT environment, and fair value assessment of assistive technology used by the vendors during demonstration. The USPS has specific assistive technologies we require and evaluate vendor compliance based on our organization's technical standards.
So I'd say there is a dependency, a strong must-have dependency hierarchy which can be demonstrated by (in our example software accessibility technical standards) meeting specific subpart B technical standards, where functional performance criteria must also be met.
I hope I didn't miss your point but welcome direct communication if I'm not getting your ideas and you want to clue me in off-list.
Regards,
Norman B. Robinson
Section 508 Coordinator
IT Governance, US Postal Service
phone: 202.268.8246
-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Phill Jenkins
Sent: Monday, June 04, 2007 4:56 PM
To: TEITAC General Interface Accessibility Subcommittee
Subject: [teitac-general] Applicability of Functional Performance Criteria
Some of the discussions during the call today and especially the examples seem to be incorrectly founded in the premise that the functional performance criteria provisions always need to be applied. There were several examples or scenarios of Web, Kiosks, and other applications that went something like this:
"The Software and Web provisions already apply here, so why do we need to also apply this "functional criteria" if we already meet all those Software & Web provisions? Shouldn't the functional performance criteria only apply when choosing not to comply with the applicable software and web provisions for a software or web application?
If we took the view of only applying the functional performance criteria when not choosing to comply with the other applicable provisions, then we wouldn't be discussing the "AT used by people with disabilities" clause. If there are some other necessary provisions, then lets discuss them. But if we continue to promote this "catch all" provision as also applying, we will continue to have this unproductive discussion. Why can't we just propose to "drop" the clause that the functional performance criteria also include AT - why not just propose that the functional performance criteria only apply when AT is not provided and the application or product shall be operable without additional AT for users who are blind?
Regards,
Phill Jenkins, (512) 838-4517
IBM Research - Human Ability & Accessibility Center
http://www.ibm.com/able
From: Hoffman, Allen
Date: Wed, Jul 18 2007 9:30 AM
Subject: Re: 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.
From: Baker, Robert C.
Date: Wed, Jul 18 2007 10:00 AM
Subject: Re: 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: Hoffman, Allen
Date: Wed, Jul 18 2007 10:15 AM
Subject: Re: functional performance criteria
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: Peter Wallack
Date: Wed, Jul 18 2007 10:30 AM
Subject: Re: functional performance criteria
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
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. <br>
<pre class="moz-signature" cols="72">Peter Wallack
Accessibility Program Director
Oracle Corporation</pre>
<br>
<br>
Hoffman, Allen wrote:
<blockquote
cite="mid: = EMAIL ADDRESS REMOVED = "
type="cite">
<title>Re: [teitac-general] functional performance criteria</title>
<meta http-equiv="Content-Type" content="text/html; ">
<meta content="MSHTML 6.00.2900.3132" name="GENERATOR">
<div dir="ltr" align="left"><span class="011160816-18072007"><font
color="#0000ff" face="Arial" size="2">If, functional performance
criteria are only outcomes of technical conformance, the untestability
is not true.</font></span></div>
<div dir="ltr" align="left"><span class="011160816-18072007"></span> </div>
<div dir="ltr" align="left"><span class="011160816-18072007"><font
color="#0000ff" face="Arial" size="2">Can we explore this as a way to
come to grips with the testability of functional performance criteria?</font></span></div>
<div dir="ltr" align="left"><span class="011160816-18072007"></span> </div>
<div> </div>
<!-- Converted from text/rtf format -->
<p><span lang="en-us"><font face="Arial" size="2">Allen Hoffman --
<a class="moz-txt-link-abbreviated" href="mailto: = EMAIL ADDRESS REMOVED = "> = EMAIL ADDRESS REMOVED = </a>; v: 202-447-0303</font></span> </p>
<div> </div>
<br>
<div class="OutlookMessageHeader" dir="ltr" align="left" lang="en-us">
<hr tabindex="-1"><font face="Tahoma" size="2"><b>From:</b>
<a class="moz-txt-link-abbreviated" href="mailto: = EMAIL ADDRESS REMOVED = "> = EMAIL ADDRESS REMOVED = </a>
[<a class="moz-txt-link-freetext" href="mailto: = EMAIL ADDRESS REMOVED = ">mailto: = EMAIL ADDRESS REMOVED = </a>] <b>On Behalf Of </b>Baker,
Robert C.<br>
<b>Sent:</b> Wednesday, July 18, 2007 11:56 AM<br>
<b>To:</b> TEITAC General Interface Accessibility Subcommittee<br>
<b>Subject:</b> RE: [teitac-general] functional performance criteria<br>
</font><br>
</div>
<div id="idOWAReplyText67789" dir="ltr">
<div dir="ltr"><font color="#000000" face="Arial" size="2">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.</font></div>
<div dir="ltr"> </div>
<div dir="ltr"><font face="Arial" size="2">Robert Baker</font></div>
</div>
<div dir="ltr"><br>
<hr tabindex="-1">
<font face="Tahoma" size="2"><b>From:</b>
<a class="moz-txt-link-abbreviated" href="mailto: = EMAIL ADDRESS REMOVED = "> = EMAIL ADDRESS REMOVED = </a> on behalf of Hoffman, Allen<br>
<b>Sent:</b> Wed 7/18/2007 11:27 AM<br>
<b>To:</b> TEITAC General Interface Accessibility Subcommittee<br>
<b>Subject:</b> Re: [teitac-general] functional performance criteria<br>
</font><br>
</div>
<div>
<p><font size="2">Expanding FPC may make far more items less-than
fully conforming, yes,<br>
which will increase for some time the "best meets" selection. "best<br>
meets" is the vast majority of selections anyway, so the change won't be<br>
that significant.<br>
<br>
Also, what was the conclusion about dealing with multiple disabilities?<br>
I don't feel we can really do this effectively. I'd love for us to<br>
include low-vision/hard-of-hearing as that is the largest group of<br>
people with multiple disabilities by far, and then deaf/blind. I don't<br>
think we have unique requirements for people, for example, blind,motor<br>
limitations, and deaf that are accepted requirements.<br>
<br>
<br>
From: Hoffman, Allen
Date: Wed, Jul 18 2007 11:55 AM
Subject: Re: functional performance criteria
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: Jim Tobias
Date: Wed, Jul 18 2007 12:00 PM
Subject: Re: functional performance criteria
I agree -- there should be such a mapping. Iy would not imply that those
provisions were sufficient, but it would provide the necessary connection
between the abstract nature of the FPCs and the technical specificity of the
provisions.
******
Jim Tobias
Inclusive Technologies
= EMAIL ADDRESS REMOVED =
+1 732.441.0831 voice/tty
skype jimtobias
+1 908.907.2387 mobile
_____
From: Peter Wallack [mailto: = EMAIL ADDRESS REMOVED = ]
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.
From: Takemura, Michael (HP Accessibility)
Date: Wed, Jul 18 2007 12:35 PM
Subject: functional performance criteria
Allen... isn't making those changes a "Fundamental alteration" to the
product ?
From: Hoffman, Allen
Date: Wed, Jul 18 2007 1:05 PM
Subject: Re: functional performance criteria
Before I answer that let me throw this one in also.
If functional performance criteria have in some instances been
problematic for acquisition protests, if one were to have employed an
evaluation method based upon how technical standards are met, and how
that affects the outcome of the functional performance criteria, and the
agencies reasonable accommodations practices and policies and
requirements, I think the functional performance criteria are very
defensible. Standards need to describe this interrelationship to help.
This is the general DHS approach regarding the FPC(s).
I can't prove my premise however, but it is systematic, and if items are
not accessible because they failed to follow technical requirements,
function follows.
Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
From: Gregg Vanderheiden
Date: Thu, Jul 19 2007 7:50 AM
Subject: Re: functional performance criteria
Hi Peter,
See the preamble section of 508 for more info
But the FPC have several roles. One is to check to be sure that the
technical requirements cover it. it is possible to follow the technical
requirements and still not have a product that is accessible to the groups
described in the FPC. So you should check to see that the FPC are in fact
met by the product.
Today the results are mixed. But because the FPC are hard to measure - it
makes it more difficult. And people often ignore them.
(another role of the FPC is to provide guidance for technologies not covered
in the technical provisions. )
Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.
_____
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Peter Wallack
Sent: Wednesday, July 18, 2007 11:28 AM
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.
From: Peter Korn
Date: Sun, Jul 22 2007 1:45 PM
Subject: Re: 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.
>>
>>
>>
From: Debbie Cook
Date: Mon, Jul 23 2007 3:10 PM
Subject: Re: functional performance criteria
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:
