EWG:Draft Aug 17

Editorial Working Group > Working Draft created August 17

TEITAC Working Draft - August 17, 2007.

This draft has been updated by the September 3 Working Draft. 

This page is the working draft with the latest versions of the work of the TEITAC. It contains all updates since the July 18 Draft. This is the draft people should review for use at the September 4-6, 2007 plenary meeting.

To make reading easier see the August 17 draft without metada.

Contents 1 Subpart A 1.1 Section 1194.1 Purpose 1.1.1 Version 1 1.1.2 Version 2 1.2 Section 1194.2 Application 1.2.1 Version 1 1.2.2 Version 2 1.3 Section 1194.3 General Exceptions 1.3.1 1194.3 - A - Intelligence Or Security Systems 1.3.2 1194.3 - NEW - Emergency, Field and First Response Use 1.3.3 1194.3 - B- Incidental To A Contract 1.3.4 1194.3 - C - Employees Not Individuals With Disabilities 1.3.5 1194.3 - D - Access By Public 1.3.6 1194.3 - E - Fundamental Alteration 1.3.6.1 Version 1 1.3.6.2 Version 2 1.3.6.3 Version 3 1.3.6.4 Version 4 1.3.6.5 Version 5 1.3.7 1194.3 - F - Service Areas 1.3.7.1 Version 1 1.3.7.2 Version 2 1.3.7.3 Version 3 1.3.8 1194.3 - G - Narrow, Delineated Use 1.3.8.1 Version 1 1.3.8.2 Version 2 1.4 Section 1194.4 Definitions 1.4.1 Agency 1.4.2 Alternate Formats 1.4.3 Alternate Methods 1.4.4 Application Software 1.4.5 Assistive Technology 1.4.6 Authoring Tools 1.4.7 Auto-updating 1.4.8 Captions 1.4.9 Closed Product Functionality 1.4.10 Comparable Access 1.4.11 Content 1.4.12 Content Format 1.4.13 Contrast Ratio 1.4.14 Decoration 1.4.15 Electronic and Information Technology 1.4.16 Freestanding 1.4.17 General Flash and Red Flash Thresholds 1.4.18 Information Technology 1.4.19 Informational Animation 1.4.20 Interactive Elements 1.4.21 Large Scale Text 1.4.22 Menu 1.4.23 Operable Controls 1.4.24 Other Services To Cooperate With Assistive Technologies 1.4.25 Peak Non-crisis Network Traffic 1.4.26 Personal-Private 1.4.27 Platform Accessibility Services (was Accessibility Services) 1.4.28 Platform Software 1.4.29 Product 1.4.30 Programatically Determined 1.4.31 Real-time Text 1.4.32 Relative Luminance 1.4.33 Shared-Public 1.4.34 Telecommunications 1.4.35 Terminal 1.4.36 TTY 1.4.37 Undue Burden 1.4.38 Video Description 1.4.39 Web Content 1.4.40 Web Page 1.4.41 World Wide Web 1.5 Section 1194.5 Equivalent Facilitation 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 Functions 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. Hardware Aspects of Products 2.2.1 2.1 All Products with Hardware 2.2.1.1 2.1-A - Contrast for displays 2.2.1.2 2.1-B - Contrast for labels 2.2.1.3 2.1-C - Mechanical Controls 2.2.1.4 2.1-D - Touch Operated 2.2.1.5 2.1-E - Standard Connection 2.2.1.6 2.1-F - Free-Standing 2.2.2 2.2 If the Product has Speech Output or Throughput 2.2.2.1 2.2-A - Magnetic Coupling 2.2.2.2 2.2-B - Interference with Hearing Device 2.2.2.3 2.2-C - Audio Connection 2.2.2.4 2.2-D - Volume 2.2.2.5 2.2-E - Volume (Gain) 2.2.2.6 2.2-F - Volume Reset 2.3 3. User Interface and Electronic Content Provisions 2.3.1 3-A - Color 2.3.2 3-B - Contrast 2.3.3 3-C - Non-text content 2.3.4 3-D - Human Language 2.3.5 3-E - Language of Parts 2.3.6 3-F - Pausing 2.3.7 3-G - Flashing 2.3.8 3-H - Consistent Identification 2.3.9 3-I - Size, shape, location 2.3.10 3-J - Audio Turnoff 2.3.11 3-K - Reading Sequence 2.3.12 3-L - Repeated Blocks 2.3.13 3-M - Link Purpose 2.3.14 3-N - Information and Relationships 2.3.15 3-O - User Interface Components 2.3.16 3-P - User Preferences 2.3.17 3-Q - Color Adjustment 2.3.18 3-R - Disruption of Access Features 2.3.19 3-S - Timing 2.3.20 3-T - Keyboard Operation 2.3.21 3-U - Focus Cursor 2.3.22 3-V - AT Interoperability 2.3.23 3-W - Both platform and Application 2.3.24 3-X - Advisory Notes 2.3.24.1 1. Suppression of unneeded function 2.3.24.2 2. Writing guidelines 2.3.24.3 3. Interaction guidelines 2.4 4. Additional Provisions for Audio-Visual Players or Displays 2.4.1 4-A - Caption Playback 2.4.2 4-B - Supplemental Audio Playback 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 and Interoperability 2.5.3 5-C - Voice Terminal Hardware and Software 2.5.4 5-D - IVR, Auto-Attendant and Messaging 2.5.5 5-E - Caller and Status Information 2.5.6 5-F - Video Support 2.6 6. Audio and/or Video Content 2.6.1 6-A - Synchronized Alternatives 2.6.2 6-B - Captions and Transcripts 2.6.3 6-C - Video Description 2.6.4 6-D - Open or Closed Captions/Descriptions 2.6.5 6-E - Interactive Elements 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-X - Advisory Notes 2.7.1.3.1 1. Context-sensitive help 2.7.1.3.2 2. Text descriptions 2.7.1.3.3 3. User interface descriptions 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-X - Advisory Notes 2.7.2.2.1 1. Remote assistance 2.8 8. Content Format and Authoring Tools 2.8.1 8.1 If a Content Format 2.8.1.1 8.1-A - Non-text Objects 2.8.1.2 8.1-B - Multimedia (Format) 2.8.1.3 8.1-C - Reading Order 2.8.1.4 8.1-D - Table Headers 2.8.1.5 8.1-E - Complex Table Headers 2.8.1.6 8.1-F - Interactive Elements 2.8.1.7 8.1-G - Links 2.8.1.8 8.1-H - Embedded Comments 2.8.1.9 8.1-I - Images of Text 2.8.1.10 8.1-J - Dynamic Information 2.8.2 8.2 Additional requirements for Web Content Authoring Tools 2.8.2.1 8.2-A - Accessible Output 2.8.2.2 8.2-B - Preserve Accessibility Information 2.8.2.3 8.2-C - Prompts 2.8.2.4 8.2-D - Evaluation Support 2.8.2.5 8.2-E - Accessible Templates

Subpart A

The Subpart A subcommittee has a action item from the July 16-18 meetings to summarize all issues and concerns so they may be discussed at the next meeting for resolution.

Editorial notes

• For Subpart A only the current text is included, to facilitate discussion.
• For Subpart A only the metadata is omitted, as this subpart, by definition, applies to all.

Updates and discussion for provisions in this section

Section 1194.1 Purpose

There are two proposed new versions

Current Text
The purpose of this part is to implement section 508 of the Rehabilitation Act of 1973, as amended (29 U.S.C. 794d). 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 that is comparable 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 that is comparable to that provided to the public who are not individuals with disabilities, unless an undue burden would be imposed on the agency.

Version 1

The purpose of this part is to implement section 508 of the Rehabilitation Act of 1973, as amended (29 U.S.C. 794d). 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 THAT IS TIMELY, ACCURATE, COMPLETE AND EFFICIENT WHEN 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 THAT IS TIMELY, ACCURATE, COMPLETE AND EFFICIENT WHEN COMPARED to that provided to the public who are not individuals with disabilities, unless an undue burden would be imposed on the agency.

Version 2

Insert provision to address comparable access in Section 1194.2 Application

Discussion or Rationale In either approach, it is recommended that new explanatory information be provided:

• Timely access means that individuals with disabilities have information and data available to them at the same time as individuals without disabilities, but that does not preclude captions that are slightly delayed or other reasonable differences in timing given individual situations.
• Accurate means that the information and data reflects the intended meaning especially when converted into another form or media.
• Complete means that all critical information and data is present when accessed by assistive technology or converted into another form or media.
• Efficient means that an individual with a disability exerts a reasonably similar or comparable amount of effort (given the capacity of current assistive technology) in using electronic and information technology as compared to an individual without a disability.

Access may be delivered via built-in access features or compatibility with assistive technology as described in the technical standards specified in XXX.)

• Status: Done
• Text from Subcommittee
• Source: {508}1194.1,
• Impact:
• External Reference:
• Testability:

Section 1194.2 Application

This provision has alternative versions. Each version and its rationale or justification are listed below.

Current Version
(a) Products covered by this part shall comply with all applicable provisions of this part. When developing, procuring, maintaining, or using electronic and information technology, each agency shall ensure that the products comply with the applicable provisions of this part, unless an undue burden would be imposed on the agency.

(1) When compliance with the provisions of this part imposes an undue burden, agencies shall provide individuals with disabilities with the information and data involved by an alternative means of access that allows the individual to use the information and data.

(2) When procuring a product, if an agency determines that compliance with any provision of this part imposes an undue burden, the documentation by the agency supporting the procurement shall explain why, and to what extent, compliance with each such provision creates an undue burden.

(b) When procuring a product, each agency shall procure products which comply with the provisions in this part when such products are available in the commercial marketplace or when such products are developed in response to a Government solicitation. Agencies cannot claim a product as a whole is not commercially available because no product in the marketplace meets all the standards. If products are commercially available that meet some but not all of the standards, the agency must procure the product that best meets the standards.

(c) Except as provided by §1194.3(b), this part applies to electronic and information technology developed, procured, maintained, or used by agencies directly or used by a contractor under a contract with an agency which requires the use of such product, or requires the use, to a significant extent, of such product in the performance of a service or the furnishing of a product.

Version 1

Add new Introductory statement:
In general, this section applies only to the (consideration, provisions or determination- need to determine which word to be used) of accessibility in the process of developing, procuring, maintaining, or using electronic and information technology.)

Rationale for Version 1 This additional language is intended to clarify that all of the regulations in this section that impact agency procurement procedures, apply only to the consideration of accessibility. The additional language is not intended to provide regulatory direction regarding how agencies consider other factors, such as business and technical needs and requirements, when making an acquisition. The FAR defines procurement parameters for a number of agencies and agencies need to determine how to address accessibility within the parameters of other required procurement considerations and processes. The workgroup has discussed the fact that there have been varying interpretations of how Section 508 should be applied when making an acquisition. In some cases there is the expectation that accessibility should trump agency business needs and other requirements. This language clarifies that accessibility must be determined within the parameters of Section 508, but does not purport to direct agencies as to how to make overall procurement decisions. Agencies are required to consider accessibility within the framework of other regulated procurement practices such as the FAR. Some subcommittee members indicated that this limitation was sufficiently provided via § 1194.1 Purpose and the new language was not necessary.

Version 2

(This would change only sub item #2 of paragraph (a), and paragraph (b).)

(2) When DEVELOPING, procuring, MAINTAINING, OR USING a product, if an agency determines that compliance with any provision of this part imposes an undue burden, the documentation by the agency supporting the DEVELOPMENT, procurement, MAINTANENCE, OR USE shall explain why, and to what extent, compliance with each such provision creates an undue burden.

(b) When procuring a product, each agency shall procure products which comply with the provisions in this part when such products are available in the commercial marketplace or when such products are developed in response to a Government solicitation. Agencies cannot claim a product as a whole is not commercially available because no product in the marketplace meets all the standards. If products are NOT commercially available that meet all of the standards, the agency must procure the product that best meets THE AGENCIES BUSINESS NEEDS AND the APPLICABLE ACCESS standards.

New Note for Procurements: To facilitate the determination of the product best meeting the provisions of this part, those provisions that apply for a given acquisition should be enumerated during the process of determining business and technical requirements.

Discussion or Rationale

• Rationale for changes to paragraph 2: Undue burden clause in prior regs only applied to procurement. Assumed oversight- revision to clarify the application of undue burden to development, maintenance and use in addition to procurement.

• Rationale for changes to paragraph b: Clarifies the use of “best meets” when products are not commercially available that comprehensively meet each and every standard, but might partially meet one or more individual standards or meet some but not all of the standards. Improves understanding of clause

• Rationale for the additional text: When attempting to clarify how 508 should be applied to determine accessibility the workgroup devised two approaches: (1)Adding the “In general” language preceding the Application section noted above and/or (2) Adding a notation to Procurement section of the Application Section. The note was intended to provide explanatory information regarding inclusion of accessibility provisions in the process of developing business and technical requirements. The subcommittee did not reach consensus on the inclusion of the note and at the July TEITAC plenary meeting there was general agreement to not include the addition of the "Note for Procurements".. Concerns were voiced that the Note was confusing and inconsistent with the addition of the introductory language.

• Some subcommittee members also voiced support for removing (b) in total and deferring all procurement decision-making procedures to the Federal Acquisition Regulations (FAR) and/or other governing procurement policies. The Access Board and FAR will be simultaneously considering the 508 regulations- this presents an opportune time for GSA and the Access Board to consider how to ensure best provide guidance for agencies to implement 508 within the procurement process.

• At the July meeting, the committee discussed changing "product" to "E&IT" throughout

• Status: In Progress
• Text from Subpart A
• Source: {508}1194.2
• Impact:
• External Reference:
• Testability:

Section 1194.3 General Exceptions

1194.3 - A - Intelligence Or Security Systems

This part does not apply to any electronic and information technology operated by agencies, the function, operation, or use of which involves intelligence activities, cryptologic activities related to national security, command and control of military forces, equipment that is an integral part of a weapon or weapons system, or systems which are critical to the direct fulfillment of military or intelligence missions.

Systems which are critical to the direct fulfillment of military or intelligence missions do not include a system that is to be used for routine administrative and business applications (including payroll, finance, logistics, and personnel management applications).

Status: In progress
Source: {508}1194.3

Work in Progress:

• Proposed addition to this section of "Physical prerequisites for personnel, also known as "fitness for duty", are not valid basis to meet national security or other exceptions in this part."

1194.3 - NEW - Emergency, Field and First Response Use

This part does not apply to any electronic and information technology operated by agencies in a field environment where the function, operation, or use is by a first responder, emergency, security, or law enforcement personnel. This exception does not apply to the agency systems administrative and business applications (including payroll, finance, logistics, and personnel management applications) or any application or system that is intended for use by members of the public.

Rationale Currently the national security exception directly addresses the accessibility exception for electronic and information technologies used as integral parts of weapons or weapons systems, in command-and-control, cryptological activities, and for direct support of intelligence and military missions. The underlying theme of that exception is often what might be considered emergency, or field conditions, and physical requirements as a prerequisite for employment. These same conditions are met in situations such as first responders, fire-fighters, law-enforcement personnel in the field, etc. Because of this similarity some Federal agencies such as Department of Homeland Security, Department of Justice, some portions of the Department of the Treasury, for example, encounter Section 508 acquisitions situations which mirror those in the national Security exception, but which are uncovered now. This requires that the agencies either apply fundamental alteration exception to such purchases, which is not always the most accurate fit, or conduct the market research and take accessibility requirements in to account during the process for items never to be used by people with disabilities. While Section 508 standards are intended to lower barriers to employment, they are not intended to remove all such barriers where disabilities and performing the job are in practice and reality mutually exclusive. Note, first responders in practice can be Federal employees or members of the public; however this exception is not based upon this status, rather the work to be performed and the location that work is performed.

• Impact:

Economic impact: Low This exception will lower the analysis level of Federal requiring officials by addressing this specific situation directly, and lower their potential market analysis workload as well. It will not impact industry negatively as it is not a requirement that they must change business practices or products to meet.

• External Reference:

Definition of "first responder": From Homeland Security Presidential Directive 8, (HSPD8), the term "first responder" refers to those individuals who in the early stages of an incident are responsible for the protection and preservation of life, property, evidence, and the environment, including emergency response providers as defined in section 2 of the Homeland Security Act of 2002 (6 U.S.C.101), as well as emergency management, public health, clinical care, public works, and other skilled support personnel (such as equipment operators) that provide immediate support services during prevention, response, and recovery operations.
Note: adoption of this provision will require reference of the Definition of First Responder in §1194.4 Definitions.

• Status: New: no consensus reached
• Text from Subcommittee
• Source: New

1194.3 - B- Incidental To A Contract

This part does not apply to electronic and information technology that is acquired by a contractor incidental to a contract.

Status: Done
Source: {508}1194.3, no change

1194.3 - C - Employees Not Individuals With Disabilities

Except as required to comply with the provisions in this part, this part does not require the installation of specific accessibility-related software or the attachment of an assistive technology device at a workstation of a Federal employee who is not an individual with a disability.

Status: Done
Source: {508}1194.3, no change

1194.3 - D - Access By Public

When agencies provide access to the public to information or data through electronic and information technology, agencies are not required to make products owned by the agency available for access and use by individuals with disabilities at a location other than that where the electronic and information technology is provided to the public, or to purchase products for access and use by individuals with disabilities at a location other than that where the electronic and information technology is provided to the public.

Status: Done
Source: {508}1194.3, no change

1194.3 - E - Fundamental Alteration

This provision has five alternative versions, with rationales provided below

Versions 1-4 are recommended with the intent to clarify that a fundamental alteration should apply only to those products and components that are required by the agency to meet their business needs and mission.

Current Provision
This part shall not be construed to require a fundamental alteration in the nature of a product or its components.

Version 1

This part shall not be construed to require a fundamental alteration in the nature of the E&IT, or its components, OR THE AGENCY'S SPECIFIED PRODUCT REQUIREMENTS.

Rationale for Version 1: Version 1 limits the exception to the nature of the E&IT or its components and those requirements “specified by the agency” (assuming they are constructed in accordance with standard procurement procedures). This is the version is the same as the July 6 draft.

Version 2

This part shall not be construed to require a fundamental alteration in the nature of the E&IT, OR THE AGENCY'S INTENDED BUSINESS NEED, or its components.

Rationale for Version 2 Version 2 limits the exception to the nature of the E&IT or that which meets the agency’s “intended business need”. This approach does not specify that it also applies to components, but may be viewed as more open with regard to allowing the agency to tie the exception to the business need even if the requirements are not specified up front. This is the version is the same as the May 30 version.

Version 3

This part shall not be construed to require a fundamental alteration in the nature of the E&IT, or its components, OR THE AGENCY'S BUSINESS NEED.

Rationale for Version 3 Version 3 amends Version 2 to incorporate E&IT components

Version 4

This part shall not be construed to require a fundamental alteration in the nature of the E&IT, or its components, OR THE AGENCIES SPECIFIED PRODUCT REQUIREMENTS OR BUSINESS NEED.

Rationale for Version 4 The authors recommend that the TEITAC adopt Version 4 of the proposed language specifically to remind agencies that their implementation of Section 508 must support both the agency’s mission as well as their responsibilities under Section 508. Version 4 demonstrates how the discussion has evolved to clarify that E&IT (previously referred to as “product”) and components are covered. Version 4 also links the fundamental alteration to the agencies specified requirements- if they are able to specify their requirements – or their business need if they are not able to specify the requirements up front.

Version 5

Retain current provision

Rationale for Version 5 Additional wording intended to clarify that agency’s specified product requirements (assuming they are constructed in accordance with standard procurement procedures) do not need to be altered. Some TEITAC members indicated this additional language is not needed, as it is implicit.

• Status: In progress: no consensus reached
• Text from Subcommittee
• Source: {508}1194.3
• Impact:
• External Reference:
• Testability:

1194.3 - F - Service Areas

This provision has alternative versions. Each version and its rationale or justification are listed below.

Current Provision
Products located in spaces frequented only by service personnel for maintenance, repair, or occasional monitoring of equipment are not required to comply with this part.

Version 1

Products DESIGNED FOR spaces frequented only by service personnel for maintenance, repair, or occasional monitoring of equipment ARE NOT REQUIRED TO MAKE CONTROLS OR INTERFACES THAT ARE OPERABLE SOLELY FROM THESE SPACES COMPLY WITH THIS PART.

Rationale for Version 1 Additional wording attempts to restrict this exception to products that are specifically designed to be located in areas frequented only by service personnel rather than covering all products by virtue of their location. It also makes clear that being able to support the system remotely is acceptable.

• Impact:
• External Reference:
• Testability:

Version 2

Products located AND OPERATIONS EXECUTED in spaces frequented only by service personnel for maintenance, repair, or occasional monitoring of equipment are not required to comply with this part. (May 30)

Rationale for Version 2 This version is an attempt to clarify and restrict this exception to products that are located in service areas, but whose controls and interfaces are only operable from the service area location, i.e. a remote interface is not available.

• Impact:
• External Reference:
• Testability:

Version 3

No Exception allowed - all products should conform

Rationale for Version 3 Some TEITAC members and subcommittee members recommend the entire exception should be deleted. This recommendation is based on the preference that all products should conform regardless of location and use.

• Impact:
• External Reference:
• Testability:

• Status: In progress: no consensus reached
• Text from Subpart A
• Source: {508}1194.3

1194.3 - G - Narrow, Delineated Use

This provision has alternative versions. Each version and its rationale or justification are listed below.

Version 1

Self-contained, closed products with narrow, delineated personal use (such as calculators, electronic dictionaries, and audio recorders) for which an agency can document readily available specialized products in the commercial marketplace that collectively meet the functional performance criteria (e.g. have features such as speech output available on one unit, large visual display available on another, large keys/buttons available on another, etc.) Are not required to comply with this part as a whole. Agencies must however provide specialized products with appropriate access features as necessary to meet the needs of end-users with disabilities.)

Rationale for Version 1 Some subcommittee members voiced the opinion this new exception is not needed

• Impact:
• External Reference:
• Testability:

Version 2

(Alternative approaches dependent upon recommendations of Closed Product Group)

• Impact:
• External Reference:
• Testability:

• Status: In progress: no consensus reached
• Text from Subpart A
• Source: New

Section 1194.4 Definitions

The following definitions apply to this part:

Agency

Any Federal department or agency, including the United States Postal Service.

Status: Done
Text from: Subpart A

Alternate Formats

• Text coming from Documentation Subcommittee.

Alternate Methods

• Text coming from Documentation Subcommittee.

Application Software

• Text coming from Web and Software Subcommittee.

Discussion information can be found on http://teitac.org/wiki/Web_and_Software:_Definitions.

Assistive Technology

Assistive technology is any item, piece of equipment, or system, whether acquired commercially, modified, or customized, that is commonly used to increase, maintain, or improve functional capabilities of individuals with disabilities. As used in this part, the term includes traditional assistive technology hardware and software along with (mainstream technology used as assistive technology,) virtual assistive technology delivered as a web service and integration of products into a system that provides assistive technology functions which allow individuals with disabilities to access electronic information technology.

Status: Done (status updated Aug 24, 2007)
Text from: Subpart A

Discussion or Rationale: Added language clarifying that assistive technology includes web based and integration services.

Authoring Tools

Any software used to create or modify content for publication.

• Note: This is not intended to apply to text editors like Notepad. Concern that this will be too broadly applied due to the definition of "content". Subcommittee still working on these concerns.

Status: In Progress
Text from: Web and Software

Auto-updating

Object whose appearance is modeling one or more data values, such as a status monitor, or stock ticker, and which is updated autonomously by software.

• Concern that there is no consideration for frequency here. Auto-updating at very slow frequencies like once per day is not a problem. Concern that this is too broad and will cause ARIA content to fail even when there is no problem.

Status: In Progress
Text from: Web and Software

Captions

Captions are synchronized text equivalents for audio information. Captions are similar to subtitles in that they convey the content of spoken dialog, but also include text for non-spoken information such as important sound effects, music, laughter, and speaker identification and location. Captions should not obscure or obstruct relevant or key information. In some countries captions are called subtitles.

Status: Done
Text from: Audio/Visual

Closed Product Functionality

Functionality of a product where assistive technology can not be used to achieve some or all of the functionality of the electronic user interface components for any reason including hardware, software, platform, license, or policy limitation.

• Products can be closed for one type of disability but not closed for another.
• Functionality is limited to "electronic UI components" because products are not considered ‘closed’ if mechanical devices like latches or lids cannot be operated by assistive technologies like screen readers. Mechanical devices such as keys that cause electronic input would however trigger “closed” designation if assistive technologies could not achieve the same functionality.
• A ‘product’ can consist of multiple devices some of which may be AT if the devices are all sold and kept together as a unit.
• Policy includes manufacturer, or vendor policies,etc. Agencies are responsibility for agency policies. If important to procurement agencies should reflect requirement as specifications in the RFP. (e.g. "Connection of user devices will not be allowed." or "All peripheral ports must be sealable.")

Status: Done
Text from: Self-Contained/Closed

Comparable Access

Comparable access means that individuals with disabilities have access to and use of information and data that is timely, accurate, complete, and efficient when compared to that available to individuals without disabilities.

• Timely access means that individuals with disabilities have information and data available to them at the same time as individuals without disabilities, but that does not preclude captions that are a millisecond or two delayed or other reasonable differences in timing given individual situations.
• Accurate means that the information and data reflects the intended meaning especially when converted into another form or media.
• Complete means that all critical information and data is present when accessed by assistive technology or converted into another form or media.
• Efficient means that an individual with a disability exerts a reasonably similar or comparable amount of effort (given the capacity of current assistive technology) in using electronic and information technology as compared to an individual without a disability.

Status: In Progress
Text from: Subpart A

Discussion or Rationale: Addition of comparable access definition at the request of federal procurement officials and other subcommittees to provide framework for application of functional performance standards.

Subcommittee could not reach consensus on including some or all of the explanatory information as part of the definition itself. It will be critical to expand on and explain the terms “timely, accurate, complete and efficient” to ensure understanding and consistency in application but the group could not reach consensus on where that explanation should occur. Not clear on how would test for this. Consumers do want measurable so don't have false access. “Reasonable accommodation” is different per Terry

Subcommittee also could not reach consensus on possible addition of the word “communication” to “information and data” to clarify that communication is part of information and data.

Content

information and sensory experience to be communicated to the user by means of software, including but not limited to: text, images, sounds, videos, controls and animations, as well as the encoding that defines the structure, presentation, and interactions associated with those elements.

Status: In Progress
Text from: Web and Software

Content Format

An encoding mechanism for storing information. Examples are HTML, JPEG, SMIL, PDF, etc.

Status: Done
Text from: Web/Software

Contrast Ratio

The relative luminance of the lighter of the foreground or background colors compared to the relative luminance of the darker of the foreground or background colors.

• (L1 + 0.05) / (L2 + 0.05), where
  • L1 is the relative luminance of the lighter of the foreground or background colors, and
  • L2 is the relative luminance of the darker of the foreground or background colors.

Notes

1. Contrast ratios can range from 1 to 21 (commonly written 1:1 to 21:1).
2. For dithered colors, use the average values of the colors that are dithered (average R, average G, and average B).
3. Text can be evaluated with anti-aliasing turned off.
4. Background color is the specified color of content over which the text is to be rendered in normal usage. If no background color is specified, then white is assumed.
5. For text displayed over gradients and background images, authors should ensure that sufficient contrast exists for each part of each character in the content.

Status: Done
Text from: Web/Software

Decoration

Sensory experience to be communicated to the user that does not convey relevant information, does not have a function, and is included only for aesthetic purposes.

Status: Done
Text from: Web and Software

Electronic and Information Technology

Includes information technology and any equipment or interconnected system or subsystem of equipment that is used in the creation, conversion, or duplication of data or information. The term electronic and information technology includes, but is not limited to, telecommunications products (such as telephones), information kiosks and transaction machines, World Wide Web sites, multimedia, and office equipment such as copiers and fax machines. The term does not include any equipment that contains embedded information technology that is used as an integral part of the product, but in which information technology is not the principal function of that product.

Status: Done
Text from: Subpart A

Discussion or Rationale: This definition cannot be changed, as it is derived from Clinger-Cohen. However, this is still an issue for agencies, and TEITAC might want to recommend that Access Board and GSA work together to create advisory notes to help them determine what is (and is not) E&IT

Freestanding

• Text coming from Hardware subcommittee

The subcommittee is requesting input from the plenary on if this should be defined since it is used in other parts of the ADA regulations and could have impacts there.

General Flash and Red Flash Thresholds

(Flashing frequency corrected from 50 to 55 Hz in bulleted list, update made Aug 28, 2007)

A sequence of flashes or rapidly changing image sequences where all three of the following occur:

1. There are more than three flashes within any one-second period; and
2. The flashing is below 55 Hz; and
3. The combined area of flashes occurring concurrently and contiguously occupies more than a total of .006 steradians (25% of any 10 degree visual field on the screen).

• For the general flash threshold, a flash is defined as a pair of opposing changes in relative luminance of 10% or more and the relative luminance of the darker image is below 0.80. An "opposing change" is an increase followed by a decrease, or a decrease followed by an increase.
• For the red flash threshold, a flash is defined as any transition to or from a saturated red.
• Note 1: For general Web content, using a 341 x 256 pixel rectangle anywhere on the displayed screen area when the content is viewed at 1024 x 768 pixels will provide a good estimate of a 10 degree visual field for standard screen sizes and viewing distances.

Status: Done
Text from: Web/Software

Information Technology

Any equipment or interconnected system or subsystem of equipment, that is used in the automatic acquisition, storage, manipulation, management, movement, control, display, switching, interchange, transmission, or reception of data or information. The term information technology includes computers, ancillary equipment, software, firmware and similar procedures, services (including support services), and related resources.

Status: Done
Text from: Subpart A

Informational Animation

An animation that conveys some information required for understanding content or functionality.

Status: Done
Text from: Web/Software

Interactive Elements

• Text coming from A/V Subcommittee

Since this term is used in multiple places, it really must be defined.

Large Scale Text

At least 18 point or 14 point bold

• Note 1: Fonts with extraordinarily thin strokes or unusual features and characteristics that reduce the familiarity of their letter forms are harder to read, especially at lower contrast levels.
• Note 2: Font size is the size when the content is delivered. It does not include resizing that may be done by a user.

Status: Done
Text from: Web/Software

Menu

Set of selectable options

Status: Done
Text from: Telecommunications
Source: HFES 200

Operable Controls

Any physical control that affects the operation of the product. Operable controls include, but are not limited to, mechanically operated controls, input and output trays, card slots, keyboards, keypads, keys, or buttons, including touch-screens.

Status: Done
Text from: Hardware

Discussion or Rationale: This draft adds individual keys and buttons, as I've inspected many devices that have only those features where the manufacture thought Section 508 didn't apply because it didn't have "a full keyboard".

There was an interesting exchange on the Listserv on this topic regarding full functionality and normal operation.

The question of if this should be "physically operable controls" so it is more specific was raised, but determined to not be needed.

Other Services To Cooperate With Assistive Technologies

A method, other than the platform accessibility services, used to interoperate with assistive technologies.

Status: Done
Text from: Web and Software

Peak Non-crisis Network Traffic

The peak measured network traffic excluding disasters and other crises, or the peak traffic the system is designed to handle.

Status: Done
Text from: Telecommunications

Personal-Private

• Text coming from Self-Contained/Closed.

Platform Accessibility Services (was Accessibility Services)

Services provided by a platform enabling interoperability with assistive technology sometimes in the form of accessibility APIs (application programming interfaces)

Status: Done
Text from: Web/Software

Platform Software

Collection of software components that runs on an underlying software or hardware layer, such that the platform creates a virtual environment in which to run applications in a manner which isolates the applications from the underlying layer.

• Note 1: If there is a direct route from the application to the underlying layer then the software components in the middle are not considered to be a "platform". For example, a program which hosts plug-in's is not a platform if the plug-in can directly access the underlying layer.
• Note 2: An application offering a compute service, such as a 3d rendering engine where a requesting application can directly access the underlying layer would also not be considered a "platform".
• Note 3: A particular software component may play the role of a platform in some situations and not in others. Platforms can include such things as Internet browsers, operating systems, plug-ins to internet browsers or other software applications, and under some situations, byte-code interpreted virtual environments, and other "programming within another programming" environments.
• TBD: Notes about bootloader programs and closed systems?

Status: In Progress
Text from: Web/Software

Product

The subcommittee recommends that this term be deleted and that the recommendations uses the term "E&IT" in place of "product" throughout.

Status: Done
Text from: Subpart A

Programatically Determined

Can be determined by software from data provided in a user-agent-supported manner such that various user agents including assistive technologies can extract and present this information to users in different modalities.

Status: Done
Text from: Web/Software

Real-time Text

Communications that employ the transmission of text wherein the characters are transmitted by a terminal within a maximum of 1 second of character input. This would typically be for conversational purposes but also may be used in voicemail, IVR and other similar applications.

Status: Done
Text from: Telecommunications

Relative Luminance

The relative perceived brightness of any point, normalized to 0 for black and 1 for maximum white

• Note 1: The relative luminance of an sRGB color is defined as L = 0.2126 * R + 0.7152 * G + 0.0722 * B where R, G and B are defined as:
  • if RsRGB <= 0.03928 then R = RsRGB/12.92 else R = ((RsRGB+0.055)/1.055) ^ 2.4
  • if GsRGB <= 0.03928 then G = GsRGB/12.92 else G = ((GsRGB+0.055)/1.055) ^ 2.4
  • if BsRGB <= 0.03928 then B = BsRGB/12.92 else B = ((BsRGB+0.055)/1.055) ^ 2.4 and RsRGB, GsRGB, and BsRGB are defined as:
    • RsRGB = R8bit/255
    • GsRGB = G8bit/255
    • BsRGB = B8bit/255
• The "^" character is the exponentiation operator. (Formula taken from [sRGB] and [IEC-4WD]).
• Note 2: Almost all systems used today to view Web content assume sRGB encoding. Unless it is known that another color space will be used to process and display the content, authors should evaluate using sRGB colorspace. If using other color spaces, see Understanding Success Criterion 1.4.3.
• Note 3: For dithered colors, use average values of the colors used (average R, average G, and average B).
• Note 4: Tools are available that automatically do the calculations when testing contrast and flash.
• Note 5: A MathML version of the relative luminance definition is available.

Status: Done
Text from: Web/Software

Shared-Public

• Text coming from Self-Contained/Closed.

Telecommunications

The transmission, between or among points specified by the user, of information of the user's choosing, without change in the form or content of the information as sent and received. (Telecommunications Act of 1996)

Status: Done
Text from: Telecommunications
Source: Telecommunications Act of 1996

Terminal

Device or devices with which the end user directly interacts and that provide the user interface.

NOTE: For some systems, the software that provides the user interface may reside on more than one device such as a phone and a server.

Status: Done
Text from: Telecommunications

TTY

An abbreviation for teletypewriter. Machinery or equipment that enables interactive text based communications through the transmission of frequency-shift-keying audio tones across the PSTN according to TIA-825-A (A Frequency Shift Keyed Modem For Use On The Public Switched Telephone Network). As used in this part, the term TTY includes devices for text-to-text communications along with voice and text intermixed communications such as voice carry over and hearing carry over. TTYs may include computers with special modems. TTYs are a subset of devices called text telephones.

Status: In Progress
Text from: Telecommunications

Undue Burden

Undue burden means significant difficulty or expense. In determining whether an action would result in an undue burden, an agency shall consider all agency resources available to the program or component for which the product is being developed, procured, maintained, or used.

Status: Done
Text from: Subpart A (no change)

Video Description

The insertion of verbal or auditory description(s) of on-screen visuals intended to describe important visual details that are not contained in, or that cannot be understood from, the main audio output alone. Video descriptions supplement the regular audio track of the program and are usually inserted between dialogue narration to provide information about actions, characters, and on-screen text that appear without verbalization. Video descriptions are a way to let people who are blind or have low vision know what is happening on screen.

Video description guidelines: The American Foundation for the Blind along with the National Center for Accessible Media at WGBH (NCAM), under contract from the Described and Captioned Media Program (U.S. Department of Education) administered by the National Association of the Deaf, is developing guidelines and best practices for authoring video description. As of August 2007, a first draft has been developed by an expert committee of academics, educators, producers, consumers and others. These guidelines should be completed by the end of 2008.

EWG recommendation: Change second paragraph to read: This definition should not conflict with the guidelines produced by the American Foundation for the Blind along with the National Center for Accessible Media at WGBH (NCAM), under contract from the Described and Captioned Media Program (U.S. Department of Education) administered by the National Association of the Deaf.

Status: Done
Text from: Audio-Video

Web Content

Content which is made available in the World Wide Web.

Alternate proposal: Remove as this is not used in any provisions.

Status: In Progress
Text from: Web and Software

Web Page

• Text coming from Web and Software Subcommittee.

Discussion information can be found on http://teitac.org/wiki/Web_and_Software:_Definitions.

World Wide Web

A very large set of hypertext-linked content files located on computers connected by the Internet.

Alternate proposal: Remove as this is not used in any provisions.

Status: In Progress
Text from: Web and Software

Section 1194.5 Equivalent Facilitation

Nothing in this part is intended to prevent the use of designs or technologies as alternatives to those prescribed in this part provided they result in substantially equivalent or greater access to and use of a product for people with disabilities.

Status: Done
Source: {508}1194.5, no change

Technical Provisions

1. Requirements for All Product and Services

Updates and discussion for provisions in this section

1.1 Functional Performance Criteria

Discussion or Rationale: There is a lot of ongoing discussion as to whether the Functional Performance Criteria should be moved to the end of the technical provisions and before the documentation/technical support provisions. There are questions regarding when the functional criteria should be used. There are also two proposals for an introductory paragraph for the section. These are not resolved at this time and are being discussed in the subcommittee and will be raised at the Sept plenary if necessary.

Version 1: If an E&IT product fails to meet one or more of the technical provisions above, meets it via equivalent facilitation, or if the technical provisions do not apply, the agency shall ensure that that the purpose of the technical provisions is met through the following functional performance criteria.

Version 2: After the technical requirements are applied, the following functional performance criteria must be applied to:
1) see if the technical provisions cover all aspects needed to provide access to the product,
2) check any equivalent facilitation, and
3) see if access can be provided in another way if any of the technical provisions are not met.

1.1-A - Without Vision

Products must provide at least one mode that allows [access] without using vision. This access may be provided directly or through assistive technology.

NOTE: The phrase "comparable access" or "access" is still being worked out.

• Status: In Progress
• Text from General
• Source: {508}1194.31(a), {255}1193.31
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities: Blindness
  • User Activities: All
  • Product Characteristics: All
  • Product Types: All

1.1-B - With Limited Vision

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

Version 2: Products must provide at least one mode that allows [access] without requiring visual acuity greater than 20/70. This mode must allow audio or enlarged text output to work together or independently, directly or through assistive technology."

Rationale for Version 2: The recommended edit is audio "or" enlarged text output. For small handheld products, it may be difficult to accommodate enlarged text in some cases and audio output may be the most practical alternative. This edit would allow more flexibility appropriate to a wider variety of products.

NOTE: The phrase "comparable access" or "access" is still being worked out.

• Status: In Progress
• Text from General
• Source: {508}1194.31(b), {255}1193.41(b)
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities: Low vision
  • 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.

Discussion or Rationale:

• Reword to ensure that this is a visual mode, and does not allow provisions for blindness to meet this provision.
• Is this covered by testable provisions, below.

NOTE: The phrase "comparable access" or "access" is still being worked out.

• Status: In Progress
• Text from General
• Source: new
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities: Color deficiency/Colorblindness
  • User Activities: All
  • Product Characteristics: All
  • Product Types: All

1.1-D - Without Hearing

Products must provide at least one mode that allows [access] without using hearing. This [access] may be provided directly or through assistive technology.

NOTE: The phrase "comparable access" or "access" is still being worked out.

• Status: In Progress
• Text from General
• Source: {508}1194.31(c), {255}1193.41(d)
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities: Deafness, Deaf-blindness, Other combined hearing/vision loss
  • 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, it must provide at least one mode that [allows] access with enhanced audio. This [access] may be provided directly or through assistive technology.

NOTE: The phrase "comparable access" or "access" is still being worked out.

• Status: In Progress
• Text from General
• Source: {508}1194.31(d), {255}1193.41(b)
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities: Hard of hearing,
  • User Activities: All
  • Product Characteristics: All
  • Product Types: All

1.1-F - Without Speech

Products must provide at least one mode that allows [access] without using speech. This [access] may be provided directly or through assistive technology.

NOTE: The phrase "comparable access" or "access" is still being worked out.

• Status: In Progress
• Text from General
• Source: {508}1194.31(e), {255}1193.41(h)
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities: Speech
  • User Activities: All
  • Product Characteristics: All
  • Product Types: All

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

Products must provide at least one mode that [allows] access without for people with limited reach and strength, and that does not require simultaneous actions. This [access] may be provided directly or through assistive technology.

NOTE: The phrase "comparable access" or "access" is still being worked out.

Discussion or Rationale: Adds AT option.

• Status: In Progress
• Text from General
• Source: {255}1193.41(e)
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities: Dexterity, Mobility
  • User Activities: All
  • Product Characteristics: All
  • Product Types: All

1.1-H - With No Reach or Touch

Except for closed products, products must provide at least one mode that allows control through assistive technologies to allow [access] for people with no reach or ability to touch.

Discussion or Rationale: This provision is proposed to address 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 issues, but we haven't yet figured out wording that we can reach consensus on or whether it is covered elsewhere.

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

NOTE: The phrase "comparable access" or "access" is still being worked out.

• Status: In Progress
• Text from General
• Source: new
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities: Dexterity, Mobility
  • User Activities: All
  • Product Characteristics: All
  • Product Types: All

1.1-I - With Cognitive, Language or Learning Limitations

Products provide at least one mode that accommodates cognitive, language or learning impairments, directly or with assistive technology.

Discussion or Rationale: This provision is here as a placeholder. 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.

• Status: In Progress
• Text from General
• Source: {255}1194.41(i)
• Impact:
• 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 Functions

If any product functionality 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.

Discussion or Rationale:

• Status: Done
• Text from Self Contained, Closed
• Source: {508}1194.25(a)
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities: All
  • User Activities: All
  • Product Characteristics: 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 or Rationale: The hardware portion of this provision is still under development.

• Status: In Progress
• Text from Self Contained, Closed
• Source: {508}1194.21(k) 1194.22(j) 1194.25(i), and {255}1193.43(f)
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities: All
  • User Activities: All
  • Product Characteristics: All
  • Product Types: All

1.2-C - Biometric ID

If a product uses biometric forms of user identification, control, or activation, which rely on a person possessing one unique biological characteristic, an alternative form of identification, control, or activation must also be provided. This alternative may use alternate biometric unique characteristics, use a biometric characteristic that all people have, or not use biometrics. Agencies must provide an alternate means of access for anyone who can not use the provided biometrics-based form of identification, control, or activation.

Explanatory note: People who do not have fingers, eyes, etc are not able to make use of biometrics-based E&IT simply because currently these solutions rely upon only one unique biometric measurement, such as a fingerprint. Allowing such solutions to accept alternative biometrics will greatly decrease the number of people who are unable to use such biometrics solutions, since people with multiple disabilities of this type are a smaller portion of the population. This, however, is only an interim step until biometric or nonbiometric alternatives are identified and integrated into security best practices that "all people" regardless of disability are able to use. For example, one potential solution may rely only upon circulation; if this is a characteristic of all people, it would be an accessible biometric.

Until non-biometric forms of identification, control or activation have been integrated into security best practices, such biometric-based systems must be developed to allow multiple biometrics to be used. Alternatively, until a biometric solution is identified that all people can use, biometrics systems that use multiple biometrics or non-biometrics must be employed. Fingerprints and retina patterns are just two examples. It is less likely for people to be missing fingerprints and retinas than either one alone. However, even when multiple biometrics are provided, alternate means of access must also be provided (in policy and implementation) for anyone who cannot use any of them. For example, if someone has neither retinas nor fingers, another procedure, which could involve physical assistance, is needed to provide comparable access.

We strongly recommended that the Access-Board direct research to identify nonbiometrics forms of identification, control or activation, or biometric alternatives that all people can make use of, to be integrated into security best practices and standards in the near future.

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

• Status: In Progress
• Text from General
• Source: {508}1194.21(k) 1194.22(j) 1194.25(i), and {255}1193.43(f)
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities: All (that could be caused by loss body part or function)
  • User Activities: All
  • Product Characteristics: All
  • 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 communications 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.

New language added:

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

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

Discussion or Rationale: for PSTN this would be TIA/EIA 825 Baudot. There is also the question to be resolved: If this regulation were adopted, would products such as a simple voice-only office intercom system or basic voice-only walkie-talkie be regarded as non-compliant? Or would they be exempt because there is no text communication standard for those platforms?

• Status: In Progress
• Text from Telecommunications
• Source: {508}1194.23(j), {255}1193.37
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

1.2-E - Audio information

All information that is needed for operation and use that is provided in audio form must also be available in visual form, either directly or via assistive technology.

• Status: Done
• Text from Self-Contained/Closed
• Source: {255}1194.43(d)
• 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 that is needed for operation and use that is provided in visual form must also be available in audio form and, where appropriate, in tactile form, either directly or via assistive technology.

• Status: Done
• Text from Self-Contained/Closed
• Source: {255}1194.43(a)
• 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.

Discussion or Rationale: Harmonize with Color (Web)

• Status: In Progress
• Text from General
• Source: {508}1194.25(g) and 1194.21(i)
• 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

• Status: In Progress
• Text from Self-Contained/Closed
• Source: {255}1193.43(b)
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities: Low vision
  • User Activities: All
  • Product Characteristics: Visual display with text
  • Product Types: All

1.2-I - Contrast

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

• Status: In Progress
• Text from Hardware
• Source:
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

2. Hardware Aspects of Products

Updates and discussion for provisions in this section

2.1 All Products with Hardware

2.1-A - Contrast for displays

This is a placeholder for a provision still being written to define contrast for LCD hardware.

Discussion or Rationale: LCD capabilities – define contrast

• For contrast ratios from hardware perspective for active displays (backlit displays such as an LCD) and passive displays.
• Does this apply to cell phones? Yes - need feedback from telecomms industry.

• Status: In Progress
• Text from Hardware
• Source: {508} 1194.26(b); {508} 1194.25(c)
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

2.1-B - Contrast for labels

This is a placeholder for a provision still being written.

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

• Status: In Progress
• Text from Hardware
• Source: {508} 1194.26(b); {508} 1194.25(c)
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

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

This does not imply that a product must be entirely operable with one hand (eg, product could be placed on a surface).

• Status: Done
• Text from Hardware
• Source: {508} 1194.26(a); 1194.23(k)
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities: All
  • User Activities: Conversations, data analysis, document sharing and reviewing, media (audio/video) creation and editing.
  • Product Characteristics: 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 similar peripherals

2.1-D - Touch Operated

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

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

Version 2a - If a product utilizes touch screens or touch-operated controls, a functionally equivalent means of input/interaction/control must be provided. Any mechanical controls employs in the equivalent input/interaction/control must comply with the Mechanical Controls provision.

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.

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

Discussion points from meeting: What is "equivalent"?

• Keyboard controls that provide equivalent functionality are equivalent
• Touch screens can't always provide a 1:1 match of soft and mechanical controls.
• Is providing a USB port equivalent? Rob says "yes" and asks for language to cover it.
• Need to add to V2 that it's possible to operate these controls without the use of the touchscreen.
• What about speech or remote control software.
• Note that for some disabilities, touch screen is better
• This was originally part of closed products - there are differences between closed and open products. Final language must address this.

• Status: In Progress
• Text from Hardware
• Source: {508} 1194.26(b); {508} 1194.25(c)
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities: All
  • User Activities: Conversations, data analysis, document sharing and reviewing, media (audio/video) creation and editing
  • Product Characteristics: 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-E - Standard Connection

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 for that type of input or output.

• If there are proprietary protocols in the terminal, so long as the protocols are over a standard physical connection, cooperation between E&IT vendors and AT vendors should make it possible for the device to be compatible with AT.

• If an adapter is required to convert a proprietary connector on an E&IT device into a standard connector, it must be the responsibility of the E&IT vendor to provide the adapter.

Discussion or Rationale: Comments about the need for proprietary connections (keeps product lines closed to competitors), and the related issue of not requiring AT to match many different proprietary connections.

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.

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.

• Status: In Progress
• Text from Hardware and Telecommunications
• Source: {508} 1194.26(d)
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities: All
  • User Activities: Conversations, data analysis, document sharing and reviewing, media (audio/video) creation and editing
  • Product Characteristics: 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-F - Free-Standing

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: Need to add "freestanding" to the definitions. - Decision made to not define it. Asking for input from plenary.

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.

• Status: Done
• Text from Hardware
• Source: {508} 1194.25(j)
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities: All
  • User Activities: Conversations, data analysis, document sharing and reviewing, media (audio/video) creation and editing
  • Product Characteristics: 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.2 If the Product has Speech Output or Throughput

2.2-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 or Rationale: 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)

• Status: In Progress
• Text from Hardware and Telecommunications
• Source: {508}1194.23(h), {255}11943.43(i)
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

2.2-B - Interference with Hearing Device

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

Version 2: Potential sources of interference to hearing technologies (including hearing aids, cochlear implants, and assistive listening devices) must be reduced as much as possible to provide a more compatible environment for a user of hearing technologies to utilize the telecommunications product.

Version 3: Interference to hearing technologies (including hearing aids, cochlear implants, and assistive listening devices) must be reduced to the lowest possible level. The interface level must allow a user of hearing technologies to utilize the telecommunications product.

Discussion or Rationale: This comes from Telecom SC and must be reconciled Hardware SC. There are questions about testability of "to the lowest level" and "as much as possible".

• Status: In Progress
• Text from Hardware and Telecommunications
• Source: {508}1194.23(i), {255}11943.43(h)
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities: Hearing, Hard of Hearing
  • User Activities:
  • Product Characteristics:
  • Product Types:

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

• Status: In Progress
• Text from Hardware
• Source: {508} 1194.23(e); {255} 1193.51(b) & (g)
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities: All
  • User Activities: Conversations, data analysis, document sharing and reviewing, media (audio/video) creation and editing.
  • Product Characteristics: 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 peripherals

2.2-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. Question about where are volumes set? Is that where you measure from? Does this overlap with 2.3.E?

• Status: In Progress
• Text from Self-Contained/Closed
• Source: {508}1194.25(f), {255}1193.43(e)
• 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.2-E - Volume (Gain)

For incoming voice signals:

1. Analog line-powered telecommunications products, wireline, and all cordless telephones (wireline or VoIP) must comply with FCC regulation §68.317 for volume control
2. All cellular phones - TBD
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.

Discussion or Rationale:

• Language for cellular phones pending outcome of ATIS Study Group 11 work
• Further research needed for 20 dB requirement
• Review telecoms/communications to be sure requirement is inclusive
• Need to determine if the phrase "telecommunications products" should be removed

• Status: In Progress
• Text from Telecommunications
• Source: {508}1194.23(f)
• 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.2-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 control may be provided to prevent the automatic reset, subject to the conditions specified in FCC Memorandum Opinion and Order DA 01-578. This applies to products with transducers held against the ear which are neither headsets nor headphones

• Status: Done
• Text from Telecommunications
• Source: {508}1194.23(g)
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

3. User Interface and Electronic Content Provisions

These provisions apply to all electronic user interfaces and content.

Discussion or Rationale: Sections 3 and 6 have been combined. The following sort of provisions is as requested by the subcommittee

3-A - Color

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

Discussion or Rationale: Need to add an example

• Status: In Progress
• Text from Web and Software
• Source: {508}1194.25(g) and 1194.21(i) (was 6.1.A in July 18 draft)
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

3-B - Contrast

Presentation of text (and images of text) in electronic documents 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.

Discussion or Rationale: Harmonization with WCAG 2.0.

• Status: Done
• Text from Web and Software
• Source: new (was 3.2.A and 6.1.B in July 18 draft)
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

3-C - Non-text content

Non-text Content: All non-text content must have 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 must have a name that describes its purpose. (See also User Interface Components provisions)
• Media: If non-text content is multimedia, live audio-only or live video-only content, then text alternatives at least identify the non-text content with a descriptive text label. (For multimedia, see also Audio and/or Video provisions)
• Test: If non-text content is a test or exercise that must be presented in non-text format, then text alternatives at least identify the non-text content with a descriptive text label. (For multimedia, see also Audio and/or Video provisions)
• Sensory: If non-text content is 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 must be provided and alternative forms in different modalities must be provided to accommodate different disabilities.
• Decoration, Formatting, Invisible Content: 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.

editorial suggestion: Non-text Objects: All non-text objects must have a text alternative that presents equivalent information, except for the situations listed below.

• Controls-Input: If a non-text object is a control or accepts user input, then it must have a name that describes its purpose. (See also User Interface Components provisions)
• Media: If a non-text object is multimedia, live audio-only or live video-only content, then text alternatives at least identify the non-text object with a descriptive text label. (For multimedia, see also Audio and/or Video provisions)
• Test: If a non-text object is a test or exercise that must be presented in non-text format, then text alternatives at least identify the non-text object with a descriptive text label. (For multimedia, see also Audio and/or Video provisions)
• Sensory: If a non-text object is primarily intended to create a specific sensory experience, then text alternatives at least identify the non-text object with a descriptive text label. (For multimedia, see also Audio and/or Video provisions)
• CAPTCHA: If the purpose of a non-text object 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 object must be provided and alternative forms in different modalities must be provided to accommodate different disabilities.
• Decoration, Formatting, Invisible Objects: If a non-text object 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:

• Status: In Progress
• Text from Web and Software
• Source: {508}1194.22(a) (was 6.1.E in July 18 draft)
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

3-D - Human Language

When presentation of electronic documents supports it, the default human language of electronic documents can be programmatically determined.

Discussion or Rationale: TBD: platform option for specifying document language should be okay

• Status: In Progress
• Text from Web and Software
• Source: new
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

3-E - Language of Parts

When presentation of electronic documents supports it, the human language of each passage or phrase in electronic documents can be programmatically determined.

Discussion or Rationale:

• Status: In Progress
• Text from Web and Software
• Source: new
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

3-F - Pausing

Moving, blinking, scrolling, or auto-updating information must allow pausing by the user unless it is part of an activity where timing or movement is essential. Such content that is pure decoration must at least allow stopping by the user.

Discussion or Rationale: Harmonization with WCAG 2.0.

• Should also allow hiding of decorative content.

• Status: In Progress
• Text from Web and Software
• Source: new (was 6.1.M in July 18 draft)
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

3-G - Flashing

Content and applications must not contain anything that flashes more than 3 times in any one second period or the flashing is below the general flash and red flash thresholds.

editorial suggestion: User interfaces and content must not contain anything that flashes more than 3 times in any one second period or the flashing is below the general flash and red flash thresholds.

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

• Status: Done
• Text from Web and Software
• Source: {508}1194.21(k) 1194.22(j) 1194.25(i), and {255}1193.43(f) (was 6.1.D in July 18 draft)
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

3-H - Consistent Identification

Components that have the same functionality must be identified consistently. (Updated Aug 24, 2007)

Prior version was: 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.

• Status: Done
• Text from Web and Software
• Source: new (was 6.1.L in July 18 draft)
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

3-I - Size, shape, location

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

• Note: Object information provided per the "Information and Relationships", "User Interface Components", or "AT interoperability" provision that describes the necessary visual cues or relationships is sufficient.

Discussion or Rationale:

• Status: Done
• Text from Web and Software
• Source: new
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

3-J - Audio Turnoff

If any audio plays automatically for more than 3 seconds, either a mechanism is available to pause or stop the audio, or a mechanism is available to control audio volume which can be set independently of the system volume.

Discussion or Rationale:

• Status: Done
• Text from Web and Software
• Source: {508}1194.25(e) - Second sentence (was 4.1.C in July 18 draft)
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

3-K - Reading Sequence

When the sequence in which information is presented affects its meaning, a correct reading sequence can be programmatically determined and sequential navigation of interactive components is consistent with that sequence.

editorial suggestion: When the sequence in which information is presented affects its meaning, a correct reading sequence must be programmatically determinable and sequential navigation of interactive components must be consistent with that sequence.

Discussion or Rationale:

• Status: Done
• Text from Web and Software
• Source: new (was 6.1.N in July 18 draft)
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

3-L - Repeated Blocks

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

Discussion or Rationale: Harmonization with WCAG 2.0. "blocks of content" is vague. Since this is harmonized with WCAG, we are raising the issue with the WCAG group.

• Status: Done
• Text from Web and Software
• Source: {508}1194.22(o) (was 6.1.F in July 18 draft)
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

3-M - Link Purpose

On Web pages, it must be possible to determine the purpose of each link from the link text or the link text together with its 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.

• Status: Done
• Text from Subcommittee
• Source: New (was 6.1.H in July 18 draft)
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

3-N - 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
4. markup is used to identify form element labels

editorial suggestion for first paragraph: Information and relationships conveyed through presentation must be either programmatically determinable or are available in text, and notification of changes to these is available to user agents, including assistive technologies. For example:

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.

• Status: Done
• Text from Web and Software
• Source: New (was 6.1.I in July 18 draft)
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

3-O - User Interface Components

For all user interface components, including form elements and those generated by scripts

• the name and role must be programmatically determined
• states, properties, and values that can be set by the user must be programmatically determined and can be programmatically set, and
• notification of changes to these items is available to user agents, including assistive technologies.

For example: Frames must be titled with text that facilitates frame identification and navigation.

editorial suggestion, version 1: For all user interface objects, including form elements and those generated by scripts

• the name and role must be programmatically determined
• states, properties, and values that can be set by the user must be programmatically determined and can be programmatically set, and
• notification of changes to these items is available to user agents, including assistive technologies.

For example: Frames must be titled with text that facilitates frame identification and navigation.

editorial suggestion, version 2: For all user interface components, including form elements and those generated by scripts, the name and role must be programmatically determined. States, properties, and values that can be set by the user must be programmatically determined and can be programmatically set. Notification of changes to these items must be available to user agents, including assistive technologies. For example: 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.

• Status: Done
• Text from Web and Software
• Source: New (was 6.1.K in July 18 draft)
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

3-P - User Preferences

Applications must provide a mode that utilizes platform settings for color, contrast, font type, font size, and focus cursor. In the absence of platform settings for color and contrast, all text (and images of text) must have a contrast ratio of at least 5:1 except for unavailable items or pure decoration. Large scale text (or images of large scale text) must allow a contrast ratio of at least 3:1.

Discussion or Rationale:

• Status: Done
• Text from Web and Software
• Source: {508}1194.21(g) (was 3.2-C in July 18 draft)
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

3-Q - Color Adjustment

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. editorial suggestion: When a user interface 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.

Discussion or Rationale:

• Status: Done
• Text from Web and Software
• Source: new
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

3-R - Disruption of Access Features

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

Discussion or Rationale:

• Status: Done
• Text from Web and Software
• Source: {508}1194.21(b) (was 3.1.A in July 18 draft)
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

3-S - Timing

For each time limit that is set by the software or 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.

editorial suggestion: Change "software or content" to "user interface or content"

Discussion or Rationale: The recommended change is harmonized with both the ISO Software Accessibility standard and WCAG 2.0.

• In Adjust, issue with "before encountering"
• In Essential Exception, still discussing the suggestion to add something about data integrity.
• "Sufficient time" is not objectively testable. There are other acceptable strategies for addressing the needs of users who need more time.

• Status: In Progress
• Text from Web and Software
• Source: New (incorporates {508}1194.22(p), {508}1194.23(d), {508}1194.25(b), and {255}1193.41(g) (was 3.1.B and in the July 18 draft)
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

3-T - Keyboard Operation

All functionality of the product operable through the user interface must be operable through a keyboard interface without requiring specific timings for individual keystrokes. The only exception is 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, such as gestures, in addition to keyboard operation.

editorial suggestion for first paragraph: All functionality operable through the user interface must be operable through a keyboard interface without requiring specific timings for individual keystrokes. The only exception is where the underlying function requires input that depends on the path of the user's movement and not just the endpoints.

Discussion or Rationale: Harmonized with WCAG 2.0 and ISO 9241 part 171.

• Status: Done
• Text from Web and Software
• Source: {508}1194.21(a) (was 3.3.A in July 18 draft)
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities: Blindness, Physical
  • User Activities: All
  • Product Characteristics: 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-U - Focus Cursor

Software must support at least one mode that provides a highly visual indication of which user interface object currently has the keyboard focus.

• Note: If the object is a text entry field, a visual indication of the text insertion point is sufficient as a focus cursor.
• Note: A focus cursor that is visually locatable by people with unimpaired vision at 2.5 meters when software is displayed on a 38 cm (15 inch) diagonal screen at 1024 x 768 pixels resolution, without moving the cursor is sufficient.

editorial suggestion for first paragraph: User interfaces must support at least one mode that provides a highly visual indication of which user interface object currently has the keyboard focus.

Discussion or Rationale: The note providing a testable sufficient technique for determining "highly visual" is not final. Focus cursors are provided by user agents for some technologies (HTML, PDF, etc.) but are needed for other technologies (JavaScript, Flash, etc.)

• Status: In Progress
• Text from Web and Software
• Source: New (was 6.1.J in July 18 draft)
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities: Blind, Physical
  • User Activities: All
  • Product Characteristics: Involves Web Content or Applications
  • Product Types: Web Content; Software (installed or through browser); Network Interface to devices; Desktop Computer Systems; Portable Computer Systems

3-V - AT Interoperability

On platforms that support 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
  • the row and column an object is in, and the headers for the row and column for that object if it is in a table that has row or column headers.
  • current value and any minimum or maximum values, if the object represents one of a range of values
  • relationship this object has as a label for another object, or being labeled by another object
  • 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.

editorial suggestion for the first paragraph: On platforms that support AT interoperability, 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:

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.

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.

• Status: In Progress
• Text from Web and Software
• Source: {508}1194.21(d) (was 3.4-A in July 18 draft)
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities: Blindness
  • User Activities: All
  • Product Characteristics: 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-W - Both 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:

• Status: Done
• Text from Web and Software
• Source: New (was 3.1.C in July 18 draft)
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities: All
  • User Activities: All
  • Product Characteristics: All
  • Product Types: Software (installed or through browser); Network Interface to devices; Desktop Computer Systems; Portable Computer Systems

3-X - Advisory Notes

The following are recommended best practices. As they are not testable criteria, they should not be included in the normative requirements for compliance with Section 508 or 255.

1. Suppression of unneeded function

Software should provide a mechanism enabling users to simplify the interface including the modification or hiding of command buttons. If such a function is provided, a mechanism should be provided to reset to the default user interface.

• EXAMPLE 1 A user with a cognitive disability may, when using a given application, change the interface via a “skin” to simplify the application’s look and feel.
• EXAMPLE 2 A word processor allows users to hide menu items and tool bar buttons that they do not find useful.

2. Writing guidelines

Authors should follow best practices for creating content that is accessible for people with disabilities. These guidelines include:

1. Organize the content to serve the reader's needs, considering their tasks and goals.
2. Use everyday words that convey meaning clearly and directly.
3. Use the present tense and the active voice.
4. Use short, simple sentences.
5. Include useful headings.
6. Use lists and tables to simplify complex material.

3. Interaction guidelines

Applications should design interaction paradigms that are accessible for people with disabilities including:

1. Provide a means to undo actions, such as by resetting the form to the original information
2. Provide a way to move backwards one step in a process to fix mistakes or check answers
3. Provide a way to cancel actions before submitting

Discussion or Rationale:

• Status: Done
• Text from Web and Software
• Source: new
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

4. Additional Provisions for Audio-Visual Players or Displays

4-A - Caption Playback

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

1. Equipment of this type:

• Analog television displays that measure 13 inches or more diagonally
• Computer equipment that includes analog television receiver or display circuitry

Uses this standard:

• CEA 608

To provide these functions:

• Receive, decode and display signals from
• broadcast
• cable
• satellite
• videotape
• DVD
• other recorded media

2. Equipment of this type:

• 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

Uses this standard:

• CEA 708

To provide these functions:

• Receive, decode and display signals from:
  • broadcast
  • cable
  • satellite
  • videotape
  • IPTV

OR

• Decode data, when available, and pass a decoded ("open-captioned") video signal to the DTV display or monitor

3. Equipment of this type:

• Other digital video source devices including personal video display devices

Uses this standard:

• CEA 708 or functional equivalent (see end-note for definition of functional equivalent)

To provide these functions:

• Pass caption data, when available, to the caption decoding circuitry of DTV displays

OR

• Decode caption data, when available, and pass a decoded ("open-captioned") video signal to the DTV display or monitor. For personal video display devices, decoding of caption data will be subject to the "readily achievable" standard; if decoding of caption data is not "readily achievable," open-captioned video must be supplied for use on that device.

Material for inclusion in the additional notes document:

TEITAC definition of "Functional Equivalent" to CEA 708

Equivalent text display functionalities must:

• Support caption placement control by caption authors for any position within the TV safe area.

• Support standard, large, and small caption sizes and must allow the caption author to choose a size and allow the viewer to choose an alternative size.

• Support eight font variations. Caption authors may specify one of these eight font styles to be used to write caption text. Equivalents must include the ability for users to choose among the eight fonts. The equivalent must display the font chosen by the caption author unless the user chooses a different font.

• Support the eight font styles defined as follows: default (undefined), monospaced with serifs (similar to Courier), proportionally spaced with serifs (similar to Times New Roman), monospaced without serifs (similar to Helvetica Monospaced), proportionally spaced without serifs (similar to Arial and Swiss), casual font type (similar to Dom and Impress), cursive font type (similar to Coronet and Marigold), and small capitals (similar to Engravers Gothic).

• Support author and user choice of eight character foreground and eight character background colors: white, black, red, green, blue, yellow, magenta and cyan).

• Support author and user selection of character and background opacity options: SOLID, TRANSLUCENT, TRANSPARENT [FLASH option deleted]

• Support options for altering the appearance of caption character edges.

• Support the authoring and selection of the six caption services, but information from only one service need be displayed at a given time.

• Include an option that permits a user to choose a setting that will display captions as intended by the caption provider (a default). Equivalents must also include an option that allows a viewer's chosen settings to remain until the viewer chooses to alter these settings, including during periods when the video source device is powered off.

• Support interoperability and conversion between other common caption formats such as CEA 608, CEA 708, Timed Text (DFXP).

• Status: Done
• Text from A/V
• Source: new
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

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

• Status: Done
• Text from A/V
• Source: new
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

5. Additional Provisions for Real-time Voice Conversation Functionality

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 or Rationale: 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.

Suggest striking "telecommunications products" from the first bullet, so this applies to all products. Possibly move to Section 1.2?

• Status: In Progress
• Text from Telecommunications
• Source: new
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

5-B - Real-Time Text Reliability and Interoperability

If hardware or software provides real-time voice conversation functionality it must provide 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);
   • RTT format must support intermixing of speech and text in both directions (and support speech and text simultaneously in both directions if IP based);
   • If product is IP based RTT format must not not rely upon audio tones for transmission of real-time text over IP.
2. Products and self-contained system 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 825 Baudot where it interfaces to the PSTN.
   • If product interfaces with other VoIP products or systems (outside of a self contained product-system) using SIP it must support RFC-4103 where it interfaces with other VoIP products or systems. If product uses SIP to interface with VoIP-to-PSTN Gateways it must also support RFC-4351. Gateways must support RFC-4103 and may support RFC-4351.
   • If product connects to other products or systems using a protocol other than SIP it must use the standard real-time text protocol that meets provision 1 above that has been established for that protocol.

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.

• Status: In Progress
• Text from Telecommunications
• Source: {508]1194.23(b), {255}1193.51(e), this is a combination of 5.B and 5.C in the July 18 draft
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

5-C - Voice Terminal Hardware and Software

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 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.
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.
3. If IP voice terminal hardware or software does not provide real-time text send and receive capability then the terminal must support the addition of terminals 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. 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.
4. 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 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;

• Status: In Progress
• Text from Telecommunications
• Source: {508}1194.23(a), {255}1193.51(d), this is a combination of 5.D and 5.E in the July 18 draft
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

5-D - IVR, Auto-Attendant and Messaging

Voice mail, messaging, auto-attendant, and interactive voice response telecommunications systems must provide access in the following manner:

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 recommendation 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, slow down and repeat all messages and prompts;
4. Provide prompts (either as provided by the vendor, or by the agency or customer) without any background sounds that would reduce intelligibility.

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

Discussion or Rationale: Telecommunications will provide an advisory note about Baudot and TTY.

• Status: In Progress
• Text from Telecommuncations
• Source: {508}1194.23(c), was 5.F in July 18 draft
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

5-E - Caller and Status Information

Products with visual interfaces that display telecommunications status information (such as caller identification and similar telecommunications functions) 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.

• Status: Done
• Text from Telecommuncations
• Source: {508}1194.23(e), was 5.G in July 18 draft
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

5-F - 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 they must have sufficient transmission bandwidth capacity to support video communication such as video relay and point to point video communications.

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

• Status: In Progress
• Text from Telecommuncations
• Source: new, was 5.H in July 18 draft
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

6. Audio and/or Video Content

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

• Status: Done
• Text from Web and Software
• Source: {508}1194.22(c) (was 3.2.A in July 18 draft)
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

6-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 video, and no original audio or other additional time-based content, must provide either a separate text description of the video or must provide an additional audio track to convey the informational content of the video.
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.

• Status: Done
• Text from A/V
• Source: {508}1194.24(c) (was 6.2.B in July 18 draft)
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

6-C - Video Description

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 original 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 video 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 video descriptions in real time to convey the informational content of the video.

• Status: Done
• Text from A/V
• Source: {508}1194.24(d) (was 6.2.C in July 18 draft)
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

6-D - Open or Closed Captions/Descriptions

At the time of playback, captions and/or video descriptions must be either (a) capable of being turned on and off ("closed"), or (b) visible or audible to all users ("open").

• Status: Done
• Text from A/V
• Source: {508}1194.24(e) (was 6.2.D in July 18 draft)
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

6-E - Interactive Elements

All "multimedia" containing interactive elements, such as menus for selection and access to segments of the content, that are part of the content must include verbal equivalents for menu selections.

• Status: Done
• Text from A/V
• Source: new (was 6.2.E in July 18 draft)
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

7. Information, Documentation and Support

Updates and discussion for provisions in this section

7.1 Product Documentation and Help

Discussion or Rationale: The question has been raised if provisions 1-3 should move to the general section 1.2 leaving only the advisory notes here.

7.1-A - Accessible Documentation and Features

Documentation for users on the installation, configuration, or use of the product including the description, installation, and use of accessibility 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, and user training or technical support materials.

Discussion or Rationale: This draft combines two provisions for a clearer requirement

• Status: Done
• Text from Documentation and Technical Support
• Source: {508}194.41(a), {508}194.41(b), {255}1193.33(a)(1)and {255}1193.33(a)(2)
• Impact: No Change
• External Reference:
• Testability:
• Metadata
  • Disabilities: All
  • User Activities: Training/learning
  • Product Characteristics: User documentation (any type – electronic or print)
  • Product Types: All

7.1-B - Keyboard Shortcuts

Information about keyboard shortcuts must be made available in documentation.

1. All shortcuts for keyboard operation must be listed in one place for easy reference.
2. When the documentation lists specific mouse based actions, the keyboard commands must also be listed.

Discussion or Rationale: This provision was created since it was felt the keyboard short cuts are hard to locate. The two methods of including them would meet the needs of all users. But this causes problems for applications that run on multiple platforms which can result in different shortcuts for the same action.

• Status: In Progress
• Text from Documentation and Technical Support
• Source: New
• Impact: +
• External Reference:
• Testability:
• Metadata
  • Disabilities: All
  • User Activities: Training/learning
  • Product Characteristics: User documentation (any type – electronic or print)
  • Product Types: All

7.1-X - Advisory Notes

Best practices for providing documentation to people with disabilities include:

1. Context-sensitive help

Context-sensitive help, which offers documentation or support for the features and functions of the current page, screen or window should be offered, using a consistent set of accessible commands to access it.

2. Text descriptions

Documentation and training materials should include text descriptions of the interface. These descriptions should stand on their own and be understandable without relying on graphic images in the materials.\

3. User interface descriptions

Descriptions of a user interface should refer to elements by name or function, in addition to their location in the visual interface.

• Status: Done
• Text from Documentation and Technical Support
• Source: New
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities: All
  • User Activities: Training/learning
  • Product Characteristics: User documentation (any type – electronic or print)
  • Product Types: All

7.2 Support and E&IT related services

7.2-A - Support Services

Help desk and technical support services for E&IT must accommodate the communication needs of users with disabilities. 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.

Discussion or Rationale: Reworded to be more specific regarding the type of support.

• Status: Done
• Text from Documentation and Technical Support
• Source: {508}194.41(c) and {255}1193.33(a)(3)
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities: All
  • User Activities: Training/learning
  • Product Characteristics: All
  • Product Types: All

7.2-X - Advisory Notes

Best practices for providing support to people with disabilities include:

1. Remote assistance

Remote assistance programs allow someone to access a computer system remotely to provide support or instruction. This ability to demonstrate features of the computer software or hardware is helpful to people with cognitive disabilities. Applications should either make such a feature available or not disrupt tools that provide it.

• Status: Done
• Text from Documentation and Technical Support
• Source: New
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities: All
  • User Activities: Training/learning
  • Product Characteristics: All
  • Product Types: All

8. Content Format and Authoring Tools

Updates and discussion for provisions in this section

8.1 If a Content Format

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

• Status: Done
• Text from Web and Software
• Source: new
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

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

• Status: In Progress
• Text from Web and Software
• Source: new
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

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

• Status: Done
• Text from Web and Software
• Source: new
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

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

• Status: Done
• Text from Web and Software
• Source: new
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

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

• Status: Done
• Text from Web and Software
• Source: new
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

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

• Status: Done
• Text from Web and Software
• Source: new
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

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

• Status: Done
• Text from Web and Software
• Source: new
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

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

• Status: Done
• Text from Web and Software
• Source: new
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

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

• Status: Done
• Text from Web and Software
• Source: new
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

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

• Status: Done
• Text from Web and Software
• Source: new
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

8.2 Additional requirements for Web Content Authoring Tools

8.2-A - Accessible Output

For each accessible content format supported, authoring tools must allow the author to produce content, including content derived from programmatic sources, that meets applicable Section 508 provisions.

Discussion or Rationale:

• Status: Done
• Text from Web and Software
• Source: new
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

8.2-B - Preserve Accessibility Information

Authoring tools must preserve accessibility information necessary to meet applicable Section 508 provisions, unless the user explicitly indicates otherwise.

Discussion or Rationale: Need to write up a rationale that includes an explanation of why "unless the user explicitly indicates otherwise" is necessary, so that the phrase is not lost during later work

• Status: In Progress
• Text from Web and Software
• Source: new
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

8.2-C - Prompts

For authoring tools with a user interface, authoring tools must provide a mode which prompts authors to create accessible content.

Discussion or Rationale: There are concerns to still be worked out on this.

• Status: In Progress
• Text from Web and Software
• Source: new
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

8.2-D - Evaluation Support

For authoring tools with a user interface, authoring tools must either provide a mode which assists authors in checking for accessibility problems, or compatibility with evaluation tools that provide that function.

Discussion or Rationale: further discuss and write up a rationale explaining what is meant by "compatability with..."

• Status: In Progress
• Text from Web and Software
• Source: new
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

8.2-E - Accessible Templates

Authoring tools which provide pre-authored content, or templates to facilitate production of content, must provide at least one version that meets applicable Section 508 provisions.

Discussion or Rationale:

• Status: Done
• Text from Web and Software
• Source: new
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types: