EWG:Draft Oct 26 Updates

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:

Strike “compared to”
Replace "implement" with "provide standards for ascertaining the accessibility of E and IT required by"
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

Accept edits from Karen P-S
Accept 3 edits from ITAA – Except change "Implement" to "provide standards for implementing".
Accept ITAA deletion of "access" in note
Accept ITAA addition of "either" and "by"
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 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.

Accept new a(2) from Version 2.
Keep (b) as it is in current version.
Accept Karen P-S edits to put in 255 language.
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

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 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

Comments from CSD/Trace Center
Version 1 Edit.

1194.3 - NEW - Narrow, Delineated Use

Go to this section in the Oct 26 Draft

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

Accept Karen P-S edit with list of sections that apply only to 508
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)
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.)

(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

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:

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).
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)
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 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 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 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 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 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 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 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 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 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 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

(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 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 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

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.
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.
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 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

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.
The third sentence does not assume any method for passing the real-time text. Just that the text not be lost.
"usable format" should be "accessible format"
There is not a restriction on codes. Just a requirement that access related codes be passed through.
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 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

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.
change "operation and use" to "product operation and use" [addresses ITAA comment]

1.2-G - Visual Information

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

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.
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.
change "operation and use" to "product operation and use" [addresses ITAA comment]

1.2-F and 1.2-G Audio and Video Information

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 text proposal created at the November plenary

No comments were submitted for this provision

1.2-I - Text size

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

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"
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.
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 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

Agree with ITAA (except use IS instead of SHALL)
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 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

ITAA comment #1 should be addressed by current notes.
To address ITAA comment #2 suggest changing "instructions on device" to "instructions printed on device"
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 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 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

Recommend against renaming. "Mechanically Operated Controls" is longer and only adds ambiguity (does mechanical mean how the controls operates or was operated).
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 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 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

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."
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.
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 text proposal created at the November plenary

Discussion of Work in Progress: 
* Need impact

2.2 If the Product has Speech Output or Throughput

(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

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

Agree with ITAA - add “of such hearing technology” after “that allows a user”
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.
Agree with ITAA - delete advisory note – it is duplicated from next provision. (edit-o)

2.2-B - Interference with Hearing Device

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

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

Use new version from Gregg V (in UPDATES) with edits to address other's issues.
Make revision above to limit to devices that output speech to address "Musak" issue identified by ITAA:
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"
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

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:

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.
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.
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.
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 softer speech sounds louder without raising the amplitude of the louder sounds. Requirement #3 could cause this approach to be regarded as non-compliant. I'd like to see the requirement reworded so that modifications of the speech signal that improve intelligibility are permitted.

Comments from CSD/Trace Center

Use new provision posted by Gregg V 11-8-07
Edit described above to limit to products with speech output.
dB-A is not for signal. dB-A is only used to measure ambient background sound level. So you can have things that have 65 dB SPL RMS output in an environment with a limit of 50 dBA ambient background level.

2.2-E - Volume (Gain)

Discussion of Work in Progress:
* Review telecoms/communications to be sure requirement is inclusive
* Need to complete item regarding "All cellular telephones"
* Need impact

2.2-F - Volume Reset

Discussion of Work in Progress:
* Need rationale and impact

3. User Interface and Electronic Content Provisions

Comment from ITI
The provisions of this section are not appropriate for hardware user interfaces. Most were contained in the original Section 508 technical standards under 1194.21 (Software and Operating Systems), 1194.22 (Web-based Intranet and Internet Information and Applications) or in the Web Content Accessibility Guidelines (WCAG) 2.0. These requirements were designed for web and software, not hardware displays. These provisions are especially of concern for handheld E&IT and closed products that by definition are unable to meet the AT compatibility provisions.

3-A - Color

Go to the text proposal created at the November plenary

Discussion of Work in Progress: 
* (Gregg) WCAG is revising their language on this item in response to TEITAC 
  and Public Comments.  We should look at their new language due out soon

Comments from ITAA
Examples: Red for negative numbers – use (###), -

3-B - Contrast

Go to the text proposal created at the November plenary

Discussion of Work in Progress: 
* (Peter K) Needs to be more general
* (Peter K) Since have this should remove 3P User Preferences, and 3E Color Adjustment
* Need to get agreement if the current text is acceptable
* (Allen H) Not clear if this applies to web pages

Comment from ITI
This provision should be more general.

Comments from ITAA
a. Precede with "Except for large-scale text,"

b. The provision must clarify what is meant by "unavailable items?"

Comments from CSD/Trace Center

Disagree that impact is significant. By having specific measurable criteria, it reduces ambiguity and make is faster and easier to evaluate. Cost to print things with high or low contrast is the same. Impact should be negative – cost savings from easier evaluation. No increase in cost for higher contrast.
OK to do ITAA "Except for large-scale text" intro

Proposed text from Sun
Presentation of text (and images of text) must have a default contrast ratio of at least 5:1, except if the text is unavailable items or pure decoration. Large-scale text (or images of large-scale text) can allow a contrast ratio of at least 3:1.

3-C - Size, shape, location

Go to the text proposal created at the November plenary

Discussion of Work in Progress: 
* (Allen H) Shouldn't this include the phrase "as the only means of conveying information"?

Comments from ITAA
a. Precede with "Onscreen".
b. Delete 2nd note
c. Need an example of "orientation of components"
d. Many vendors don't have an appreciation for what this is all about. Provision must make this clear.

Comments from (Japan/Haijime Yamada)
Suggest replacing "Instructions" with "Onscreen information", so the provision would read:

"Onscreen information provided for understanding components and operating user interfaces must not rely on size, shape, visual location, or orientation of components."

Comments from CSD/Trace Center

Agree with ITAA (and Japan) to remove 2nd note and add "on-screen" to provision. BUT "on-screen" should relate to the buttons and controls not the location of the instructions. (Referring to the shape of a physical button works well – no matter where the instructions are – but the shape of the onscreen button is lost on screen reader users). It would then read: "Instructions provided for understanding information and operating on-screen user interfaces must not rely on shape, size, visual location, or orientation of components."
Agree with ITAA that example is needed. Suggest: Example: A user of a screen reader cannot discern which on-screen button he or she needs to trigger if the desired button is only identified by a visual characteristic such as shape, size or location such as "When done press the button on the right" or "round button" or "large button" or "arrow pointing to the right".

3-D - User Preferences

Go to the text proposal created at the November plenary

Discussion of Work in Progress: 
* (Allen H) Suggest add definition for "unavailable items" Unavailable items are 
   interface elements which can not be selected, or interacted with accept as 
   read-only items on screen due to application state or other reasons.

Comments from ITAA
Vendors find this provision is unclear. Is this a requirement on the platform, the application, or the content, or all, or some?

3-E - Color Adjustment

Go to the text proposal created at the November plenary

Discussion of Work in Progress: 
* Need to resolve EWG input

No comments were submitted for this provision.

3-F - Non-text Objects

Go to the text proposal created at the November plenary

Comments from ITAA
a. Introduction has bulleted list of exceptions. Please number the list for reference.

b. The second bullet says there are exceptions to the exception, and it is not clear which of the following bullets these are. The structure should make this clear.

c. Formatting of "test" is wrong.

d. Define CAPTCHA. The specification of the alternatives to the CAPTCHA should be limited to 1 – “an alternative form”

3-G - Human Language

Go to the text proposal created at the November plenary

Comments from Japan/Hajime
Both this provision and 3-H - Language of Parts start with "When presentation of electronic documents supports it." We do not understand what the term "it" means.

Also we want to know "human language" is consistent with WCAG 2.0 definition.

3-H - Language of Parts

Go to the text proposal created at the November plenary

No comments were submitted for this provision

3-I - Pausing

Go to the text proposal created at the November plenary

Comments from ITAA
a. Auto updating is not well understood by lay audience

b. Providing pause is major impact to some web developers. Constituents want to know how acute is the problem? Confusion? Seizures? [This question begs the larger question of which provisions are more important than others – vendors insist on being able to make reasonable tradeoffs between them]

Comments from CSD/Trace Center

Web content can be paused and restarted by 'clicking' on the content – without needing to add any controls.
This provision is for people with attention disorders – and also, in some cases, for those using screen readers or magnifiers that refocus on changing content.

3-J - Flashing

Discussion of Work in Progress: 
* (Peter K) Is subset of 1.2C - Flashing, so this entry should be removed
* Need to get agreement if the current text is acceptable. There is also EWG input.

3-K - Consistent Identification

Comments from ITAA
a. We propose to make this a best-practice, not a provision, as it makes the page more usable, it doesn’t proscribe access.

b. The "must" imperative as opposed to "should" is very difficult to accomplish in a eGovernment or eBusiness portal federation context. What might be consistent within the boundaries of a specific portal providing a specific business capability will/may not be consistent for all companion capabilities that coexist in the environment. What a user sees on a page may come from very diverse vendors, and these may vary from one access to another. Consistency of identification across this domain may well be impossible.

Comments from CSD/Trace Center
What is 'usability problem' for those with higher cognitive abilities may be a barrier to those with cognitive disabilities.

3-L - Audio Turnoff

Additional text proposed by Karen Peltz Strauss for compatibility with 255
Availability of audio cutoff – when a product delivers audio output through an external speaker, provide an industry standard for headphones or personal listening devices (e.g., phone-like handset or earcup which cuts off the speaker(s) when used.

Text from: Telecommunications §1193.43 (g)

Rationale: The section 255 telecommunications guidelines contained the following different section, which does not appear to be covered anywhere in these guidelines

Comment from ITI
This should be an advisory note and not a standard, and should include a clarification of the situation for web pages. There are many ways to enable Audio Turnoff, e.g., at the system level, at the browser, plug-in audio controls, etc. Requiring the content provider to supply this capability seems to be the least effective and efficient.

Comment from Sun
We included our comments in the ITI report for this provision, but feel strongly that this item needs resolution. This should be an advisory note and not a standard. Should clarify the situation for web pages. There are many ways to enable Audio Turnoff (at the system level, at the browser, plug-in audio controls, etc.) and requiring the content provider to supply this capability seems to be the least effective/efficient.

Comments from (Japan/Haijime Yamada)
The description of "three seconds" in 3-L is quotation of WCAG 2.0 (guideline 1.4.2). When the standard of the web content apply to other products such as Closed Product, does not the problems come out?

Other comments

(Jim A) The browser (user agent) can only turn off sound that it knows about, such as the <bgsound> element. If the author uses <embed> or <object> to contain FLASH or media player sounds or some JavaScript to play the sound the hosting user agent has no "knowledge" or control of what occurs in these elements.
(Jared S) This provision should be an advisory note

Comments from CSD/Trace Center

RE ITI and SUN comment about system level turn off. Turning off the sound at the system level turns off the screen reader sound as well. There needs to be a means to turn off the content sound without turning off the screen reader output or the screen reader cannot be used. This should not be advisory as it can preclude use of the screen reader. The word 'mechanism' is used to allow the content to rely on mechanisms in the browser etc if it is a fair assumption that such a mechanism exists. (mostly it does not today – except for an experimental browser from IBM).
RE Japan question: The problem would continue to exist in closed products where the sounds would interfere with built in self voicing.

Proposed text from Sun
When any audio plays on a web site automatically for more than 3 seconds, there must be a mechanism to pause or stop the audio, or a mechanism to control audio volume which can be set independently of the system volume. Use of a web browser with the ability to turn off audio is sufficient to meet this provision.

3-M - Reading Sequence

Discussion of Work in Progress: 
* (Peter K) The phrase "correct reading order" is not clear. In 8.1.C of the Sept 14 draft, the 
            phrase "logical linear" was used which is clearer. Note: this topic is to be discussed 
            at the plenary not the subcommittee level

Current WCAG 2.0 text:

1.3.2 Meaningful Sequence: When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined. (Level A)

How to Meet 1.3.2

Understanding 1.3.2

2.4.3 Focus Order (Relationships): If a Web page can be navigated sequentially, focusable components receive focus in an order that follows information and relationships conveyed through presentation. (Level A)

How to Meet 2.4.3

Understanding 2.4.3

2.4.11 Focus Order (Visual): If a Web page can be navigated sequentially and the focus order affects operability, focusable components receive focus in an order that is consistent with the visual layout order of the web page. (Level AAA)

How to Meet 2.4.11

http://www.w3.org/WAI/GL/WCAG20/WD-UNDERSTANDING-WCAG20-20071102/navigation-mechanisms-focus-order-visual.html Understanding 2.4.11]

3-N - Link Purpose

Comments from ITAA
Define “Purpose.” There may be a different purpose for different users – how do we change the name to reflect the purpose.

Current WCAG 2.0 text:
2.4.4 Link Purpose (In Context): The purpose of each link can be determined from the [link text] alone, or from the link text together with its programmatically determined link context, except where the purpose of the link would be ambiguous to users in general. (Level A)

How to Meet 2.4.4

Understanding 2.4.4

2.4.9 Link Purpose (Link Only): A mechanism is available to allow the purpose of each link to be identified from link text alone. (Level AAA)

How to Meet 2.4.9

Understanding 2.4.9

3-O - Information and Relationships

Discussion of Work in Progress
* (Peter K) This provision pretty clearly assumes it is 
            talking about a document, but it doesn't mention it explicitly 
            (and there, an XML/HTML document). In (2), (3), and (4) it directs 
            the explicit use of “markup” to do things (all of which are covered in 3-V). 
            This provision should either be removed as redundant, or scoped to 
            explicitly apply to (web) documents.
* (Jared S) Should remove "markup"
* (Jared S) Disagrees with removing this provision
* Need to get agreement if the current text is acceptable, There is also EWG input.
* This topic was discussed at the General Subcommittee meeting on Oct 15. 
  Please see  the meeting notes for more information.

Comment from ITI
This provision pretty clearly assumes it is talking about a document, but it doesn't mention it explicitly (and there, an XML/HTML document). In (2), (3), and (4) it directs the explicit use of “markup” to do things (all of which are covered in 3-V). This provision should either be removed as redundant, or scoped to explicitly apply to (web) documents.

Comments from ITAA
Propose rewording for clarity: Information and relationships that are conveyed through presentation, or that can be programatically determined, or that are available in text, and notification of changes to this information and these relationships shall be available to user agents, including assistive technologies. For example:

row and column headers that are identified for data tables
markup that is used to associate data cells and header cells for data tables that have two or more logical levels of row or column headers.
markup that is used to identify section headings
markup that is used to identify form element labels

WCAG 2.0 Text
1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. (Level A)

How to Meet 1.3.1

Understanding 1.3.1

3-P - User Interface Components

Discussion of Work in Progress: 
* (Peter K) Same comments as 3O - Information and Relationship. Recommend remove this provision.
* (Jared S) Disagree with removing
* This topic was discussed at the General Subcommittee meeting on Oct 15. 
  Please see  the meeting notes for more information.

Comment from ITI
This is really about (web) documents; everything in it is covered by 3-U. We should either remove it as redundant, or scope to it web documents. Please specifically note the final text of 3-U: "Note: This provision applies to forms in the software."

Comments from ITAA
a. Change all “programmatically determined” to “programmatic determinable” per the definitions in Subpart A

b. Number, not bullet, the list

c. At the end of the first item in the list, add “, and”

d. At the beginning of the 3rd item, precede with “any” and replace “is” with “must be”

3-Q - Disruption of Access Features

Discussion of Work in Progress: 
* (Allen H) This doesn't read to me like "applications shall not disrupt assistive
  technology". Is there a way to get that concept back in even if through additional
  notes?

Comments from ITAA
a. I'm pretty sure that developers will not "define an accessibility usage" if it means they can get around this provision.

b. The provision needs to clarify the meaning of "platform developer documentation?" Manuals for application developers, manuals for platform developers, or written by the platform vendor organization?

3-R - Timing

Discussion of Work in Progress
* (Peter K) An additional bullet should be added stating that time limits that minimally 
  impact the user's experience, information, or session state are allowable.  This will 
  cover time out features like screen locks, web session locks were a user may return 
  to the session state after logging in again, etc.
* (Gregg V/WQ)"is true" should be "must be" (harmonize style)

Comment from ITI
An additional bullet should be added stating that time limits that minimally impact the user's experience, information, or session state are allowable. This will cover time out features like screen locks, web session locks were a user may return to the session state after logging in again, etc.

Comments from ITAA
a. Replace “is true” with “must be true”

b. Number, don’t bullet, list

c. As with the biometric discussion, this item is a prime example of frequent requirement conflicts. The security imperatives (Federal Information Security Management Act (FISMA) imparted in NIST Special Publication 800-53A Guide for Assessing the Security Controls in Federal Information Systems as well as DoD and other Federal Agency implementations require sessions to be killed after x-minutes of inactivity. The security imperative is a far better example of an "essential" timing requirement than those presently identified.

d. Delete 4th item – a real-time exception is just a special case of an essential exception and doesn’t need a special category.

Comments from CSD/Trace Center
Should not add new bullet (re ITI). Current language covers that to the extent it should be covered. New bullet language opens up a major loophole and breaks harmonization with WCAG.

Proposed text from Sun
Proposed text for new bullet: Inconsequential Impact Exception: the impact of the user failing to react within the time limit is inconsequential – no data, state, or opportunity is lost

3-S - Keyboard Operation

Comment from Closed Subcommittee
NEEDS TO HAVE PHRASE ADDED TO FRONT: For products that have a keyboard or keyboard interface, or content that can be viewed on devices that have a keyboard,...

Comment from ITI
Object to this draft; there are several alternative drafts (at http:// teitac.org/wiki/Web_and_Software:_September_12#Keyboard_Operation ), some of which would be fine. Number 4 is best.

Comments from ITAA
Regarding version 1:

a. Precede with "for products that interface with a keyboard," otherwise, ALL products will have to have a keyboard interface.

b. Define Keyboard: Does a remote control qualify? A cell-phone keypad? Are there any restrictions on keyboard? Must it have mechanical keys?

Comments from CSD/Trace Center
Agree with Closed product group addition

3-T - Focus Indicator

Discussion of Work in Progress 
* (Allen H) Either add one more note to version 1 stating: "This 
   provision is restricted to the visibility of the focus. Focus must 
   also be programmatically exposed for assistive technology 
   usage--see 3-U."  OR use version 2.

Comment from ITI
This provision would be very difficult to test and therefore should be dropped.

Comments from CSD/Trace Center
High visibility of focus indicator is a very important provision – and invisible or barely visible indicators are a major barrier to low vision, and physical disabilities. (Also cognitive).

3-U - AT Interoperability

Discussion of Work in Progress
* (from Sept plenary) question raised if this should also list other 
   accessibility issues such as sound.
* Note that there is an outstanding issue as to whether or not this provision 
  is met by software that uses an accessibility API but does not actually work 
  with AT. This issue is related to the issues around the functional 
  performance criteria.
* This topic was discussed at the General Subcommittee meeting on Oct 15. 
  Please see  the meeting notes for more information.

Comment from TIA
The provisions of these sections have not been adequately vetted for Telecommunications hardware user interfaces and application. These requirements were designed for web and software in an IT computing environment, not telecommunications hardware displays, and are platform specific. These provisions are of special concern for handheld Telecom devices many of which are unable to meet the AT interoperability provisions and have a different perspective for platform and application interaction.

NOTE: The TIA comment also applied to provision 3.V "Both platform and application" in the Sept 14 draft.

Comments from ITAA
a. Numbers instead of bullets, please

b. There is no definition of “user interface objects”.

c. This wording would require that any product that can meet the provisions for accessibility without AT must STILL use the services on the platform. What we think was meant was if you use AT to meet specific provisions, you must interface to the AT thought the specified services. Also there is confusion as to whether "such services" means both platform services and/or "other" services.

d. 5th bullet – The provision should clarify if the names of elements and objects are wanted? Are elements objects?

e. Precede text of 5th sub-bullet of 1st bullet with “name of”

f. This requirement imposes no constraint on currency for the AT tool itself. Should an application have to demonstrate interoperability with pre-Microsoft Active Accessibility (MSAA) or Java Foundation Classes (JFC or Swing) implemented the Java Accessibility API as represented in an earlier Java Runtime Environment (JRE) that are now obsolete or deprecated. The MSAA and Java APIs respectively are examples of "platform software" in this instance, but MSAA on Windows 95 is not the same as MSAA on Vista Ultimate. The JAVA Accessibility API is not the same on JRE 1.3 and 1.5.

This can of worms sometimes leads to an interpretation that support is required for very early versions of emacsspeak with a Lynx browser, or no longer supported tools like IBM's Home Page Reader, Vocal Point's VoiceBrowser, and others.

There needs to be some constraining text that addresses obsolescence for practicality sake. Should the next iteration of Section 508 lay unaltered for a period equivalent to the present circumstance (nearly 10 years - multiple web generations), the same issues will be manifested where the best practice or best approach is compromised by the constraining text of the standard. Even in the browser, the accessibility features available in HTML 3.2 when Section 508 was introduced are greatly expanded in current markup language releases

Comments from CSD/Trace Center

Very important provision
Products that have built in access can be closed and skip this.
Phones are increasingly including operating systems and can thus support this instead of operating as closed products.
This provision does not specify an API that can be built to. It only provides requirements for an API.
This provision needs to clearly state that "AT interoperability" means that products that pass this provision will really interoperate with AT. (also applies to 3-V by inheritance).

3-V - Accessibility Services

Comments from ITAA
a. Change "sufficient" to "sufficiently"

b. There is no discussion of translation of the plausible future state of mediation services to achieve accessibility. First generation examples include Adobe PDF Conversion by Email Attachment and Adobe PDF Conversion by Simple Form. Emerging examples include Service Oriented Architecture (SOA) mediation and metadata discovery services that would provide alternative rendering of XML content based on the user (or their user agent needs). These types of services are already performed routinely in situations where a PDA (as identified by the agent string) is delivered information in a 9 line display while a full size browser receives the whole page. XML is the same, XSL handles the transform.

Comments from ITAA regarding provision 3-V "Both Platform and Application (included here since 3-V "Accessibility Services" has replaced the prior provision

Clarify ambiguity of “running within its platform”, perhaps replace with “using this software as a platform”

3-W - Multiple Ways (New provision)

Discussion of Work in Progress: 
* Need impact
* EWG comment: this does not follow the format of telling what must be done. Need to 
   clarify the goal of this provision.

3-X - Labels or Instructions (New provision)

Discussion of Work in Progress: 
* Need impact

3-Y - On Focus (New provision)

Discussion of Work in Progress: 
* Need impact and rationale

3-Z - On Input (New provision)

Discussion of Work in Progress: 
* Need impact

3-AA - Error Identification (New provision)

Discussion of Work in Progress: 
* Need impact and rationale
* Need to resolve EWG input

3-BB - Labels Descriptive (New provision)

Discussion of Work in Progress: 
* Need impact and rationale
* Need to resolve EWG input

3-CC - Advisory Notes

Discussion of Work in Progress: 
* (Jared S) Recommend that we add additional advisory notes to 3-X, where
            appropriate, to further address some of the WCAG 2.0 provisions that
            have been excluded. Primarily:
            - Descriptive Page Titles (Level A)
            - Focus Order (Level A)
            - Error suggestion (Level AA)
            These are the Level AA or below items not currently in the draft that
            should at least receive honorable mention in advisory notes. If this
            is agreeable, I can work on pulling out the relevant text and
            structuring it - we'll probably need a "Web only" section in 3-X.
* Need rationale and impact

Comment from ITI
Advisory notes should not be included within the standard, but rather, posted on the Access Board web site either in the FAQ page or perhaps a section that provides additional guidance to federal agencies.

4. Additional Provisions for Audio-Visual Players or Displays

4-A - Caption Playback

Go to the text proposal created at the November plenary

Version 2, proposed by subcommittee on November 7, 2007:

Analog television, digital television and tuners, computer equipment, and other products must provide support for closed and open captions:

1. Products that are governed by U.S. Federal Communications Commission (FCC) regulations 47 CFR 15.119 (Closed caption decoder requirements for analog television receivers) and 47 CFR 15.122 (Closed caption decoder requirements for digital television receivers and converter boxes) must provide support for TV closed captions and open captions.

Such equipment must either pass TV caption data to the caption decoding circuitry of analog and DTV displays for decoding as displayed text, or decode TV caption data and pass on a decoded ("open-captioned") video signal to the display.

2. Products that do not fall under the regulation of the U.S. Federal Communications Commission (FCC), including personal video display devices and software players, must provide support for a functional equivalent to TV closed captions.

Such products must either pass TV caption data to the caption decoding circuitry of DTV displays for decoding as displayed text or decode a functional equivalent to TV closed captions and pass on a decoded ("open-captioned") video signal to the display.

Rationale for version 2: An attempt to align the 4-A - Caption Playback provisions with the 4-B - Supplemental Audio Playback provisions.

Comments from ITAA (based on Sept 17 draft)
The set of “products of type ___ use CEA x08…” format. Provision should clarify, does this mean they MUST?

Comments from Japan/Haijime
In both 4-A and 4-B, does the term “playback” mean “repeat audio and caption”? If not, delete the term.

4-B - Supplemental Audio Playback

Go to the text proposal created at the November plenary

Version 2, proposed by subcommittee on November 7, 2007:

Television tuners, including tuner cards for use in computers, must support video description playback:

Analog-signal tuners must be equipped with Secondary Audio Program (SAP) playback circuitry as defined by the Multichannel Television Sound standard developed by the Broadcast Television Systems Committee (BTSC) in 1984.
Digital-signal tuners must be equipped with ancillary audio program playback circuitry according to the A/53 standard developed by the Advanced Television Systems Committee (ATSC), major elements of which were adopted by the FCC in December of 1996.

Rationale for version 2: An attempt to align the 4-A - Caption Playback provisions with the 4-B - Supplemental Audio Playback provisions.

4-C - Access to Caption Controls

Go to the text proposal created at the November plenary

Title will be changed to "Access to Caption and Video Controls"

Version 3 from the subcommittee on November 7, 2007:

For products that are covered under 4-A.1, the user controls needed to access closed captioning and video description must be in at least one location that is comparable in prominence to the controls needed to control volume or program selection. At a minimum, this requires placement of such controls on either the product's physical apparatus or its remote control, where the ability to control volume or program selection is otherwise provided on that apparatus or remote control.

For example:

For captioning:

A caption on/off button on a TV remote comparable in prominence to the volume control on that remote;
Caption controls on the first menu that appear when on-screen menus are displayed

For video description: A tactile button to turn on video description.

Note: Comparable in prominence does not require exact equivalence in size, location, or shape.

Rationale: Manufacturers are encouraged to use buttons with unique shapes to enable persons with low vision to make a tactile distinction among them.

For products that are covered under 4-A.2, the user controls needed to access closed captioning and video description must be comparable in prominence to the play controls or channel selector.

Input from EWG:
The rationale listed is not really rationale. It is a recommendation. Need to have rationale explain why this provisions is needed.

5. Additional Provisions for Real-time Voice Conversation Functionality

Comment from IBM
Seems odd that this section is between the requirements for A/V players and A/V content.

5-A - Relay Services Accessibility

Go to the text proposal created at the November plenary

Discussion of Work in Progress: 
* Need rationale, impact, and metadata

Comment from IBM
Agency requirements should be separated from the Technical Provisions.

5-B - Real-Time Text Reliability and Interoperability

Go to the text proposal created at the November plenary

New Version Proposed by TIA
If hardware or software provides real-time voice conversation functionality it must support at least one means of real-time text communication where the following reliability requirements are met:

Products must use a real-time text (RTT) format that meets the following requirements:
- RTT format must be the standard real-time text format for the voice platform (one that is supported by all terminal, router, gateway and other products on that platform);
- RTT format must transmit characters with less than 1 second delay from entry;
- RTT format must transmit text with less than 1% Total Character Error Rate at the peak network traffic specified for intelligible speech transmission (text must work on the network as long as speech does);
Products and self-contained systems of all types may use any real-time text format internally that meets reliability provision above as long as it support the following interoperability provisions where it connects to other systems and products:
- If product interfaces with PSTN, it must use TIA 825A Baudot where it interfaces to the PSTN.
- If product interfaces with other VoIP products or systems (outside of a self-contained product-system) it must support transmission of text as per RFC-4103, TIA 1001, or TIA 825A where it interfaces with other VoIP products or systems.

NOTE: All products may support and use other protocols in addition to these as long as the meet the 5 requirements of 5-B(1) above.

NOTE: A self-contained SIP system that all uses the same real-time text protocol can be treated as a single product and can use any protocol internally as long as it supports RFC-4103 where the system-product connects to other systems or products.

TIA Comments on this Proposal:
Version 1 Real Time Text Reliability and Interoperability prematurely selects a specific standard, RFC4103, to achieve Section 508 compliance for real time text. It is the view of TIA that selection of any specific standard at this time is premature and will not promote long term optimal user experiences for deaf and hard of hearing users. Several standards and technologies are in early-stage development and there is much to be learned from and about these new standards and technologies before casting in stone a standard for all U.S. government procurement. The risk is high that development of new or enhanced standards and technologies that could greatly improve the user experience will be thwarted or derailed if RFC4103 is locked in as the requirement to achieve Section 508 compliance at this early stage.

TIA views the following as the long term objective here: achieving a telecommunications service that enables effective communications by users who are deaf or hard of hearing in real time. This might entail character-at-a-time or en-bloc text transmission, various forms of messaging, or various forms of video communication, or more than one at the same time. It may be that some users want to sign with video communication; others want to converse with messaging systems and others want legacy TTY character by character interface.

Any service will necessarily be based on IP and might use IP Multimedia Subsystem (IMS) or other new technologies. H.323 still dominates the long distance VoIP market, commanding a 15.8% of the total voice minutes, while SIP and IMS are less than 4%. Skype technology already has 4.4% of users, and newer IP-based systems and technologies are being studied. While it is recognized that IMS does incorporate support for RFC-4103, to what extent and how quickly IMS will gain traction in commercial implementations within the US is unclear. Carriers are now working on SIP-based network deployment and both enterprises and service providers are working to make necessary terminal equipment upgrades but such work will take 10 or more years to complete in the mobile environment and probably as long in the fixed broadband environment. Implementation timetables will vary by carrier, network technology and service area. All the while, through the migration, telecommunications service providers and equipment vendors will have to provide legacy TTY support to ensure access to existing services by the current users.

RFC4103 is the first real-time text standard created for use with both H.323 and SIP systems. It provides character by character real time text, but only when communicating with other devices which have RFC4103. There is no certainty at all that it will rapidly or widely be deployed, in part because users are experimenting with a number of technologies, not just RFC4103. Many users are now heavily using en-bloc style instant messaging technologies. Newer technologies, such as Message Session Relay Protocol (“MSRP”) defined in RFC4975, have the potential to offer both real-time text functionality and instant messaging functionality through a single protocol. Businesses and government have the ability to offer any form of text communication through a web browser interface, and many businesses are already doing that to provide technical support services to customers who are both hearing and deaf. Users have not made a clear selection, nor does TIA believe users yet know the choices and options they will have. Until users have seen the options and have voiced their preferences and, until a clear roadmap is in place to interoperate with legacy equipment that must still work with 911 and relay services, TIA does not believe the Access Board and other bodies of the US Government should make a technology choice that might actually introduce interoperability problems or prove to be contrary to what users actually want.

Other promising standards are in development. It is important to understand these efforts in this early stage to assess whether what emerges meets the needs of users who are deaf and hard of hearing. Shifts in technology, user behavior, and user preferences need to be carefully studied, as the right solution for the deaf and hard of hearing might lie in these, or multiples of these technologies, and to our knowledge, not all options have been fully explored.. Other standards that should be considered include TIA 1001 and ITU-T V.151, as well as RFC4975 and alternative web-enabled text transmission technologies.. While these are not parallel in their capabilities to RFC4103, they need to be considered as potential solutions for some users.

There are also other technologies and/or service providers worldwide that are actively promoting IP-based real-time text solutions for mobile devices These include AnnieS, a Java client operating on certain BlackBerry terminals that provides connectivity between terminals and gateways to legacy text phones and to the Omnitor server. Netwise has developed a product called Flexitext operating both PC and mobile phone environment (Java client) through a service that provides connectivity between terminals and to legacy terminals and relay services. RNID has also developed Java clients that operate on certain mobile phones. TIA does not suggest that these clients currently provide the full range of capabilities needed by all users who are deaf or hard of hearing to achieve full communications in real-time . However, there is much to be learned from users in these various trials that could inform and improve what is offered so that it could be more widely used and adopted. Other technologies also exist, such as potential web-based technologies like http://www.ip-relay.com/, https://www.sprintip.com, http://www.siprelay.com/, http://www.ip-vrs.com/, http://www.relaycall.com. All of these are IP-based relay services, but could be extended to provide text, voice, video.

Interoperability is an issue that must be addressed in any implementation strategy to IP communication architectures. In the short term the use of gateways will be necessary, but flexibility and planning ultimately will be needed to move users from where they are today to the technology of tomorrow; while maintaining backward compatibility with legacy devices, including TTY calls to 911.

Besides the mobile device context, 5B and 5C place requirements on the desktop computing environment. In this environment – with a large number of existing open and proprietary audio and video communications applications and protocols – retrofitting a real-time-text communications mechanisms into those multiple existing communications protocols would be expensive and time consuming. There is an alternate approach – one that places real-time-text communication on its own IP-based protocol which would operate in parallel to the multiple, existing audio and video communications protocols – which should be permitted under any guidelines adopted Such an approach has the advantage of being easier to implement (and so faster to market), without any difference in the end user experience. Another advantage is that this approach makes RTT interoperability easier to achieve, as instead of multiple, non-interoperating communications protocols separately implementing RTT support, a single standard RTT protocol can be used across all audio and video communications applications alongside their existing protocols.

With respect to handsets, as written, the proposed standard could theoretically require every handset supporting VoIP to include RFC4103, independent of any consideration of whether or not the networks will support it, and also independent of whether or not the handset design even includes a keyboard or acceptable display, and independent of what the users want or need.. For voice-centric devices without a keyboard and with a small display, this solution will not provide an effective and usable text experience since these devices were not designed for that purpose. Moreover, even where the device has the physical characteristics needed, development of new client software application programs on each handset that support, for example, the "simultaneous use" of voice and text faces numerous complexities and constraints. Screen size, font size, multiple applications running concurrently, etc. all come into play, such that the software development challenges for the application are significant. Industry has taken years to optimize the user experience for voice applications and messaging applications independently on our respective platforms, and the effort required to combine the two aspects into something useful should not be underestimated.

It cannot be stressed enough that input from the user community is vital. Some have brought into question whether the legacy mode character-at-a-time text transmission like TTY, which was utilized in the PSTN solely because it was the only understood means of transmitting text at the time it was created, is or will be important to younger generations, given the pervasive use of instant messaging systems. It is important to observe that instant messaging technology has profoundly changed the way in which deaf and hard of hearing users communicate by closing the communication gap between those individuals and the hearing community – something that the TTY has never been able to accomplish. Industry wants to deliver text communication solutions to users, but it is important to deliver solutions that people really want and that are significant improvements over legacy technology.

Therefore, before leaping to impose one particular solution as a Section 508 procurement standard, TIA recommends that there be research into what deaf and hard of hearing users really want. Does the user want character by character or en-bloc messaging? Does the user want access to both? Do they want video for signing? . While some may prefer real-time text, many may not. Further, there may be clearly observable trends in user preference for the mode or style of text communication. Until now, most users who are deaf have not been given a choice; the advent of new technologies - - video, messaging, broadband speech-to-text engines - - can change that. Do they prefer texting from a 10-key keypad, or would they prefer a text-device accessory? Are there combinations of such features that make sense for most users? Are there new technologies, operating platforms or programs that can provide a fuller range of functionality for such users? In summation, before mandating standards that impact terminal devices and networks, it is important to have good data on user requirements, desires and preferences. Because of all the possibilities for addressing these needs, TIA asserts that it is premature at this time to lock down on a particular standard as the required solution.

Discussion of Work in Progress: 
* (Peter K) First sentence of current draft is a duplicate of 5C 
  that says you must have/support RTT. Recommend removing from 
  this provision
* Need rationale, impact, and metadata

Comment from ITI
Discussion of this provision was never completed at the subcommittee level. Additional versions are going to be submitted and need to be reviewed. There is also the issue of citing specific technologies, which can limit innovation.

Comments from CSD/Trace Center

TIA revision has the following issues
1. it removes the 4th bullet which requires intermixing of speech and text. This is essential for voice carry over and it required by current standard
2. for IP , removal of 4th bullet also removes simultaneous speech and text in same direction. This is required for support of captioned telephony – a new relay form – on VoIP (e.g. SIP).
3. Removal of 5th bullet allows text data to be send as tones on IP thus blocking captioned telephony and perpetuating TTY on IP which creates interoperability problems – and large burdens on IP telephony to support natively.
4. Changing the requirement for all VoIP to support one format – prevents users who use text from being able to call each other. Each user could have one of three formats and would only be able to talk to those who have equipment that supports the format theirs does. And even then it may not work if intervening hardware doesn’t also support their format. This is not acceptable. Either all products need to support one format – or all products need to support all three formats.
5. The provision that allowed companies to use whatever format they wanted to as long as they used some consistent format for the transmission protocol.
6. The comment that TIA hasn’t reviewed this language is inappropriate. The mission was to develop guidelines that would apply to 508 and 255 from the start. Committee participants were supposed to be following the work on the various groups.
RE comments
1. The only way to have interoperability is to have a common fall back provision. Selecting one today does not in any way prevent innovation (G711 is supported by all SIP platforms and did not stop the development and use of numerous other codecs.) The required format can always be relied upon however when products don't support other formats in common. ALSO the existence of a common format allows innovation in the future while still allowing future products to communicate with products made before the new formats were introduced. When communicating between new products, the new format can be used. When communicating between an old and new, the fall back format can be used.
2. RFC- 4103 was originally developed for Ericsson under their sponsorship. It has been adopted by 3GPP and is also the method specified for real-time text by the 9-1-1 group for IP 9-1-1.
3. RFC-4103 can support both one character at a time and block transmission (e.g. transmit on carriage return).
4. RFC-4103 is only required for SIP – so H.323 dominance of long distance trunks is not a problem. RFC-4103 is not required for H.323.
5. MSRP is very inefficient for character by character transmission. And if used for captioned telephony it is extremely inefficient and sends all of its communication data on the control channel rather than a communication channel where it should be. (which is one of the reasons why 4103 was developed in the first place. )
6. The user community has provided input to the proposed approach on an international level. And representatives came to the TEITAC meeting and spoke directly as well as to the importance of making RTT a reality in IP.
7. The TIA comments talk about "leaping" to impose a particular solution. The proposed solution is the result of almost a decade of work with consumers and industry to explore approaches and develop industry standards that make up RFC-4103 including the ITU and IETF. It has been endorsed by major industry study groups working on both the next generation infrastructure and the next generation emergency services infrastructure. It would take a decade to develop something else with the same functionality, thought and support. By then, the VoIP infrastructure will have been built out and there would have to be retrofits (and consumers would have no interoperable real-time text for the decade).
8. The TIA discussion provides no alternative that would provide interoperability. It is an argument for doing nothing. And the arguments for not doing anything now would apply at any point in the future as well.
9. There is no reason not do adopt RFC-4103 as the standard format for SIP telephony. It works wherever it is supported. It has support. It is what all the infrastructures that are planning for real-time text have selected. And if another format is developed in 5 years – it can be deployed and used as soon as it comes out. RFC-4103 would still provide the mechanism to communicate with the installed base.

5-C - Voice Terminal Hardware and Software

Go to the text proposal created at the November plenary

Discussion of Work in Progress: 
* (Peter K) Needs to be reworded. Says do A. If don't have A, then do B. Should change 
   to You must do either A or B or both.
* Need rationale, impact, and metadata

Comment from TIA
TIA has feedback on this provision. Please see the comments listed in 5.B Real-Time Text Reliability and Interoperability

New version proposed for this provision:
Terminal hardware or software that is capable of providing voice communications in real-time must comply with the following:

If hardware or software provides voice conversation over IP in any form, and has a user interface with a multi-line display or runs on devices that have a multi-line display, then terminal must either display any real-time text that is received if it is received in the standard real-time text format for that voice transmission format or platform; or it must support the addition of a terminal and terminal peripheral equipment that do support real-time text functionality in conjunction with the voice call functionality, in the same location and with the same permissions for use as their voice terminal. In the case of such an addition, if the terminal is in a pubic or shared area and not in an individual's private work area then the connection must be possible without requiring system-administrator intervention.
If terminal hardware or software provides voice conversation over IP in any form, and has text generation capability, then the terminal must allow user to send real-time text in the standard format for that voice transmission format in parallel with the voice; or it must support the addition of a terminal and terminal peripheral equipment that do support real-time text functionality in conjunction with the voice call functionality, in the same location and with the same permissions for use as their voice terminal. In the case of such an addition, if the terminal is in a pubic or shared area and not in an individual's private work area then the connection must be possible without requiring system-administrator intervention.
(was number 4, old number 3 removed) If terminal is analog or TDM-digital wired terminal then it must support the connection of a TTY via an RJ-11 jack in the same location and with the same permissions for use as the telephone and it must be capable of allowing simultaneous speech and text conversation without interference or its microphone shall be capable of being turned on and off to allow the user to intermix speech with text use.

Note: Provision of the RJ-11 jack may be accomplished by through one of the following techniques:

Provision of the RJ-11 jack on the telephone,
The use of a Y-adapter that allows both the analog telephone and the TTY to be plugged into the same line outlet,
having built in capability to support an RJ11 module that can provide a connection point for TTYs

Comments from ITAA
Provision should make clear the subject for the clause "…runs on devices…"?

Comments from CSD/Trace Center
Although TIA did not provide any language related to this provision, they did provide comments. Mostly it asks questions which this will attempt to address

The provision requires all VoIP phones / terminals to support real-time text. It does not require them to support RFC-4103 unless that is the form of real-time text that is used with that terminal. This is the equivalent of the current provision that requires all phones to support non-acoustic connection of TTYs.
The provision does not require support of RFC-4103 for phones/terminals that are on networks that have a different standard for real-time text that they support.
The provision requires display of incoming text on phones/terminal that have multiline displays. The overwhelming majority of late deafened adults speak just fine and have no need of a keyboard to speak with most of the people they communicate with. They speak and the others (or the relay service) types back to them.
There is discussion about 'user experience' and how display of text may disrupt it. For those using speech – it would not disrupt the screen at all. For those who are deaf – there is no user experience at all to disrupt if there is no text.
It was mentioned that IM has profoundly changed the way deaf people communicate. It has profoundly changed the way many people communicate. It has not eliminated the need for real time telephony however. And the fact that people who are deaf are all using only IM is a function of the fact that they have no other choices on their standard phones. If real-time text were available IM would continue to be used by some all the time and others some of the time – just as IM is used almost exclusively by some who speak but others use IM sometimes and real time conversation others. The informal studies done so far have shown that when given the choice, both modes are used and desired for different applications. Just as people use both the SMS and phone functions of the cell phones – and wouldn’t want to give up either one.
TIA states: While some may prefer real-time text, others may not. This is true as is the reverse. Mostly people will want both. And real-time text is essential for some types of communication like captioned telephony and it is highly desirable in emergency communications.
TIA comments end with saying that it is not known which of many options people who are deaf will want. The answer is that they will want the same spectrum of things that everyone else does. And there is no reason to deny them something they really need because it is not clear exactly how many will use which modes how much.
Real-time text is needed as discussed and as made clear by the consumer representatives. I couldn’t have made any of these points any better – you have captured the heart and soul of this issue in the above points.

ITI states that other versions are going to be submitted?

5-D - IVR, Auto-Attendant and Messaging

Go to the text proposal created at the November plenary

Discussion of Work in Progress: 
* Telecommunications will provide an advisory note about Baudot and TTY.
* (Peter K) Not clear on the statement "All functions that are accessible to voice users 
            must also be directly accessible to users of real-time text." How to do on a 
            voice prompt menu.
* Need rationale, impact, and metadata

Comment from ITI
The text of item 1 says: “All functions that are accessible to voice users must also be directly accessible to users of real-time text.” We are not aware of this ever being accomplished for a voice-prompted menu. The committee should not put anything into a testable provision that has yet to be demonstrated in real-world applications via a working example.

5-E - Caller and Status Information

Go to the text proposal created at the November plenary

Discussion of Work in Progress: 
* (Peter K) This says that products with visual interfaces that display status 
          info must make the info available for TTYs among others. How do I make 
          Skype's connection information available to a TTY? This provision is 
          making assumptions about the device that don't match the text of the 
          provision.
* Need rationale, impact, and metadata

Comment from ITI
This says that products with visual interfaces that display status info must make the info available for TTYs among others. We don't know how to do this for many classes of products (e.g. making Skype's connection information available to a TTY). This provision is making assumptions about the device that don't match the text of the provision.

Comments from IBM

Agree with Peter K's comment about TTYs.
Bullet 3 of this requirement is covered by 1.2-G Visual information for closed products and by 3-U AT interoperability for products that are compatible with AT.
The last sentence actually refers to the "software and content" provisions.
The second bullet raises testability concerns.
In summary, bullet 3 is covered by other provisions and should be removed. Bullet 2 is untestable and should be removed. And the requirement for providing information to TTY users should be clarified.

5-F - Video Support

Go to the text proposal created at the November plenary

Discussion of Work in Progress: 
* Need rationale, impact, and metadata

6. Audio and/or Video Content

6-A - Captions and Transcripts

Go to the text proposal created at the November plenary

Comment from ITI
Real time audio/video requirements must come with exceptions vital for agencies attending to their business needs. For instance, under this provision real-time and recorded security camera feeds would have to have synchronized captioning. Applying this to ALL audio and video content is unreasonable in cases where the content would have no benefit to blind, low vision, or deaf users (i.e. video/audio training materials for TSA screening agents, audio for a larger server HW servicing video, etc.). Exceptions are needed to narrow this requirement.

Comments from ITAA
Change item 2 to: 2. Materials containing prerecorded video with concurrent audio must provide synchronized captions.

Other Notes

(Peter K) Note 2 and 3 use the term "concurrent audio" should that be 'concurrent spoken audio"
(Whitney Q) or "concurrent audio information" - the broader term.

Proposed text from Sun
Proposed text for a new item number 4: This provision does not apply to live or recorded video where visual analysis, monitoring, or review are an assumed or required faculty of the end user (i.e. security feed being viewed by a security guard, scanning of shipping containers by Customs Officers, x-Ray machine training video for TSA agents, etc.)

Comment from IBM

Bullet 1 and 6-B bullet 1 seem to be identical. Isn't 6-A bullet 1 meant to address audio only? Suggested re-wording: "Materials containing prerecorded audio information, and no original video or other additional time-based content must provide a separate transcript of the audio information."
Wording "Materials containing real-time audio" is awkward. Suggest removing "Materials containing".

6-B - Video Description

Go to the text proposal created at the November plenary

Comment from Sun
Sun feels it's critical we go with version #2 of the draft.

Comments from ITAA
Our constituents prefer version 2

Comment from IBM
Bullet 3 is really not possible for most types of live video content unless it is a television broadcast where the video descriptions can be provided on a separate audio channel. The pauses where video descriptions are normally inserted in prerecorded content are of unknown duration in live video content.

6-C - Open or Closed Captions/Descriptions

Go to the text proposal created at the November plenary

Comments from ITAA
What other options are there? Is this just saying that closed is OK? Unless this is saying that captions are required, it appears to be superfluous. Recommend deleting provision.

6-D - Interactive Elements

Go to the text proposal created at the November plenary

7. Information, Documentation and Support

7.1 Product Documentation and Help

Comment from ITI
There is a proposal to merge 7.1 and 7.2 since frequent current use of blended documentation and support styles, such as the self-service support on the web (look at our docs/Q&A database first, then ask a question through a form, email, call-back or live chat), are effectively blending the two. This was not resolved due to not having clear text for the provisions. This will be addressed again once the provision text is complete.

Comments from ITAA
a. Insert “documentation” between “This” and “includes” in the second sentence.

b. ITAA supports the inclusion of an additional category of documentation requirements under Standards 1194.41 that clarifies accessibility requirements for all documentation other than user documentation, and defines the accessibility requirement for such EIT deliverables. These documentation products include: program progress reports, qa/qc plans, program management plans, white papers, analyses, etc. Various agencies such as the VA, EPA, have stated that all documentation submitted under their funding will be accessible - is this the operative statutory requirement?

7.1-A - Accessible Documentation and Features

Changes proposed by Karen Peltz Strauss to be consistent with the telecommunications guidelines §1193.33
Documentation for users on the installation, configuration, or use of the product including the description, installation, and use of accessibility, usability, and compatibility features, must conform to the relevant accessibility provisions in 1194 Subparts B and C. This includes, but is not limited to, reports, system documentation, user help, installation guides for end-user installable devices covered by Section 255, and user training or technical support materials. Features included in the product specifically to meet accessibility requirements must be documented. The documentation must be available in alternate formats or modes upon request and, for the purposes of Section 255, at no additional charge.

7.1-B - Keyboard Shortcuts

Comment from ITI
ITI supports Version 2.

Comments from ITAA
a. ITAA endorses version 3.
b. In list item 3, add "equivalent" before "keyboard commands"

Comments from Japan/Haijime Yamada
Suggest changing the expressiong "operating system" in 7.1 B version 3 to "platform software" since the later is defined in the Definitions.

Other comments

Still looking for a way to express this provision that will meet the needs of all users (for example allowing for inclusion in either contextual help or consolidated documentation.
Still looking for a way to address applications that run on multiple platforms which can result in different shortcuts for the same action.

7.1-X - Advisory Notes

Discussion of Work in Progress:

Proposal for a best practice entry for compatibility of assistive technology with the product, so vendors can include information as to which AT they work with, installation and configuration information. No conclusion was reached.

7.2-A - Support Services

Discussion of Work in Progress:

Need impact

Changes proposed by Karen Peltz Strauss to be consistent with the telecommunications guidelines §1193.33
Help desk, technical support, and customer support services provided by call centers and in-person service centers, must accommodate the communication needs of users with disabilities, where these services are otherwise provided by agencies or manufacturers,. For the purposes of Section 255, such services must be made available at no additional charge. These support services must be able to offer information on the basic use of assistive technology, as well as complete and accurate information on how to install and configure assistive technology for optimum performance.

Comments from ITAA
For the situation where the agency has the vendor provide support vendors cannot "comply" with this without the AT knowledge

Other discussion points

Reworded to be more specific regarding the type of support.
Question about if it's the accessibility configuration of the product, or the configuration of the AT with the product.
Concerns regarding the phrase "complete and accurate information on how to install and configure assistive technology for optimum performance." Vendors should be giving support information about their own product, not the AT.
Recommendation to make these best practices since it's not possible for vendors to test all of their products with all the possible AT and know how it should all be configured.
We were reminded that this provision applies to the agency and not the product manufactures. It was mostly agreed that this clarification should be added to the provision. Agencies can contract for these services, but are generally the ones doing the first line support.
More research is needed on how section 508 differs from section 255 with regards to this.

7.NEW - Manufacturer Contact

New provision proposed by Karen Peltz Strauss to be consistent with the telecommunications guidelines
For purposes of Section 255, manufacturers shall include in general product information the contact method for obtaining the information required by this section.

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

7.NEW - Training

New provision proposed by Karen Peltz Strauss to be consistent with the telecommunications guidelines
Where manufacturers provide employee training, they shall ensure that it is appropriate to each employee's function, and give consideration to the following factors in developing and providing that training::

(1) Accessibility requirements of individuals with disabilities; (2) Means of communicating with individuals with disabilities; (3) Commonly used adaptive technology with the manufacturer’s products; (4) Designing for accessibility; (5) Solutions for accessibility and compatibility.

Text from: Telecommunications §1193.33(c)

8. Additional Provisions for Authoring Tools

8.A - Accessible Output

Discussion of Work in Progress: 
* Need rationale, impact, and metadata

Proposed change to the explanatory text from ITI (additional text in italics):
For each accessible content format supported, when available, authoring tools must allow the author to produce content, including content derived from programmatic sources, which meets applicable Section 508 provisions.

The committee should also provide a definition for “accessible content format.”

Comments from ITAA
Provision must clarify meaning of “content derived from programmatic sources”.

8.B - Preserve Accessibility Information

Discussion of Work in Progress: 
* Need rationale, impact, and metadata

Proposed change from ITI (additional text in italics):
For each accessible content format supported, authoring tools must preserve accessibility information necessary to meet applicable Section 508 provisions, unless the user explicitly indicates otherwise.

8.C - Prompts

Discussion of Work in Progress: 
* Need rationale, impact, and metadata

8.D - Accessible Templates

Discussion of Work in Progress: 
* Need rationale, impact, and metadata

Comment from ITI:
Templates are often supplied as a convenience and are not necessarily supported by the original product. This provision could be interpreted as meaning one of each type of template would need to be made accessible. For some products, this would be a very burdensome task and we feel that resources would be better spent building more accessible authoring tools. Accordingly, ITI recommends that this provision be removed.

8.X - Advisory Notes