From TEITAC

Editorial Working Group > Working Draft July 6

TEITAC Working Draft - July 6, 2007.

Please see the Updated July 18 draft

This page contains the full text of all provisions from the subcommittees as of July 6, 2007. The current draft of Subpart A is on a separate page, but linked here in the correct order.

Contents 1 Subpart A 2 Technical Provisions 2.1 1. Requirements for All Product and Services 2.1.1 [1.1] Functional Performance Criteria 2.1.1.1 1.1-A - Without Vision 2.1.1.2 1.1-B - With Limited Vision 2.1.1.3 1.1-C - With Color Vision Deficits 2.1.1.4 1.1-D - Without Hearing 2.1.1.5 1.1-E - With Limited Hearing 2.1.1.6 1.1-F - Without Speech 2.1.1.7 1.1-G - With Limited Reach, Strength, or Manipulation 2.1.1.8 1.1-H - With No Reach or Touch 2.1.1.9 1.1-I - With Cognitive, Language or Learning Limitations 2.1.2 [1.2] General Technical Requirements 2.1.2.1 1.2-A - Closed Products 2.1.2.2 1.2-B - Flashing 2.1.2.3 1.2-C - Biometric ID 2.1.2.4 1.2-D - Pass Through 2.1.2.5 1.2-E - Audio information 2.1.2.6 1.2-F - Visual Information 2.1.2.7 1.2-G - Color 2.1.2.8 1.2-H - Text size 2.1.2.9 1.2-I - Contrast 2.2 2. Provisions for Hardware Aspects of Products 2.2.1 [2.1] All Products with Hardware 2.2.1.1 2.1-A - Touch Operated 2.2.1.2 2.1-B - Free-Standing 2.2.1.3 2.1-C - Standard Connection 2.2.1.4 2.1-D - Contrast for displays 2.2.1.5 2.1-E - Contrast for labels 2.2.2 [2.2] If the Product has Physical Controls 2.2.2.1 2.2-A - Mechanical Controls 2.2.3 [2.3] If the product has Audio Output 2.2.3.1 2.3-A - Magnetic Coupling 2.2.3.2 2.3-B - Interference with Hearing Device 2.2.3.3 2.3-C - Audio Connection 2.2.3.4 2.3-D - Volume 2.2.3.5 2.3-E - Volume (Gain) 2.2.3.6 2.3-F - Volume Reset 2.3 3. Software & General Behavior Provisions 2.3.1 [3.1] All products 2.3.1.1 3.1-A - Disruption of Access Features 2.3.1.2 3.1-B - Timing 2.3.1.3 3.1-C - Software as platform and application 2.3.2 [3.2] If the Product has Visual Output or Display 2.3.2.1 3.2-A - Contrast 2.3.2.2 3.2-B - Animation 2.3.2.3 3.2-C - User Preferences 2.3.3 [3.3] If the Product has Standard Keyboard or Keyboard Interface 2.3.3.1 3.3-A - Keyboard 2.3.4 [3.4] If Software runs on platform with Operating System with AT Support 2.3.4.1 3.4-A - AT Interoperability 2.3.4.2 3.4-B - Bitmap Icons 2.3.4.3 3.4-C - Focus Indicator 2.4 4. Additional Provisions for Audio-Visual Content or Players/Displays 2.4.1 4-A - Caption Playback 2.4.2 4-B - Supplemental Audio Playback 2.4.3 4-C - Play Control (Audio) 2.5 5. Additional Provisions for Real-time Voice Conversation Functionality 2.5.1 5-A - Accessibility Configuration 2.5.2 5-B - Real-time Text Reliability 2.5.3 5-C - Real-Time Text Interoperability 2.5.4 5-D - VOIP Terminals and Real-Time Text 2.5.5 5-E - Voice Terminals without Real-Time Text 2.5.6 5-F - IVR etc. 2.5.7 5-G - Caller and Status Information 2.5.8 5-H - Video Support 2.6 6. Electronic Content Provisions 2.6.1 [6.1] If Web Content or Web Applications 2.6.1.1 6.1-A - Color (Web) 2.6.1.2 6.1-B - Contrast (Web) 2.6.1.3 6.1-C - Timing (Web) 2.6.1.4 6.1-D - Flashing (Web) 2.6.1.5 6.1-E - Non-text Content 2.6.1.6 6.1-F - Repeated Blocks 2.6.1.7 6.1-G - Keyboard 2.6.1.8 6.1-H - Link Purpose 2.6.1.9 6.1-I - Information and Relationships 2.6.1.10 6.1-J - Focus Cursor (Web) 2.6.1.11 6.1-K - User Interface Components 2.6.1.12 6.1-L - Consistent Identification 2.6.1.13 6.1-M - Pausing 2.6.1.14 6.1-N - Reading Order 2.6.2 [6.2] If a Content Format 2.6.2.1 6.2-A - Non-text Objects 2.6.2.2 6.2-B - Multimedia (Format) 2.6.2.3 6.2-C - Reading Order 2.6.2.4 6.2-D - Table Headers 2.6.2.5 6.2-E - Complex Table Headers 2.6.2.6 6.2-F - Interactive Elements 2.6.2.7 6.2-G - Links 2.6.2.8 6.2-H - Embedded Comments 2.6.2.9 6.2-I - Images of Text 2.6.2.10 6.2-J - Dynamic Information 2.6.3 [6.3] If Audio and/or Video Content 2.6.3.1 6.3-A - Synchronized Alternatives 2.6.3.2 6.3-B - Captions and Transcripts 2.6.3.3 6.3-C - Video Description and Full Text Equivalents 2.6.3.4 6.3-D - Open or Closed Captions/Descriptions 2.6.3.5 6.3-E - Interactive Elements 2.6.4 [6.4] Additional requirements for Web Content Authoring Tools 2.7 7. Information, Documentation and Support 2.7.1 [7.1] Product Documentation and Help 2.7.1.1 7.1-A - Accessible Documentation and Features 2.7.1.2 7.1-B - Keyboard Shortcuts 2.7.1.3 7.1-C - Advisory Notes 2.7.2 [7.2] Support and E&IT related services 2.7.2.1 7.2-A - Support Services 2.7.2.2 7.2-B - Advisory Notes 3 Provisions removed or combined in this draft

Subpart A

• Current draft of Subpart A

Technical Provisions

1. Requirements for All Product and Services

Discuss or propose edits to the provisions in this section - Includes suggestion for editorial change to wording of these provisions.

[1.1] Functional Performance Criteria

Discussion: Provisions in this version change "full access" to "comparable access". Updates also provide for: comparable access required for direct use or via AT, and that access to functions might be mixed (direct & AT).

1.1-A - Without Vision

At least one mode must be provided that allows comparable access to product without using vision, directly or via AT.

• Source: {508}1194.31(a) and {255}1193.31
• Subcommittee: General Interface Accessibility
• Impact: No impact. Text clarified which would cause minor decrease in implementation costs.
• External Reference:
• Testability
• Metadata
  • Disabilities: Blindness, Deaf-Blindness, Other combined hearing-vision loss
  • User Activities: All
  • Product Characteristics: All
  • Product Types: All

1.1-B - With Limited Vision

At least one mode must be provided that allows comparable access to product without requiring visual acuity greater than 20/70. This mode must allow audio and enlarged text output to work together or independently, directly or via AT.

• Source: {508}1194.31(b) and {255}1193.41(b)
• Subcommittee: General Interface Accessibility
• Impact: No impact. Text clarified which would cause minor decrease in implementation costs.
• External Reference:
• Testability
• Metadata
  • Disabilities: Low vision, Other combined hearing-vision loss
  • User Activities: All
  • Product Characteristics: All
  • Product Types: All

1.1-C - With Color Vision Deficits

At least one mode must be provided that allows comparable access to product with color vision deficits.

• Source: {508}1194.31(a) and {255}1193.31
• Subcommittee: General Interface Accessibility
• Impact:
• External Reference:
• Testability
• Metadata
  • Disabilities: Color deficiency/Colorblindness
  • User Activities: All
  • Product Characteristics: All
  • Product Types: All

1.1-D - Without Hearing

At least one mode must be provided that allows comparable access to product without using hearing, directly or via AT.

• Source: {508}1194.31(c) and {255}1193.41(d)
• Subcommittee: General Interface Accessibility
• Impact:
• External Reference:
• Testability
• Metadata
  • Disabilities: Deafness, Hard of Hearing
  • User Activities: All
  • Product Characteristics: All
  • Product Types: All

1.1-E - With Limited Hearing

Where audio information is important for the use of a product, at least one mode must be provided that allows comparable access to product with enhanced audio, directly or via AT.

• Source: {508}1194.31(d) and {255}1193.43(e)
• Subcommittee: General Interface Accessibility
• Impact: No impact. Text clarified which would cause minor decrease in implementation costs.
• External Reference:
• Testability
• Metadata
  • Disabilities: Hard of hearing
  • User Activities: All
  • Product Characteristics: All
  • Product Types: All

1.1-F - Without Speech

At least one mode must be provided that allows comparable access to product without using speech, directly or via AT.

• Source: {508}1194.31(e) and {255}1193.41(h)
• Subcommittee: General Interface Accessibility
• Impact: No impact. Text clarified which would cause minor decrease in implementation costs
• External Reference:
• Testability
• Metadata
  • Disabilities: Speech
  • User Activities: All
  • Product Characteristics: All
  • Product Types: All

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

At least one mode must be provided that allows comparable access to product with limited reach and strength and without simultaneous actions, directly or via AT.

Discussion or Rationale: Adds AT option.

• Source: {255}1193.41(e)
• Subcommittee: General Interface Accessibility
• Impact: Should potentially reduce cost to companies by giving additional options - and increase productivity and employment by people with disabilities. So this would decrease costs and increase benefits.
• External Reference:
• Testability
• Metadata
  • Disabilities: Mobility, Dexterity
  • User Activities: All
  • Product Characteristics: All
  • Product Types: All

1.1-H - With No Reach or Touch

(provision text still being written)

Discussion: This provision is proposed to addess a concern that without a provision for individuals who are unable to reach and touch the product, a large group of people will be left out.

On the other side there is a concern that we don't have good techniques for built-in access to products that will address the range reach and touch disabilities. Voice, eye gaze, and head pointing might work, but might not work well enough in the field, or even meet the full range of disabilities being addressed with this provision.

A second concern is around closed products and the fact that if you can't attach AT then you have to rely on a built in solution. Some suggested that we should try to figure out how to create a safe way to have "closed products" be open to AT and thus solve the problem that way.

There is consensus on the issue, but we haven't yet figured out wording that we can reach consensus on.

The Self-Contained/Closed group suggests that we start this item with the words "Except for Closed products,..."

• Source: New
• Subcommittee: General Interface Accessibility
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities: Mobility, Dexterity
  • User Activities: All
  • Product Characteristics: All
  • Product Types: All

1.1-I - With Cognitive, Language or Learning Limitations

At least one mode must be provided that accommodates cognitive, language or learning impairments, directly or via AT.

Discussion or Rationale: This provision is here as a placeholder. The general group identified the following issues and questions in trying to move this forward.

• Source: {255}1193.41(i)
• Subcommittee: General Interface Accessibility
• Impact: This is one of the largest or the largest group of people with disabilities in the government. The cost in increased productivity can be great. Even simplification act has talked about using plain language. GSA reports that there is some guidance there to use plain language. The cost to learn to write plainly though is not known or other aspects of this. The benefits are believed to outweigh costs in the end however so a net decrease in cost is believed.
• External Reference:
• Testability
• Metadata
  • Disabilities: Cognitive language/learning
  • User Activities: All
  • Product Characteristics: All
  • Product Types: All

[1.2] General Technical Requirements

1.2-A - Closed Products

If any product functionality is closed, then individuals with disabilities must have comparable 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 provision [ 2.3.C-AUDIO CONNECTION ] is not considered assistive technology.

• Source: {508}1194.25(a) (was 3.5.A in May 30 draft)
• Subcommittee: Self Contained/Closed
• Impact:
• External Reference:
• Testability
• Metadata
  • Disabilities: All
  • User Activities: All
  • Product Characterisics: All
  • Product Types: All

1.2-B - Flashing

Products must not flash more than 3 times in any one second period, unless:

• Flashing created by software is under the general flash and red flash threshold.

• Flashing created by hardware is either:
  • greater than YYY candelas; or
  • greater than 20 candelas/sq meter and contiguously occupies more than a total of .006 steradians (25% of any 10 degree visual field).

Discussion: The hardware portion of this provision is still under development.

• Source: {508}1194.21(k) 1194.22(j) 1194.25(i), and {255}1193.43(f) (was 1.1.H in May 30 draft)
• Subcommittee: General Interface Accessibility
• Impact:
• External Reference:
• Testability
• Metadata
  • Disabilities: All
  • User Activities: All
  • Product Characteristics: All
  • Product Types: All

1.2-C - Biometric ID

When biometric forms of user identification or control are used, an alternative form of identification or activation must also be provided unless all people can use the biometric device.

Discussion or Rationale: This would allow biometric systems in the future that are based on circulatory system or other characteristics common to all people.

• Source: {508}1194.25(d), {508}1194.26(c) (was 2.1.D in the May 30 draft)
• Subcommittee: General Interface Accessibility
• Impact:
• External Reference:
• Testability
• Metadata
  • Disabilities: All (that could be caused by loss body part or function)
  • User Activities: All
  • Product Characteristics: Biometric ID
  • Product Types: All

1.2-D - Pass Through

Products that transmit or conduct information or communication must pass through cross-manufacturer, non-proprietary, industry-standard codes, translation protocols, formats or other information necessary to provide the information or communication in a usable format.

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 & real-time text) that are standard for that technology platform without distortion or error beyond 1%.

Discussion: for PSTN this would be TIA/EIA 825 Baudot.

Only phones that are passing text signals onto another device, e.g. TTY, would be subject to this provision.

• Source: {508}1194.23(j) (was 3.1.C in May 30 draft)
• Subcommittee: Telecommunications
• Impact:
• External Reference:
• Testability
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

1.2-E - Audio information

All information provided in audio form must also be available in visual form.

• Source: {255}1193.43(d) (new in July 6 draft)
• Subcommittee: Self Contained/Closed
• Impact:
• External Reference:
• Testability
• Metadata
  • Disabilities: Deaf, Hard of Hearing
  • User Activities: All
  • Product Characteristics: Sound output – speech, Sound output (other than speech)
  • Product Types: All

1.2-F - Visual Information

All information provided in visual form must also be available in audio form and, where appropriate, in tactile form.

• Source: {255}1193.43(a) (New in July 6 draft)
• Subcommittee: Self Contained/Closed
• Impact:
• External Reference:
• Testability
• Metadata
  • Disabilities: Blind, Low Vision
  • User Activities: All
  • Product Characteristics: Visual display with text, Visual display with graphics
  • Product Types: All

1.2-G - Color

Color coding must not be used as the only means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.

• Source: {508}1194.25(g) and 1194.21(i) (was 3.2.B in May 30 draft - also 6.1.A) (no changes since May 30 draft)
• Subcommittee: General Interface Accessiblity
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities: Color deficiency/Colorblindness
  • User Activities: All
  • Product Characteristics: Uses Color (on keys, labels, displays, indicators, anywhere etc.)
  • Product Types: All

1.2-H - Text size

All information provided in text must be a minimum of 3/16 inch (4.8 mm) high, based on the uppercase letter "I" or, where the display size is not part of the product, 14 pt type.

Discussion or Rationale: To match ADAAG - Characters

• Source: {255}1193.43(b) and {ADAAG}707.7.2 (new in July 6 draft)
• Subcommittee: Self Contained/Closed
• Impact:
• External Reference:
• Testability
• Metadata
  • Disabilities: Low vision
  • User Activities: All
  • Product Characteristics: Visual display with text
  • Product Types: All

1.2-I - Contrast

Note: Contrast is currently split out between software and hardware. If this approach is successful, then this placeholder provision will be deleted.

• Source: {508} 1194.26(b); {508} 1194.25(c)
• Subcommittee: Hardware

2. Provisions for Hardware Aspects of Products

Discuss or propose edits to the provisions in this section

[2.1] All Products with Hardware

2.1-A - Touch Operated

This provision has two proposals that are still under consideration.

Version 1 - If a product utilizes touch screens or touch-operated controls, an input method must be provided that complies with Mechanical Controls Section.

Version 2 - If a product utilizes touch screens or touch-operated controls, an equivalent means of input/interaction/control must be provided.

Discussion or Rationale: Need to finalize some language that addresses the intent of “redundancy” of controls beyond just requiring another set of mechanical controls.

There has been a good debate on this one relative to how this impacts products and users. The major differentiation is in the product usage model of closed versus open.

These are the mechanical control requirements.

The issue of touch controls has been discussed amongst the subcommittee. The challenge being the application of the original language and its requirement of redundant controls. Several points made include: What about touch controls that are replicated via SW (for example capacitve media buttons when media can also be controlled via SW)?

This language addresses the issues associated with touch-based controls (specifically biophysical) by requiring a redundant interaction method without assigning the control type. If mechanical controls are required, by default they would have to meet the proposed language for mechanical controls.

• Source: {508} 1194.26(b); {508} 1194.25(c)
• Subcommittee: Hardware
• Impact:
• External Reference:
• Testability
• Metadata
  • Disabilities: All disabilities
  • User Activities: Conversations, data analysis, document sharing and reviewing, media (audio/video) creation and editing.
  • Product Characterisics: Physical controls or connectors, touchscreen or touch sensitive buttons.
  • Product Types: Hardware, telephone, telephone system, audiovisual equipment, public information terminal, desktop computer system, portable computer system, copier, printer, scanner, other similar peripheral

2.1-B - Free-Standing

Products which are freestanding, non-portable, and intended to be used in one location and which have operable controls must comply with the following. The position of any operable control shall be determined with respect to a vertical plane, which is 48 inches in length, centered on the operable control, and at the maximum protrusion of the product within the 48 inch length on products which are freestanding, non-portable, and intended to be used in one location and which have operable controls.

Products which are freestanding, non-portable, and intended to be used in one location and which have operable controls must comply with the following. Where any operable control is 10 inches or less behind the reference plane, the height must be 54 inches maximum and 15 inches minimum above the floor.

Products which are freestanding, non-portable, and intended to be used in one location and which have operable controls must comply with the following, Where any operable control is more than 10 inches and not more than 24 inches behind the reference plane, the height must be 46 inches maximum and 15 inches minimum above the floor.

Products which are freestanding, non-portable, and intended to be used in one location and which have operable controls must comply with the following. Operable controls must not be more than 24 inches behind the reference plane.

EWG proposed rework: Freestanding, non-portable products intended to be used in one location must have any operable controls positioned within reach.

The allowed position of any operable control must be determined with respect to a vertical plane, which is 48 inches in length, centered on the operable control, and at the maximum protrusion of the product within the 48 inch length (see Figure 1 of this part).

• If an operable control is 10 inches or less behind the reference plane, the height must be 54 inches maximum and 15 inches minimum above the floor.

• If an operable control is more than 10 inches and not more than 24 inches behind the reference plane, the height must be 46 inches maximum and 15 inches minimum above the floor.

• Operable controls must not be more than 24 inches behind the reference plane (see Figure 2 of this part).

Discussion or Rationale: Point of discussion arose regarding the concept of "fixed" products such as ATMs. There is a consideration to change free-standing to "free-standing or built-in". Need clarification from access board as to correct term relative to "built-in".

These requirements are based on ADAAG requirements and have been left at the same level as the current ADAAG; not the draft as was originally proposed. Hence the change back to a max height of 54 inches.

• Source: {508} 1194.25 j(1-4)
• Subcommittee: Hardware
• Impact:
• External Reference:
• Testability
• Metadata
  • Disabilities: All disabilities
  • User Activities: Conversations, data analysis, document sharing and reviewing, media (audio/video) creation and editing.
  • Product Characterisics: Physical controls or connectors, touchscreen or touch sensitive buttons.
  • Product Types: Hardware, telephone, telephone system, audiovisual equipment, public information terminal, desktop computer system, portable computer system, copier, printer, scanner, other similar peripheral

2.1-C - Standard Connection

Where user interface connection capabilities are provided, whether wired or wireless, at least one connection must comply with publicly available industry standards and all of the product functionality that is controllable by the user through the non-standard connection(s) must be controllable by the user via the standard connection using industry standard protocols for that type of input or output.

EWG suggested edits for clarity If a product has user interface connection capabilities, whether wired or wireless, at least one connection must comply with publicly available industry standards.

If users can control any product functionality through a non-standard connection, they must also be able to control that functionality through a standard connection using industry standard protocols for that type of input or output.

Discussion or Rationale: There has been a large degree of conversation regarding this provision. The original language was from the Desktops and Portable section. In this revision, it has been applied across all projects. Attempts were made to create language that did not stifle innovation and allowed for proprietary connections. Care needs to be taken in any "guidelines" to ensure that the intent of this provision, to provided a means of connection is clear.

A second debate regarding who is responsible for "adapters" was not resolved.

There has been discussion on the listserv relative to how this language addresses the responsibility of driver development, especially with KIOSK (closed) system interaction.

The context of the language relative to Hardware is that it is to ensure that the "the connection" can be made from the "physical" perspective.

One interpretation from the listserv of the language is:

• IF a company provides I/O functionality on a proprietary connector
• THEN it must provide same functionality on a std connector.
• This provision does not require that any AT drivers be provided.
• It doesn't require that any standard connector be provided. ( a wireless connection would suffice if standard)
• It doesn't require that any standard connection be provided UNLESS there are I/O functions on a proprietary connector.
• IF there is an I/O function on a proprietary connection, it DOES require a driver that provides I/O function on the standard connection.

• Source: {508} 1194.26(d)
• Subcommittee: Hardware
• Impact:
• External Reference:
• Testability
• Metadata
  • Disabilities: All disabilities
  • User Activities: Conversations, data analysis, document sharing and reviewing, media (audio/video) creation and editing.
  • Product Characterisics: Physical controls or connectors, touchscreen or touch sensitive buttons.
  • Product Types: Hardware, telephone, telephone system, audiovisual equipment, public information terminal, desktop computer system, portable computer system, copier, printer, scanner, other simliar peripheral

2.1-D - Contrast for displays

This is a placeholder for a provision still being written.

Discussion: LCD capabilities – define contrast

• Source: {508} 1194.26(b); {508} 1194.25(c)
• Subcommittee: Hardware

2.1-E - Contrast for labels

This is a placeholder for a provision still being written.

Discussion: Define contrast and set limits relative to contrast is necessary if it is the only means of conveying intent

• Source: {508} 1194.26(b); {508} 1194.25(c)
• Subcommittee: Hardware

[2.2] If the Product has Physical Controls

2.2-A - Mechanical Controls

All mechanically operated controls and keys:

1. Must be tactilely discernible without activating the controls or keys.
2. Must be operable with one hand and must not require pinching, twisting of the wrist, tight grasping, or simultaneous actions. The force required to activate controls and keys must be 5 lbs. (22.2 N) maximum.
3. If key repeat is supported, the delay before repeat must be adjustable to at least 2 seconds. The key repeat rate must be adjustable to 2 seconds per character.
4. The status of all locking or toggle controls or keys must be visually discernible, and discernible either through touch or sound.

Discussion or Rationale: Changes in this section were limited to the addition of the "Simultaneous controls" to the operability requirements and reordering requirements to align the adjective "tight" with "grasping".

• Source: {508} 1194.26(a); 1194.23(k)
• Subcommittee: Hardware
• Impact:
• External Reference:
• Testability
• Metadata
  • Disabilities: All disabilities
  • User Activities: Conversations, data analysis, document sharing and reviewing, media (audio/video) creation and editing.
  • Product Characterisics: Physical controls or connectors, touchscreen or touch sensitive buttons, color
  • Product Types: Hardware, telephone, telephone system, audiovisual equipment, public information terminal, desktop computer system, portable computer system, copier, printer, scanner, other simliar peripherals.

[2.3] If the product has Audio Output

2.3-A - Magnetic Coupling

Where a telecommunications product delivers output by an audio transducer which is normally held up to the ear, a means for effective magnetic wireless coupling to hearing technologies must be provided that allows the user of such technologies to effectively utilize the telecommunication product. This guideline shall apply to wireless, wireline, cordless and Bluetooth applications.

Discussion: TIA alternate for last sentence:

"This guideline shall apply to wireline and wireless technologies."

EWG proposed edit for clarity Telecommunications products that deliver output with an audio transducer, which is normally held up to the ear, must provide a means for effective magnetic wireless coupling to hearing technologies that allows a user to effectively utilize the product. This guideline applies to wireless, wireline, cordless and Bluetooth applications. (or TIA alternate)

• Source: {508}1194.23(h)
• Subcommittee: Telecommunications - may be overridden by Hardware
• Impact:
• External Reference:
• Testability
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

2.3-B - Interference with Hearing Device

Interference to hearing technologies (including hearing aids, cochlear implants, and assistive listening devices) must be reduced to the lowest possible level that allows a user of hearing technologies to utilize the telecommunications product.

Discussion: This comes from Telecom SC and may be overriden by Hardware SC

• Source: {508}1194.23(i) (no changes)
• Subcommittee: Telecommunications
• Impact:
• External Reference:
• Testability
• Metadata
  • Disabilities: All
  • User Activities: All
  • Product Characteristics: All
  • Product Types: All

2.3-C - Audio Connection

When products provide auditory output, the audio signal must be provided at a standard signal level through an industry standard connector (connection???) that will allow for private listening.

Discussion or Rationale: There is a broader issue here relative to open/closed or public/private... Need more freedoms at workstation/private level.

When products provide auditory output, the audio signal must be provided at a standard signal level through an industry standard connector that will allow for private listening. The product must provide the ability to interrupt, pause, and restart the audio at anytime.

Software or Firmware may be needed to address the "The product must provide the ability to interrupt, pause, and restart the audio at anytime."

• Source: {508} 1194.23(e); {255} 1193.51(b) & (g) (was 2.3.F in May 30 draft)
• Subcommittee: Hardware
• Impact:
• External Reference:
• Testability
• Metadata
  • Disabilities: All disabilities
  • User Activities: Conversations, data analysis, document sharing and reviewing, media (audio/video) creation and editing.
  • Product Characterisics: Physical controls or connectors, touchscreen or touch sensitive buttons.
  • Product Types: Hardware, telephone, telephone system, audiovisual equipment, public information terminal, desktop computer system, portable computer system, copier, printer, scanner, other simliar peripherals.

2.3-D - Volume

All products with audio output must allow users to adjust the audio level. At peak volume output they must have less than 12 dB symmetrical clipping or a total harmonic distortion (THD) less than XXX dB

• For products used in a public place, the maximum volume level must be at least 80 dB SPL RMS

• For products that will not be used in public places or where the volume of the public place is controlled to be under 50 dBA SPL RMS, the maximum volume level must be at least 65 dB SPL RMS.

Discussion or rationale: Final level for THD still to be determined

• Source: {508}1194.25(f) (was 2.3.C: Volume - Public Area in May 30 draft)
• Subcommittee: Self Contained/Closed
• Impact:
• External Reference:
• Testability
• Metadata
  • Disabilities: Hard of hearing
  • User Activities: All
  • Product Characteristics: Sound output – speech, Sound output (other than speech)
  • Product Types: All

2.3-E - Volume (Gain)

There are 2 proposed versions, not settled within Telecom SC:

Version 1: For incoming voice signals:

Line powered telecommunications products must comply with FCC regulation §68.317 for volume control,

OR

1. Telecommunications products must provide a built in gain adjustable up to a minimum of 20 dB. For incremental volume control, at least one intermediate step of 12 dB of gain must be provided.
2. All other telecommunications products or systems that provide a function allowing voice communication must provide a gain adjustable up to a minimum of 20? dB with incremental volume control of at least one intermediate step of 12 dB of gain provided as measured and documented in accordance with the provisions of the FCC regulation §68.317 for volume control.

Version 2: (NEW TIA PROPOSAL as amended by Working Group on 6/25 conference call)

1. Analog line-powered telecommunications products and wireline all cordless telephones (wireline or VoIP) must comply with FCC regulation §68.317 for volume control
2. All cellular phones - (language pending outcome of ATIS study group 11 work).
3. All other telecommunications products or systems that provide a function allowing voice communication must provide a gain adjustable from the normal unamplified level to at least 20 dB above the normal unamplified level as measured in accordance with the provisions of the FCC regulation §68.317 for volume control. The volume at the normal unamplified level setting must also meet the requirement in FCC regulation 68.317.

• Source: {508}1194.23(f) (was 2.3.D: Volume -General in May 30 draft)
• Subcommittee: Telecommunications
• Impact:
• External Reference:
• Testability
• Metadata
  • Disabilities: Hard of hearing
  • User Activities: Real-time voice conversation, IVR
  • Product Characteristics: Audio output
  • Product Types: Telephones, IVRs

2.3-F - Volume Reset

• If the product allows a user to adjust the receive volume to a level greater than 18 dB above normal unamplified level, a function must be provided to automatically reset the volume to a level not greater than 18 dB above normal unamplified level after every use. A manual override switch may be provided to prevent the automatic reset, subject to the conditions specified in FCC Memorandum Opinion and Order DA 01-578.

Discussion: this is from Telecom; Hardware SC may override.

• Source: {508{1194.23(g) (was 2.3.E in May 30 draft)
• Subcommittee: Telecommunications
• Impact:
• External Reference:
• Testability
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

3. Software & General Behavior Provisions

Discuss or propose edits to the provisions in this section

[3.1] All products

Requirements that apply to all products: equivalence for visual information (active and passive), consistent use of images, no interference with access features, time/repeat adjustments, flashing, etc.

3.1-A - Disruption of Access Features

Applications must not, except by specific user request, disrupt the features of the platform that have an accessibility usage in the platform developer documentation.

Discussion or Rationale

• "other products" is too broad. Application vendors can't be expected to avoid interfering with an infinite set of other products.
• "accessibility features" is too narrow. Some features that have an accessibility usage may not be labeled as such.
• Should only be such features that have a documented accessibility usage but needs to be scoped to the developer documentation provided by the platform, not that which some random third party might provide.

• Source: {508}1194.21(b)
• Subcommittee: Web and Software
• Impact: No impact. Text clarified which would cause minor change in implementation costs.
• External Reference:
• Testability:
• Metadata
  • Disabilities: All
  • User Activities: Data analysis (spreadsheet, database); Document creation and editing (text, graphics, layout); Document sharing and reviewing; Media (audio/video) creation and editing; Publishing and viewing; Training/learning; Work/project management
  • Product Characterisics: All
  • Product Types: Web Content; Telephone only device; Software (installed or through browser); Copiers; AudioVisual equipment (Video Monitor, TV, Projector); KIOSKS; Network Interface to devices; Desktop Computer Systems; Portable Computers

3.1-B - Timing

For each time limit that is set by the software, at least one of the following is true:

• Turn off: the user is allowed to turn off the time limit before encountering it; or
• Adjust: the user is allowed to adjust the time limit before encountering it over a wide range that is at least ten times the length of the default setting; or
• Extend: the user is warned before time expires and given at least 20 seconds to extend the time limit with a simple action (for example, "hit any key"), and the user is allowed to extend the time limit at least ten times; or
• Real-time Exception: the time limit is a required part of a real-time event (for example, an auction), and no alternative to the time limit is possible; or
• Essential Exception: the time limit is part of an activity where timing is essential and time limits can not be extended further without invalidating the activity.
  • TBD: In Adjust, issue with "before encountering"
  • TBD: In Essential Exception, still discussing the suggestion to add something about data integrity.

Discussion or Rationale: "Sufficient time" is not objectively testable. Also, there are other acceptable strategies for addressing the needs of users who need more time. The recommended change is harmonized with both the ISO Software Accessibility standard and WCAG 2.0.

• Source: {508}1194.25(b); was 3.1.D in May 30 draft.
• Subcommittee: Web and Software
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities: Blind; Low Vision; Deafness; Hard of Hearing; Physical; Cognitive Language, Learning
  • User Activities: All
  • Product Characterisics: Has Time limits of any type (timeout, double-clicks, keyrepeat); Involves Web Content or Applications
  • Product Types: Web Content; Telephone only device; IVR (Voicemail, Autoattendant, Audiotext); Software (installed or through browser); Copiers; AudioVisual equipment (Video Monitor, TV, Projector); KIOSKS; Network Interface to devices; Desktop Computer Systems; Portable Computer Systems

3.1-C - Software as platform and application

Software that is both a 'platform', and an 'application' running on another platform must:

1. expose the underlying platform's color, contrast, and other individual display settings to applications running within its platform, so that these applications can meet the User Preferences provision.
2. define, expose, and translate accessibility service information between applications running within its platform and the underlying platform - so that those applications can meet the AT Interoperability provision.
3. provide mechanisms for:
   • moving the keyboard focus into and out of an application, and
   • addressing central conflicts between keyboard mnemonics in the application and the host platform.

Discussion or Rationale: Still to be done is to look at ISO 9241-171 provisions around platform requirements to ensure no harmonization issues.

• Source: New
• Subcommittee: Web and Software
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities: All
  • User Activities: All
  • Product Characterisics: All
  • Product Types: Software (installed or through browser); Network Interface to devices; Desktop Computer Systems; Portable Computer Systems

[3.2] If the Product has Visual Output or Display

3.2-A - Contrast

When a product permits a user to adjust color and contrast settings, at least one color selection capable of producing a minimum luminosity contrast ratio of 7:1 must be provided.

• TBD: Add a requirement addressing default contrast.
• TBD: Add something to address unavailable elements.

Discussion or Rationale: The existing provision in Section 508 is ineffective as all software passes it. If software doesn't permit the user to adjust the settings, it passes. If it does permit adjustment, it also passes because "a variety of color selections capable of producing a range of contrast levels shall be provided." is too subjective to determine failure. The recommended provision is harmonized with WCAG 2.0.

• Source: {508}1194.21(j)
• Subcommittee: Web and Software
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities: Low Vision
  • User Activities: All
  • Product Characterisics: Has Visual Display with Text; Has Visual Display with Graphics; Uses Color (on keys, labels, displays, indicators, anywhere etc.); Product Allows User to Set Preferences
  • Product Types: Web Content; Software (installed or through browser); Network Interface to devices; Desktop Computer Systems; Portable Computer Systems

3.2-B - Animation

When an informational animation is displayed that will last for more than three seconds, software must give the user a means to pause and restart the animation. When a decorative animation is displayed that will last for more than three seconds, software must give the user a means to stop the animation.

Discussion or Rationale: If animations can be implemented such that they meet the requirements of the standard, static alternatives are not needed. If they can't meet the requirements of the standard, static alternatives can be provided as equivalent facilitation. Even for accessible animations though, users need a way to pause and restart them because they might not be able to take in the information as fast as it is being displayed. Decorative animations don't need to be restarted because they are not conveying information. Stopping decorative animations is sufficient for users who are distracted by them and can't focus on other features of the application.

• Source: {508}1194.21(h) and {255}1193.43(c), was 3.2.D in May 30 draft, no change since May 30 draft
• Subcommittee: Web and Software
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities: Blindness; Low Vision; Cognitive Language, Learning
  • User Activities: All
  • Product Characteristics: Has Visual Display with Text; Has Visual Display with Graphics
  • Product Types: Web Content; Media content (audio/video); Telephone only device; Software (installed or through browser); Copiers; AudioVisual equipment (Video Monitor, TV, Projector); KIOSKS; Network Interface to devices; Desktop Computer Systems; Portable Computer Systems

3.2-C - User Preferences

Applications must utilize user selected contrast and color selections and other individual display attributes when the availability of those selections are developed and documented according to industry standards.

Discussion or Rationale: Subcommittee is still working on this one to define "other individual display attributes" and address the issue of "documented according to industry standards. "Other display attributes" is vague. Need to clarify.

EWG suggested rewording When a function, developed and documented according to industry standards, makes user preferences for contrast, color and other display attributes available, applications must use those selections.

• Source: {508}1194.21(g), (was 3.2.E "Display Attributes" in May 30 draft)
• Subcommittee: Web and Software
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities: Low Vision
  • User Activities: All
  • Product Characterisics: Has Visual Display with Text; Has Visual Display with Graphics
  • Product Types: Web Content; Software (installed or through browser); AudioVisual equipment (Video Monitor, TV, Projector); KIOSKS; Network Interface to devices; Desktop Computer Systems; Portable Computer Systems

[3.3] If the Product has Standard Keyboard or Keyboard Interface

3.3-A - Keyboard

All functionality of the product operable through the user interface is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints.

• Note: This exception relates to the underlying function, not the input technique. For example, if using handwriting to enter text, the input technique (handwriting) requires path dependent input but the underlying function (text input) does not.
• Note: This does not forbid and should not discourage providing mouse input or other input methods in addition to keyboard operation.

Discussion or Rationale

• The phrase "textually discernible" is an issue because it is interpreted differently by different people.
• Harmonized with WCAG 2.0 and ISO 9241 part 171.

• Source: {508}1194.21(a)
• Subcommittee: Web and Software
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities: Blindness, Physical
  • User Activities: All
  • Product Characterisics: Uses Keyboard (Physical - touch typeable)
  • Product Types: Web Content; Telephone only device; IVR (Voicemail, Autoattendant, Audiotext); Software (installed or through browser); Copiers; AudioVisual equipment (Video Monitor, TV, Projector); KIOSKS; Network Interface to devices; Desktop Computer Systems

[3.4] If Software runs on platform with Operating System with AT Support

3.4-A - AT Interoperability

Software that provides user interface objects must either use the accessibility services provided by platform software or other services to cooperate with assistive technologies when such services allow the software to meet the accessibility provisions of this standard. Using such services, software must:

• provide assistive technology with object information including but not limited to:
  • role, state(s), boundary, name, and description
  • any table row & column, and row & column headers (if the object is in a table)
  • current value and any minimum or maximum (if the object represents one of a range of values)
  • relationship this object has as a label for another, or being labelled by another
  • parent or containing element, and any children objects
  • text contents, text attributes, and the boundary of text rendered to the screen
• provide assistive technology with a list of actions that can be executed on an object and allow assistive technology to programmatically execute any of those actions;
• allow assistive technology to track and modify focus, text insertion point, and selection attributes of user interface objects;
• provide assistive technology with notification of events relevant to user interactions, including but not limited to changes in the object's state(s), value, name, description, or boundary

Note: This provision applies to forms in the software.

Discussion or Rationale: The current provisions in Section 508 that address interoperability with AT are 1194.21(c), 1194.21(d) and 1194.21(f). "Sufficient information" in 1194.21(d) is not testable and the three requirements together are insufficient to meet the needs of assistive technology. The proposed provision is much more comprehensive. It details what type of object information must be provided and includes event notification which is critical for assistive technology interoperability. It is also harmonized with ISO 9241 part 171 and is supported by the major accessibility APIs on desktop operating systems. The phrase beginning "or other services to cooperate with assistive technologies" is provided to allow for other methods of cooperating with assistive technology where platforms and APIs are insufficiently mature to support the necessary functions.

• Source: {508}1194.21(d)
• Subcommittee: Web and Software
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities: Blindness
  • User Activities: All
  • Product Characterisics: Has OS that supports installed AT and user can install
  • Product Types: Telephone only device; Software (installed or through browser); Network Interface to devices; Desktop Computer Systems; Portable Computer Systems

3.4-B - Bitmap Icons

When bitmap images are used to identify controls, status indicators, or other programmatic elements, the meaning assigned to those images must be consistent throughout an application's performance.

Discussion or Rationale: No change recommended to this existing Section 508 provision. Although it is not needed if the AT interoperability provision is met, assistive technology vendors strongly advocated to keep this requirement to support their workarounds.

EWG sugggested rewording An application must assign a consistent meaning to any bitmap images used to identify controls, status indicators, or other programmatic elements.

• Source: {508}1194.21(e), no change
• Subcommittee: Web and Software
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities: All
  • User Activities: All
  • Product Characterisics: Has Visual Display with Graphics; Involves Web Content or Applications
  • Product Types: Web Content; Telephone only device; Software (installed or through browser); Copiers; KIOSKS; Network Interface to devices; Desktop Computer Systems; Portable Computer Systems

3.4-C - Focus Indicator

Software must provide a visual indication of which user interface object currently has the keyboard focus. If the object is a text entry field, a visual indication of the text insertion point must be provided, and is sufficient.

• TBD: TEITAC action item for the visual indication to be well-defined or highly visible. Looking at ISO 9241-171 for testable criteria and harmonization.

Discussion or Rationale: The requirement that the keyboard focus be programmatically exposed is covered by the AT interoperability provision. The proposed provision clarifies that for a text input field, a text input cursor or caret is sufficient and that an outline cursor is not also needed for text input fields.

• Source: {508}1194.21(c)
• Subcommittee: Web and Software
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities: Blindness, Low Vision
  • User Activities: All
  • Product Characterisics: Has Visual Display with Text; Has Visual Display with Graphics
  • Product Types: Telephone only device; Software (installed or through browser); Network Interface to devices; Desktop Computer Systems; Portable Computer Systems

4. Additional Provisions for Audio-Visual Content or Players/Displays

Discuss or propose edits to the provisions in this section

4-A - Caption Playback

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

Equipment of this type…	Uses this standard…	To provide these functions…
Analog television displays that measure 13 inches or more diagonally Computer equipment that includes analog television receiver or display circuitry	CEA 608	Receive, decode and display signals from broadcast cable satellite videotape DVD
Wide-screen (16:9) digital television (DTV) displays measuring at least 7.8 inches vertically DTV sets with conventional (4:3) displays measuring at least 13 inches diagonally Stand-alone DTV tuners, whether or not they are marketed with display screens Computer equipment that includes DTV receiver or display circuitry	CEA 708	Receive, decode and display signals from broadcast cable satellite videotape DVD
HD-DVD, BluRay and other digital video source devices	CEA 708	Pass data, when available, to the caption decoding circuitry of DTV displays OR Decode data, when available, and pass an open-captioned signal to the DTV display

• Source: {508}1194.24(a)
• Subcommittee: Audio-Video
• Impact:
• External Reference:
• Testability
• Metadata
  • Disabilities: Blindness, low vision, color deficiency/colorblindness, other combined hearing/vision loss, cognitive language/learning.
  • User Activities: Media (audio/video) creation and editing, training/learning.
  • Product Characterisics: Visual display with text, Visual display with graphics,Does not allow user-installable at (closed by policy), User-installable at not feasible (underlying technology limit), Product has hardware component (not pure software)?, Any visual display or visual output (printed etc)? Any ability to play or display audio-visual material?
  • Product Types: Hardware, AudioVisual equipment (Video Monitor, TV, Projector), Desktop computer system, Portable computer system (laptop, PDA, tablet), Media content (audio/video).

4-B - Supplemental Audio Playback

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

• Analog-signal tuners must be equipped with secondary audio program playback circuitry
• Digital-signal tuners must be equipped with ancillary audio program playback circuitry

Discussion or Rationale Edited for clarity

• Source: {508}1194.24(b)
• Subcommittee: Audio Video
• Impact:
• External Reference:
• Testability
• Metadata
  • Disabilities: Blindness, low vision, color deficiency/colorblindness, other combined hearing/vision loss, cognitive language/learning.
  • User Activities: Conversation, media (audio/video) creation and editing, training/learning.
  • Product Characteristics: Visual display with text, Visual display with graphics,Does not allow user-installable AT (closed by policy), User-installable at not feasible (underlying technology limit), Product has hardware component (not pure software)?, Any visual display or visual output (printed etc)? Any ability to play or display audio-visual material?
  • Product Types: Hardware, AudioVisual equipment (Video Monitor, TV, Projector), Desktop computer system, Portable computer system (laptop, PDA, tablet), Media content (audio/video).

4-C - Play Control (Audio)

The product must provide the ability to interrupt, pause, and restart the audio at anytime.

• Source: {508}1194.25(e) - Second sentence (no changes since May 30 draft)
• Subcommittee: Web/Software
• Impact:
• External Reference:
• Testability
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

5. Additional Provisions for Real-time Voice Conversation Functionality

Discuss or propose edits to the provisions in this section

5-A - Accessibility Configuration

In complying with this subpart, each agency must:

1. Activate accessibility features and configure telecommunications products so that they are accessible to and usable by people with disabilities.
2. Ensure access to and use of all telecommunications relay services as approved by the Federal Communications Commission pursuant to its authority under 47 U.S.C. Sec. 225, for incoming and outgoing calls, as needed to achieve functionally equivalent communication access by people with disabilities.

Discussion: The first provision addresses agency requirements, not procurement. It may need to be moved to another section (Recommendations for Agency Requirements) and/or made into a general requirement applying to all products and services.

• Source: New
• Subcommittee: Telecommunications
• Impact:
• External Reference:
• Testability
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characterisics:
  • Product Types:

5-B - Real-time Text Reliability

There are 2 proposed versions, not settled within Telecom SC:

Version 1: Systems that support real-time voice communication must support at least one standard (for the system) means for real time text communication that is supported by all terminal, router, gateway and other products on that system, and that meets the following requirements:

1. Provides transmission of characters with less than 1 second delay from entry;
2. Provides transmission with less than 1% Total Character Error Rate under peak non-crisis network traffic;
3. Support alternating speech and text in both directions on non-packet based systems and simultaneously speech and text in both directions on packet based systems.
4. IP systems cannot rely upon audio channels for transmission of real-time text. {can delete 5 if interop provision and peak traffic clause are retained.

Version 2 (Trace Alternate Proposal): Real-time voice communication systems must support at least one means for real-time text communication that:

1. Is standard for the system and supported by all terminal, router, gateway and other products on that system, and
2. Provides transmission of characters with less than 1 second delay from entry; and
3. Provides transmission with less than 1% Total Character Error Rate under peak non-crisis network traffic; and
4. Supports intermixing of speech and text in both directions (simultaneously if and only if IP based), and
5. If it is an IP based system, does not rely upon audio signals for transmission of real-time text.

Discussion: A system may be standard or proprietary but it includes all products that use that system. This version allows use of audio channel for text data

• Source: New
• Subcommittee: Telecommunications
• Impact:
• External Reference:
• Testability
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

5-C - Real-Time Text Interoperability

There are 3 proposed provisions, not settled within Telecom SC:

Version 1 Products that provide real-time text conversation functionality must do so in the standard format that is supported for that transport medium.

1. Products that connect directly to the PSTN must support TIA 825 Baudot where they interface to the PSTN;
2. Products that connect directly to the Internet via SIP must support RFC 4103 where they interface to the Internet via SIP;
3. All other Products (including PBX, cellular, and peer to peer Internet phones) that do not connect to PSTN or use SIP over the Internet must support the standard real-time text format for that system. These systems only need to support TIA 825 Baudot at the juncture to the PSTN (if any) and only need to support RFC 4103 at the point where they connect to public SIP systems (if any).

Version 2 (Trace Proposal); Products that provide real-time text conversation functionality must

1. provide real-time text functionality in the standard real-time text format that is specified for that system
2. use TIA 825 Baudot where they interface to the PSTN
3. support both RFC-4103 and RFC-4351 where they interface to other VoIP systems or to the Internet via SIP

Note: Closed systems, where the real-time text format of all the components is controlled and identical, may use any real-time text format that meets provisions for (Real-time Text Reliability) and (Real-time Text Interoperability).

Version 3 (TIA Proposal): Products that provide real-time text conversation functionality must do so in the standard format that is supported for that transport medium and provide level of service that does not exceed 1% Total Character Error Rate under normal network conditions.

1. Products that connect directly to the PSTN, including packet based systems, must support TIA 825 Baudot where they interface to the PSTN.
2. Packet based systems must support real-time text communication between text capable terminals.

• Source: New (was 5.E in May 30 draft)
• Subcommittee: Telecommunications
• Impact:
• External Reference:
• Testability
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

5-D - VOIP Terminals and Real-Time Text

The user interface of IP terminals that provide real-time voice communication must meet the following provisions:

1. IP terminal user interfaces that have a multiline display must display any real-time text that is received in the standard format for that platform.
2. IP terminal user interfaces that have the ability to generate text must allow sending real-time text in the standard real-time text format for that platform.
3. Such real time text send and receive capabilities must be synchronized with voice as part of the same communication session.

• Source: New
• Subcommittee: Telecommunications
• Impact:
• External Reference:
• Testability
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

5-E - Voice Terminals without Real-Time Text

There are 3 proposed provisions, not settled within Telecom SC:

Version 1: Telecommunications terminals and other terminals capable of providing real-time voice communications which do not themselves provide TTY or other real-time text conversation functionality must comply with the following:

1. All analog and TDM-digital wired terminals must support the connection of a TTY in the same location and with the permissions for use as the telephone. This must be accomplished by:
   • Providing an RJ-11 jack on the telephone, or
   • For an analog telephone, by the use of a Y-adapter that allows both the analog telephone and the TTY to be plugged into the same line outlet, or
   • Having built-in capability to support an RJ11 module that can provide a connection point for TTYs.
2. Other types of terminals covered by this section must support the connection of real-time text capable devices in conjunction with the voice call capability in the same location and the same permissions for use as the terminal.
3. These products must either:
   • Be capable of allowing simultaneous speech and text conversation without interference or
   • Its microphone must be capable of being turned on and off to allow the user to intermix speech with text use.

Version 2 (NEW TIA PROPOSAL): Telecommunications products or systems [terminals and other terminals capable of providing real-time voice communications which do not themselves] provide TTY or other real-time text conversation functionality must comply with the following:

1. All analog and TDM-digital wired terminals must support the connection of a TTY in the same location and with the permissions for use as the telephone. This may be accomplished by:
   • Providing an RJ-11 jack on the telephone, or
   • For an analog telephone, by the use of a Y-adapter that allows both the analog telephone and the TTY to be plugged into the same line outlet, or
   • By having built-in capability to support an RJ11 module that can provide a connection point for TTYs.
2. Packet based telecommunication systems must support the addition of terminals and terminal peripheral equipment that support real-time text functionality in conjunction with the voice call functionality in the same location and with the same permissions for use as the terminal.
3. These products must either:
   • Be capable of allowing simultaneous speech and text conversation without interference, or
   • Its microphone must be capable of being turned on and off to allow the user to intermix speech with text use.

Version 3 (TRACE PROPOSAL): Terminals capable of providing real-time voice communications that do not themselves provide TTY or other real-time text conversation functionality shall comply with the following:

1. All analog and TDM-digital wired terminals shall support the connection of a TTY in the same location and with the permissions for use as the telephone. This may must be accomplished by providing an RJ-11 jack on the telephone, or, in the case of an analog telephone, by the use of a Y-adapter that allows both the analog telephone and the TTY to be plugged into the same line outlet, or by having built in capability to support an RJ11 module that can provide a connection point for TTYs;
2. Packet based telecommunication All other real-time voice communication systems shall support the ad hoc addition of terminals and terminal peripheral equipment that support real-time text functionality in conjunction with the voice call functionality in the same location andwith the same permissions for use as their voice terminal.
3. Shall 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.

• Source: {508}1194.23(a)
• Subcommittee: Telecommunications
• Impact:
• External Reference:
• Testability
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

5-F - IVR etc.

There are 2 proposed provisions, not settled within Telecom SC:

Version 1: Voice mail, messaging, auto-attendant, and interactive voice response telecommunications systems must make information available and be capable of recording Baudot TTY signals.

These systems must:

• Use the ITU-T G.711 standard for encoding and storing audio information. If an audio encoder other than G711 is employed, the vendor must provide evidence that the intelligibility is equal to or better than that provided by G.711;
• Provide full player controls that allow users to pause, rewind, slow down and repeat all messages and prompts, and adjust volume;
• Provide prompts (either as provided by the vendor or by the user) without any background sounds that would reduce intelligibility.

2. In using such systems agencies must:

• Preferably present the system user with 4, but no more than 6, menu choices at one time unless the user requests to hear more options.
• Provide easy to understand and act upon menu items and other navigational messages.

Version 2: Voice mail, messaging, auto-attendant, and interactive voice response telecommunications systems must:

1. All functions that are accessible to voice users must also be directly accessible to users of real-time text.
2. Use the ITU-T G.711 standard for encoding and storing audio information. If an audio encoder other than G711 is employed, the vendor must provide evidence that the intelligibility is equal to or better than that provided by G.711;
3. Provide full player controls that allow users to pause, rewind, and repeat all messages and prompts;
4. Provide prompts (either as provided by the vendor or by the user) without any background sounds that would reduce intelligibility.

NOTE: Relay services are not considered to be "directly accessible".

• Source: {508}1194.23(c)
• Subcommittee: Telecommunications
• Impact:
• External Reference:
• Testability
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

5-G - Caller and Status Information

Where provided, visual interfaces for telecommunications status information such as caller identification and similar telecommunications functions as part of interactive voice response systems or equivalents must also be available for users of TTYs or other text conversation systems, and for users who cannot see displays and must meet all accessibility provisions for software and content.

Suggested edit for clarity: Products with visual interfaces that display telecommunications status information (such as caller identification and similar telecommunications functions) as part of interactive voice response or equivalent systems must also make this information available for:

• Users of TTYs,
• Users of other text conversation systems, and
• Users who cannot see displays.

These products must also meet all accessibility provisions for software and content.

• Source: {508}1194.23(e)
• Subcommittee: Telecommunications
• Impact:
• External Reference:
• Testability
• Metadata
  • Disabilities: Blindness, Low vision, Deafness, Hard of hearing, Deaf-blindness, Other combined hearing/vision loss
  • User Activities:
  • Product Characteristics:
  • Product Types:

5-H - Video Support

Telecommunications products or systems which have the capacity to transmit video, text and voice communications must support internet protocol text and voice communications in X format and must have sufficient transmission bandwidth capacity to support video communication such as video relay and point to point video communications.

Discussion: "X format" remains undefined; comments were received regarding whether this should be applied to 255 in addition to 508.

• Source: New
• Subcommittee: Telecommunications
• Impact:
• External Reference:
• Testability
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

6. Electronic Content Provisions

Discuss or propose edits to the provisions in this section

[6.1] If Web Content or Web Applications

6.1-A - Color (Web)

Web pages shall be designed so that all information conveyed with color is also available without color, for example from context or markup.

EWG proposed rework: Color coding must not be used as the only means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.

• Source: {508}1194.25(g) and 1194.21(i) (was 3.2.C in May 30 draft - also 1.2.F) (no changes since May 30 draft)
• Subcommittee: General Interface Accessiblity / Web and Software
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities: Color deficiency/Colorblindness
  • User Activities: All
  • Product Characterisics: Uses Color (on keys, labels, displays, indicators, anywhere etc.)
  • Product Types: All

6.1-B - Contrast (Web)

Text (and images of text) have a contrast ratio of at least 5:1, except if the text is pure decoration. Larger-scale text or images of text can have a contrast ratio of 3:1.

Discussion or Rationale Harmonization with WCAG 2.0.

• Source: New, 6.1.M in May 30 Draft
• Subcommittee: Web and Software
• Impact:
• External Reference: WCAG 2.0
• Testability:
• Metadata
  • Disabilities: Low Vision
  • User Activities: All
  • Product Characterisics: Visual display with text; Visual display with graphics; Web content or applications
  • Product Types: Web Content

6.1-C - Timing (Web)

Timing: For each time limit that is set by the content, at least one of the following is true:

• Turn off: the user is allowed to turn off the time limit before encountering it; or
• Adjust: the user is allowed to adjust the time limit before encountering it over a wide range that is at least ten times the length of the default setting; or
• Extend: the user is warned before time expires and given at least 20 seconds to extend the time limit with a simple action (for example, "hit any key"), and the user is allowed to extend the time limit at least ten times; or
• Real-time Exception: the time limit is a required part of a real-time event (for example, an auction), and no alternative to the time limit is possible; or
• Essential Exception: the time limit is part of an activity where timing is essential and time limits can not be extended further without invalidating the activity.
  • TBD: In Adjust, issue with "before encountering"
  • TBD: In Essential Exception, still discussing the suggestion to add something about data integrity.

Discussion or Rationale: "Sufficient time" is not objectively testable. Also, there are other acceptable strategies for addressing the needs of users who need more time. The recommended change is harmonized with both the ISO Software Accessibility standard and WCAG 2.0.

• Source: New (incorporates {508}1194.22(p) and {508}1194.23(d) and {255}1193.41(g), was 6.1.K in May 30 draft
• Subcommittee: Web and Software
• Impact:
• External Reference:
• Testability
• Metadata
  • Disabilities: Blind, Low Vision, Deafness, Heard of Hearing, Physical, Cognitive Learning and Language
  • User Activities: All
  • Product Characterisics: Has Time limits of any type (timeout, double-clicks, keyrepeat)
  • Product Types: Web Content; Telephone only device; IVR (Voicemail, Autoattendant, Audiotext); Software (installed or through browser); Copiers; AudioVisual equipment (Video Monitor, TV, Projector); KIOSKS; Network Interface to devices; Desktop Computer Systems; Portable Computer Systems

6.1-D - Flashing (Web)

Web content and applications do not contain anything that flashes more than 3 times in any one second period, unless the flashing is below the general flash and red flash thresholds.

Discussion: This provision is a subset of 1.2.B - Flashing

• Source: {508}1194.21(k) 1194.22(j) 1194.25(i), and {255}1193.43(f) (was 1.1.H in May 30 draft)
• Subcommittee: General Interface Accessibility
• Impact:
• External Reference:
• Testability
• Metadata
  • Disabilities: All
  • User Activities: All
  • Product Characteristics: All
  • Product Types: All

6.1-E - Non-text Content

Non-text Content: All non-text content has a text alternative that presents equivalent information, except for the situations listed below.

• Controls-Input: If non-text content is a control or accepts user input, then it has a name that describes its purpose. (See also User Interface Components provisions)
• Media, Test, Sensory: If non-text content is multimedia , live audio-only or live video-only content, a test or exercise that must be presented in non-text format , or primarily intended to create a specific sensory experience , then text alternatives at least identify the non-text content with a descriptive text label. (For multimedia, see also Audio and/or Video provisions)
• CAPTCHA: If the purpose of non-text content is to confirm that content is being accessed by a person rather than a computer, then text alternatives that identify and describe the purpose of the non-text content are provided and alternative forms in different modalities are provided to accommodate different disabilities.
• Decoration, Formatting, Invisible: If non-text content is pure decoration, or used only for visual formatting, or if it is not presented to users, then it is implemented such that it can be ignored by assistive technology.

Discussion or Rationale Both the existing Section 508 provision 1194.22(a) and WCAG 1.0 guideline 1.1 require alternatives for non-text content but give no testable criteria for appropriate alt text. 508 should leverage the extensive work done in WCAG and adopt this provision.

• Source: {508}1194.22(a), was 6.1.A in May 30 draft
• Subcommittee: Web and Software
• Impact:
• External Reference:
• Testability
• Metadata
  • Disabilities: Blind, Low Vision, Deafness, Hard of Hearing
  • User Activities: All
  • Product Characterisics: Has OS that supports installed AT and user can install
  • Product Types: Web Content; Software (installed or through browser); Network Interface to devices; Desktop Computer Systems; Portable Computer Systems

6.1-F - Repeated Blocks

A mechanism must be available to bypass blocks of content that are repeated on multiple Web pages.

• TBD: "blocks of content" is vague. Since this is harmonized with WCAG, we are raising the issue with the WCAG group.

Discussion or Rationale: Harmonization with WCAG 2.0.

• Source: {508}1194.22(o), was 6.1.D in May 30 draft
• Subcommittee: Web and Software
• Impact:
• External Reference: WCAG 2.0
• Testability
• Metadata
  • Disabilities: Blind, Physical
  • User Activities: All
  • Product Characterisics: Involves Web Content or Applications
  • Product Types: Web Content; Software (installed or through browser); Network Interface to devices; Desktop Computer Systems; Portable Computer Systems

6.1-G - Keyboard

All functionality of the content operable through the user interface is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints.

• Note: This exception relates to the underlying function, not the input technique. For example, if using handwriting to enter text, the input technique (handwriting) requires path dependent input but the underlying function (text input) does not.
• Note: This does not forbid and should not discourage providing mouse input or other input methods in addition to keyboard operation.

Discussion or Rationale

• The phrase "textually discernible" is an issue because it is interpreted differently by different people.
• Harmonized with WCAG 2.0 and ISO 9241 part 171.

• Source: {508}1194.21(a) (same as 3.3.A)
• Subcommittee: Web and Software
• Impact:
• External Reference: WCAG 2.0 and ISO 9241 part 171
• Testability:
• Metadata
  • Disabilities: Blindness, Physical
  • User Activities: All
  • Product Characterisics: Uses Keyboard (Physical - touch typeable)
  • Product Types: Web Content; Telephone only device; IVR (Voicemail, Autoattendant, Audiotext); Software (installed or through browser); Copiers; AudioVisual equipment (Video Monitor, TV, Projector); KIOSKS; Network Interface to devices; Desktop Computer Systems

6.1-H - Link Purpose

The purpose of each link can be determined from the link text or the link text together with it's programmatically determined link context.

Discussion or Rationale Harmonization with WCAG 2.0. Unlike the restrictive requirement in WCAG 1.0 which requires unique link text for each link within the page, this provision is more flexible. There are cases where it is actually more usable to have identical link text on several links such as on a page that lists document titles and provides links to versions of the document in different formats. This provision allows links within a page to have the same link text as long as the purpose of the link can be determined from the link text and its context, such as the table row or column header, list item, sentence, etc.

• Source: New, was 6.1.F in May 30 draft
• Subcommittee: Web and Software
• Impact:
• External Reference:
• Testability
• Metadata
  • Disabilities: Blind, Physical
  • User Activities: All
  • Product Characterisics: Involves Web Content or Applications
  • Product Types: Web Content; Software (installed or through browser); Network Interface to devices; Desktop Computer Systems; Portable Computer Systems

6.1-I - Information and Relationships

Information and relationships conveyed through presentation can be programmatically determined or are available in text, and notification of changes to these is available to user agents, including assistive technologies. For example:

1. row and column headers are identified for data tables
2. markup 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 is used to identify section headings

Discussion or Rationale The existing 508 provisions on table headers are technology specific to HTML. This more general provision is more applicable to Web content in other technologies.

• Source: New, was 6.1.G in May 30 draft
• Subcommittee: Web and Software
• Impact:
• External Reference:
• Testability
• Metadata
  • Disabilities: Blind, Physical
  • User Activities: All
  • Product Characterisics: Involves Web Content or Applications
  • Product Types: Web Content; Software (installed or through browser); Network Interface to devices; Desktop Computer Systems; Portable Computer Systems

6.1-J - Focus Cursor (Web)

A focus cursor must be provided that visually indicates which user interface element currently has the keyboard input focus, as well as the focus location within that element when one exists. The focus cursor must be programmatically determinable so that assistive technology can track focus and focus changes.

Discussion or Rationale: Focus cursors are provided by user agents for some technologies (HTML, PDF, etc.) but are needed for other technologies (JavaScript, Flash, etc.)

• Source: New, was 6.1.G in May 30 draft
• Subcommittee: Web and Software
• Impact:
• External Reference:
• Testability
• Metadata
  • Disabilities: Blind, Physical
  • User Activities: All
  • Product Characterisics: Involves Web Content or Applications
  • Product Types: Web Content; Software (installed or through browser); Network Interface to devices; Desktop Computer Systems; Portable Computer Systems

6.1-K - User Interface Components

For all user interface components, including form elements and those generated by scripts, the name and role must be programmatically determinable, states, properties, and values that can be set by the user must be programmatically determinable and can be programmatically set, and notification of changes to these items is available to user agents, including assistive technologies. For example:

1. Frames must be titled with text that facilitates frame identification and navigation.

Discussion or Rationale: To ensure that interactive elements in non-HTML technologies, or those implemented by re-purposing HTML elements with JavaScript, properly expose information for AT interoperability.

• Source: New, was 6.1.I in May 30 draft
• Subcommittee: Web and Software
• Impact:
• External Reference:
• Testability
• Metadata
  • Disabilities: Blind, Physical
  • User Activities: All
  • Product Characterisics: Involves Web Content or Applications
  • Product Types: Web Content; Software (installed or through browser); Network Interface to devices; Desktop Computer Systems; Portable Computer Systems

6.1-L - Consistent Identification

Components that have the same functionality within a set of Web pages must be identified consistently.

Discussion or Rationale Harmonization with WCAG 2.0. Helps people with cognitive disabilities.

• Source: New, was 6.1.J in May 30 draft
• Subcommittee: Web and Software
• Impact:
• External Reference: WCAG 2.0
• Testability
• Metadata
  • Disabilities: Blind, Physical
  • User Activities: All
  • Product Characterisics: Involves Web Content or Applications
  • Product Types: Web Content; Software (installed or through browser); Network Interface to devices; Desktop Computer Systems; Portable Computer Systems

6.1-M - Pausing

Moving, blinking, scrolling, or auto-updating information can be paused by the user unless it is part of an activity where timing or movement is essential. Moving content that is pure decoration can be stopped by the user.

Discussion or Rationale Harmonization with WCAG 2.0.

• Source: New, was 6.1.L in May 30 draft
• Subcommittee: Web and Software
• Impact:
• External Reference: WCAG 2.0
• Testability
• Metadata
  • Disabilities: Blind, Physical
  • User Activities: All
  • Product Characterisics: Involves Web Content or Applications
  • Product Types: Web Content; Software (installed or through browser); Network Interface to devices; Desktop Computer Systems; Portable Computer Systems

6.1-N - Reading Order

When the sequence in which content is presented affects its meaning, a correct reading sequence is programmatically determinable.

• programmatically determinable is defined as: can be determined by software from data provided in a user-agent-supported manner such that various user agents including assistive tecnologies can extract and present this information to users in different modalities.

Discussion or Rationale: This definition and its connection to assitive technologies needs further discussion.

• Source: New, was in April draft, but then was incorrectly dropped
• Subcommittee: Web and Software
• Impact:
• External Reference:
• Testability
• Metadata
  • Disabilities: Blind, Physical
  • User Activities: All
  • Product Characterisics: Involves Web Content or Applications
  • Product Types: Web Content; Software (installed or through browser); Network Interface to devices; Desktop Computer Systems; Portable Computer Systems

[6.2] If a Content Format

The Web and Software subcommittee was charged with looking at the issue of accessible content - e-mail, attachments in e-mail, etc. One issue is that the content format itself has to have certain features to enable the creation of accessible content. We therefore recommend adding a section that defines the necessary accessibility features. Agencies should store information only in compliant content formats and should therefore purchase products that support compliant content formats. Note that content creators still have to utilize the features in order for the content to actually be accessible.

6.2-A - Non-text Objects

A content format that supports non-text objects must provide an encoding mechanism to associate non-text objects with textual descriptions that a user-agent can display.

Discussion or Rationale: See rationale information in introductory paragraph.

• Source: New, no change since May 30 draft
• Subcommittee: Web and Software
• Impact:
• External Reference:
• Testability
• Metadata
  • Disabilities: All
  • User Activities: All
  • Product Characteristics: All
  • Product Types: All

6.2-B - Multimedia (Format)

When a content format supports multimedia, an encoding mechanism must be provided to include synchronized text of verbal content, and audio descriptions of critical nonverbal activity displayable by a user-agent.

Discussion or Rationale: See rationale information in introductory paragraph.

• Source: New, no change since May 30 draft
• Subcommittee: Web and Software
• Impact:
• External Reference:
• Testability
• Metadata
  • Disabilities: All
  • User Activities: All
  • Product Characteristics: All
  • Product Types: All

6.2-C - Reading Order

When a content format supports 2 dimensional display of information, an encoding mechanism must be provided to identify the logical linear reading order of the content displayable by a user-agent.

Discussion or Rationale: See rationale information in introductory paragraph.

• Source: New, no change since May 30 draft
• Subcommittee: Web and Software
• Impact:
• External Reference:
• Testability
• Metadata
  • Disabilities: All
  • User Activities: All
  • Product Characteristics: All
  • Product Types: All

6.2-D - Table Headers

When a content format supports row and column headers in data tables, an encoding mechanism must be provided to identify row and column headers for data tables displayable by a user-agent.

Discussion or Rationale: See rationale information in introductory paragraph.

• Source: New, no change since May 30 draft
• Subcommittee: Web and Software
• Impact:
• External Reference:
• Testability
• Metadata
  • Disabilities: All
  • User Activities: All
  • Product Characterisics: All
  • Product Types: All

6.2-E - Complex Table Headers

When a content format supports data tables that have two or more logical levels of row or column headers, an encoding mechanism must be provided to associate row and column headers with data cells, displayable by a user-agent.

Discussion or Rationale: See rationale information in introductory paragraph.

• Source: New, no change since May 30 draft
• Subcommittee: Web and Software
• Impact:
• External Reference:
• Testability
• Metadata
  • Disabilities: All
  • User Activities: All
  • Product Characterisics: All
  • Product Types: All

6.2-F - Interactive Elements

When a content format supports interactive elements, an encoding mechanism must be provided to identify name, operation, and state, of any interactive elements displayable by a user-agent.

Discussion or Rationale: See rationale information in introductory paragraph.

• Source: New, no change since May 30 draft
• Subcommittee: Web and Software
• Impact:
• External Reference:
• Testability
• Metadata
  • Disabilities: All
  • User Activities: All
  • Product Characterisics: All
  • Product Types: All

6.2-G - Links

When a content format supports links, an encoding mechanism must be provided to identify link text displayable by a user-agent.

Discussion or Rationale: See rationale information in introductory paragraph.

• Source: New, no change since May 30 draft
• Subcommittee: Web and Software
• Impact:
• External Reference:
• Testability
• Metadata
  • Disabilities: All
  • User Activities: All
  • Product Characterisics: All
  • Product Types: All

6.2-H - Embedded Comments

When a content format supports embedded comments, an encoding mechanism must be provided to identify embedded comments and associate those comment locations within the document.

Discussion or Rationale: See rationale information in introductory paragraph.

• Source: New, no change since May 30 draft
• Subcommittee: Web and Software
• Impact:
• External Reference:
• Testability
• Metadata
  • Disabilities: All
  • User Activities: All
  • Product Characterisics: All
  • Product Types: All

6.2-I - Images of Text

When a content format supports scanned images of text, an encoding mechanism must be provided to identify text of scanned images of text, displayable by a user-agent. Note, this means allowing for inclusion of the text of a scanned image of text.

Discussion or Rationale: See rationale information in introductory paragraph.

• Source: New, no change since May 30 draft
• Subcommittee: Web and Software
• Impact:
• External Reference:
• Testability
• Metadata
  • Disabilities: All
  • User Activities: All
  • Product Characterisics: All
  • Product Types: All

6.2-J - Dynamic Information

When a content format supports dynamic presentations, graphs, or other extracted information, an encoding mechanism must be provided to include data used for any dynamic presentations, graphs, or other extracted information displayable by a user-agent.

Discussion or Rationale: See rationale information in introductory paragraph.

• Source: New, no change since May 30 draft
• Subcommittee: Web and Software
• Impact:
• External Reference:
• Testability
• Metadata
  • Disabilities: All
  • User Activities: All
  • Product Characterisics: All
  • Product Types: All

[6.3] If Audio and/or Video Content

Note: The Audio Visual committee is still working on updates for these provisions.

6.3-A - Synchronized Alternatives

Equivalent alternatives for any multimedia presentation must be synchronized with the presentation.

Discussion: Web/Software subcommittee states needs to harmonize with AV input

• Source: {508}1194.22(b)
• Subcommittee: Web/Software

6.3-B - Captions and Transcripts

All materials containing video and/or audio, regardless of format, that contain speech or other audio information necessary for the comprehension of the content, must comply with the following:

1. Materials containing prerecorded audio and no additional time-based content must provide either a transcript or synchronized captions.
2. Materials containing prerecorded video with concurrent audio must provide synchronized captions and may offer a transcript in addition to, but not in place of, the captions.
3. Materials containing real-time audio, with or without video, must provide synchronized real-time captions.

• Source: {508}1194.24(c)
• Subcommittee: Audio-Video

6.3-C - Video Description and Full Text Equivalents

All materials containing video and/or audio, regardless of format, that contain visual information necessary for the comprehension of the content, must comply with the following:

1. materials containing prerecorded video and no audio or other additional time-based content must provide either a separate text description of the video or provide an additional audio track to convey the informational content of the video.
2. materials containing prerecorded video with concurrent audio must provide synchronized audio descriptions, or a separate text description of the video, to convey the informational content of the video.
3. materials containing live video must provide synchronized audio descriptions in real time to convey the informational content of the video.

• Source: {508}1194.24(d)
• Subcommittee: Audio-Video

6.3-D - Open or Closed Captions/