# EWG:Draft Oct 26 Updates

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

They are collected here for discussion at the November plenary.

## New Proposed Drafts (aka, The Sandbox) 

## Subpart A: Section 1194.1 Purpose

[*[Go to the Oct 26 Draft of this
Provision]{.underline}*](http://teitac.org/wiki/EWG:Draft_Oct_26#Section_1194.1_Purpose)

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

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

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

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

**Comments from ITAA\
**Input on version 1:

1.  Strike "compared to"

2.  Replace \"implement\" with \"provide standards for ascertaining the
    accessibility of E and IT required by\"

3.  Add reference to section 255

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

**Input on Notes:** Delete "access" to follow the style used in
subsequent bulleted items

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

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

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

**Input on Rationale comment:** Change "comparable" to to "comparable
to"

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

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

1.  Accept edits from Karen P-S

2.  Accept 3 edits from ITAA -- Except change \"Implement\" to \"provide
    standards for implementing\".

3.  Accept ITAA deletion of \"access\" in note

4.  Accept ITAA addition of \"either\" and \"by\"

5.  Best NOT add \"at option of company/agency\". It is not necessary
    and sometimes it is one or the other -- better to make generic.

## Subpart A: Section 1194.2 Application

[*[Go to the Oct 26 Draft of this
Provision]{.underline}*](http://teitac.org/wiki/EWG:Draft_Oct_26#Section_1194.2_Application)

### Additions proposed to incorporate 255 by Karen Peltz Strauss

1\. Mark entire currrent draft as applicable to 508

2\. Add section for 255

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

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

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

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

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

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

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

1.  Accept new a(2) from Version 2.

2.  Keep (b) as it is in current version.

3.  Accept Karen P-S edits to put in 255 language.

4.  Include additional section proposed by Karen P-S

-   Prohibited reduction of accessibility, usability and compatibility

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

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

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

## Subpart A: Section 1194.3 General Exceptions

[*[Go to the Oct 26 Draft of this
Provision]{.underline}*](http://teitac.org/wiki/EWG:Draft_Oct_26#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 Oct 26 Draft of this
Provision]{.underline}*](http://teitac.org/wiki/EWG:Draft_Oct_26#1194.3_-_E_-_Fundamental_Alteration)

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

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

## 1194.3 - F - Service Areas

[*[Go to the Oct 26 Draft of this
Provision]{.underline}*](http://teitac.org/wiki/EWG:Draft_Oct_26#1194.3_-_F_-_Service_Areas)

**Comments from CSD/Trace Center\
**Version 1 Edit.

## 1194.3 - NEW - Narrow, Delineated Use

[*[Go to the Oct 26 Draft of this
Provision]{.underline}*](http://teitac.org/wiki/EWG:Draft_Oct_26#1194.3_-_NEW_-_Narrow.2C_Delineated_Use)

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

## 1194.3 - NEW -- Inherently Visual EIT Assets

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

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

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

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

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

### Comments from CSD/Trace Center

1.  Accept Karen P-S edit with list of sections that apply only to 508

2.  Do NOT accept new provision from ITAA regarding \'Inherently Visual
    E&IT Assets. (Rationale: If we do it opens up an unending list of
    exceptions such ach inherently auditory, inherently fine motor,
    inherently simultaneous action, etc. There are many things that will
    not make sense for particular people with particular disabilities to
    do. This is covered through undue burden since it is technically not
    possible to do these. In addition adding accessibility to these
    types of products might cause a fundamental alteration to their
    nature or function, a basic defense to access under the
    Rehabilitation Act which already exists)

3.  Do NOT accept new emergency and First Response Use (Rationale: this
    is same as #2 above. It falls in the same category -- and is prone
    to abuse. For example, after 9-11 there were field units that people
    used to locate their children. This could be interpreted to mean
    that such units did not need to be accessible -- leaving people with
    disabilities unable to post notices or search for their children.
    This should be covered by \'undue burden\'. Where it is possible and
    for those disabilities it should apply. For those disabilities that
    do not make sense, it would not apply. Again the fundamental
    alteration language should take care of this.)

# Definitions (New)

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

## Customer premises equipment

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

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

## Interconnected Voice over Internet Protocol (VoIP) Product

A product that is used to provide interconnected VoIP service

*Source: FCC regulations*

## Interconnected Voice over Internet Protocol (VoIP) Service

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

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

## Manufacturer

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

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

## Peripheral devices

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

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

## Readily achievable

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

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

## Specialized customer premises equipment

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

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

## Telecommunications equipment

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

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

## Telecommunications service

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

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

## Usable

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

*Source: Telecommunications §1193.3 (no change)*

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

# Definitions-comments 

## Content

-   (Robert B) Definition is not clear enough. Recommend adding: (for
    example: word processing files, presentation files, spreadsheet
    files, text files, portable document files, web based content, etc.)

-   (Japan/Haijime Yamada) The definition of Web Content (Content which
    is made available in the World Wide Web) is too narrow. It must be
    such as "Content which is made available by web browser technology."
    Web browser technology is used in a stand-alone product that is not
    connected to the Web.

-   (CSD/Trace Center) Accept Robert B examples

## Decoration 

-   (Peter K) Should this perhaps be only visual sensory experience? Or
    audio too?

-   (Gregg V) The definition could apply to either - but we only use it
    for visual in the standard.

-   (CSD/Trace Center) Keep as proposed by Web and Software.

## Electronic and Information Technology 

-   (Peter K) It seems to me that by this definition, a copier is NOT
    E&IT, as the IT is embedded. Is this the intention?

-   (Aubrey W) The definition is clear that it does include copiers.
    Clarification is needed on what the third sentence means.

-   (Gregg V) A copier is IT. So is a printer.

-   Need to get agreement if the current text is acceptable

-   (CSD/Trace Center) Change \"not the principal function\" to \"not a
    principal function\". And add to end \"E&IT that is combined with
    non-E&IT is covered but the coverage does not extend to the
    non-E&IT\" There are too many compound products that are clearly IT
    with something added. A computer mounted on the door of a
    refrigerator should count as a computer -- but the refrigerator
    should not be included.

    -   Add \"Note: A computer mounted on the door of a refrigerator
        should count as a computer -- but the refrigerator should not be
        included.\"

## Information Technology 

-   (ITAA) It is not clear if this definition includes Telecom or not.
    Suggest including in the list of examples if so, or stating that it
    does not.

-   (Andi S) Why do we need this definition and the definition of E&IT?

-   (CSD/Trace Center) REMOVE the definition. (Rationale: The term is
    not used anywhere in any provision except within the phrase
    \"electronic and information technology\" which is already defined.
    ITAA has noted that it is confusing but cannot be changed because it
    comes from Clinger Cohen.)

## Menu 

-   (Peter K) this needs to be scoped, perhaps just to telecom or "audio
    menus". As it reads now, things like a collection of radio buttons
    would be considered a menu. Also, where is this term used in 508?
    three things to consider: instead of "Set of selectable options",
    what about "Presentation of a set of selectable options", or
    "Presentation of a set of user-selectable options". But in either
    case, we should note that this is an audio/aural presentations

-   (Gregg V) Menu is used in a number of places. We need to be careful
    of each one.

-   (Andi S) Suggest deleting this term and changing 6-D to \"\... such
    as options for selection and access to segments of the
    content\....\".

-   (CSD/Trace Center) Agree with Peter K and Gregg V comments. Menu is
    used in 3 places: 3-CC advisory note example referring to software
    menus, in 4-C to refer to menu\'s on television display like device,
    and in 6-D referring to multimedia menus (like on DVDs). No
    suggested text.

## Real-time Text 

-   (Peter K) Do we need \"by a terminal\"

-   (Gregg V) I believe that phrase was included to prevent the 1 second
    from being applied to things that retransmit the text enroute.

-   (CSD/Trace Center) After the word \"terminal\" add \"(hardware or
    software)\" to clarify since that is how it is used in the
    provisions.

## Synchronized Media 

-   (ITAA) Propose revising to: Audio or video displayed at the same
    time as other time-based content that is required for understanding
    of the complete presentation. The other time-based content does not
    include equivalents such as captions, subtitles, or video
    description.

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

## Video Description 

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

## Section 1194.5 Equivalent Facilitation 

[*[Go to this section in the Oct 26
Draft]{.underline}*](http://teitac.org/wiki/EWG:Draft_Oct_26#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]{.underline}*](http://teitac.org/wiki/EWG:Draft_Oct_26#Technical_Provisions)

**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]{.underline}*](http://teitac.org/wiki/EWG:Draft_Oct_26#1.1_Functional_Performance_Criteria)

**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 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\
**1. Move the FPC to a section after the technical Provisions and before
the Documentation and Process Provisions. (Rationale: The functional
Performance criteria do serve a different purpose than the technical
provisions and are specified in the 508 Law as a separate but required
component. Locating them after the Technical Provisions follows the
logic that they are used to check to see if the technical provisions
covered all the aspects and as an overall check for success of the
technical provisions and any equivalent facilitation that might have
been used as well.)

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

The functional performance criteria have three roles:

1.  If any of the technical provisions are not met, the Functional
    Performance Criteria are used to see if access is provided in
    another way (i.e. through equivalent facilitation).

2.  If the technical provisions are met, the Functional Performance
    Criteria are used to see if the technical provisions cover all
    aspects needed to provide access to the product. (i.e overall
    evaluation)

3.  The Functional Performance Criteria can be used to help identify and
    report functions (of a partially conforming product) that would not
    meet the Functional Performance Criteria (and would therefore not
    work with employees and/or public users with disabilities) so that
    agency can evaluate the importance of lack of access to those
    functions to the intended use of the product.

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

-   Without requiring color vision -- sounds like it is only for people
    with no color vision at all -- which is very rare. Color vision
    deficits pose unique problems, are very common and must be
    addressed.

-   Without requiring visual acuity -- would mean that the person was
    blind rather than low vision

-   For hard of hearing -- what would it say?

-   Without requiring speech -- sounds like speech output cannot be
    used.

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

-   Change 1.1A to \"without requiring user vision\"

-   Change 1.1D to \"without requiring user hearing\"

-   Change 1.1F to \"without requiring user speech\"

## 1.1-A - Without Vision

[*[Go to the current version in the Oct 26
Draft]{.underline}*](http://teitac.org/wiki/EWG:Draft_Oct_26#1.1-A_-_Without_Vision)

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

## 1.1-B - With Limited Vision

[*[Go to the current version in the Oct 26
Draft]{.underline}*](http://teitac.org/wiki/EWG:Draft_Oct_26#1.1-B_-_With_Limited_Vision)

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

## 1.1-C - With Color Vision Deficits

[*[Go to the current version in the Oct 26
Draft]{.underline}*](http://teitac.org/wiki/EWG:Draft_Oct_26#1.1-C_-_Without_Color_Vision_Deficits)

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

## 1.1-D - Without Hearing

[*[Go to the current version in the Oct 26
Draft]{.underline}*](http://teitac.org/wiki/EWG:Draft_Oct_26#1.1-D_-_Without_Hearing)

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

## 1.1-E - With Limited Hearing

[*[Go to the current version in the Oct 26
Draft]{.underline}*](http://teitac.org/wiki/EWG:Draft_Oct_26#1.1-E_-_With_Limited_Hearing)

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

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

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

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

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

## 1.1-F - Without Speech

[*[Go to the current version in the Oct 26
Draft]{.underline}*](http://teitac.org/wiki/EWG:Draft_Oct_26#1.1-F_-_Without_Speech)

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

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

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

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

[*[Go to the current version in the Oct 26
Draft]{.underline}*](http://teitac.org/wiki/EWG:Draft_Oct_26#1.1-G_-_With_Limited_Reach.2C_Strength.2C_or_Manipulation)

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

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

*Source: §1193.41(e)*

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

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

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

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

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

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

## 1.1-H - Without Physical Contact

[*[Go to the current version in the Oct 26
Draft]{.underline}*](http://teitac.org/wiki/EWG:Draft_Oct_26#1.1-H_-_Without_Physical_Contact)

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

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

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

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

*Rationale and Notes*

-   It is well known that a large population of people with physical
    disabilities cannot reach out to touch a product or cannot reach out
    long enough to actually operate a product physically.

-   While it is preferable that no contact at all be required, some
    physical contact may be needed to turn power on, initialize a
    telephone call or change mode of operation. In some cases it may be
    required for the user to be assisted by a companion or bystander
    with these operations.

-   Assistive Technology examples:

    -   The use of a standard network interface (e.g. USB, Ethernet,
        IEEE 1394, Wi-Fi, Bluetooth, etc.) that allows users to control
        the product using software via a wired or wireless network
        connection would meet this provision.

    -   The use of the infra-red ("IR") port used for remote controls in
        consumer electronics products would meet this provision.

-   Direct Access examples:

    -   Voice dialing is an example of direct access. Access to voice
        dialing may require physical contact with the product to
        initiate the call or change mode of operation to enable voice
        dialing.

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

## 1.1-I - With Cognitive, Language or Learning Limitations

[*[Go to the current version in the Oct 26
Draft]{.underline}*](http://teitac.org/wiki/EWG:Draft_Oct_26#1.1-I_-_With_Cognitive.2C_Language_or_Learning_Limitations)

**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-A - Accessibility Configuration

[*[Go to the Oct 26 Draft of this
Provision]{.underline}*](http://teitac.org/wiki/EWG:Draft_Oct_26#1.2-A_-_Accessibility_Configuration)

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

-   Products procured must be capable of being configured to be
    accessible to and usable by people with disabilities while
    simultaneously meeting the products function.

-   After procurement each agency must activate accessibility features
    and configure products so that they are accessible to and usable by
    people with disabilities who will be using the products or systems.

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

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

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

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

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

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

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

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

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

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

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

### Comments from CSD/Trace Center

-   Use language proposed by Gregg V \[this would address first comments
    by ITI\]

-   Do not move to application section. This relates to both products
    (first bullet) and to companies who provide services to the
    government (e.g. \'seats\').

## 1.2-C - Closed Functionality

[*[Go to the Oct 26 Draft of this
Provision]{.underline}*](http://teitac.org/wiki/EWG:Draft_Oct_26#1.2-C_-_Closed_Product_Functionality)

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

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

-   2.1-E - Connector or Connection Language

-   3-F - All Non-Text Objects

-   3-G - Human Language

-   3-H - Language of Parts

-   3-N - Link Purpose

-   3-O - Information and Relationships

-   3-P - User Interface Components

-   3-U - AT Interoperability

-   3-W - Accessibility Services

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

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

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

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

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

### Comments from CSD/Trace Center

1.  Products are not \"closed\" unless all of their functionality is
    closed. This one is written to apply to specific functionalities.
    Since it acts as an exception to other technical requirements it
    should be included here. It helps to identify what needs to occur if
    aspects of products do not meet the \"compatibility\" provision.

2.  The provision is meant to apply to all of the functionality of the
    product. Not necessarily all the features (i.e. ways of getting to a
    products functions) but to the functions of the product.

3.  This provision also highlights the need to look at this from a
    function standpoint rather than whole product or main function.

## 1.2-C - Flashing

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

## 1.2-D - Biometric ID

[*[Go to this section of the Oct 26
Draft]{.underline}*](http://teitac.org/wiki/EWG:Draft_Oct_26#1.2-D_-_Biometric_ID)

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

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

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

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

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

## 1.2-E - Pass Through

*[[Go to the Oct 26 Draft of this
Provision]{.underline}](http://teitac.org/wiki/EWG:Draft_Oct_26#1.2-E_-_Pass_Through)*

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

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

Also rename the provision to: Telecommunications Information Pass
Through

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

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

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

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

### Other Comments 

-   (Gregg V) It says that these things should not strip disability
    access information in the process. For most things it would be no
    issue. In places where it does apply it would be important.

-   (Gregg V) I think the last \"usable\" is supposed to be Accessible.

-   (David B/Gregg) Need note that this applies to captions

-   Need rationale and impact for this provision.

### Comments from CSD/Trace Center

1.  The provision is intended to apply to every E&IT device. All that it
    required however is that access information not be removed when
    information is being transferred etc. If the processes are
    transparent and not lossy (i.e. they do not throw some data away)
    then this will not be a problem. Disk drives etc. would not be a
    problem and would pass automatically. The problem originated with
    the stripping of captions. It would also apply to stripping text or
    video from a call whether the call is via traditional
    telecommunications or via interconnected VoIP, which is now covered
    under Section 255.

2.  The third sentence does not assume any method for passing the
    real-time text. Just that the text not be lost.

3.  \"usable format\" should be \"accessible format\"

4.  There is not a restriction on codes. Just a requirement that access
    related codes be passed through.

5.  Computer manufacturers are responsible for what they deliver -- not
    for software added later - as is true for all the provisions.

## 1.2-F - Audio Information

*[[Go to the Oct 26 Draft of this
Provision]{.underline}](http://teitac.org/wiki/EWG:Draft_Oct_26#1.2-F_.E2.80.93_Audio_Information)*

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

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

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

### Comments from CSD/Trace Center

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

2.  change \"operation and use\" to \"product operation and use\"
    \[addresses ITAA comment\]

## 1.2-G - Visual Information

[*[Go to the Oct 26 Draft of this
Provision]{.underline}*](http://teitac.org/wiki/EWG:Draft_Oct_26#1.2-G_-_Visual_Information.3D.3D.3D)

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

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

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

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

c\. The provision must make clear what "where appropriate" means?

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

### Comments from CSD/Trace Center

1.  This is easily tested. Remove all visual input from user (e.g. using
    mask) and see if they can use the product successfully. If so then
    all visual information needed to use product is available in audio
    form.

2.  There are many products with audio output. Those products where
    there is not audio output or tactile output of key information would
    indeed fail this provision. That is the purpose of the provision, to
    identify products that cannot be used for this group of users.

3.  change \"operation and use\" to \"product operation and use\"
    \[addresses ITAA comment\]

## 1.2-F and 1.2-G Audio and Video Information

[*[Go to the current version in the Oct 26
Draft]{.underline}*](http://teitac.org/wiki/EWG:Draft_Oct_26#1.2-F_-_Audio_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-I - Text size

[*[Go to the Oct 26 Draft of this
Provision]{.underline}*](http://teitac.org/wiki/EWG:Draft_Oct_26#1.2-I_-_Text_size)

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

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

### Comments from CSD/Trace Center

1.  Agree with ITAA to change \"done\". But \"read is perhaps the wrong
    word since it refers to \"activating a mode\" and not just reading.
    Suggest \"seen by people\"

2.  In checking with a vision scientist at Lighthouse -- this provision
    would cover most types of mild low vision up to 20/70. Those not
    covered would be those with field deficits that allowed standard
    vision -- but they would not need this.

3.  It was pointed out that some products could not meet this provision.
    However this is appropriate. Products that do not meet this
    provision would not be usable by people with even mild low vision
    (20/70). So it would be appropriate that those products be noted as
    not meeting this provision \-- so that it would be clear that
    employees with low vision would have problems with the products.
    Most standard keyboards would meet this provision -- even for keys
    with words and multiple legends.

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

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

# 2. Hardware Aspects of Products

## 2.1-A - Luminance Contrast Ratio for Display 

[*[Go to the Oct 26 Draft of this
Provision]{.underline}*](http://teitac.org/wiki/EWG:Draft_Oct_26#2.1-A_-_Luminance_Contrast_Ratio_for_Display.3D.3D.3D)

**Discussion of Work in Progress**

\* Need rationale and impact

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

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

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

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

### Comments from CSD/Trace Center

1.  Agree with ITAA (except use IS instead of SHALL)

2.  RE: ITI comment. Almost all displays will come with these values
    already specified. For manufacturers it should not be hard to
    calculate the ratio from the product specifications.

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

## 2.1-B - Reflectance Contrast for Legends and Passive Displays 

[*[Go to the Oct 26 Draft of this
Provision]{.underline}*](http://teitac.org/wiki/EWG:Draft_Oct_26#2.1-B_-_Reflectance_Contrast_for_Legends_and_Passive_Displays)

**Discussion of Work in Progress:**

\* Need rationale and impact

\* There is some conflict between guidance provided in non-accessibility

ISO standards such as ISO 9241.4

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

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

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

### Comments from CSD/Trace Center

1.  ITAA comment #1 should be addressed by current notes.

2.  To address ITAA comment #2 suggest changing \"instructions on
    device\" to \"instructions printed on device\"

3.  RE ITI comment. We understood from discussions on hardware committee
    that these did match what was already in ISO standards. A ratio
    higher than 3:1 is desired.

## 2.1-C - Flashing 

[*[Go to the Oct 26 Draft of this
Provision]{.underline}*](http://teitac.org/wiki/EWG:Draft_Oct_26#2.1-C_-_Flashing)

### Comments from Gregg V

-   We are still working on the Hardware flash definitions for

    -   screen flicker (not content)

    -   indicators and visual alerts

-   Impact should say: \"Negative cost - The change saves money (e.g.
    special circuitry not needed to control frequency of status LEDs)
    and provides additional flexibility to industry for non-critical
    stimuli.\"

-   Possible advisory note: \"NOTE: Screen flicker of 60hz is safe for
    most (85%) but refresh frequencies of 75hz or greater are
    recommended where possible.\"

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

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

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

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

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

## 2.1-D - Mechanical Controls 

[*[Go to the Oct 26 Draft of this
Provision]{.underline}*](http://teitac.org/wiki/EWG:Draft_Oct_26#2.1-D_-_Mechanical_Controls)

**Discussion of Work in Progress:**

\* Need impact

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

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

### Comments from CSD/Trace Center

1.  Recommend against renaming. \"Mechanically Operated Controls\" is
    longer and only adds ambiguity (does mechanical mean how the
    controls operates or was operated).

2.  This provision does not disallow rotational controls that can be
    operated by rubbing edges or moving pointers etc. It does
    specifically disallow controls that require twisting of the wrist. A
    quick test is if they can be operated by using the eraser end of a
    pencil.

## 2.1-E - Touch Operated Controls 

[*[Go to the Oct 26 Draft of this
Provision]{.underline}*](http://teitac.org/wiki/EWG:Draft_Oct_26#2.1-E_-_Touch_Operated_Controls)

**Discussion of Work in Progress**

\* Keyboard controls that provide equivalent functionality are
equivalent

\* Touch screens can\'t always provide a 1:1 match of soft and
mechanical controls.

\* Need to finalize some language that addresses the intent of
"redundancy"

of controls beyond just requiring another set of mechanical controls.

\* Need to add an ability to de-activate the touch screen to prevent
accidental

activation

\* Is remote control an acceptable alternative

\* Need impact

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

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

## 2.1-F - Standard Connection

[*[Go to the Oct 26 Draft of this
Provision]{.underline}*](http://teitac.org/wiki/EWG:Draft_Oct_26#2.1-E_-_Standard_Connection)

**Discussion of Work in Progress:**

\* Need to determine provision title

\* Need impact

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

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

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

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

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

c\. Does this provision unprotect proprietary connections?

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

### Comments from CSD/Trace Center

1.  Agree with ITI and ITAA -- that E&IT vendor not be called out in 508
    standard which is agency requirement. Suggest slight edit to ITI
    suggestion to remove SHALL -- so it reads \".. the procuring agency
    must identify a market source for the connector if it isn\'t a
    standard option for the product.\"

2.  Agree with closed committee on \"User Interface\" but feel it must
    be a standard connection so suggest \"Standard User Interface
    Connection\". This will also clearly separate it from audio
    connection.

3.  RE ITAA question on Proprietary connections -- it allows all
    connections to be proprietary. But if a proprietary connection is
    used for alternate control of a product -- then an adapter to a
    standard format is required so that alternate accessible interfaces
    can also be used without having to design them custom for the
    proprietary interface (a very expensive and seldom available
    option).

## 2.1-G - Installed or Free-Standing Products

[*[Go to the Oct 26 Draft of this
Provision]{.underline}*](http://teitac.org/wiki/EWG:Draft_Oct_26#2.1-G_-_Installed_or_Free-Standing_Products)

**Discussion of Work in Progress:**

\* Need impact

## 2.2 If the Product has Speech Output or Throughput

[*[Go to the Oct 26 Draft of this
Provision]{.underline}*](http://teitac.org/wiki/EWG:Draft_Oct_26#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.

```{=html}
<!-- -->
```
-   (Andi S) Is \"speech\" really the right word for this title? What if
    it has audio output that is not speech? Wouldn\'t some of these
    provisions apply in that case?

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

-   2.2A - \"Products that deliver \[speech\] output with an audio
    transducer that is normally held up to the ear ...\"

-   2.2B - \"Products that deliver \[speech\] output with an audio
    transducer that is normally held up to the ear.

-   2.2C - \"When products that provide speech output or throughput,
    ....

-   2.2D - \"When products that provide speech output,

-   2.2E - OK as is

-   2.2F - OK as is.

## 2.2-A - Magnetic Coupling

[*[Go to the Oct 26 Draft of this
Provision]{.underline}*](http://teitac.org/wiki/EWG:Draft_Oct_26#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

1.  Agree with ITAA - add "of such hearing technology" after "that
    allows a user"

2.  Add a note to clarify the issue raised by ITAA.

    -   Note: The standard handset on a phone or other device is not an
        \'accessory\' and is not an exception to this provision.

3.  Agree with ITAA - delete advisory note -- it is duplicated from next
    provision. (edit-o)

## 2.2-B - Interference with Hearing Device

[*[Go to the Oct 26 Draft of this
Provision]{.underline}*](http://teitac.org/wiki/EWG:Draft_Oct_26#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

*[[Go to the Oct 26 Draft of this
Provision]{.underline}](http://teitac.org/wiki/EWG:Draft_Oct_26#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

1.  Use new version from Gregg V (in UPDATES) with edits to address
    other\'s issues.

2.  Make revision above to limit to devices that output speech to
    address \"Musak\" issue identified by ITAA:

3.  RE ITAA question: Cell phones should be required to include
    headphone jack directly or via adapter but current language (crafted
    to remove requirement for public pay phones) also removed existing
    requirement for headphone jack from cell phones. To address this

    -   Add the following to the front of the first bullet: \"Product is
        designed for public use and\"

4.  To address Karen PS concern about need for private listening

    -   Add the following to the end of the Second bullet: \"that allows
        for private listening\"

    -   Add the following to the end of the Second bullet: \"and that
        allows for private listening\"

## 2.2-D - Volume 

[*[Go to the Oct 26 Draft of this
Provision]{.underline}*](http://teitac.org/wiki/EWG:Draft_Oct_26#2.2-D_Volume.3D.3D.3D)

**Discussion of Work in Progress:**

\* Need rationale and impact

\* Final level for THD still to be determined.

\* Question about where are volumes set? Is that where you measure from?

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

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

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

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

1.  For products use in public places where the background noise level
    is not controlled to less than 50 dBA SPL RMS, the maximum volume
    level must be at least 80 dB SPL RMS measured at a typical listening
    position.

2.  For products not for use in public places or where the background
    noise level of the public place is controlled to less than 50 dBA
    SPL RMS, the maximum volume of the product must be at least 65 dB
    SPL RMS.

3.  All products must have less than 12 dB symmetrical clipping or a
    total harmonic distortion (THD) less than xxx% at all volume levels
    including maximum volume level.

4.  Volume on audio jacks must be adjustable.

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

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

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

1.  Use new provision posted by Gregg V 11-8-07

2.  Edit described above to limit to products with speech output.

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

[*[Go to the Oct 26 Draft of this
Provision]{.underline}*](http://teitac.org/wiki/EWG:Draft_Oct_26#2.2-E_-_Volume_.28Gain.29)

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

[*[Go to the Oct 26 Draft of this
Provision]{.underline}*](http://teitac.org/wiki/EWG:Draft_Oct_26#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 Oct 26 Draft of this
Provision]{.underline}](http://teitac.org/wiki/EWG:Draft_Oct_26#3-A_-_Color)*

**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 Oct 26 Draft of this
Provision]{.underline}](http://teitac.org/wiki/EWG:Draft_Oct_26#3-B_-_Contrast)*

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

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

2.  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 Oct 26 Draft of this
Provision]{.underline}](http://teitac.org/wiki/EWG:Draft_Oct_26#3-C_-_Size.2C_shape.2C_location)*

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

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

2.  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 Oct 26 Draft of this
Provision]{.underline}](http://teitac.org/wiki/EWG:Draft_Oct_26#3-D_-_User_Preferences)*

**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 Oct 26 Draft of this
Provision]{.underline}](http://teitac.org/wiki/EWG:Draft_Oct_26#3-E_-_Color_Adjustment)*

**Discussion of Work in Progress:**

\* Need to resolve EWG input

## 3-F - Non-text Objects 

*[[Go to the Oct 26 Draft of this
Provision]{.underline}](http://teitac.org/wiki/EWG:Draft_Oct_26#3-E_-_Color_Adjustment)*

**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 Oct 26 Draft of this
Provision]{.underline}](http://teitac.org/wiki/EWG:Draft_Oct_26#3-G_-_Human_Language)*

**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-I - Pausing 

*[[Go to the Oct 26 Draft of this
Provision]{.underline}](http://teitac.org/wiki/EWG:Draft_Oct_26#3-I_-_Pausing)*

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

1.  Web content can be paused and restarted by \'clicking\' on the
    content -- without needing to add any controls.

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

*[[Go to the Oct 26 Draft of this
Provision]{.underline}](http://teitac.org/wiki/EWG:Draft_Oct_26#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 

*[[Go to the Oct 26 Draft of this
Provision]{.underline}](http://teitac.org/wiki/EWG:Draft_Oct_26#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 

*[[Go to the Oct 26 Draft of this
Provision]{.underline}](http://teitac.org/wiki/EWG:Draft_Oct_26#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

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

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

*[[Go to the Oct 26 Draft of this
Provision]{.underline}](http://teitac.org/wiki/EWG:Draft_Oct_26#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.]{.underline}](http://www.w3.org/WAI/GL/WCAG20/#programmaticallydetermineddef)
(Level A)

[[How to Meet
1.3.2]{.underline}](http://www.w3.org/WAI/WCAG20/quickref/20071102/Overview.php#content-structure-separation-sequence)

[[Understanding
1.3.2]{.underline}](http://www.w3.org/WAI/GL/WCAG20/WD-UNDERSTANDING-WCAG20-20071102/content-structure-separation-sequence.html)

2.4.3 Focus Order (Relationships): If a [[Web
page]{.underline}](http://www.w3.org/WAI/GL/WCAG20/#webpagedef) can be
[[navigated
sequentially]{.underline}](http://www.w3.org/WAI/GL/WCAG20/#nav-seqdef),
focusable components receive focus in an order that follows information
and relationships conveyed through
[[presentation]{.underline}](http://www.w3.org/WAI/GL/WCAG20/#presentationdef).
(Level A)

[[How to Meet
2.4.3]{.underline}](http://www.w3.org/WAI/WCAG20/quickref/20071102/Overview.php#navigation-mechanisms-focus-order)

[[Understanding
2.4.3]{.underline}](http://www.w3.org/WAI/GL/WCAG20/WD-UNDERSTANDING-WCAG20-20071102/navigation-mechanisms-focus-order.html)

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]{.underline}](http://www.w3.org/WAI/WCAG20/quickref/20071102/Overview.php#navigation-mechanisms-focus-order-visual)

[[http://www.w3.org/WAI/GL/WCAG20/WD-UNDERSTANDING-WCAG20-20071102/navigation-mechanisms-focus-order-visual.html]{.underline}](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 

*[[Go to the Oct 26 Draft of this
Provision]{.underline}](http://teitac.org/wiki/EWG:Draft_Oct_26#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]{.underline}](http://www.w3.org/WAI/GL/WCAG20/#linkpurposedef) can
be determined from the \[link text\] alone, or from the link text
together with its [[programmatically determined link
context]{.underline}](http://www.w3.org/WAI/GL/WCAG20/#pdlinkcontextdef),
except where the purpose of the link would be [[ambiguous to users in
general]{.underline}](http://www.w3.org/WAI/GL/WCAG20/#ambiguouslinkdef).
(Level A)

[[How to Meet
2.4.4]{.underline}](http://www.w3.org/WAI/WCAG20/quickref/20071102/Overview.php#navigation-mechanisms-refs)

[[Understanding
2.4.4]{.underline}](http://www.w3.org/WAI/GL/WCAG20/WD-UNDERSTANDING-WCAG20-20071102/navigation-mechanisms-refs.html)

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]{.underline}](http://www.w3.org/WAI/WCAG20/quickref/20071102/Overview.php#navigation-mechanisms-link)

[[Understanding
2.4.9]{.underline}](http://www.w3.org/WAI/GL/WCAG20/WD-UNDERSTANDING-WCAG20-20071102/navigation-mechanisms-link.html)

## 3-O - Information and Relationships

*[[Go to the Oct 26 Draft of this
Provision]{.underline}](http://teitac.org/wiki/EWG:Draft_Oct_26#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]{.underline}](http://teitac.org/wiki/Monday_10-15-2007_General_telecon)
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:

1.  row and column headers that are identified for data tables

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

3.  markup that is used to identify section headings

4.  markup that is used to identify form element labels

**WCAG 2.0 Text\
**1.3.1 Info and Relationships: Information, structure, and
[[relationships]{.underline}](http://www.w3.org/WAI/GL/WCAG20/#relationshipsdef)
conveyed through
[[presentation]{.underline}](http://www.w3.org/WAI/GL/WCAG20/#presentationdef)
can be [[programmatically
determined]{.underline}](http://www.w3.org/WAI/GL/WCAG20/#programmaticallydetermineddef)
or are available in text. (Level A)

[[How to Meet
1.3.1]{.underline}](http://www.w3.org/WAI/WCAG20/quickref/20071102/Overview.php#content-structure-separation-programmatic)

[[Understanding
1.3.1]{.underline}](http://www.w3.org/WAI/GL/WCAG20/WD-UNDERSTANDING-WCAG20-20071102/content-structure-separation-programmatic.html)

## 3-P - User Interface Components

*[[Go to the Oct 26 Draft of this
Provision]{.underline}](http://teitac.org/wiki/EWG:Draft_Oct_26#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]{.underline}](http://teitac.org/wiki/Monday_10-15-2007_General_telecon)
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

*[[Go to the Oct 26 Draft of this
Provision]{.underline}](http://teitac.org/wiki/EWG:Draft_Oct_26#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

*[[Go to the Oct 26 Draft of this
Provision]{.underline}](http://teitac.org/wiki/EWG:Draft_Oct_26#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 

*[[Go to the Oct 26 Draft of this
Provision]{.underline}](http://teitac.org/wiki/EWG:Draft_Oct_26#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]{.underline}](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 

*[[Go to the Oct 26 Draft of this
Provision]{.underline}](http://teitac.org/wiki/EWG:Draft_Oct_26#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 

*[[Go to the Oct 26 Draft of this
Provision]{.underline}](http://teitac.org/wiki/EWG:Draft_Oct_26#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]{.underline}](http://teitac.org/wiki/Monday_10-15-2007_General_telecon)
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

1.  Very important provision

2.  Products that have built in access can be closed and skip this.

3.  Phones are increasingly including operating systems and can thus
    support this instead of operating as closed products.

4.  This provision does not specify an API that can be built to. It only
    provides requirements for an API.

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

*[[Go to the Oct 26 Draft of this
Provision]{.underline}](http://teitac.org/wiki/EWG:Draft_Oct_26#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) 

*[[Go to the Oct 26 Draft of this
Provision]{.underline}](http://teitac.org/wiki/EWG:Draft_Oct_26#3-W_-_Multiple_Ways_.28New_provision.29)*

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

*[[Go to the Oct 26 Draft of this
Provision]{.underline}](http://teitac.org/wiki/EWG:Draft_Oct_26#3-X_-_Labels_or_Instructions_.28New_provision.29)*

**Discussion of Work in Progress:**

\* Need impact

## 3-Y - On Focus (New provision) 

*[[Go to the Oct 26 Draft of this
Provision]{.underline}](http://teitac.org/wiki/EWG:Draft_Oct_26#3-Y_-_On_Focus_.28New_provision.29)*

**Discussion of Work in Progress:**

\* Need impact and rationale

## 3-Z - On Input (New provision) 

*[[Go to the Oct 26 Draft of this
Provision]{.underline}](http://teitac.org/wiki/EWG:Draft_Oct_26#3-Z_-_On_Input_.28New_provision.29)*

**Discussion of Work in Progress:**

\* Need impact

## 3-AA - Error Identification (New provision) 

*[[Go to the Oct 26 Draft of this
Provision]{.underline}](http://teitac.org/wiki/EWG:Draft_Oct_26#3-AA_-_Error_Identification_.28New_provision.29)*

**Discussion of Work in Progress:**

\* Need impact and rationale

\* Need to resolve EWG input

## 3-BB - Labels Descriptive (New provision) 

*[[Go to the Oct 26 Draft of this
Provision]{.underline}](http://teitac.org/wiki/EWG:Draft_Oct_26#3-BB_-_Labels_Descriptive_.28New_provision.29)*

**Discussion of Work in Progress:**

\* Need impact and rationale

\* Need to resolve EWG input

## 3-CC - Advisory Notes 

*[[Go to the Oct 26 Draft of this
Provision]{.underline}](http://teitac.org/wiki/EWG:Draft_Oct_26#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 Oct 26 Draft of this
Provision]{.underline}](http://teitac.org/wiki/EWG:Draft_Oct_26#4-A_-_Caption_Playback)*

### 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 Oct 26 Draft of this
Provision]{.underline}](http://teitac.org/wiki/EWG:Draft_Oct_26#4-B_-_Supplemental_Audio_Playback)*

### 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 Oct 26 Draft of this
Provision]{.underline}](http://teitac.org/wiki/EWG:Draft_Oct_26#4-C_-_Access_to_Caption_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:

1.  A caption on/off button on a TV remote comparable in prominence to
    the volume control on that remote;

2.  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 Oct 26 Draft of this
Provision]{.underline}](http://teitac.org/wiki/EWG:Draft_Oct_26#5-A_-_Relay_Services_Accessibility)*

**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 Oct 26 Draft of this
Provision]{.underline}](http://teitac.org/wiki/EWG:Draft_Oct_26#5-B_-_Real-Time_Text_Reliability_and_Interoperability)*

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

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

2.  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/]{.underline}](http://www.ip-relay.com/),
[[https://www.sprintip.com]{.underline}](https://www.sprintip.com/),
[[http://www.siprelay.com/]{.underline}](http://www.siprelay.com/),
[[http://www.ip-vrs.com/]{.underline}](http://www.ip-vrs.com/),
[[http://www.relaycall.com]{.underline}](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

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

2.  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 Oct 26 Draft of this
Provision]{.underline}](http://teitac.org/wiki/EWG:Draft_Oct_26#5-C_-_Voice_Terminal_Hardware_and_Software)*

**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]{.underline}](http://teitac.org/wiki/EWG:Draft_Oct_26_Updates#5-B_-_Real-Time_Text_Reliability_and_Interoperability)

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

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

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

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

3.  *(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

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

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

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

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

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

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

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

8.  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 Oct 26 Draft of this
Provision]{.underline}](http://teitac.org/wiki/EWG:Draft_Oct_26#5-D_-_IVR.2C_Auto-Attendant_and_Messaging)*

**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 Oct 26 Draft of this
Provision]{.underline}](http://teitac.org/wiki/EWG:Draft_Oct_26#5-E_-_Caller_and_Status_Information)*

**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 Oct 26 Draft of this
Provision]{.underline}](http://teitac.org/wiki/EWG:Draft_Oct_26#5-E_-_Caller_and_Status_Information)*

**Discussion of Work in Progress:**

\* Need rationale, impact, and metadata

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

# 6. Audio and/or Video Content

## 6-A - Captions and Transcripts

*[[Go to the Oct 26 Draft of this
Provision]{.underline}](http://teitac.org/wiki/EWG:Draft_Oct_26#6-A_-_Captions_and_Transcripts)*

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

## 6-B - Video Description

*[[Go to the Oct 26 Draft of this
Provision]{.underline}](http://teitac.org/wiki/EWG:Draft_Oct_26#6-B_.E2.80.93_Video_Description)*

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

-   6-B bullet 1 and 6-C bullet 1 seem to be identical. Isn\'t 6-B
    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-C - Open or Closed Captions/Descriptions

*[[Go to the Oct 26 Draft of this
Provision]{.underline}](http://teitac.org/wiki/EWG:Draft_Oct_26#6-C_-_Open_or_Closed_Captions.2FDescriptions)*

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

**Comment from IBM\
**6-C 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.

# 7. Information, Documentation and Support

## 7.1 Product Documentation and Help

[*[Go to this provision in the current
draft]{.underline}*](http://teitac.org/wiki/EWG:Draft_Oct_26#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

[*[Go to this provision in the current
draft]{.underline}*](http://teitac.org/wiki/EWG:Draft_Oct_26#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

[*[Go to this provision in the current
draft]{.underline}*](http://teitac.org/wiki/EWG:Draft_Oct_26#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

[*[Go to this provision in the current
draft]{.underline}*](http://teitac.org/wiki/EWG:Draft_Oct_26#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

[*[Go to this provision in the current
draft]{.underline}*](http://teitac.org/wiki/EWG:Draft_Oct_26#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.

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

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

[*[Go to this provision in the current
draft]{.underline}*](http://teitac.org/wiki/EWG:Draft_Oct_26#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 

[*[Go to this provision in the current
draft]{.underline}*](http://teitac.org/wiki/EWG:Draft_Oct_26#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 

[*[Go to this provision in the current
draft]{.underline}*](http://teitac.org/wiki/EWG:Draft_Oct_26#8-C_-_Prompts)

**Discussion of Work in Progress:**

\* Need rationale, impact, and metadata

## 8.D - Accessible Templates 

[*[Go to this provision in the current
draft]{.underline}*](http://teitac.org/wiki/EWG:Draft_Oct_26#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 

[*[Go to this provision in the current
draft]{.underline}*](http://teitac.org/wiki/EWG:Draft_Oct_26#8-X_-_Advisory_Notes)

**Discussion of Work in Progress:**

\* Need rationale and impact

\* Further discuss and write up a rationale explaining what is meant

by \"compatible with\...\"

\* From Sept 3 plenary: need to add more information about repair or
remediation

\* Need rationale, impact, and metadata

# Additional Discussion About 255 

**Comments from Karen Peltz Strauss\
**1. I want to make sure that the following sections from \"1193.51
Compatibility\" in the telecom guidelines are captured:

-   \(a\) external electronic access to all information and control
    mechanisms. Information needed for the operation of products
    (including output, alerts, icons, on-line help and documentation)
    shall be available in a standard electronic text format on a
    cross-industry standard port and all input to and control of a
    product shall allow for real time operation by electronic text input
    into a cross-industry standard external port and in cross industry
    standard format. The cross-industry standard port shall not require
    manipulation of a connector by the user.\"

```{=html}
<!-- -->
```
-   \(e\) TTY signal compatibility -- products, including those
    providing voice communication functionality, shall support use of
    all cross-manufacturer non-proprietary standard signals used by
    TTYs.

2\. The appendix to the Section 255 guidelines contains a wealth of
information about how to comply with the Section 255 directives. Much of
this seems to be valuable information that should be carried over as
explanations for the new guidelines. Here is a summary of what is
covered, and what should be included in the new working draft (this is a
lot of text and so I have not re-typed all of it):

-   explanation of what is "readily achievable" (for definition
    section). Recommendation: Leave as is.

```{=html}
<!-- -->
```
-   explanation of the process of designing, developing and evaluating
    products for accessibility (for 1193.23)

    -   **Recommendation:** Leave as is, but delete the following
        sentence from number 3: "It does not require that such a process
        be submitted to any entity or that it even be in writing." If
        the Access Board chooses to refrain from issuing rules on
        reporting requirements, it should stay out of this issue
        entirely. There may come a point that reporting requirements are
        put into effect by the FCC and this section should not attempt
        to preclude that from occurring.

```{=html}
<!-- -->
```
-   explanation of how manufacturers should go about providing access to
    information and documentation, including examples of alternate
    formats (Braille, large print, audio recordings, etc.) and alternate
    modes (relay services, text-to-speech synthesis, video description,
    captioning, etc.) (for 1193.33). This section emphasizes the need to
    provide information in a format or mode that is usable by the person
    needing the information and contains very detailed information about
    how best to provide Braille, electronic text, large print, cassette
    recordings, captioning, video description, Internet postings,
    telecommunications relay services, and TTYs. It also explains how to
    provide a point of contact for obtaining information about
    accessibility features and to obtain documents in alternate formats.
    Finally, this section provides guidance on how manufacturers could
    include information about accessibility in training it provides to
    staff.

    -   **Recommendation:** Keep this section, but update it to reflect
        new types of TRS. In addition, improve the section on training,
        which at present is very weak. Someone also probably needs to
        make sure that the TTY section is up to date.

```{=html}
<!-- -->
```
-   Explanation of redundancy and selectability (for 1193.35) -- This
    contains valuable guidance on the need to accomplish access through
    multiple and redundant modalities of input and output.

    -   **Recommendation:** This section is "reserved." I am not sure
        what this means or why this was done, but there is some very
        useful information in this section that would be helpful to add
        as explanatory guidance in the revisions to the Access Board's
        guidelines.

```{=html}
<!-- -->
```
-   various strategies and solutions to achieve compliance with the
    sections on (1) input, controls and mechanical functions (for
    1193.41) and (2) output, displays and control functions (for
    1193.43)

    -   **Recommendation:** These contain the various technical ways of
        how to comply. I would recommend that the EWG, or someone with
        technical know-how review each of these to see if they are
        already incorporated into our new proposals, or the extent to
        which some of these should simply be carried forward as is, as
        general guidance. It appears that there is information in these
        sections that is not yet included in the EWG draft of September
        14.

```{=html}
<!-- -->
```
-   Guidance on achieving non-interference with hearing technologies
    (for 1193.43(h) and hearing aid coupling (for 1193.43(i)

    -   **Recommendation:** update the section on interference, and
        review the section on coupling -- I think the latter is still
        ok.

```{=html}
<!-- -->
```
-   Guidance on achieving compatibility where accessibility is not
    readily achievable (for 1193.51), including external electronic
    access to information and control mechanisms, connection point for
    external audio processing devices, compatibility of controls with
    prosthetics, TTY connectability, and TTY signal compatibility.

    -   **Recommendation:** I will defer to others as to what to do with
        respect to this guidance.