EWG:Draft Oct 26 Updates

From TEITAC

This page (The Sandbox) or (The Updates Page) contains any updated text, comments (and minority report comments) and suggested text for provisions are collected on a single page, and cross-linked from each affected provision.

They are collected here for discussion at the November plenary.

This page is now "locked" for the meeting.

• Return to October 26th Draft.

New Proposed Drafts (aka, The Sandbox)

Subpart A: Section 1194.1 Purpose

Go to the Oct 26 Draft of this Provision

Go to the provision from the plenary meeting

Edits proposed to Version 1 to incorporate 255 by Karen Peltz Strauss
The purpose of this part is to implement section 508 of the Rehabilitation Act of 1973, as amended (29 U.S.C. 794d) and Section 255 of the Telecommunications Act, 47 U.S.C. 255.

Section 508
Section 508 of the Rehabilitation Act requires that when Federal agencies develop, procure, maintain, or use telecommunications, electronic and information technology, Federal employees with disabilities have access to and use of information and data including communication that are as timely, accurate, complete, and efficient as compared to the access and use by Federal employees who are not individuals with disabilities, unless an undue burden would be imposed on the agency. Section 508 also requires that individuals with disabilities, who are members of the public seeking information or services from a Federal agency, have access to and use of information and data including communication that are as timely, accurate, complete, and efficient as compared to that provided to the public who are not individuals with disabilities, unless an undue burden would be imposed on the agency.

Section 255
Pursuant to Section 255 of the Telecommunications Act, this part provides requirements for accessibility, usability, and compatibility of new telecommunications and interconnected voice over Internet protocol (VoIP) products and customer premises equipment (CPE) used to provide telecommunications services or interconnected VoIP service, as well as existing products and CPE that undergo substantial change or upgrade, or for which new releases are distributed. This part does not apply to minor or insubstantial changes to existing products and CPE that do not affect functionality

Text from: Telecommunications §1193.2; FCC Report and Order No. 07-110, released June 15, 2007) – amended to include interconnected VoIP equipment and CPE (new material in italics)

Comments from ITAA
Input on version 1:

1. Strike “compared to”
2. Replace "implement" with "provide standards for ascertaining the accessibility of E and IT required by"
3. Add reference to section 255

Proposed revised version 1: The purpose of this part is to provide standards for ascertaining the accessibility of E and IT required by section 508 of the Rehabilitation Act of 1973, as amended (29 U.S.C. 794d) and section 255 of the telecommunications act. Section 508 requires that when Federal agencies develop, procure, maintain, or use electronic and information technology, Federal employees with disabilities have access to and use of information and data including communication that are as timely, accurate, complete, and efficient as the access and use by Federal employees who are not individuals with disabilities, unless an undue burden would be imposed on the agency. Section 508 also requires that individuals with disabilities, who are members of the public seeking information or services from a Federal agency, have access to and use of information and data including communication that are as timely, accurate, complete, and efficient as that provided to the public who are not individuals with disabilities, unless an undue burden would be imposed on the agency.

Input on Notes: Delete “access” to follow the style used in subsequent bulleted items

Input on paragraph after last bulleted note: Major recurring issue - A or B. Insert "either" before "via" and "by" after "or", and "at the option of the vendor (… well, OK, then of the agency)" after "Subpart X".

Proposed revised paragraph after bulleted note: Access may be delivered either via built-in access features or by compatibility with assistive technology as described in the technical requirements specified in Subpart X at the option of the vendor. It should be noted that the determination of timely, accurate, complete, and efficient will not be a quantifiable measure.

Other comment on "purpose" section: Throughout the standards, replace all bulleted lists with numbered lists for ease of reference by users of standard.

Input on Rationale comment: Change “comparable” to to “comparable to”

Comment from IBM
In Version 2, it states: "Insert provision to address comparable access in Section 1194.2 Application". what is the provision being proposed here?

Comments from CSD/Trace Center
Accept Version 1 with the following edits

1. Accept edits from Karen P-S
2. Accept 3 edits from ITAA – Except change "Implement" to "provide standards for implementing".
3. Accept ITAA deletion of "access" in note
4. Accept ITAA addition of "either" and "by"
5. Best NOT add "at option of company/agency". It is not necessary and sometimes it is one or the other – better to make generic.

Subpart A: Section 1194.2 Application

Go to the Oct 26 Draft of this Provision

Go to the text proposal created at the November plenary

Additions proposed to incorporate 255 by Karen Peltz Strauss

1. Mark entire currrent draft as applicable to 508

2. Add section for 255

Section 255
Where readily achievable, telecommunications and interconnected VoIP equipment and customer premises equipment shall comply with the requirements of (fill in subpart) of this part. Where it is not readily achievable to comply with (fill in subpart'), telecommunications and interconnected VoIP equipment and customer premises equipment shall comply with the requirements of (fill in subpart), if readily achievable.

Product design, development and evaluation (for equipment and CPE covered under Section 255)

(a) Manufacturers shall evaluate the accessibility, usability, and compatibility of equipment and customer premises equipment used to provide telecommunications and interconnected VoIP services and shall incorporate such evaluation throughout product design, development, and fabrication, as early and consistently as possible. Manufacturers shall identify barriers to accessibility and usability as part of such a product design and development process.

(b) In development such a process, manufacturers shall consider the following factors, as the manufacturer deems appropriate:
(1) Where market research is undertaken, including individuals with disabilities in target populations of such research;
(2) Where product design, testing, pilot demonstrations, and product trials are conducted, including individuals with disabilities in such activities;
(3) Working cooperatively with appropriate disability-related organizations; and
(4) Making reasonable efforts to validate any unproven access solutions through testing with individuals with disabilities or with appropriate disability-related organizations that have established expertise with individuals with disabilities.

Text from: Telecommunications §1193.21 (first paragraph) and Telecommunications §1193.23 (second section). Changes to original text in italics.
Note: there are 3 references to subparts that must be filled in above. The first refers to accessibility provisions and the latter subpart refers to compatibility provisions.

Comment from IBM
Version 2, proposed paragraph (a)(2) - the inclusion of the language "using a product" significantly broadens the requirement on agencies. Seems like this language would require agencies to document undue burden for any non-compliant content created when "using a product".

Comments from CSD/Trace Center
Accept current text with the following edits.

1. Accept new a(2) from Version 2.
2. Keep (b) as it is in current version.
3. Accept Karen P-S edits to put in 255 language.
4. Include additional section proposed by Karen P-S

• Prohibited reduction of accessibility, usability and compatibility

(a) For purposes of Section 255, no change shall be undertaken which decreases or has the effect of decreasing the net accessibility, usability, or compatibility of telecommunications equipment, interconnected VoIP equipment, or customer premises equipment used with telecommunications or interconnected VoIP services.

(b) Exception: Discontinuation of a product shall not be prohibited.

Rationale: Text from: Telecommunications §1193.39 (the only change are the references to Section 255 and interconnected VoIP)

Subpart A: Section 1194.3 General Exceptions

Go to the Oct 26 Draft of this Provision

Additions proposed to incorporate 255 by Karen Peltz Strauss
Add a note that the following provisions apply only to Section 508

• 1194.3 - A - Intelligence Or Security System
• 1194.3 - NEW - Emergency, Field and First Response Use
• 1194.3 - B- Incidental To A Contract
• 1194.3 - C - Employees Not Individuals With Disabilities
• 1194.3 - D - Access By Public
• 1194.3 - F - Service Areas
• 1194.3 - NEW - Narrow, Delineated Use

1194.3 - E - Fundamental Alteration

Go to the Oct 26 Draft of this Provision

Go to the text proposal created at the November plenary

Comments by Karen Peltz Strauss to be consistent with the telecommunications guidelines
Version 2 (Current Provision)
This section as it was originally written can apply to both Section 508 and 255 and it would be a lot simpler to leave as is.

Comments from CSD/Trace Center
No change to language. (Version 2) Also version 2 can be applicable to both section 255 and 508 while version 1 specifies E&IT, which is only section 508.

1194.3 - F - Service Areas

Go to the Oct 26 Draft of this Provision

Comments from CSD/Trace Center
Version 1 Edit.

1194.3 - NEW - Narrow, Delineated Use

Go to the Oct 26 Draft of this Provision

Comments from CSD/Trace Center
Not accept. (Rationale: Not needed and dangerous. Likely to be abused.)

1194.3 - NEW – Inherently Visual EIT Assets

Addition proposed by ITAA
a. There are EIT deliverables that do not lend themselves to accessibility, nor do they lend themselves to equivalent facilitation because the information they impart is intended to be analyzed using motion, shape, color or other vision-dependent attribute, and/or because they present an ever-changing stream of information. Examples include:

i. Weather simulation imagery that presents a moving visualizations of weather systems (required by National Weather Service)

ii. Modeling and simulation results of physical phenomena that provides information (e.g., electronic sensor data transmitted by ocean buoys to illustrate ocean movement - NOAA, modeling and simulation of blast phenomena - DARPA, US Army

iii. Real-time monitoring by systems that simultaneously provide imagery and electronic reports that can be transmitted via web-enabled methodologies to analysts elsewhere (e.g., container inspection or passenger inspection systems used by U.S. Customs Service)

b. We recommend an exception be created to allow these applications to fall in a recognized are of the standard, rather than requiring stretching the application of some other provision.

Comments from CSD/Trace Center

1. Accept Karen P-S edit with list of sections that apply only to 508
2. Do NOT accept new provision from ITAA regarding 'Inherently Visual E&IT Assets. (Rationale: If we do it opens up an unending list of exceptions such ach inherently auditory, inherently fine motor, inherently simultaneous action, etc. There are many things that will not make sense for particular people with particular disabilities to do. This is covered through undue burden since it is technically not possible to do these. In addition adding accessibility to these types of products might cause a fundamental alteration to their nature or function, a basic defense to access under the Rehabilitation Act which already exists)
3. Do NOT accept new emergency and First Response Use (Rationale: this is same as #2 above. It falls in the same category – and is prone to abuse. For example, after 9-11 there were field units that people used to locate their children. This could be interpreted to mean that such units did not need to be accessible – leaving people with disabilities unable to post notices or search for their children. This should be covered by 'undue burden'. Where it is possible and for those disabilities it should apply. For those disabilities that do not make sense, it would not apply. Again the fundamental alteration language should take care of this.)

Definitions (New)

New and updated definitions proposed for compatibility with Section 255 by Karen Peltz Strauss

Customer premises equipment

Equipment employed on the premises of a person (other than a carrier) to originate, route, or terminate telecommunications or interconnected VoIP service.

Text from: Telecommunications §1193.3
Source: Telecommunications Act of 1996; FCC Order No. 07-110

Interconnected Voice over Internet Protocol (VoIP) Product

A product that is used to provide interconnected VoIP service

Source: FCC regulations

Interconnected Voice over Internet Protocol (VoIP) Service

A service that:
(1) Enables real-time, two-way voice communications;
(2) Requires a broadband connection from the user's location;
(3) Requires Internet protocol-compatible customer premises equipment; and
(4) Permits users generally to receive calls that originate on the public switched telephone network and to terminate calls to the public switched telephone network.

Text from: FCC regulations 47 C.F.R. §9.3

Manufacturer

A manufacturer of telecommunications or VoIP equipment or customer premises equipment that sells to the public or to vendors that sell to the public; a final assembler.

Text from: Telecommunications §1193.3
Source: Telecommunications Act of 1996; FCC Order No. 07-110

Peripheral devices

Devices employed in connection with telecommunications or VoIP equipment or customer premises equipment to translate, enhance, or otherwise transform telecommunications or VoIP services into a form accessible to individuals with disabilities

Text from: Telecommunications §1193.3
Source: Telecommunications Act of 1996; FCC Order No. 07-110

Readily achievable

Easily accomplishable and able to be carried out without much difficulty or expense.

Text from: Telecommunications §1193.3 (no change)
Source: Telecommunications Act of 1996

Specialized customer premises equipment

Equipment, employed on the premises of a person (other than a carrier) to originate, route, or terminate telecommunications or VoIP services, which is commonly used by individuals with disabilities to achieve access..

Text from: Telecommunications §1193.3; FCC Order No. 07-110

Telecommunications equipment

Equipment, other than customer premises equipment, used by a carrier to provide telecommunications services, and includes software integral to such equipment (including upgrades).

Text from: Telecommunications §1193.3 (no change)
Source: Telecommunications Act of 1996

Telecommunications service

The offering of telecommunications for a fee directly to the public, or to such classes of users as to be effectively available directly to the public, regardless of the facilities used.

Text from: Telecommunications §1193.3 (no change)
Source: Telecommunications Act of 1996

Usable

Means that individuals with disabilities have access to the full functionality and documentation for the product, including instructions, product information (including accessible feature information), documentation, and technical support functionally equivalent to that provided to individuals without disabilities.

Source: Telecommunications §1193.3 (no change)

Comments from CSD/Trace Center
Add definitions list above from 255 so they are there to support the 255 provisions.

Definitions-comments

Content

• (Robert B) Definition is not clear enough. Recommend adding: (for example: word processing files, presentation files, spreadsheet files, text files, portable document files, web based content, etc.)
• (Japan/Haijime Yamada) The definition of Web Content (Content which is made available in the World Wide Web) is too narrow. It must be such as “Content which is made available by web browser technology.” Web browser technology is used in a stand-alone product that is not connected to the Web.
• (CSD/Trace Center) Accept Robert B examples

Decoration

• (Peter K) Should this perhaps be only visual sensory experience? Or audio too?
• (Gregg V) The definition could apply to either - but we only use it for visual in the standard.
• (CSD/Trace Center) Keep as proposed by Web and Software.

Electronic and Information Technology

• (Peter K) It seems to me that by this definition, a copier is NOT E&IT, as the IT is embedded. Is this the intention?
• (Aubrey W) The definition is clear that it does include copiers. Clarification is needed on what the third sentence means.
• (Gregg V) A copier is IT. So is a printer.
• Need to get agreement if the current text is acceptable
• (CSD/Trace Center) Change "not the principal function" to "not a principal function". And add to end "E&IT that is combined with non-E&IT is covered but the coverage does not extend to the non-E&IT" There are too many compound products that are clearly IT with something added. A computer mounted on the door of a refrigerator should count as a computer – but the refrigerator should not be included.
  • Add "Note: A computer mounted on the door of a refrigerator should count as a computer – but the refrigerator should not be included."

Information Technology

• (ITAA) It is not clear if this definition includes Telecom or not. Suggest including in the list of examples if so, or stating that it does not.
• (Andi S) Why do we need this definition and the definition of E&IT?
• (CSD/Trace Center) REMOVE the definition. (Rationale: The term is not used anywhere in any provision except within the phrase "electronic and information technology" which is already defined. ITAA has noted that it is confusing but cannot be changed because it comes from Clinger Cohen.)

Menu

• (Peter K) this needs to be scoped, perhaps just to telecom or “audio menus”. As it reads now, things like a collection of radio buttons would be considered a menu. Also, where is this term used in 508? three things to consider: instead of “Set of selectable options”, what about “Presentation of a set of selectable options”, or “Presentation of a set of user-selectable options”. But in either case, we should note that this is an audio/aural presentations
• (Gregg V) Menu is used in a number of places. We need to be careful of each one.
• (Andi S) Suggest deleting this term and changing 6-D to "... such as options for selection and access to segments of the content....".
• (CSD/Trace Center) Agree with Peter K and Gregg V comments. Menu is used in 3 places: 3-CC advisory note example referring to software menus, in 4-C to refer to menu's on television display like device, and in 6-D referring to multimedia menus (like on DVDs). No suggested text.

• This definition can be removed since the term is no longer used.

Real-time Text

• (Peter K) Do we need "by a terminal"
• (Gregg V) I believe that phrase was included to prevent the 1 second from being applied to things that retransmit the text enroute.
• (CSD/Trace Center) After the word "terminal" add "(hardware or software)" to clarify since that is how it is used in the provisions.

Synchronized Media

• (ITAA) Propose revising to: Audio or video displayed at the same time as other time-based content that is required for understanding of the complete presentation. The other time-based content does not include equivalents such as captions, subtitles, or video description.
• (CSD/Trace Center) Use language posted to AV committee list per last meeting similar to ITAA edit: Audio or video displayed at the same time as other time-based content and/or with time-based interactive component that is required for understanding or use of the complete presentation. NOTE: The other time-based content that the audio or video is synchronized with to meet this definition does not include equivalents such as captions, subtitles, or video description.

Video Description

• (ITAA) Recommend change to rationale information. The last sentence is unclear. We propose a change from "This definition should not conflict with these guidelines" to "This definition should be changed so that it does not conflict with these guidelines, when published," or else "It is expected that there will be no conflict with these guidelines when they are published," depending on the intent of the sentence.

Section 1194.5 Equivalent Facilitation

Go to this section in the Oct 26 Draft

Comment from ATIA/ITI Joint Recommendation
Add a new sentence to 1194.5, Equivalent Facilitation, as follows:

• When equivalent facilitation is used to meet a technical provision, the Functional Performance Criteria should be used by the Federal department or agency to evaluate conformance with Section 508.

Rationale: The bulk of this sentence is currently included in the EWG 10-26 draft as the first in a list of three "roles" of the FPC. Given that it addresses Equivalent Facilitation, we recommend that it be moved into this section. We revised the sentence to emphasize the role of the FPC relative to the legal obligations of government departments and agencies under Section 508.

Technical Provisions

Go to this section in the Oct 26 Draft

Proposed introduction to distinguish between Section 255 and Section 508 by Karen Peltz Strauss
For the purposes of Section 255, each manufacturer of a product that is used to provide telecommunications or interconnected VoIP service must ensure that such products are designed, developed and fabricated to incorporate the access features described in the functional performance and technical criteria contained in this part, if readily achievable. Whenever it is not readily achievable to incorporate such access features directly into the products, the manufacturer must ensure that the products are compatible with existing peripheral devices or specialized customer premises equipment commonly used by individuals with disabilities to achieve access, if readily achievable.

For the purposes of Section 508, compliance with the functional performance and technical criteria contained in this part may be achieved directly or through assistive technology by each federal agency, unless the agency can show that such compliance would cause an undue burden.

Source: FCC Regulations 47 C.F.R. §§6.5; 7.5

Comments from ITAA
The current recommendation document proposes a complete re-work of the current Accessibility Standards format and layout. At present, we have six years of contracted efforts which have recorded operative regulatory guidance under the current format. The proposed organization of technical and performance requirements will result in a massive bottleneck of applicable Standards under the old format, and applicable Standards under a new organizational format. Any recommended input to the Access Board should also proposed how any new technical and performance criteria will be mapped to the previous requirement.

We feel the FAR is not the place for such technical and performance requirements transition since the FAR only addresses the procurement process itself.

Comments from CSD/Trace Center
Adopt Karen P-S additions for 255 and 508 addition. This includes removing the "directly or via AT sentence" and moving that to the intro saying that either method is appropriate but that there are differences in how they are applied for the two regulations.

1. Requirements for All Product and Services

1.1 Functional Performance Criteria

Go to this section of the Oct 26 Draft

Go to the text proposal created at the November plenary

Changes proposed to accommodate Section 255 by Karen Peltz Strauss
In the following provisions, remove the sentence: "This access may be provided directly or through assistive technology."

• 1.1-A - Without Vision
• 1.1-B - With Limited Vision
• 1.1-D - Without Hearing
• 1.1-E - With Limited Hearing
• 1.1-F - Without Speech
• 1.1-G - With Limited Reach, Strength or Manipulation

Comments from Sun
The Functional Performance Criteria were not part of the technical provisions of the current 508 and should not be part of them in the new version. They have not been discussed at the plenary level and the individual provisions have not been discussed at even the subcommittee level. The issue of testability has never been resolved. Recommend these remain, placed after the technical provisions, and be articulated as the goals of the technical provisions. Beyond that, we should go with "version 1" of the introductory language.

Comments from ITI
ITI has a number of concerns with the proposed language. The proposed new wording (both variations) imply that equivalent facilitation (EF) is a triggering mechanism for having to apply the functional performance criteria (FPC). The underlying premise seems to be that if a manufacturer must “invoke” EF, then they have “failed” to meet a technical provision. This would be a significant change from current interpretations. The implication appears to be that each technical provision has in effect “prescribed” a solution to the point that a deviation from it represents an “alternative.” However, a prescribed solution does not exist for many of the provisions (for example, 3A Color, 3F Non-text objects, 3I Pausing, etc.). In such cases, one could argue that any solution is EF, which certainly would not constitute a “failure.”

Equivalent Facilitation should remain distinct from the FPC in terms of the technical provisions: each technical provision should itself be “supportable” via the use of EF. To the extent that the FPC is intended to address situations not covered by any technical provision, then any solution would automatically be covered by the EF definition.

Finally, the FPC are not part of the technical provisions of the current Section 508 standards and we strongly believe that they should not be in a revised version, either. They have not been discussed at the plenary level and the individual provisions have not been discussed at even the subcommittee level. In addition, the critical issue of testability has never been resolved. ITI recommends that the FPC remain after the technical provisions and be interpreted as goals of the Section 508 standards.

Comments from TIA
TIA has issues and concerns with the 1.1 FPC provisions related to AT compatibility that were just put forth as resolutions for discussion from the General Interface Subcommittee Meeting on Oct 15, 2007. TIA asserts that some of these provisions are really only practical for a PC environment/platform that support software. Telecom and CE products usually do not permit, and may not be capable of supporting, the same kind and scope of AT compatibility that a PC allows.

Comments from ITAA
a. Version 1 is self-contradictory: "If [product] fails to meet… provisions" then “the agency what ensure that the purpose of the technical provisions is met”. Actually, if the provision is not met, it's not met.

b. “If the technical provisions do not apply,” then the FPC apply? In general the technical provisions do not apply when there is an exception. This provision says that the FPC ALWAYS apply, even in the exception case, which is faulty.

c. We agree that the FPC are good criteria for equivalent facilitation.

d. Version 2 is not well formed.

e. Structure provision 1.1 - A thru 1.1 - I similarly: "…without requiring _____.” [Vision, Visual Acuity, Color Vision, Hearing, Speech …], else there will be differences in interpretation of the applicability of the various FPCs.

Comment from IBM
General comment - Agree with the fundamental issues that have been raised about not including the functional performance criteria in the technical standards. These should be in a separate section because many of the technical standards support the objectives of the functional performance criteria. Also, since AT products are not subject to Section 508 compliance, prefer the existing Section 508 wording of the functional performance criteria. IT products can ensure that they have provided support for assistive technology products but without cooperation with AT vendors, support for all product functions by AT is not achievable.

Comment from ATIA/ITI Joint Recommendation

• Separate out the Technical Provisions and Functional Performance Criteria (FPC) from Subpart A.
• Incorporate the Technical Provisions into a new Subpart B and the FPC into a new Subpart C.

Rationale: Section 508 of the Rehabilitation Act (29 U.S.C. 794d) tasked the Access Board with, among other things, developing "the technical and functional performance criteria necessary to implement" Section 508. The law makes a distinction between the two, which is reflected in the current standards. Some within industry also believe that it is appropriate to continue to follow the order of reference in the law, i.e., listing the Technical Provisions first (e.g., as Subpart B) and the FPC second (Subpart C). However, we are mindful that some members of TEITAC are concerned that the FPC have not received appropriate consideration by government agencies and procurement officials, and believe that placing the FPC earlier in the standards may help resolve this. Accordingly, ATIA and ITI recommend that the committee set aside time on Tuesday, November 13, to discuss this matter in conjunction with a joint briefing that we are preparing in support of these recommendations.

• Revise the introductory text of the FPC section to read as follows:

The purpose of the Functional Performance Criteria is to provide guidance to help Federal departments or agencies determine whether products being used, developed, procured or maintained meet the functional needs of individuals with disabilities. The Functional Performance Criteria can also be used to help departments and agencies identify and report product functions that may not meet the Functional Performance Criteria and evaluate the importance of the lack of access to those functions relative to the intended use of the product.

Rationale: This revision helps to clarify the role of the FPC relative to the legal obligations of government departments and agencies under Section 508.

Comments from CSD/Trace Center - Gregg stated this is from the General Subcommittee
1. Move the FPC to a section after the technical Provisions and before the Documentation and Process Provisions. (Rationale: The functional Performance criteria do serve a different purpose than the technical provisions and are specified in the 508 Law as a separate but required component. Locating them after the Technical Provisions follows the logic that they are used to check to see if the technical provisions covered all the aspects and as an overall check for success of the technical provisions and any equivalent facilitation that might have been used as well.)

2. Include new intro (in main draft) but reworded to make them easier to read as follows:

The functional performance criteria have three roles:

1. If any of the technical provisions are not met, the Functional Performance Criteria are used to see if access is provided in another way (i.e. through equivalent facilitation).
2. If the technical provisions are met, the Functional Performance Criteria are used to see if the technical provisions cover all aspects needed to provide access to the product. (i.e overall evaluation)
3. The Functional Performance Criteria can be used to help identify and report functions (of a partially conforming product) that would not meet the Functional Performance Criteria (and would therefore not work with employees and/or public users with disabilities) so that agency can evaluate the importance of lack of access to those functions to the intended use of the product.

3. We think we understand what ITAA is trying to get at with the suggestion that a common format for the FPC be used. However the specific suggestion that they all be the same form does not work. These provisions were all discussed individually (except for the final 'common components' dealing with "full/comparable/etc" and "via users' AT/etc") extensively over many weeks and it was found that different wording was needed for the different items. Some examples of problems that arise from trying to use the format suggested:

• Without requiring color vision – sounds like it is only for people with no color vision at all – which is very rare. Color vision deficits pose unique problems, are very common and must be addressed.
• Without requiring visual acuity – would mean that the person was blind rather than low vision
• For hard of hearing – what would it say?
• Without requiring speech – sounds like speech output cannot be used.

However, there are some places where the language could be more regular. These are noted below and under the specific provisions and get at much of what we believe ITAA intended.

• Change 1.1A to "without requiring user vision"
• Change 1.1D to "without requiring user hearing"
• Change 1.1F to "without requiring user speech"

1.1-A - Without Vision

Go to the current version in the Oct 26 Draft

Go to the text proposal created at the November plenary

Comments from CSD/Trace Center
Change 1.1A to "without requiring user vision" [to address ITAA comment]

1.1-B - With Limited Vision

Go to the current version in the Oct 26 Draft

Go to the text proposal created at the November plenary

Comments from CSD/Trace Center
Change 1.1B to "without requiring visual acuity better than 20/70 and without relying on audio output."
Rationale: If audio is not eliminated as a solution – then 1.1B is always satisfied by 1.1A. 20/70 is used instead of the 20/200 to harmonize 508 and 255.

1.1-C - With Color Vision Deficits

Go to the current version in the Oct 26 Draft

Go to the text proposal created at the November plenary

Comments from Sun
This language is not testable, and in fact doesn't map well to existing technical standards (see the text in 3-A – Color, which states things much more clearly, and also 3-B - Contrast). So long as the Functional Performance Criteria aren't considered testable, this language isn't a large problem; but still this is already much better stated in 3-A and 3-B, and it would be better to eliminate this provision.

1.1-D - Without Hearing

Go to the current version in the Oct 26 Draft

Go to the text proposal created at the November plenary

Comments from CSD/Trace Center
Change 1.1D to "without requiring user hearing" [to address ITAA comment]

1.1-E - With Limited Hearing

Go to the current version in the Oct 26 Draft

Go to the text proposal created at the November plenary

Additional text from the telecommunications guidelines proposed by Karen Peltz Strauss
This subpart requires the provision of auditory feedback that is important for use of the product through at least one mode in enhanced auditory fashion such as increased amplification, increased signal-to-noise ratio or a combination.

Comment from ITI/Sun
The text refers to “enhanced audio” without defining it. We should not make such a reference without providing a definition.

Comments from ITAA
Proposed new wording for consistency. “Products must provide a mode that allows access with enhance audio, if audio information is required for access. This access may be provided directly or through assistive technology."

Comments from CSD/Trace Center
Add note to 1.1E to "Audio can be enhanced by providing increased volume or removal of background music or sounds." [to address ITAA, ITI and Sun comment]

Comment from Sun
Propose the definition of "Enhanced Audio": Audio which has been enhanced through amplification and/or through a variety of audio filters to make it easier for people with hearing impairments to understand.

1.1-F - Without Speech

Go to the current version in the Oct 26 Draft

Go to the text proposal created at the November plenary

Comments from CSD/Trace Center
Change 1.1F to "…without requiring user speech" [to address ITAA comment]

1.1-NEW - With Low Vision and Limited or No Hearing

Go to the text proposal created at the November plenary

New provision proposed by Karen Peltz Strauss
Products must provide at least one mode that permits operation by users with visual acuity between 20/70 and 20/200, without relying on audio output

Text from: Telecommunications §1193.41 (b) (no change)

1.1-G - With Limited Reach, Strength, or Manipulation

Go to the current version in the Oct 26 Draft

Go to the text proposal created at the November plenary

Addition from telecommunications guidelines proposed by Karen Peltz Strauss
Products must provide at least one mode that allows access for people with limited reach and strength, that does not require user fine motor control, and that does not require simultaneous actions.

Rationale: This draft adds the phrase "that does not require fine motor control" as well as reflecting the general recommendation to remove the phrase about AT.

Source: §1193.41(e)

Comment from ITI
This text is completely redundant with the technical provision 2.1-D (2). This duplication is unnecessary and adds to the burden of meeting 508 with no benefit. This should be removed.

Comments from ITAA
Reword for consistency. “Allows access without requiring more than limited reach and strength, and without requiring simultaneous actions.”

Comment from Japan/Hajime
Previous functional performance criteria include the following:

"At least one mode of operation and information retrieval that does not require fine motor control or simultaneous actions and that is operable with limited reach and strength shall be provided."

In section 1.1-G (With Limited Reach, Strength, or Manipulation), we could only find the functional performance criteria relating to the clause " does not require simultaneous actions" and could not find anything relating to the clause "does not require fine motor control." Do we miss it in the new draft?

Comments from CSD/Trace Center
Change 1.1-G. to "…Products must provide at least one mode that allows access for people with limited reach and strength, and that does not require user fine motor control or simultaneous actions. [to address Japan and Karen P-S comment. Also somewhat ITI]

1.1-H - Without Physical Contact

Go to the current version in the Oct 26 Draft

Go to the text proposal created at the November plenary

Comments from ITI
Products not meeting the no-touch through AT portion of the provision can claim the exception for "closed products". There is an inescapable logical loop rendering this proposed provision completely ineffective. The proposed provision should be removed because, in addition to the logical loop problem, no-touch access through AT is already served by the limited mobility functional standard (1.1-G) as well as many of the technical standards.

Comment from Paul Schomburg
I think this provision as drafted is confusing, incomplete and requires more in-depth discussion. My primary concern is that the existence of a network interface by itself does not provide access to “all the features of the product” and thus by itself cannot assure accessibility. With regard to the specific solutions sited by Greg Vanderheiden, I don’t know of any commercial off-the-shelf product that is compatible with the ANSI/INCITS URC standard and thus doubt it is a practical solution at this time. I also don’t believe that the “use of cameras to monitor user movement to control input would meet this provision” since such a method of control is not a product feature a manufacturer could incorporate into the product itself.

Rather than apply this to all E&IT products, these requirements should only be applied to products with a visual interface that could be accessed from across a network. I would need further explanations or examples for how E&IT products without a visual interface could comply to be comfortable with applying this to all E&IT products. To be proactive here are some suggestions for a new version, but there may be other parties that also need to weigh in with their views:

New proposed text: Products with a visual interface must provide at least one mode that allows the product to be accessible for people with disabilities with only minimal physical contact with the product such as power-on, initialization of a call, change of a mode of operation, or initial connection and setup of a special interface device. This access may be provided directly or through assistive technology.

Rationale and Notes

• It is well known that a large population of people with physical disabilities cannot reach out to touch a product or cannot reach out long enough to actually operate a product physically.
• While it is preferable that no contact at all be required, some physical contact may be needed to turn power on, initialize a telephone call or change mode of operation. In some cases it may be required for the user to be assisted by a companion or bystander with these operations.
• Assistive Technology examples:
  • The use of a standard network interface (e.g. USB, Ethernet, IEEE 1394, Wi-Fi, Bluetooth, etc.) that allows users to control the product using software via a wired or wireless network connection would meet this provision.
  • The use of the infra-red (“IR”) port used for remote controls in consumer electronics products would meet this provision.
• Direct Access examples:
  • Voice dialing is an example of direct access. Access to voice dialing may require physical contact with the product to initiate the call or change mode of operation to enable voice dialing.

Comments from CSD/Trace Center
If there is concern here – then perhaps an 'at risk' note could be used to say that it would be removed if certain things were not true by the time the rules were promulgated.

1.1-I - With Cognitive, Language or Learning Limitations

Go to the current version in the Oct 26 Draft

Go to the text proposal created at the November plenary

Update proposed by Karen Peltz Strauss
Products must/shall? provide at least one mode that accommodates cognitive, language, memory or learning impairments, directly or with assistive technology.

Rationale: The telecommunications guidelines include a requirement for provision of a mode that “minimizes the need for memory.” §1193.41(i). This version adds the word "memory"

Comment from ITI
While ITI appreciates the sincere interest and desire of many to address cognitive disabilities within Section 508, we believe that doing so would present a number of serious challenges for manufacturers and government agencies, including:

• A lack of technical provisions relevant to cognitive disorders
• A lack of differentiation of various types of cognitive disorders, and
• A lack of clear distinction of when the needs for those with cognitive disorders are met.

If we are still struggling with even understanding what this should be at this time, then we likely don't have enough time to finish it. Accordingly, we recommend removal of this provision.

Comment from Sun
We included our comments in the ITI report for this provision, but feel strongly that this item needs resolution. If we are still struggling with even understanding what this should be at this time, then we likely don't have enough time to finish it. The current provision text is written as a general goal, and Sun supports including "should" language for this provision at this point, if it is stated in the context of a goal for the technical provisions.

Comments from ITAA

• This requirement is overly broad. Anyone can claim conformance.
• This theoretical mode of operation is not testable as described, even by "Expert Evaluation". There are no thresholds described, e.g., grade level reading.
• What are the criteria for satisfying this mode.
• Until there are thresholds defined, we prefer this provision not be included.

Other Comments

• The general group identified several issues and questions in trying to move this forward. The working group is looking for sufficient technical provisions to support the inclusion of a FPC.
• From Web and SW Subcommittee: This requirement is extremely broad. Three features recommended by Dr. Clayton Lewis to address the needs of people with cognitive disabilities are: Word lookup, Text Reading, Spelling assistance. The AT Interoperability provision supports AT with the necessary information to provide these functions.

Comments from CSD/Trace Center
Use language proposed by Karen PS from 255

1.2 General Technical Requirements

1.2-A - Accessibility Configuration

Go to the Oct 26 Draft of this Provision

Go to the text proposal created at the November plenary

New version proposed for this provision by Gregg V
In complying with this subpart,

• Products procured must be capable of being configured to be accessible to and usable by people with disabilities while simultaneously meeting the products function.
• After procurement each agency must activate accessibility features and configure products so that they are accessible to and usable by people with disabilities who will be using the products or systems.

Rationale: Based on an earlier comment from Robert Baker that this should be a two-part provision, and updated to remove the references to RFPs

Additional section proposed by Karen PS
Prohibited reduction of accessibility, usability and compatibility

(a) For purposes of Section 255, no change shall be undertaken which decreases or has the effect of decreasing the net accessibility, usability, or compatibility of telecommunications equipment, interconnected VoIP equipment, or customer premises equipment used with telecommunications or interconnected VoIP services.

(b) Exception: Discontinuation of a product shall not be prohibited.

Rationale: Text from: Telecommunications §1193.39 (the only change are the references to Section 255 and interconnected VoIP)

Comment from ITI
While it is clear the proposed provision intends to apply only to agencies, traditionally agencies have flowed all of the Technical Standards down to vendors. As written, this proposed provision compels agencies to configure for accessibility despite the very real prospect that large numbers of disabled and non-disabled users would experience significant degradation in efficiency and productivity.

While this provision solves problems with web and other server-side solutions, it is unreasonable when it comes to desktop/laptop procurements. Turning on ALL accessibility features of a desktop will render them useless to ALL users.

This provision should be moved to the Application section (Section 1194.2) with revisions allowing agency discretion so it is not applied in unreasonable situations.

New version proposed for this provision:
As needed by employees and members of the public, agencies must activate accessibility features and configure products so that they are accessible to and usable by people with disabilities.

Comment from IBM
Agency requirements such as these should be separated into a separate section from the Technical Provisions so as not to confuse procurement officials about what they should be asking of vendors.

Comments from NASCIO:
Agency requirements do not belong in "technical requirements" to be applied to EIT products/services. This includes 1.2-A, 1.2-C, 5-A, 5-F (1) & (3), and 7.2-A. These might all be adopted as agency policies (perhaps with much more specificity applicable to implementation in that agency), but not as EIT technical standards.

Comments from CSD/Trace Center

• Use language proposed by Gregg V [this would address first comments by ITI]
• Do not move to application section. This relates to both products (first bullet) and to companies who provide services to the government (e.g. 'seats').

1.2-B - Accessible Content

Go to the Oct 26 Draft of this Provision

Go to the text proposal created at the November plenary

This provision is new in the Oct 26 draft, so there were no comments to list in this page.

1.2-C - Closed Functionality

Go to the Oct 26 Draft of this Provision

Go to the text proposal created at the November plenary

Comment from ITI
The proposed provision is overly complicated as written. The following edit makes the intent of this provision more clear.

New version proposed by ITI for this provision:
If any functionality of a product is closed for any reason including policy constraints or technical limitations then that closed functionality must be made available to and operable by people with disabilities within the product itself. As a result, the following provisions would not apply to the closed product or closed functionality:

• 2.1-E - Connector or Connection Language
• 3-F - All Non-Text Objects
• 3-G - Human Language
• 3-H - Language of Parts
• 3-N - Link Purpose
• 3-O - Information and Relationships
• 3-P - User Interface Components
• 3-U - AT Interoperability
• 3-W - Accessibility Services

Comment from ITAA
In testing to see if a product is "closed", the definition from subpart A is used. If the reason a product is “closed” is because of policy, the vendor cannot represent his product as "compliant" with 1.2 - C, even though he/she has made allowance to have a "non-closed" product. Therefore a vendor cannot represent the level of accessibility to a purchaser.

Comments from (Japan/Haijime)
(This comment also applies to the definition). What are the products the requirement of 1.2-B 'Closed Product and Function' should be applied to? Are the multi-function printers (having functions such as print, copy and scan) a closed product? What happens if main function (e.g. print) is supported and auxiliary functions (e.g. copy and scan) are not supported? If an industrial standard interface in hardware and/or software exists, can the product be determined as 'Supported' We would like to propose the following modification:

"If any main functionality of the product is closed, then individuals with disabilities must have access to that functionality without the use of any assistive technologies that must be attached or installed. A personal assistive listening device that connects to the standard audio connection required in the audio connection provision is not considered assistive technology."

Comment from IBM
There is something wrong with our structure. Closed products have certain requirements that are not required of products that are compatible with assistive technology. Likewise, some of the requirements, 1.2-F Audio Information and 1.2-G Video information, in the General section do not apply to products that should be compatible with AT. Somehow we have to fix this.

Comments from NASCIO
Agency requirements do not belong in "technical requirements" to be applied to EIT products/services. This includes 1.2-A, 1.2-C, 5-A, 5-F (1) & (3), and 7.2-A. These might all be adopted as agency policies (perhaps with much more specificity applicable to implementation in that agency), but not as EIT technical standards.

Comments from CSD/Trace Center

1. Products are not "closed" unless all of their functionality is closed. This one is written to apply to specific functionalities. Since it acts as an exception to other technical requirements it should be included here. It helps to identify what needs to occur if aspects of products do not meet the "compatibility" provision.
2. The provision is meant to apply to all of the functionality of the product. Not necessarily all the features (i.e. ways of getting to a products functions) but to the functions of the product.
3. This provision also highlights the need to look at this from a function standpoint rather than whole product or main function.

1.2-C - Flashing

This provision was transferred out of the General SC to the Hardware SC and Web/Software SC and the text moved to Sections 2 and 3

1.2-D - Biometric ID

Go to this section of the Oct 26 Draft

Go to the text proposal created at the November plenary

Comments from ITAA
a. Remove “form” from “alternative form”. Biometric was already identified as a "form" and we are agreed that another biometric, even though it's not an "alternative form," is OK.

b. When multiple biometrics fail, we assume that accommodation may be used.

c. It is the opinion of computer security professionals in the ITAA membership that the Access Board should not specify solutions to security issues in Section 508, but rather leave it to National Institute of Standards and Technology (NIST) and their partners to remedy this in the standards for security identification. We encourage the access board to provide them with the an understanding of the issue.

Comment from IBM
The explanatory note should not be recommended to be in the standard but should be in backup material that we submit to the Access Board.

Comments from CSD/Trace Center
Keep current language. It provides both industry and agencies with maximum flexibility in identifying ways for people with disabilities to get through processes requiring ID. It does not specify any method or limitations – just that some way be available / provided.

1.2-E - Pass Through

Go to the Oct 26 Draft of this Provision

Go to the text proposal created at the November plenary

Comment from Sun and ITI
The first sentence would apply to virtual every computing device. Virtually every computing device “transmits or conducts information or communication,” so this would apply to things like disk drive firmware and a huge host of other things that have no user input impact. It should be altered, restricted to telecommunications products (where the provision came from), or removed. The second sentence is fine. The third presumes a specific technical approach to real-time-text which may not be appropriate.

New version proposed for this provision:
Technologies which use encoding, signal compression, format transformation, or similar techniques must not remove information needed for access, or must restore it upon delivery. Firewalls, routers, gateways and other products that pass real-time voice communication must also pass real-time text communication signals (including mixed voice and real-time text) that are standard in the United States for that technology platform without distortion or error beyond 1%.

Also rename the provision to: Telecommunications Information Pass Through

Comments from ITAA
a. It's the INFORMATION or COMMUNICATIONS that must pass through, not PRODUCTS. What is a “translation protocol”? What is definition of “usable format”? The provision is unclear.

b. Is a computer a product that transmits or conducts? Then it would meet or not meet this provision, however, how does the computer vendor know what a software will do? He/she doesn’t, but he/she is still responsible for representing conformance to the agency. There appears to be issues that will impact implementation.

c. Is a telephone a product that transmits information? How can this apply to voice? The provision should clarify.

d. A restriction on codes will impede innovation. This provision is too vague and is open to too many possible interpretations.

Other Comments

• (Gregg V) It says that these things should not strip disability access information in the process. For most things it would be no issue. In places where it does apply it would be important.
• (Gregg V) I think the last "usable" is supposed to be Accessible.
• (David B/Gregg) Need note that this applies to captions
• Need rationale and impact for this provision.

Comments from CSD/Trace Center

1. The provision is intended to apply to every E&IT device. All that it required however is that access information not be removed when information is being transferred etc. If the processes are transparent and not lossy (i.e. they do not throw some data away) then this will not be a problem. Disk drives etc. would not be a problem and would pass automatically. The problem originated with the stripping of captions. It would also apply to stripping text or video from a call whether the call is via traditional telecommunications or via interconnected VoIP, which is now covered under Section 255.
2. The third sentence does not assume any method for passing the real-time text. Just that the text not be lost.
3. "usable format" should be "accessible format"
4. There is not a restriction on codes. Just a requirement that access related codes be passed through.
5. Computer manufacturers are responsible for what they deliver – not for software added later - as is true for all the provisions.

1.2-F - Audio Information

Go to the Oct 26 Draft of this Provision

Go to the text proposal created at the November plenary

Comment from Sun
This is not a testable provision. It belongs in the FPC section rather than here.

Comments from ITAA
The provision must clarify “operation and use” of WHAT? A product? A system of products to solve a business problem of an agency?

Comment from IBM
Audio content is covered by 6-A - Captions and Transcripts. We need to clarify what the additional requirement is here or remove it.

Comments from CSD/Trace Center

1. This is easily tested. Remove all audio input from user (e.g. using masking headphones) and see if they can use the product successfully. If so then all audio information needed to use product is available in visual form.
2. change "operation and use" to "product operation and use" [addresses ITAA comment]

1.2-G - Visual Information

Go to the Oct 26 Draft of this Provision

Go to the text proposal created at the November plenary

Comment from ITI
This provision requires products that are not compatible with assistive technology (closed products) to include audio output and, where appropriate, tactile markings. Currently, there are few mainstream E&IT products that offer built-in audio output to fully operate the product. Adding this feature would significantly increase the E&IT cost. It may also limit product availability for federal and state agencies if, due to the expense, manufacturers only incorporate audio into a select number of models. Allowing audio or tactile forms to share visual information provides more cost effective options for both the manufacturer and the customer.

This is not a testable provision. It belongs in the Functional Performance Criteria section rather than here.

Comments from ITAA
a. The provision must clarify “operation and use” of WHAT? A product? A system of products to solve a business problem of an agency?

b. The provision must make clear if this means BOTH audio AND tactile, or just tactile, “where appropriate?”

c. The provision must make clear what “where appropriate” means?

Comment from IBM
Visual content is covered thoroughly by section 6 for content and section 3 for products that are intended to be compatible with AT. If there is something additional that is required by this provision it needs to be clarified. If this provision is only meant for closed products, it needs to be scoped or moved to a separate section. Also, the phrase "where appropriate" raises testability issues.

Comments from CSD/Trace Center

1. This is easily tested. Remove all visual input from user (e.g. using mask) and see if they can use the product successfully. If so then all visual information needed to use product is available in audio form.
2. There are many products with audio output. Those products where there is not audio output or tactile output of key information would indeed fail this provision. That is the purpose of the provision, to identify products that cannot be used for this group of users.
3. change "operation and use" to "product operation and use" [addresses ITAA comment]

1.2-F and 1.2-G Audio and Video Information

Go to the current version in the Oct 26 Draft

Update proposed by Karen Peltz Strauss
A similar edit to the changes proposed for section 1.1 is also proposed for two other sections, to delete from the following provisions, the phrase: "either directly or via assitive technology"

• 1.2-F - Audio information
• 1.2-G - Visual Information

1.2-H - Color

Go to the Oct 26 Draft of this Provision

Go to the text proposal created at the November plenary

No comments were submitted for this provision

1.2-I - Text size

Go to the Oct 26 Draft of this Provision

Go to the text proposal created at the November plenary

Comment from ITI
ITI has serious concerns about the application of this provision to fixed text, such as on legends, labels, icons, etc. It would limit form factor options and is based on a software-driven requirement where there is greater flexibility within software to address text variation, whereas a legend on a keyboard or phone pad will not change and is fixed and can be learned. In addition, this provision would present serious testability issues.

Comments from ITAA
Replace "done" with "read by people with 20/20 vision"

Comments from CSD/Trace Center

1. Agree with ITAA to change "done". But "read is perhaps the wrong word since it refers to "activating a mode" and not just reading. Suggest "seen by people"
2. In checking with a vision scientist at Lighthouse – this provision would cover most types of mild low vision up to 20/70. Those not covered would be those with field deficits that allowed standard vision – but they would not need this.
3. It was pointed out that some products could not meet this provision. However this is appropriate. Products that do not meet this provision would not be usable by people with even mild low vision (20/70). So it would be appropriate that those products be noted as not meeting this provision -- so that it would be clear that employees with low vision would have problems with the products. Most standard keyboards would meet this provision – even for keys with words and multiple legends.

Proposed new text from CSD/Trace: There must be at least one mode where all information that is required for product use and is provided in text that is 3.5 times the minimum size needed for people with 20/20 vision or is readable by people with 20/20 vision at 3.5 times their typical viewing distance. This mode must be the default mode unless the activation method for that mode can be see by people at 3.5 times the typical viewing distance or the product automatically sets itself to that mode for users who require it.

Note: Providing text in an accessible file on a device meets this requirement for information that is not location specific (e.g. labels are location specific).

2. Hardware Aspects of Products

2.1 All Products with Hardware

2.1-A - Luminance Contrast Ratio for Display

Go to the Oct 26 Draft of this Provision

Go to the text proposal created at the November plenary

Discussion of Work in Progress  
* Need rationale and impact

Comment from ITI
The challenges set forth in this provision are driven by the light measurement protocols and equipment that will be required to document the high and low state luminance conditions, at a minimum a “dark room lab” and basic photometer would be required to measure the light output for active displays. For passive display an additional light source would be required. Typically, light measurement involves very specific equipment in highly controlled environment. Additionally, there are concerns that this requirement is not in harmony with current ISO standards for CRT and LCD performance.

Comments from ITAA
Insert "products with displays must provide". Delete "For displays on products" and "must exist"

Proposed new wording: Products with displays must provide at least one mode where the contrast ratio between the luminance at light state compared to luminance at dark state shall be X:1.

Comments from Japan/Hajime
Are the definition in 1194.4 and clauses 2.1-A and 2.1-B consistent with each other? Also please explain the harmonization against international standards such as ISO9241-3 and ISO13406-2.

Comments from CSD/Trace Center

1. Agree with ITAA (except use IS instead of SHALL)
2. RE: ITI comment. Almost all displays will come with these values already specified. For manufacturers it should not be hard to calculate the ratio from the product specifications.

Proposed new text from CSD/Trace: Products with displays must provide at least one mode where the contrast ratio between the luminance at light state compared to luminance at dark state is 5:1.

2.1-B - Reflectance Contrast for Legends and Passive Displays

Go to the Oct 26 Draft of this Provision

Go to the text proposal created at the November plenary

Discussion of Work in Progress: 
* Need rationale and impact
* There is some conflict between guidance provided in non-accessibility 
  ISO standards such as ISO 9241.4

Comment from ITI
The challenges set forth in this provision are driven by the light measurement protocols and equipment that will be required to document the luminance contrast. At a minimum, a “dark room setting”, basic photometer, and controllable light source would be required. Typically, light measurement involves very specific equipment in highly controlled environment. Additionally, there are concerns that this requirement is not in harmony with current ISO standards for keyboard legends/labels.

Comments from ITAA
a. The provision needs to clarify if this means "printed on the device?" Can a vendor print a sheet and enclose it with the product in the packaging? Then it's not "the only way."

b. The provision needs to clarify the meaning of "instructions on the device"? Does it mean instructions CONCERNING the device, or does it mean instructions physically written on the device?

Comments from CSD/Trace Center

1. ITAA comment #1 should be addressed by current notes.
2. To address ITAA comment #2 suggest changing "instructions on device" to "instructions printed on device"
3. RE ITI comment. We understood from discussions on hardware committee that these did match what was already in ISO standards. A ratio higher than 3:1 is desired.

2.1-C - Flashing

Go to the Oct 26 Draft of this Provision

Go to the text proposal created at the November plenary

Comments from Gregg V

• We are still working on the Hardware flash definitions for
  • screen flicker (not content)
  • indicators and visual alerts
• Impact should say: "Negative cost - The change saves money (e.g. special circuitry not needed to control frequency of status LEDs) and provides additional flexibility to industry for non-critical stimuli."
• Possible advisory note: "NOTE: Screen flicker of 60hz is safe for most (85%) but refresh frequencies of 75hz or greater are recommended where possible."

Comments from ITAA
a. If it is possible that a computer with a small, dim monitor pass, and a computer with a large, bright monitor fail, which product does not comply? The computer, the software, the content, or the monitor?

b. "Under the general flash and red flash threshold" means “less than some thresholds expressed elsewhere?” Reference?

Replies to ITAA from Gregg V
a. There currently is no provision dealing with monitors. Only the provisions for software and Web have been completed. The Display Provision is still being worked on by a subcommittee of hardware subcommittee (consisting of Rob N, Tom A and Gregg V).

REGARDING THE 'SOFTWARE/CONTENT/MONITOR question: Any of the three could fail. The Monitor; if it flickers itself with no content being displayed (the monitor is not responsible for what is displayed on it). The software or content could fail if they generate images that flash in a way that violates either flash threshold. For content it is a function of the content not the brightness of the display - so failures by software or content are independent of the display.

b. "General Flash and Red Flash Threshold" are defined in the Definition section. (Suggestion: all defined terms should be marked when they are used, or linked to the definition, so they can be easily identified.)

2.1-D - Mechanical Controls

Go to the Oct 26 Draft of this Provision

Go to the text proposal created at the November plenary

Discussion of Work in Progress: 
* Need impact

Comments from ITAA
Regarding item 2, does this disallow audio volume controls with knobs for twisting? If so, we suggest if there is alternative, accessible way of controlling the parameter that is controlled by twisting, this be allowed in the provision.

Suggest change in title to MECHANICALLY OPERATIED CONTROLS as named in the definition of OPERABLE CONTROLS.

Comments from CSD/Trace Center

1. Recommend against renaming. "Mechanically Operated Controls" is longer and only adds ambiguity (does mechanical mean how the controls operates or was operated).
2. This provision does not disallow rotational controls that can be operated by rubbing edges or moving pointers etc. It does specifically disallow controls that require twisting of the wrist. A quick test is if they can be operated by using the eraser end of a pencil.

2.1-E - Touch Operated Controls

Go to the Oct 26 Draft of this Provision

Go to the text proposal created at the November plenary

Discussion of Work in Progress
* Keyboard controls that provide equivalent functionality are equivalent
* Touch screens can't always provide a 1:1 match of soft and mechanical controls.
* Need to finalize some language that addresses the intent of “redundancy” 
  of controls beyond just requiring another set of mechanical controls.  
* Need to add an ability to de-activate the touch screen to prevent accidental
  activation
* Is remote control an acceptable alternative
* Need impact

Comments from ITAA
The provision must clarify the logical connection between clauses 1 and 2 AND? OR?

Comments from CSD/Trace Center
RE ITAA comment. If it is not clear that both provisions must be met, they could be connected with AND.

2.1-F - Standard Connection

Go to the Oct 26 Draft of this Provision

Go to the text proposal created at the November plenary

Discussion of Work in Progress: 
* Need to determine provision title
* Need impact

Comment from ITI
The Section 508 standards should not dictate what types of products vendors must offer. Section 508 is a government procurement law and should not attempt to regulate industry. The phrase "...it shall be the responsibility of the E&IT vendor to offer such adapter" should be changed to "..it shall be the responsibility of the procuring agency to identify that such adapters are available in the market." This creates an agency requirement that can more easily flow down to vendors.

New version proposed for this provision:
If users can access and control the user interface of a product through a non-standard user connection, they must also be able to control that functionality through a standard user connection using standard protocols for that type of input or output. If an adapter is required to convert a non-standard user connection on an E&IT device into a standard user connection, it shall be the responsibility of the procuring agency to identify that such adapters are available in the market.

Comment from Closed SC
The Closed SC felt pretty strongly that since this is about user interface, that term needed to be in the title. They didn't know what "standard" means in this context. Recommend changing the title to: "User Interface Connector or Connection" or "User Interface Connection"

Comments from ITAA
a. Title is not descriptive. (Referring to "Connector or Connection Language)

b. First clause does not make sense: If users can access and the user interface of a product

c. Does this provision unprotect proprietary connections?

d. Deciding who the responsible party is in this spec is, respectfully, out of scope.

Comments from CSD/Trace Center

1. Agree with ITI and ITAA – that E&IT vendor not be called out in 508 standard which is agency requirement. Suggest slight edit to ITI suggestion to remove SHALL – so it reads ".. the procuring agency must identify a market source for the connector if it isn't a standard option for the product."
2. Agree with closed committee on "User Interface" but feel it must be a standard connection so suggest "Standard User Interface Connection". This will also clearly separate it from audio connection.
3. RE ITAA question on Proprietary connections – it allows all connections to be proprietary. But if a proprietary connection is used for alternate control of a product – then an adapter to a standard format is required so that alternate accessible interfaces can also be used without having to design them custom for the proprietary interface (a very expensive and seldom available option).

2.1-G - Installed or Free-Standing Products

Go to the Oct 26 Draft of this Provision

Go to the text proposal created at the November plenary

Discussion of Work in Progress: 
* Need impact

2.2 If the Product has Speech Output or Throughput

Go to the Oct 26 Draft of this Provision

• (Phil J) An editorial comment - that the text in the 2.2 provisions A through F do not match the title - 'audio output' vs 'speech output'. Because of the mismatch, one can think it applies to all audio output, but apparently the title is correct and its the provisions A through F that need editing to make it clearer. All the 2.2 provisions A through F say "audio output", except 2.2-E uses "incoming voice signals", and 2.2-D explicitly uses both: "Product Characteristics: Sound output – speech, Sound output (other than speech)" So the text needs to be tightened up in the next editorial pass to avoid the confusion.

• (Andi S) Is "speech" really the right word for this title? What if it has audio output that is not speech? Wouldn't some of these provisions apply in that case?

Comments from CSD/Trace Center
For all of the provisions in this section ensure that provisions refer specifically to speech rather than "auditory output beyond simple tonal feedback or signaling,". Specifically

• 2.2A - "Products that deliver [speech] output with an audio transducer that is normally held up to the ear …"
• 2.2B - "Products that deliver [speech] output with an audio transducer that is normally held up to the ear.
• 2.2C - "When products that provide speech output or throughput, ….
• 2.2D - "When products that provide speech output,
• 2.2E - OK as is
• 2.2F - OK as is.

2.2-A - Magnetic Coupling

Go to the Oct 26 Draft of this Provision

Discussion of Work in Progress: 
* Need rationale and impact

Comments from ITAA
a. Add “of such hearing technology” after “that allows a user”

b. The provision must clarify if the provision is primarily for transducers that don’t have a jack connection to the product, or if it’s for things that are held up to the ear. Does it apply to a handset that plugs into a jack?

c. Advisory note is misplaced – it refers to levels, not magnetic coupling.

Comment from IBM
Need to settle on how we are going to handle advisory notes. In section 3, they are all grouped at the end of the section.

Comments from CSD/Trace Center

1. Agree with ITAA - add “of such hearing technology” after “that allows a user”
2. Add a note to clarify the issue raised by ITAA.
   • Note: The standard handset on a phone or other device is not an 'accessory' and is not an exception to this provision.
3. Agree with ITAA - delete advisory note – it is duplicated from next provision. (edit-o)

2.2-B - Interference with Hearing Device

Go to the Oct 26 Draft of this Provision

Discussion of Work in Progress: 
* SC is working on the wording of this and will report back
* Need exact title/number of existing standards for reference
* Need rationale and impact

Comments from ITAA
Replace “the "lowest possible level that allows" with "a level low enough to allow". New proposed text would be: Interference to hearing technologies (including hearing aids, cochlear implants, and assistive listening devices) must be reduced to a level low enough to allow a user of hearing technologies to utilize the telecommunications product.

Comments from CSD/Trace Center
Keep current language "lowest possible level that allows"

2.2-C - Audio Connection

Go to the Oct 26 Draft of this Provision

New Version Proposed by Gregg Vanderheiden
When products provide auditory output beyond simple tonal feedback or signaling, one of the following must be true:

(a) Conforming Handset: Auditory output is available via audio transducer that is designed to be held up to the ear that meets 2.2-A (Magnetic Coupling), 2.2-B (Interference with Hearing Device), and 2.2-E (Volume - gain) and product does not require simultaneous use of keyboard; or

(b) Phone Jack: A standard 2.5mm or 3.5mm audio jack for headphones/headsets is provided; or

(c) Any Connection with Adapter available: Product is a not designed to be located in a public location and an adapter from the product's audio output format to a 2.5mm or 3.5mm phone jack is commonly available or available from the manufacturer; or

(d) Public Display only: Product is designed for public audio or audio-video display only and there is a standard audio output on the product-system (which can be but does not need to be accessible to the public).

Note: RJ-9, RCA, USB, and Bluetooth connections all have commonly available adapters. Products (not designed for public locations) with these or other forms of audio connection that have adapters would meet 2.2-C-(c)

Note: Public Display systems need to meet other provisions in the guidelines including the ability to display captions and supplemental audio.

Rationale

• Public phones have amplification and coupling and that meets needs of almost all users so shouldn’t need a jack
• Audio output critical to use of kiosks and other products where user needs to hear information from product in order to use it. (either usual output or speech output
• Users should not be required to carry ‘all’ adapters with them so public systems should not require them to have an adapter to use the product (other than a simple 2.5 to 3.5 or 3.5 to 2.5 adapter)
• The RJ-9/RJ-10/RJ-11/4P4C (or whatever we end up calling it) connector has adapters as does Bluetooth and RCA and USB. Note was added since there was concern that unless in a note, purchasing agents may not recognize it as allowable.
• Addresses the issue of “private listening’ which is provided via the standard handset.
• Kiosks with keyboards usually require blind people to have both hands free.
• Addresses the key need for such a connection on kiosks – and that audio connection be in a standard form that people who are blind will have audio connector for.
• Addresses the need to have an audio connector somewhere on public Audio or Audio-Video systems so that public assistive listening device systems can be connected.

How it would apply

• Public phones would use (a - Conforming Handset)
• Office phones would likely use (c – Any Connection with Adapter Avail) but could use (b – Phone Jack)
• Computers with build in speech conversation could use (b – Phone Jack) which most have already or (c – Any Connection with Adapter Avail) including Bluetooth.
• Kiosks without keyboards could use (a - Conforming Handset) or (b – Phone Jack) or both.
• Kiosks WITH keyboards would have to use (b – Phone Jack) or, of course, both (a - Conforming Handset) and (b – Phone Jack)
• Television sets would use (c – Any Connection with Adapter Avail) or (d - Public Display Only)
• Public address systems and Custom Designed public Video Displays would use (d – Public Display Only) which only requires an audio connection they will already have.
• (etc)

Discussion of Work in Progress: 
* Need to be more specific about "standard signal level"
* Need to check against the definitions for public-shared and 
  personal-private to be sure they work for this provision (or 
  define the distinction here).
* Need impact and rationale

Comments from ITAA
a. This provision needs to clarify if a headphone jack is required for cell (and other) phones.

b. This provision needs to clarify if a headphone jack is required even if no "information" is provided by audio output (muzak).

Comments from CSD/Trace Center

1. Use new version from Gregg V (in UPDATES) with edits to address other's issues.
2. Make revision above to limit to devices that output speech to address "Musak" issue identified by ITAA:
3. RE ITAA question: Cell phones should be required to include headphone jack directly or via adapter but current language (crafted to remove requirement for public pay phones) also removed existing requirement for headphone jack from cell phones. To address this
   • Add the following to the front of the first bullet: "Product is designed for public use and"
4. To address Karen PS concern about need for private listening
   • Add the following to the end of the Second bullet: "that allows for private listening"
   • Add the following to the end of the Second bullet: "and that allows for private listening"

2.2-D - Volume

Go to the Oct 26 Draft of this Provision

Discussion of Work in Progress: 
* Need rationale and impact
* Final level for THD still to be determined. 
* Question about where are volumes set? Is that where you measure from? 

Comment from ITI
This provision contains different volume requirements that are dependent upon where the product is placed. Many E&IT products can either be used by an individual, or shared by a group in a public area. Which volume requirement applies can not be determined by the manufacturer, since the customer chooses the location where it will be placed. This is problematic for product designers. Using “products designed for use in a public space” versus “products located in a public space” would solve this problem.

Comments from ITAA
a. Please number, not bullet, the list

b. If the volume in a public place is controlled to be 50 dBA, how can the provision require something be louder than 50 dBA?

New version proposed by Trace Center:
All products with speech output must meet the following provisions regarding volume:

1. For products use in public places where the background noise level is not controlled to less than 50 dBA SPL RMS, the maximum volume level must be at least 80 dB SPL RMS measured at a typical listening position.
2. For products not for use in public places or where the background noise level of the public place is controlled to less than 50 dBA SPL RMS, the maximum volume of the product must be at least 65 dB SPL RMS.
3. All products must have less than 12 dB symmetrical clipping or a total harmonic distortion (THD) less than xxx% at all volume levels including maximum volume level.
4. Volume on audio jacks must be adjustable.

Note: It is recommended that volume levels be adjustable by users where products are used by single individuals.

Rationale for this version: Products should not be required to have adjustable volume. PA systems for example. Old wording also was ambiguous about dBA referring to background sound. Old language REQUIRED that volume be adjustable - when it would not always make sense. (PA system. Any broadcast information). Volume controls will automatically be included where logical in order to allow volume to be set down from the maximum. Note also that all audio information must be visual due to other provisions.

Comment from Avaya regarding Trace Center proposal:
Audio clipping is not necessarily a bad thing. There are systems that do peak clipping deliberately as a way to improve intelligibility in noisy environments. The basic problem is that the high-amplitude events in human speech (such as voiced vowels) tend to be several dB louder than the soft events (such as unvoiced fricatives). In noisy environments, it's possible for high-amplitude speech events to be audible, while the low-amplitude speech sounds are inaudible due to the background noise. Making all components of the speech signal louder is not always a good solution -- e.g., when the audio amplifier does not have adequate strength. Under these conditions, it can be beneficial to make the