Functional Performance Criteria Issues and Recommendations

To facilitate tomorrow’s (today’s) discussion – here are some notes and recommendations/language to help facilitate and focus the discussion.

Sorry these are late but I got in late due to airplane fun and just pulled them together.

• Issue 1:   Are FPC guidance or requirements
• Issue 2:  Where do the FPC go
• Issue 3:  How are the FPC applied
• Issue 4:  Should the Functional Performance Criteria be more Testable
• Issue 5:  What does “through AT” mean

Issue 1:  Are FPC guidance or requirements

General Committee found that 508 Statute says the Access Board (and therefore we) must create functional and technical criteria.

The committee concluded that this said that both “Functional” and “Technical” are “Criteria” and must be met.

Recommendation:  They we keep them as “Criteria” for meeting the standard as specified in the statute.

Issue 2:  Where do the FPC go

Currently:  they are after the technical.

Pedagogically:  they could go before since they are the higher level requirements.

Practically:  people do the technical first and then look at functional to see if they need to do more or are done.

The current 508 standard says:  (from Subpart B preamble):

“(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.”

And (from Subpart C 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.”

These both seem to indicate that the FPC usually get looked at after the technical provisions are done.

Recommendation:  That the FPC be positioned after the Technical (as they are now) and as they are likely to be used.

Issue 3:  How are the FPC applied

This one is more complicated due to the fact that people interpret the current FPC differently.

some:  Say that they are not testable and do not need to be met.

some:  Say that they are only applied if there are no technical provisions that cover the product.

• the FAQ is cited that says that FPC do not need to be used if technical provisions:
  • Agencies should first look to the provisions in Subpart B to determine if there are specific technical provisions that apply to the EIT need they are seeking to satisfy.
  • 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.  Acquired products that meet the specific technical provisions set forth in Subpart B will also meet the broader functional performance criteria in Subpart C.
  • If an agency’s procurement needs are not fully addressed by Subpart B, then the agency must look to Subpart C for applicable functional performance requirements.
• Not clear from this text however is how you test to determine that “provisions in Subpart B fully address the product or service being procured.”  The only known way to do this is to see if meeting the technical criteria does indeed allow you to meet the FPC.  The General group solicited other ways to determine this and none were found.

some:  Say that FPC are the final test after doing the technical provisions.

• They cite the fact that the statute requires both functional and technical
• They also cite the paragraphs from the existing 508 regulations that say they should be used for a variety of reasons including:
  1. Overall Product Evaluation
  2. For technologies or components for which there aren’t specific technical provisions
  3. To ensure that the individual accessible components work together to create an accessible product
  • (from Subpart B preamble):
    • “(Functional 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.”
  • And (from Subpart C 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.”
• Further they are concerned that reducing its role from the three roles in the current standard would weaken the standard.

some:  Felt that the FPC were a justification for equivalent facilitation and that that was another role for the FPC.

some:  Felt that equivalent facilitation was an option independent of the FPC  (so it was not a role of the FPC though the FPC could still be useful to test the results as always).

some:  Felt that you could meet a technical provision with equivalent facilitation rather than thinking of equivalent facilitation as something you did at the FPC level after you failed the technical requirement.

Recommendation:  That the current roles and language be brought forward into the next version by using the following as the preamble to the FPC section:

“[The] functional performance criteria [are] for:

• overall product evaluation;
• for technologies or components for which there is no specific requirement under other sections; [and]
• to ensure that the individual accessible components work together to create an accessible product.”

Except for the three words in square brackets — [The], [are], and [and] — this is verbatim from the current 508 standard but is formatted to make it easier to see the three roles — in keeping with the formatting we have used for all of our previous work.

This neither expands, nor reduces, any of the roles that are currently defined for the functional performance criteria.

Issue 4:  Should the Functional Performance Criteria be more Testable

Currently:  the FPC are as testable as the old ones.

• But people have complained that they were not specific enough to be testable.
• The testability varies dramatically.
• Some are quite testable:
  • “access to all functionality without using vision”
  • “access to all functionality without using hearing”
    • These do not say usable by all people without vision or with all types of people with vision loss.
    • They simply say that all aspects need to be accessed without the person using vision.
    • This can be tested in a number of ways.
• Some are not as testable
  • access to all functionality of the product for people with limited reach and strength,
    • how limited?
  • access to all functionality of the product with enhanced audio
    • how enhanced?
• Some are in between
  • access to all functionality of the product visually without requiring visual acuity greater than 20/70
    • would be quite testable if 20/70 were changed to engineering terms rather than optometric distance vision.

Recommendation 1:  Although our current FPC are as testable as the old ones, we commission a group to look at them and see if they can be made more testable (or not).

Recommendation 2:  We consider dropping the new FPC dealing with color blindness — or change it to match the technical provision.  After talking to members no one could come up with a criterion for doing any more than the technical provisions or for testing to see that the FPC was met except the technical provisions (both the color and the contrast provisions).

Issue 5:   what does “through AT” mean

Does “through assistive technology” in the FPC (and “AT interoperability” and “programmatically determinable” etc. in the technical provisions):

1. require that products work with AT that is available to users; — or
2. is an API by itself sufficient, even if users can’t get any AT that works with the product.

The General group documented the following issues:

1. Should a product fail FPC(s) and/or technical standard(s) if some features don't work with some AT?
   • what if most but not all features work — bug in AT prevents the rest?
   • what if it worked fully and then AT changed (bug fix or new version) and no longer works?
   • what if it works with one AT and not another?
2. Should a product ‘pass’ 508 FPC(s) and/or technical standard(s) if product would work with AT only if AT was customized?
   • where info is not available at all (i.e., fails technical standard(s)and/or FPC) without customization?
   • where customization is needed to work efficiently?
3. Should a product ‘pass’ 508 FPC(s) and/or technical standard(s) if product won’t work with any AT that users can get
   • if there is an API but not product supports the API?
   • If there is an API but it only works with AT that users cannot get?

Recommendation:

1. We require that there be actual AT that users can get that would provide access in order to meet 508.
   1. We do not require that it be the AT that users currently have.
   2. We do require that AT exist.
   3. We do recognize that, where there is more than one way to do something, AT only needs to work with all components necessary to “access all information and functionality” of the product.  It is not necessary to access all features if they are redundant.  (e.g. One can print using the print command in the menu.  One does not necessarily need to access the print button in the toolbar as well – though that is preferable and desirable.)
   4. We do recognize that products may work except for specific aspects that are due to bugs in AT and we find a graceful way for companies to make these known (since they can block use by government employees) but do it in a non-pejorative way (since it may be beyond the control of the vendor).
   5. We do  encourage the ATIA to publish list of tools (and develop them if and as possible) that can be used to test for compatibility with whole classes of AT where that is possible (e.g. USB based alternate keyboards) and then work with researchers, industry and AT vendors to continually extend what can be done in this regard.
2. We draft a group to work on text to reflect this in our recommendation language.