Developed for:

U.S. Architectural and Transportation Barriers Compliance Board

April 2008

# Table of Contents {#table-of-contents .Title}

1 Executive Summary [8](#executive-summary)

2 Summary of Recommendations [10](#summary-of-recommendations)

2.1 Subpart A [10](#subpart-a)

2.2 Subpart B - Functional Performance Criteria
[11](#subpart-b---functional-performance-criteria)

2.3 New Organization of the Technical Requirements in Subpart C
[11](#new-organization-of-the-technical-requirements-in-subpart-c)

General Technical Requirements [12](#general-technical-requirements)

Requirements for Hardware Aspects of Products
[12](#requirements-for-hardware-aspects-of-products)

Requirements for User Interfaces and Electronic Content
[12](#requirements-for-user-interfaces-and-electronic-content)

Additional Requirements for Audio-Visual Players or Displays
[12](#additional-requirements-for-audio-visual-players-or-displays)

Requirements for Audio and/or Video Content
[13](#requirements-for-audio-andor-video-content)

Additional Requirements for Real-time Voice Conversation Functionality
[13](#additional-requirements-for-real-time-voice-conversation-functionality)

Additional Requirements for Authoring Tools
[13](#additional-requirements-for-authoring-tools)

2.4 Sections on Support and Implementation in Subpart D
[13](#sections-on-support-and-implementation-in-subpart-d)

Information, Documentation and Support
[13](#information-documentation-and-support)

Implementation, Operation and Maintenance
[13](#implementation-operation-and-maintenance)

2.5 New Advisory Notes [14](#new-advisory-notes)

2.6 Provisions Considered, But Not Recommended
[14](#provisions-considered-but-not-recommended)

2.7 Applying the Recommendations to Sections 508 and 255
[14](#applying-the-recommendations-to-sections-508-and-255)

3 Background [16](#background)

3.1 A History of Section 508 [16](#a-history-of-section-508)

3.2 A History of Section 255 [17](#a-history-of-section-255)

4 Updates to the Standard and Guidelines
[19](#updates-to-the-standard-and-guidelines)

4.1 Federal Agency and Consumer Experiences Driving the Refresh
[19](#federal-agency-and-consumer-experiences-driving-the-refresh)

4.2 Technological Changes Driving the 255/508 Refresh
[21](#technological-changes-driving-the-255508-refresh)

Introduction [21](#introduction)

Specific technologies [21](#specific-technologies)

4.3 Harmonization [23](#harmonization)

Planning for Future Updates [24](#planning-for-future-updates)

4.4 Economic Impact [25](#economic-impact)

5 Implementation Recommendations [27](#implementation-recommendations)

5.1 Serving Multiple Audiences [27](#serving-multiple-audiences)

5.2 Testability [28](#testability)

5.3 Assistive Technology and Sections 255 and 508
[29](#assistive-technology-and-sections-255-and-508)

Is AT ICT? [30](#is-at-ict)

AT Interoperability and Testing Requirements
[30](#at-interoperability-and-testing-requirements)

Reporting AT Compatibility Testing Results
[31](#reporting-at-compatibility-testing-results)

5.4 Accessibility for People with Cognitive Disabilities
[31](#accessibility-for-people-with-cognitive-disabilities)

5.5 Usability of the Standard and Guidelines
[32](#usability-of-the-standard-and-guidelines)

Writing Style of the Provisions [32](#writing-style-of-the-provisions)

Making the Complex Clear [33](#making-the-complex-clear)

Improving the Usability of the Requirements
[34](#improving-the-usability-of-the-requirements)

5.6 Recommendations for Research [34](#recommendations-for-research)

Captions [35](#captions)

Speech and Audio Volume and Quality
[35](#speech-and-audio-volume-and-quality)

Cognitive Disability [35](#cognitive-disability)

Biometrics [35](#biometrics)

Audio Menus [36](#audio-menus)

Low Vision: Relationship Between Clinical Metrics and Product
Performance
[36](#low-vision-relationship-between-clinical-metrics-and-product-performance)

Photosensitive Seizure Disorders [36](#photosensitive-seizure-disorders)

Compatibility Between Prosthetics and Touch Sensitive Input Technologies
[36](#compatibility-between-prosthetics-and-touch-sensitive-input-technologies)

Gesture-based Input Technologies [36](#gesture-based-input-technologies)

6 The Recommendations [37](#the-recommendations)

How to read these recommendations
[37](#how-to-read-these-recommendations)

Terminology Used in the Provisions
[37](#terminology-used-in-the-provisions)

Notes Included with the Provisions
[37](#notes-included-with-the-provisions)

Additional Information Included with the Provisions
[38](#additional-information-included-with-the-provisions)

General Exceptions [38](#general-exceptions)

General Introduction [38](#general-introduction)

Subpart A [39](#subpart-a-1)

1\. Purpose [39](#purpose)

Purpose for Section 255 [39](#purpose-for-section-255)

Purpose for Section 508 [39](#purpose-for-section-508)

2\. Application [40](#application)

Application for Section 255 [40](#application-for-section-255)

Application for Section 508 [41](#application-for-section-508)

3\. General Exceptions [43](#general-exceptions-1)

A - Intelligence Or Security Systems
[43](#a---intelligence-or-security-systems)

B- Incidental To A Contract [44](#b--incidental-to-a-contract)

C - Employees Not Individuals With Disabilities
[44](#c---employees-not-individuals-with-disabilities)

D - Access By Public [44](#d---access-by-public)

E - Fundamental Alteration [44](#e---fundamental-alteration)

F - Maintenance and Monitoring Aspects of Products
[45](#f---maintenance-and-monitoring-aspects-of-products)

5\. Equivalent Facilitation [45](#equivalent-facilitation)

Subpart A: Definitions [45](#subpart-a-definitions)

Subpart B: Functional Performance Criteria
[55](#subpart-b-functional-performance-criteria)

A - Without Vision [55](#a---without-vision)

B - With Limited Vision [55](#b---with-limited-vision)

C - With Color Vision Deficits [55](#c---with-color-vision-deficits)

D - Without Hearing [55](#d---without-hearing)

E -- With Limited Hearing (no consensus)
[56](#e-with-limited-hearing-no-consensus)

G - Without Speech [56](#g---without-speech)

H - With Limited Reach, Strength, or Manipulation
[56](#h---with-limited-reach-strength-or-manipulation)

I -- Without Physical Contact (no consensus)
[56](#i-without-physical-contact-no-consensus)

J -- With Cognitive, Language, or Learning Limitations (no consensus)
[56](#j-with-cognitive-language-or-learning-limitations-no-consensus)

Subpart C: Technical Requirements
[57](#subpart-c-technical-requirements)

1\. General Technical Requirements
[57](#general-technical-requirements-1)

1-A: Closed Functionality [57](#a-closed-functionality)

1-B: Biometric ID [58](#b-biometric-id)

1-C: Pass Through [59](#c-pass-through)

1-D: Audio Information [59](#d-audio-information)

1-E: Visual Information (no consensus)
[59](#e-visual-information-no-consensus)

1-F: Color [60](#f-color)

1-G: Text Size (no consensus) [60](#g-text-size-no-consensus)

1-H: Speech Operation [60](#h-speech-operation)

2\. Requirements for Hardware Aspects of Products
[61](#requirements-for-hardware-aspects-of-products-1)

2.1 All Products with Hardware [61](#all-products-with-hardware)

2.1-A: Reflectance Contrast for Legends and Passive Displays
[61](#a-reflectance-contrast-for-legends-and-passive-displays)

2.1-B: Flashing (Hardware) [61](#b-flashing-hardware)

2.1-C: Mechanical Controls [62](#c-mechanical-controls)

2.1-D: Touch Operated Controls [63](#d-touch-operated-controls)

2.1-E: Standard User Interface Connection
[63](#e-standard-user-interface-connection)

2.1-F: Installed or Free-Standing Products
[64](#f-installed-or-free-standing-products)

2.2 If the Product has Speech Output or Throughput
[64](#if-the-product-has-speech-output-or-throughput)

2.2-A: Magnetic Coupling [64](#a-magnetic-coupling)

2.2-B: Interference with Hearing Device
[65](#b-interference-with-hearing-device)

2.2-C: Audio Connection [65](#c-audio-connection)

2.2-D: Volume [67](#d-volume)

2.2-E - Volume (Gain) [68](#e---volume-gain)

2.2-F - Volume Reset [69](#f---volume-reset)

3\. Requirements for User Interface and Electronic Content
[70](#requirements-for-user-interface-and-electronic-content)

3-A: Color [70](#a-color)

3-B: Contrast [70](#b-contrast)

3-C: Size, Shape, Location [71](#c-size-shape-location)

3-D: User Preferences [72](#d-user-preferences)

3-E: Color Adjustment [72](#e-color-adjustment)

3-F: Non-text Objects [73](#f-non-text-objects)

3-G: Human Language [74](#g-human-language)

3-H: Language of Parts [74](#h-language-of-parts)

3-I: Pausing [75](#i-pausing)

3-J: Flashing (Content and User Interfaces)
[76](#j-flashing-content-and-user-interfaces)

3-K: Consistent Identification [76](#k-consistent-identification)

3-L: Audio Turnoff [77](#l-audio-turnoff)

3-M: Reading Sequence [77](#m-reading-sequence)

3-N: Link Purpose [78](#n-link-purpose)

3-O: Information and Relationships
[78](#o-information-and-relationships)

3-P: User Interface Components (no consensus)
[79](#p-user-interface-components-no-consensus)

3-Q: Disruption of Access Features
[79](#q-disruption-of-access-features)

3-R: Timing [80](#r-timing)

3-S: Keyboard Operation [81](#s-keyboard-operation)

3-SS: Visual Indication of Keyboard Shortcuts (no consensus)
[81](#ss-visual-indication-of-keyboard-shortcuts-no-consensus)

3-T: Focus Indicator [82](#t-focus-indicator)

3-U: AT Interoperability (partial consensus)
[82](#u-at-interoperability-partial-consensus)

3-V: Accessibility Services [82](#v-accessibility-services)

3-VV: Assistive Technology (no consensus)
[83](#vv-assistive-technology-no-consensus)

3-W: Multiple Ways [83](#w-multiple-ways)

3-X: Labels or Instructions [84](#x-labels-or-instructions)

3-Y: On Focus [84](#y-on-focus)

3-Z: On Input [84](#z-on-input)

3-AA: Error Identification [85](#aa-error-identification)

3-BB: Headings and Labels [85](#bb-headings-and-labels)

4\. Additional Requirements for Audio-Visual Players or Displays
[85](#additional-requirements-for-audio-visual-players-or-displays-1)

4-A: Caption Processing [85](#a-caption-processing)

4-B: Supplemental Audio Process [86](#b-supplemental-audio-process)

4-C: Access to Caption and Video Controls
[87](#c-access-to-caption-and-video-controls)

5\. Requirements for Audio and/or Video Content
[88](#requirements-for-audio-andor-video-content-1)

5-A: Captions and Transcripts [88](#a-captions-and-transcripts)

5-B: Video Description [88](#b-video-description)

5-C: Interactive Elements [89](#c-interactive-elements)

6\. Additional Requirements for Real-Time Voice Conversation
Functionality
[89](#additional-requirements-for-real-time-voice-conversation-functionality-1)

6-A: Real-Time Text Reliability and Interoperability
[89](#a-real-time-text-reliability-and-interoperability)

6-B: Voice Terminal Hardware and Software
[91](#b-voice-terminal-hardware-and-software)

6-C: IVR, Auto-Attendant and Messaging
[92](#c-ivr-auto-attendant-and-messaging)

6-D: Caller and Status Information (no consensus)
[93](#d-caller-and-status-information-no-consensus)

6-E: Video Support [93](#e-video-support)

6-F: Audio Clarity for Interconnected VoIP
[93](#f-audio-clarity-for-interconnected-voip)

6-G: External Alerting Devices [94](#g-external-alerting-devices)

7\. Additional Requirements for Authoring Tools
[95](#additional-requirements-for-authoring-tools-1)

7-A: Accessible Output [95](#a-accessible-output)

7-B: Preserve Accessibility Information
[95](#b-preserve-accessibility-information)

7-C: Prompts (no consensus) [96](#c-prompts-no-consensus)

7-D: Accessible Templates (no consensus)
[96](#d-accessible-templates-no-consensus)

Subpart D [96](#subpart-d)

1\. Information, Documentation and Support
[96](#information-documentation-and-support-1)

1.1 Product Documentation and Help [96](#product-documentation-and-help)

1.1-A: Accessible Documentation and Features
[96](#a-accessible-documentation-and-features)

1.1-B: Keyboard Shortcuts (no consensus)
[97](#b-keyboard-shortcuts-no-consensus)

1.2 Support and E&IT Related Services
[97](#support-and-eit-related-services)

1.2-A: Support Services [97](#a-support-services)

1.2-B - Manufacturer Contact [97](#b---manufacturer-contact)

1.2-C - Training [98](#c---training)

2\. Implementation, Operation, and Maintenance
[98](#implementation-operation-and-maintenance-1)

2-A: Relay Services Accessibility [98](#a-relay-services-accessibility)

2-B: Video Support [98](#b-video-support)

2-C: Accessibility Configuration [99](#c-accessibility-configuration)

2-D: Accessible Content [99](#d-accessible-content)

Advisory Notes [100](#advisory-notes)

Subpart A: Inherently Visual E&IT
[100](#subpart-a-inherently-visual-eit)

Advisory Notes for User Interface and Electronic Content
[101](#advisory-notes-for-user-interface-and-electronic-content)

1\. Suppression of Unneeded Function
[101](#suppression-of-unneeded-function)

2\. Writing Guidelines [101](#writing-guidelines)

3\. Interaction Guidelines [101](#__RefHeading___Toc194686994)

4\. Parsing [102](#parsing)

5\. User Preferences (non-visual) [102](#user-preferences-non-visual)

Recommendations for Additional Advisory Notes:
[102](#recommendations-for-additional-advisory-notes)

Advisory Notes for Authoring Tools
[102](#advisory-notes-for-authoring-tools)

1\. Assistance with Checking for Accessibility Problems
[102](#assistance-with-checking-for-accessibility-problems)

Advisory Notes for Information, Documentation and Support
[102](#advisory-notes-for-information-documentation-and-support)

1\. Context-Sensitive Help [102](#context-sensitive-help)

2\. Text Descriptions [103](#text-descriptions)

3\. User Interface Descriptions [103](#user-interface-descriptions)

Recommendations for Additional Advisory Notes:
[103](#recommendations-for-additional-advisory-notes-1)

Advisory Notes for Support and E&IT Related Services
[103](#advisory-notes-for-support-and-eit-related-services)

1\. Remote Assistance [103](#remote-assistance)

7 Provisions Considered but Not Achieving Consensus
[104](#provisions-considered-but-not-achieving-consensus)

Subpart B: Functional Performance Criteria E, I, and J
[104](#subpart-b-functional-performance-criteria-e-i-and-j)

E -- With Limited Hearing (no consensus)
[104](#e-with-limited-hearing-no-consensus-1)

I - Without Physical Contact (no consensus)
[105](#i---without-physical-contact-no-consensus)

J - With Cognitive, Language or Learning Limitations (no consensus)
[106](#j---with-cognitive-language-or-learning-limitations-no-consensus)

Provisions from Subpart C [107](#provisions-from-subpart-c)

1-E: Visual information (no consensus)
[107](#e-visual-information-no-consensus-1)

1-G: Text Size (no consensus) [109](#g-text-size-no-consensus-1)

3-P - User Interface Components (no consensus)
[112](#p---user-interface-components-no-consensus)

3-SS: Visual Indication of Keyboard Shortcuts (no consensus)
[114](#ss-visual-indication-of-keyboard-shortcuts-no-consensus-1)

3-U:AT Interoperability (partial consensus)
[115](#u-at-interoperability-partial-consensus-1)

3-VV: Assistive Technology (no consensus)
[118](#vv-assistive-technology-no-consensus-1)

6-D: Caller and Status Information (no consensus)
[120](#d-caller-and-status-information-no-consensus-1)

7-D: Accessible Templates (No consensus)
[123](#d-accessible-templates-no-consensus-1)

Subpart D: 1.1-B: Keyboard Shortcuts (no consensus)
[124](#subpart-d-1.1-b-keyboard-shortcuts-no-consensus)

Definitions Considered but Not Completed
[125](#definitions-considered-but-not-completed)

Proposed Additions to Subpart A but Not Accepted
[132](#proposed-additions-to-subpart-a-but-not-accepted)

Exception: Narrow, Delineated Use (no consensus)
[132](#exception-narrow-delineated-use-no-consensus)

Exception: Emergency, Field, and First Response Use (no consensus)
[133](#exception-emergency-field-and-first-response-use-no-consensus)

Provisions Considered, but Dropped
[134](#provisions-considered-but-dropped)

Basic Input/Output System (BIOS) Settings
[134](#basic-inputoutput-system-bios-settings)

8 Source and Harmonization of Recommendations
[136](#source-and-harmonization-of-recommendations)

8.1 Source of Recommendations from the Current 508 and 255
[136](#source-of-recommendations-from-the-current-508-and-255)

8.2 Harmonization of the Recommendations to WCAG 2.0
[140](#harmonization-of-the-recommendations-to-wcag-2.0)

8.3 Identification of Provisions Supporting Functional Performance
Criteria
[143](#identification-of-provisions-supporting-functional-performance-criteria)

9 Annexes [148](#annexes)

9.1 TEITAC Organizational Members List
[148](#teitac-organizational-members-list)

9.2 Related Federal Legislation Protecting the Rights of Individuals
with Disabilities
[150](#related-federal-legislation-protecting-the-rights-of-individuals-with-disabilities)

9.3 Charter [153](#charter)

9.4 Operating Protocols [153](#operating-protocols)

# Executive Summary

This report contains a set of recommended standards and guidelines that
the Access Board may use to update regulations that implement two laws
regarding accessible information and communication technology (ICT):
Section 508 of the Rehabilitation Act and Section 255 of the
Communications Act of 1996[^1]. These two laws help to form the legal
backbone of accessibility in the American information and communications
technology (ICT) environment. In broad terms, Section 508 requires
federal agencies to use accessibility as a selection criterion when
procuring ICT, while the Access Board's Section 255 requires certain
telecommunications--related equipment and services to be designed,
developed and fabricated to be accessible to and usable by people with
disabilities, if readily achievable.[^2]

Federal agencies, consumers, technology manufacturers and many others
now have several years of experience working within those regulations,
years in which technology evolved on many fronts, additional
accessibility standards arose, and the technology of accessibility has
been transformed.

In 2006 the Access Board directed its staff to revise and update the
accessibility standards for E&IT covered under Section 508 and the
accessibility guidelines for telecommunications equipment and customer
premises equipment covered under Section 255 and to harmonize the
updated standards with international accessibility standards.[^3] In
order to effectively update these regulations, the Access Board
consulted with various stakeholders:

-   Federal agencies

-   Telecommunications, electronics, and information technology
    industries

-   Public and nonprofit agencies and organizations

-   Public and nonprofit agencies and organizations representing
    individuals with disabilities

-   Accessibility consultants

-   Academics

-   International standards organizations.

Recognizing that accessibility is emerging as an important issue
globally and that other countries are also developing and implementing
accessibility standards, representatives from three other countries and
the European Commission were also included in the consultation. The
Access Board established the Telecommunications and Electronic and
Information Technology Advisory Committee (TEITAC) comprised of 41
organizations representing the various stakeholders. (The members of the
Committee are listed in Annex 9.1.) TEITAC is a formal federal advisory
committee, managed under the regulations of the Federal Advisory
Committee Act (FACA).

This report reflects the deliberations and recommendations of the TEITAC
(The Committee). The principal content of this report is a set of
recommended updates to the Section 508 Standard and the Section 255
Guidelines that commercial vendors and Federal departments and agencies
use to develop, procure, maintain, or use E&IT and telecommunications
products and services (Section 6). This report proposes standards needed
so that people with disabilities might achieve access and use of
information comparable to that of people without disabilities.

Manufacturers and providers of ICT products need to be able to make
design choices and R&D investments with a clear understanding of the
direct or indirect accessibility mandates under Sections 508 and 255.
Federal officials in turn need to develop, procure, use, and maintain
E&IT based on verifiable, and up-to-date accessibility standards. The
Department of Justice (DOJ) is required by Section 508 to measure and
report to Congress the extent to which the Federal Government complies
with the Section 508 standard. The Federal Communications Commission
(FCC) needs to be able to respond to informal and formal complaints
concerning compliance of telecommunications products and services under
Section 255 and to initiate its own actions. People with disabilities,
whether Federal employees or the general public, should be confident in
their ability to access telecommunications and federal information. We
hope that these stakeholders will be aided by the Committee
recommendations.

The Committee recognizes that Federal agencies and consumers with
disabilities need to benefit from advances in technology. The pace of
technological advancement in ICT is rapid and the level of innovation is
high. In this environment, a static standard consisting of design
specification and fixed checklists would tend to stifle innovation and
to delay the availability of technology advancements to people with
disabilities. At the same time, clear and specific standards may ease
compliance. To balance these needs, this report recommends provisions
that explicitly address alternative technical approaches. All of these
provisions, we believe, describe the required types of accessibility
features. Some refer to specific accessibility features that are known
to be both feasible and effective. Federal agency compliance with the
procurement process will encourage and give incentives to manufactures
and providers to meet and hopefully exceed these requirements, and will
help foster innovation and improvement in accessibility.

# Summary of Recommendations

Information and communications technology (ICT) that is accessible to
and usable by people with disabilities allows the performance of regular
operating functions of the ICT, including input and control functions,
operation of mechanical mechanisms, and access to information displayed
in visual and auditory form.[^4] Interfacing with assistive technology
(AT) used by people with disabilities to access ICT is important to
providing access to ICT. The ICT and AT should use documented interfaces
to interoperate with each other, and where possible not interfere with
each other.

The provisions recommended in this report apply to a full range of ICT,
consistent with the applicable statues, including those used for
communication, duplication, computing, storage, presentation, control,
transport and production. Our goal is to make these products accessible
to as wide a range of people with disabilities as possible including
people with:

-   Visual disabilities (blindness, low vision, and lack of color
    perception)

-   Hearing disabilities (hard of hearing and deafness)

-   Physical disabilities (e.g., limited strength, reach or
    manipulation, tremor, lack of sensation)

-   Speech disabilities

-   Cognitive disabilities (e.g., disabilities affecting reading,
    language, learning, thinking, remembering, sequencing, etc.)

-   Other disabilities (e.g., photosensitive seizure disorders), and
    individuals with some combinations of these conditions (e.g.,
    deaf-blindness).

## Subpart A

Subpart A includes material that explains how the provisions are to be
used including:

-   Separate purpose statements for Sections 255 and 508

-   Separate application statements for Sections 255 and 508

-   Additions and some changes to the general exceptions

-   Additions and changes to the definitions

-   Equivalent facilitation has not been changed

## Subpart B - Functional Performance Criteria

Subpart B includes the Functional Performance Criteria (FPC), which
refer to different disability categories and the necessity of providing
access to the functionality of products. The FPC have been modified from
the previous version. They now include a note on the role of assistive
technology in meeting the Functional Performance Criteria. However,
there is an unresolved issue of when and how the criteria are used,
which the Committee is sending to the Access Board for its consideration
and final decision.

The FPC now precede the Technical Provisions because they help frame the
Technical Provisions. The move of the FPC to this location was a topic
of much discussion for the Committee. Their position in this document,
as a report to the Access Board and not a regulation by itself, has no
implications for interpretation or enforcement.

## New Organization of the Technical Requirements in Subpart C

The organization of the technical requirements in the current Section
508 standard no longer matches the types of ICT products currently or
likely to become available. The groupings in the standard currently in
force are based on product types such as web, software, and
telecommunications. Since the time that these groups were first created,
however, many of these technologies have evolved and many of their
various functions have converged and overlapped. It has become difficult
to determine which provisions should be applied to a product using the
current organization of the provisions[^5]. An example of this is how
telephones have changed from a device used to talk to another person, to
a tool for accessing the web and reading emails. We also concluded that
the organizational structures of the Section 255 guidelines and Section
508 standards would not work for harmonization or current product
designs.

We therefore re-arranged the technical requirements in Subpart C into
categories based on product characteristics or features. This allowed us
to address the convergence of features and functionality in ICT. Instead
of attempting to define the difference, for example, between "software"
and a "web application," provisions are organized by how the products
are constructed and used. This, and other similar groupings in the
report, was done to eliminate duplication of requirements, and make it
easier for designers to ignore or skip over provisions that did not
relate to their products. The categories are as follows:

### General Technical Requirements {#general-technical-requirements .unnumbered}

This is a new category that consolidates provisions that apply to all
ICT to eliminate duplication of requirements that appeared in more than
one section under the current Standard.

### Requirements for Hardware Aspects of Products {#requirements-for-hardware-aspects-of-products .unnumbered}

These provisions apply to any ICT with hardware and have been broken
down into two groups. The "All Products with Hardware" group of
provisions applies to all products with hardware. The "If the Product
has Speech Output or Throughput" group applies only to hardware for ICT
with speech output or throughput, to ensure that products do not
interfere with hearing technologies, and include appropriate audio
connections and controls and limits for volume.

### Requirements for User Interfaces and Electronic Content {#requirements-for-user-interfaces-and-electronic-content .unnumbered}

Technological changes have brought web and software interfaces into
close correspondence. In some cases a web-based application offers the
same functionality as an application installed on a computer. At the
same time, electronic content has posed a problem for end users, content
authors, and Section 508 officials concerned when electronic content is
considered E&IT and subject to Section 508 technical requirements and
functional performance criteria. The Access Board asked the Committee to
address both issues.

The interface behavior of physical products, such as the relationship
between button presses and the contents of a copier's display, is a
function both of the hardware and the software, with the software
controlling the behavior. This interaction risks creating duplicate
requirements in the hardware and software sections of the Standard.

Our response was to develop recommendations to harmonize the
requirements for user interfaces and electronic content. The provisions
in this section apply to any electronic content, including web pages or
other documents and information, and to any software and web user
interfaces. The definition of content includes as examples: word
processing files, presentation files, spreadsheet files, text files,
portable document files, and web based content.

There was a difference of opinion on the Committee as to whether the
provisions in this section should apply to hardware user interfaces, or
only to software. One view is that provisions in this section came from
the current Section 508 requirements for Software Applications and
Operating Systems (Section 508 1194.21), the Web-based Intranet and
Internet Information and Applications (Section 508 1194.22), or the Web
Content Accessibility Guidelines (WCAG) 2.0 and therefore should not
apply to hardware displays. The other point of view is that the behavior
of hardware is controlled by software so this section applies to the
interface aspects of hardware.

### Additional Requirements for Audio-Visual Players or Displays {#additional-requirements-for-audio-visual-players-or-displays .unnumbered}

These provisions apply to ICT that includes audio-visual player or
display functions (including products such as televisions, tuners,
computer equipment, web browser plug-ins, software players, and kiosks).
They include requirements to ensure that captions and supplemental audio
playback (for example, video description) are available, and that there
is equivalent access to these features.

### Requirements for Audio and/or Video Content {#requirements-for-audio-andor-video-content .unnumbered}

These provisions apply to content that includes audio, video, or both
audio and video, including both pre-recorded and real-time audio. They
include requirements for captions and video description, as well as an
equivalent way of selecting interactive elements in synchronized media,
previously often referred to as multimedia.

### Additional Requirements for Real-time Voice Conversation Functionality  {#additional-requirements-for-real-time-voice-conversation-functionality .unnumbered}

These provisions apply to any software or hardware that provides the
ability for voice conversation in real time. They include requirements
for real-time text (RTT), voice conversation via interconnected VoIP,
voice messaging and other interactive voice systems, caller ID, and
real-time video communication. Although many of these requirements
originally came from Section 255, they also apply to ICT products
covered by Section 508 that include telecommunications-like
functionality.

### Additional Requirements for Authoring Tools {#additional-requirements-for-authoring-tools .unnumbered}

These new provisions apply to authoring tools, defined as "software
intended to create or modify content for publication in one or more
formats that support compliance with the user interface and content
provisions." They include requirements for how these tools support the
creation of accessible content.

## Sections on Support and Implementation in Subpart D

These provisions address how ICT is deployed for use in federal agencies
after procurement.

### Information, Documentation and Support {#information-documentation-and-support .unnumbered}

These provisions cover product documentation and technical support. New
provisions were added to clarify the types of things that need to be
documented and the kinds of support and training that must be
accessible.

### Implementation, Operation and Maintenance {#implementation-operation-and-maintenance .unnumbered}

During the Committee's deliberations it became clear that an accessible
product may need to be set up in a particular way so as to provide the
benefit of the accessibility to the federal employee or member of the
public with a disability. These new provisions refer to specific actions
that must be taken subsequent to procurement by agencies in order to
expose the accessibility to the product's users. Many of these
provisions apply only to Section 508.

## New Advisory Notes

In some cases, the Committee agreed on the need for a provision, but
could not agree on how to write the requirement with sufficient
precision. In other cases, the Committee concluded that an issue could
be better addressed as an advisory note issued by the Access Board.
These recommendations are gathered in one place for convenience. They
are written as *guidelines*, using "should" rather than "must" to
indicate that they are best practice rather than *provisions*.

## Provisions Considered, But Not Recommended

In the course of the Committee's deliberations we discussed many ideas
for provisions that did not become a final recommendation. Most of these
were factored into other provisions, or were discarded as unnecessary. A
small number of provisions were considered by the Committee, and had one
or more advocates, and one or more opponents. Those provisions are
recorded here, in order to deliver a true report of the Committee's
deliberations and the range of positions taken on issues raised.

## Applying the Recommendations to Sections 508 and 255

One of the charges to the Committee was to update both the Section 508
Standard and the Section 255 Guidelines at the same time. Some of the
individual provisions that applied to each of these laws were in
conflict, and both were in need of significant technological updating,
especially concerning text communication and voice over Internet
Protocol (VoIP). Access Board staff suggested that the Committee create,
if possible, a single harmonized set of consistent requirements that
could be applied for both contexts.

The Committee looked at the guidelines originally developed by the
Access Board, many of which were adopted by the FCC. The FCC rules apply
to information and documentation associated with the covered products,
as well as information and documentation necessary to use the covered
products. This information and documentation includes user guides,
bills, installation guides for end-user installable devices, and product
support and communications. (47 CFR §§6.11 and 7.11). Finally, the
Commission's rules cover equipment used for voicemail or interactive
menu services (47 CFR §7.1)

The Committee formed a Task Force to work on 255/508 differences and
develop harmonized proposals where possible, or separate text where
necessary. The Committee accepted the Task Force report, which
determined that the recommendations generally apply to both Section 508
and Section 255, except in some specific provisions. In cases where the
separate environments of the two regulations require it, the provisions
explicitly document this, either within the text of a recommended
provision, as a note attached to a provision, or in other text.

Specifically, the Committee agreed that technical standards that would
improve the accessibility of any of the items covered by Section 255,
whether a phone or VoIP device, a printed user guide, or a web-based
billing function, are candidates for inclusion in the Access Board's
Section 255 guidelines.

We believe that this report renders the Committee\'s best judgment on
these issues, and points towards significant opportunities for
harmonization.  At the same time we have explicitly called out
situations and applications that should refer to the separate
environments in which Section 255 and Section 508 operate, either within
the text of a recommended provision, as a note attached to a provision,
or in other text.

# Background

## A History of Section 508

Section 508 was created in 1986 when Congress added this section to the
Rehabilitation Act of 1973. The Rehabilitation Act contains
comprehensive prohibitions against employment discrimination by the
Federal government, 29 U.S.C. §791, by contractors for the Federal
government, 29 U.S.C. §793, and by programs and activities receiving
Federal financial assistance. 29 U.S.C. §794. In the 1980's Federal
agencies significantly increased their dependency on electronic office
technologies. Section 508 was added to ensure that such E&IT would be
accessible to individuals with disabilities. Pub. L. 99-506, Title VI,
§603(a); Title I §103(d)(2)(A), (C), as amended, Pub. L 100-630, Title
II, §206(f); Pub. L. 102-569, Title V §509(a), codified at 29 U.S.C.
§794d.

Section 508 guidelines were initially released in October 1987, and
adopted by the GSA in Sept 1988. In January 1991 the GSA published
Bulletin C-8 containing these guidelines as amended, in the Federal
Information Resources Management System (FIRMR). In April 1987, the GSA
had published Bulletin 48 in the FIRMR that sets forth requirements for
agencies to provide accommodations designed to meet the needs of
employees with disabilities when replacing the agencies' computer
systems.

In 1997, the Federal Electronic and Information Technology Accessibility
Compliance Act was introduced and incorporated into the Workforce
Investment Act of 1998, revising Section 508 through the Rehabilitation
Act Amendments of 1998. Pub. L. 105-220, Title IV, §408(b), codified at
29 U.S.C. §794d. Section 508 places strict requirements on Federal
agencies that develop, procure, maintain, or use EI&IT that is accessed
by both Federal employees with disabilities and individuals with
disabilities outside the government who need government information,
unless doing so would impose an undue burden. The law specifically
directs Federal agencies to provide access to information and data to
people with disabilities that is comparable to the access available to
individuals without disabilities. Where providing access would result in
an undue burden, agencies are directed to (1) provide documentation on
why compliance will create an undue burden and (2) provide the
information and data through an alternative means of access.

The amended version of Section 508 directed the Access Board to publish
standards by setting forth (1) a definition of electronic and
information technology, and (2) technical and functional performance
criteria necessary to achieve electronic and information access. The
definition of electronic and information technology established by the
Access Board had to be consistent with the definition of information
technology contained in the Clinger-Cohen Act. 40 U.S.C. §1401(3). This
was completed through the formation of the Electronic and Information
Technology Accessibility Advisory Committee (EITAAC). The revised
provisions of Section 508 went into effect in June 2001. The Attorney
General also prepared the first biennial report to the President on the
extent to which electronic and information technology available within
agency was accessible and usable by individuals with disabilities. The
Federal Acquisition Regulatory Council was to revise the Federal
Acquisition Regulation and each Federal agency had to revise its own
Federal procurement policies and directives to incorporate the new
Section 508 standards. The amended Section 508 allows individuals to
file complaints against Federal agencies alleging noncompliance with
Section 508 in procurements or for an agency award to be protested by a
contractor or vendor bidding on a contract. Agencies receiving such
complaints are directed to utilize their existing complaint procedures
for Section 504 of the Rehabilitation Act.

A separate law, the Technology-Related Assistance for Individuals with
Disabilities Act of 1988, Pub.L.100-407, later replaced by the Assistive
Technology Act of 1998, as amended, Pub.L.108-364, 29 U.S.C. §3001 and
now known as the AT Act, requires States to provide an assurance of
their compliance with Section 508 as a condition to receiving Federal
funds for the State Grants for Assistive Technology. The 2004 amendments
to the Assistive Technology Act of 1998, clarified the scope specifying
that the assurance apply only to the State Assistive Technology Program.
However, many states have adopted or adapted Section 508 accessibility
requirements in state law, executive order, legislation, or other policy
initiatives. As a result, the new Section 508 standards will have wide
reaching impact at the state level.

##  A History of Section 255

Section 255 was enacted as part of the amendments to the Communications
Act of 1934, contained in the Telecommunications Act of 1996, Pub. L.
104-104, codified at 47 U.S.C. This section requires telecommunications
services and equipment to be accessible to and usable by people with
disabilities, where readily achievable.[^6] Where not readily
achievable, such services and equipment must nevertheless be compatible
with existing peripheral devices or specialized customer premises
equipment (CPE) commonly used by people with disabilities to achieve
access to telecommunications, again where this is readily achievable.
Readily achievable is defined as \"easily accomplishable and able to be
carried out without much difficulty or expense.\" In determining whether
an access feature is readily achievable, the FCC has directed entities
to weigh the nature and cost of that feature with the overall financial
resources of the manufacturer or service provider, including such
factors as the type, size, and nature of that company's operation.[^7]
The legislation contemplates that manufacturers and service providers
will consider access needs during the design, development and
fabrication of their offerings, as well as whenever a natural
opportunity to review the design of the service or product arises, so
that expensive and burdensome retrofitting for access will not be
necessary.

Section 255 directed the Access Board to develop guidelines for
accessibility of telecommunications equipment and CPE within eighteen
months after the legislation's enactment. In order to accomplish this
task, the Access Board created a body similar to EITAAC -- called the
Telecommunications Access Advisory Committee, or TAAC. After meeting
over a period of seven months, TAAC presented its proposed guidelines to
the Access Board in January of 1997. The contents of these proposals
formed the basis for the Access Board's Section 255 guidelines, released
to the public on February 3, 1998, 63 Fed. Reg. 5608 (Feb. 3, 1998)
codified at 36 C.F.R. Part 1193, and effective as of March 5, 1998. The
FCC then used these guidelines to develop its regulations to implement
Section 255's mandates for telecommunications equipment and service
providers. Those rules, released in September 1999, also created
procedures to enforce Section 255's provisions with respect to
telecommunications services, telecommunications equipment, and CPE.

The Access Board's guidelines on Section 255 created detailed
requirements for the accessibility, usability, and compatibility of
telecommunications equipment and CPE. 36 C.F.R. §1193 et. seq. Among
other things, the guidelines contain requirements for input, output,
display, control, and mechanical functions to be accessible by
individuals with varying disabilities and functional limitations. The
compatibility requirements focus on the need for standard connectors,
compatibility of controls with prosthetics, and TTY compatibility. In
order to identify access needs and solutions, the guidelines directed
manufacturers to consider consulting with individuals with disabilities,
and suggested including individuals with disabilities in market research
and the validation of access solutions. The rules defined \"usable\" as
access to information about how to use the product, and directed that
\"instructions, product information ... documentation, and technical
support\" be functionally equivalent to that which is provided to
individuals without disabilities. In order to monitor the industry's
progress in making telecommunications equipment accessible, in January
2000, the Access Board compiled and released a \"market monitoring
report,\" that identified the state of the art of CPE and
telecommunications equipment, as well as problem areas and solutions
that have been used to achieve access to these products.

# Updates to the Standard and Guidelines

Improvements in ICT accessibility have come from many sources: how
people use technology, how technology itself changes, and how products
change must all be taken into consideration. The intent of Sections 255
and 508 is to enhance and improve the accessibility of ICT to Federal
employees and to the general public. The Committees recommendations are
designed to encourage agencies to consider and show preference for these
improved alternatives as they are introduced.

Concurrent with the development of the Committees recommendations, other
national and international standards and guidelines are being developed.
The Committee has referred to some of these standards and guidelines
below. Others are expected to be cited by the Access Board in technical
assistance to Federal agencies. There are significant benefits in
harmonizing with these international standards. Such harmonization
creates a larger marketplace demanding accessibility solutions, thereby
attracting more offerings and increasing the likelihood of commercial
availability of highly accessible ICT options.

Accessibility is receiving increasing attention and priority throughout
the world. This heightened interest suggests further investments and
advancements in accessibility technologies in many countries and across
multiple scientific disciplines. As these advancements progress, the
Access Board (or other appropriate body) should review and update the
Federal accessibility standards to reflect the advancing state of the
art. Because ICT is a global market, the harmonization with
international standards and guidelines where appropriate may also
benefit agencies, service providers, manufacturers, and people with
disabilities by reducing costs that would be associated with designing
and developing different products to meet conflicting requirements in
different markets.

## Federal Agency and Consumer Experiences Driving the Refresh

The Committee received several presentations from agency Section 508
coordinators and others. We were repeatedly reminded that although the
Committee is composed of experts on accessibility, there are hundreds or
even thousands of non-experts to whom these regulations are important.
This includes agency staff responsible for carrying out the provisions,
ICT vendors voluntarily supplying compliance information or reports, as
well as millions of consumers, federal employees, and members of the
public with disabilities. The experience of these stakeholders with the
current Section 255 guidelines and Section 508 regulations should be
carefully factored into any refreshed regulations and guidelines.

Below is a list of the issues raised in this context. Where possible,
the Committee made an effort to address and solve the problem noted.
However, some of the issues were beyond the scope of the Committee.

> The following were discussed:

-   Lack of clarity on some provisions (e.g., baseline for
    amplification).

-   No guidance on whether electronic content (such as email messages
    and word processing documents) is E&IT.

-   Inconsistencies between Sections 255 and 508 (e.g., phone
    amplification).

-   Coverage of \"non-office\" equipment, such as field equipment and
    scientific tools.

-   Agencies purchase network E&IT with accessibility features, but do
    not turn those features on, and sometimes users are left without the
    ability to turn the accessibility features on.

-   Confusion about \"back office\" (\"service area\") exception.

-   Non-US jurisdictions and the need to harmonize.

-   Confusion about whether/how to prioritize the provisions.

-   Confusion about decision-making: how to rate, rank, or weigh the
    relative importance of conformance to individual access requirements
    when provisions address different disability needs.

-   Confusion about how cost, business need, and accessibility
    considerations are to be factored into procurement decision-making.

-   Questions regarding access to video relay versus network security.

> The following was considered to be out of scope:

-   Questions from states, localities, universities, etc. on how to
    apply 508.

> The following were discussed but the Committee could not agree on how
> to resolve:

-   Insufficient technical detail on the meaning of individual
    provisions (need more detailed technical assistance). While there
    were improvements on many of the technical provisions, the Committee
    did not go as far as they would have liked in some cases.

-   Insufficient guidance in the provisions on how technical support
    should be handled by ICT vendors regarding AT compatibility,
    configuration and use.

-   Role of the Functional Performance Criteria when Technical
    Provisions are met or not met.

-   AT Compatibility -- is an application programming interface (API)
    only sufficient? Is testing with AT needed? If so, how many models
    of AT is enough?

-   Lack of testability and testing methodologies.

## Technological Changes Driving the 255/508 Refresh

### Introduction {#introduction .unnumbered}

Since the first Section 255 guidelines and Section 508 standard were
developed, the pace of technological change has been rapid. This change,
as it affects accessibility, falls into two categories: changes to
products themselves and changes in the accessibility environment.

First, products themselves have undergone radical evolution and
convergence in many cases. For example, of the six product categories
used in the current Section 508 standard, virtually all have undergone
significant changes that have thrown the current descriptions into
question. The rise of web-based applications has blurred the line
between \"software\" and \"web\" to a great degree, and software
development itself is now performed on a cascading hierarchy of
interoperating tools and platforms. \"Telecommunications,\" is now used
to deliver a much wider array of products and services than before. In
addition to voice, text or video communication capabilities can be found
in many ICT products or services. Desktop computers are no longer the
only information processing hardware, mobile devices with radically
different input and output characteristics now fill this role. Audible
and visual media, synchronized or not, are now provided over many
distribution paths, both as a permanent record and as a network service.
Some formerly closed product types are now open, while some formerly
open product types are now closed, more or less by policy rather than
technology; digital rights management is a new and important
consideration for manufacturers and content providers.

Second, accessibility barriers that were severe at the time when these
regulations were first drafted, and thus the subject of intense
interest, have been either resolved or rendered less relevant in the
current technology environment. For example the accessibility of online
forms has been improved to the point that, if the designers themselves
use the proper approach, the tools themselves no longer prevent the
design of accessible forms. This problem was a serious obstacle to
participation in e-government at the time the current version of the
Section 508 standard was developed; Provision 1194.22(n) specifically
addresses online forms. The Committee also felt that a more general user
interface approach would be better than addressing all interface
categories (of which online forms are only one) individually. In this we
have followed the practice of the Web Accessibility Initiative as well
as other accessibility efforts.

### Specific technologies {#specific-technologies .unnumbered}

Below are some examples of technologies whose introduction is altering
the landscape of accessibility.[^8] Some of these innovations may offer
improved accessibility to some users while jeopardizing others. Because
of these changes, awareness of capacities of technology to be used by
wider audiences has increased, and resources to provide information and
data in more accessible ways are more ubiquitous to assistive technology
producers.  This also means that assistive technology vendors and
information technology vendors need to improve methods of
interoperability to allow for each specialty group to do what they do
best.

1\. Web applications and web-software convergence. Web content has
shifted from the presentation of more or less static information to
full-fledged applications with complex user interfaces. For example,
there are now word processors and spreadsheets with virtually all the
features of installed software that exist entirely on the web. In fact,
the Committee made use of such tools in managing its work. This change
has reduced the distinction between "software" and "web" provisions.

2\. Convergence in hardware, especially mobile devices. Multipurpose
mobile devices have largely replaced voice-only mobile phones, some
amount of text, video, navigation, web browsing, and/or media playing
capabilities are features on mobile phones. In some mobile phones, it is
necessary to navigate through an IT like layer (usually Section 508
only) to get to the telephony functionality (Sections 255 and 508). Some
of these functions may not be covered by either Section 255 or 508 in
all cases.

3\. Changes to the concepts of \"self-contained,\" \"closed\" products.
This category had been established to require accessible functionality
where users could not be expected to install AT accommodations. However,
more and more products are software-defined, and have added some
openness to modifications of the user interface. At the same time
digital rights management (DRM) has closed some functionality of
otherwise open products. The Committee had difficulty in finding a
structure and a terminology to reflect the changes to both personal and
public/shared products; we recognize that there are now "closed product
functionality" rather than fully-closed products.

4\. Voice over Internet Protocol (VoIP). The growth of internet-based
telephony has complicated accessibility regulations. There are a variety
of VoIP applications available. There are different relationships to the
existing public switched telephone network, some of which are managed
only by the end user. Text and video have been added to some voice
services, and all have been integrated with each other and with
messaging and notification services.

5\. Multitouch and gesture interfaces. New touch interfaces on mobile
devices contain features far beyond simple keyboard simulation. These
touchscreens, cameras, and other movement detection systems can receive
and analyze complex actions: not only "chorded" input from several
fingers at once, but whole gestures like spreading two fingers apart or
tilting one's head to the side.

6\. Synchronized media has evolved and is now delivered digitally over
multiple pathways (broadcast, Internet, DVD, etc.). Users can interact
with these media, requiring more complex user interfaces. This evolution
means that issues beyond broadcast or transport must be addressed to
ensure that full access to such content is available no matter what
device or location it is accessed from.

7\. Assistive technologies have in some cases moved in to the
mainstream. For example speech input and output are becoming more common
place on devices such as cell phones and automobiles.  The concepts used
for communicating via interactive text are now fully mainstreamed.

Technology and the market move more quickly and unpredictably than the
current regulatory framework can easily accommodate. The Committee's
generalized approach to the user interface reduces this incompatibility,
and the Access Board may want to consider how it can address the pace of
rapid technological updates while maintaining regulatory reliability and
consistency.

## Harmonization

The Access Board directed the Committee to consider harmonization
issues. Harmonization means the adoption of specific accessibility
standards and guidelines across as many jurisdictions and standards
bodies as feasible. Harmonization results in a more unified regulatory
environment in which all participants benefit from clarity and
simplicity. Recognizing the importance of international harmonization,
representatives from the European Commission, Japan, Canada, and
Australia participated in TEITAC. Industry supports harmonization in
principle because it allows the ICT market to address accessibility
through a global process \-- one product developed to be sold world-wide
\-- rather than by trying to meet unique, potentially conflicting
standards required by different countries. Harmonization should result
in more accessible products, delivered through a more economically
efficient market. Consumers thus benefit directly from harmonization;
they also benefit indirectly because harmonization allows advocates to
focus their efforts on fewer standards development activities. It is
this economy of focused effort that may offer the greatest net benefit
to people with disabilities.

In practical terms, harmonization often means the adoption of an
international or national standard by a particular jurisdiction, or that
the jurisdiction\'s policies are derived from that international
standard. The Committee uses the term \"jurisdictions\" instead of
\"countries\" because one of the issues in the United States is how to
make sure we do not end up with 50 different state versions of the
Section 508 standard. It has been mentioned that states either adopt
Section 508 or do not, but some have made an effort to adapt it as they
adopt it, i.e., revising some provisions and/or creating additional
requirements. This has also occurred in some instances within the
Federal government. Such adaptations may reduce economy of scale if
there are conflicts or extension of standard provisions, making ICT more
expensive for all.

Accessibility has attracted the attention of standards bodies in diverse
fields. There are accessibility standards in buildings, ICT hardware,
software, web development, consumer electronics, transportation,
education, and other fields. These have arisen independently through
different professions and in different countries.

In the course of the last decade these standards and guidelines have
proliferated, along with a general awareness that some of the relevant
provisions might be in conflict with each other. These standards and
standards-setting committees include, among others:

-   ANSI C63.19: Wireless Hearing Aid Compatibility

-   IEC TC100 Multimedia Systems and Equipment, Technical Report:
    Usability Considerations for Audio, Video and Multimedia Systems and
    Equipment Standardization, Draft Survey of Opinions and National
    Body Positions

```{=html}
<!-- -->
```
-   ISO TC 173: Technical systems and aids for people with disabilities

-   ISO TC 159: Software Accessibility

```{=html}
<!-- -->
```
-   JIS X8341-5 "Accessibility Guideline for Office Equipment" held
    jointly by the Japanese Industrial Standards Committee (JISC) and
    Japanese Standards Association (JSA)

-   SOGITS N 1032 - EN for DG XIII: (European Standards)

-   Nordic Standards for Accessibility

-   World Wide Web Consortium (W3C) Web Accessibility Initiative
    Guidelines (Web Content Accessibility Guidelines; User Agent
    Accessibility Guidelines; Authoring Tool Accessibility Guidelines)

In October 2004, the Joint Technical Committee 1 (JTC 1) of the
International Organization for Standardization (ISO) and the
International Electrotechnical Commission (IED) established a Special
Working Group on Accessibility (SWG-A) to create a comprehensive summary
of user needs and inventory of existing accessibility standards. The
goal of the SWG-A is to raise awareness of existing accessibility
standards and to identify gaps where standards are not addressing user
needs.

The TEITAC was fortunate to have several members who also participate in
several of these other standards bodies.

The Committee worked to harmonize its recommendations with the W3C Web
Content Accessibility Guidelines 2.0 (WCAG 2.0) Working Group. The WCAG
2.0 Working Group also accepted changes from the Committee. This was
facilitated by the fact that there were several common members between
the two groups including a co-chair of the TEITAC subcommittee on Web
and Software guidelines and a co-chair of the WCAG Working Group.

We recommend that the Access Board continue to monitor WCAG 2.0 as it
proceeds to become a W3C recommendation by the end of 2008. Where there
are provisions in the TEITAC proposal that are harmonized with WCAG 2.0,
the Access Board should consider harmonization with the wording of the
final WCAG 2.0 provisions.

We also made an effort to harmonize with ISO 9241 part 171 where
appropriate. Some of the existing Section 508 software requirements do
not have a direct counterpart in WCAG 2.0 but were harmonized with the
ISO standard as appropriate.

### Planning for Future Updates {#planning-for-future-updates .unnumbered}

Regulatory changes happen at a slow pace because the rulemaking process
must take into account the perspectives of many stakeholders. This makes
it is difficult for regulatory change to match the pace of technological
change. The Committee's consultative process alone has taken almost two
years, and the subsequent rulemaking may take as long. By the time the
new rules are in effect, some may already be in need of updating. The
Committee discussed, but no consensus was reached on a method of
minimizing this time lag. The proposal of separating the more permanent
elements (such as Subpart A and the Functional Performance Criteria)
from the technical requirements, which are more subject to market and
technological changes is described below, but there are concerns that
shorter periods between provision changes would be hard to implement on
products since development cycles can be longer. It was also noted that
the change in cycles might be in conflict with Administrative Procedures
Act requirements for agency rulemaking.

The two types of provisions might have different review procedures. The
former could continue on the current 5-8 year cycle. The latter might
have "review triggers" such as:

-   Emerging products identified by technology analysts as having
    accessibility implications that are not addressed adequately by the
    technical standards.

-   Frequent references and concerns raised in FCC complaints, Section
    508 Coordinator dialogues, requests for technical assistance from
    the Access Board, etc.

-   Changes to standards documents (e.g., WCAG, ISO) cited by these
    regulations.

It might be possible to review the affected provisions quickly and
efficiently, using a narrowly focused mission, a smaller set of
stakeholders and open public input processes. The Access Board might
consider establishing such an approach and structure its near-term
rulemaking to prepare for it.

## Economic Impact

Changes to these regulations will have both direct and indirect effects
on the costs of implementation. The Access Board is responsible for
developing an Economic Impact Statement for the Office of Management and
Budget (OMB) as part of the process for implementing new versions of the
Section 255 guidelines and Section 508 standard. The Access Board
requested that the Committee provide qualitative information that the
Access Board could use in its Statement. This information is provided
for only a small number of the recommended provisions.

In this section, however, we would like to discuss the issue of economic
impact at a more abstract level, as a way of explaining how we came to
the conclusions we drew about the economic effect of the refreshed
Guidelines and Standard.

1\. The Access Board made it clear that our economic impact analysis
should refer only to changes from the current Section 508 provisions,
not overall impact. That is, the Access Board's Economic Impact
Statement will only state whether changes in the provisions add to or
subtract from the total cost of compliance.

2\. As we understand it, the economic effect of a change to an
individual provision will not be factored into OMB's review; only the
total aggregated effect is placed under scrutiny.

3\. We attempted to craft recommended provisions that are more clear
than the current ones based on the belief that clarity reduces costs
because it simplifies testing and analysis but may inhibit innovation.
In some instance we were able to do so and in others were not.

4\. We believe that harmonization generally reduces costs by eliminating
conflicts between different government and industry standards. The
Committee placed harmonization high on its list of criteria for drafting
provisions, and we believe that we have succeeded in eliminating
inconsistencies with any of the other standards of which we are aware.
Although such inconsistencies only affect ICT vendors directly, those
costs must be recaptured somehow in the price, and agencies will bear
the cost.

5\. We are aware that some provisions do in fact expand the scope and
level of effort, or will increase ICT costs in some other manner and the
overall volume of provisions is significantly expanded which will
increase the economic impact. In the case of VoIP, for example, the
Committee's recommendation assumes rough parity between VoIP and
non-VoIP forms of voice conversation. In doing so, the provision simply
follows the lead of the FCC's regulatory action. In other cases, the
recommended provision clarifies current Section 508 provisions. Even
when a gap was unintended, agencies may have avoided certain costs
through a mistaken interpretation. The correction of that mistake should
not be interpreted as a newly imposed obligation.

6\. Some of the provisions also take advantage of new technical
developments and have been reformulated to give companies new options
for meeting the provisions.

# Implementation Recommendations

## Serving Multiple Audiences

The Sections 255 and 508 materials have many audiences, with different
needs:

-   Procurement staff

-   ICT managers

-   Regulators and regulatory staff

-   Federal employees with disabilities

-   Designers, engineers, and developers, including document creators

-   Disability advocates

-   Consumers with disabilities

The provisions and related information should serve both those with a
deep knowledge of ICT accessibility, and those new to it.

The Committee worked with a goal to make clear and testable provisions.
This has resulted in there being more provisions and more details in the
individual provisions.

The Committee is also aware of the tools made available by the General
Services Agency (GSA) such as the BuyAccessible wizard (and
corresponding Buy Accessible Product and Services Directory), which can
help agency procurement officers determine what requirements to include
in a request for proposals (RFP) or other contract. Tools such as these
have proved valuable when working with other accessibility standards,
such as WCAG 2.0 and its Quick Reference tool.[^9]

The Committee is required to deliver its recommendations in a report
consisting of a complete set of provisions in a document suitable for
publication in the Federal Register. However, we also discussed several
alternatives to a report that could take the provisions out of a "flat"
document form, and put them into an electronic tool that could be
manipulated to deliver the kinds of information that different audiences
require, in the most suitable format. This work is beyond the scope of
the Committee, but we hope and expect tools to be developed that will
help all audiences make effective use of the provisions to procure,
develop or deploy products and services that meet the new regulations.
One value of tools such as these is that they help people identify the
provisions that are relevant to their current work, focus on their
accessibility tasks and improve their management. To help with this
future work, the report includes some limited (non-normative) additional
information for the provisions:

-   The source provision in both Section 508 and Section 255

-   Identification of any external references, such as other standards

-   Identification of any harmonization with other standards

-   The disabilities the provision addresses[^10]

It should be noted that the thorough process of discussion, iterative
modification, and final consensus used by the committee on the wording
of each provision was not utilized in the formulation of the metadata.
The metadata was by and large submitted by individuals and, although
subject to review and comment by committee members, was not discussed in
committee or brought forward for consensus.

## Testability

One criticism of the current Section 255 Guidelines and Section 508
Standard (and other accessibility standards efforts) is that the
provisions are too broad or vague resulting in conflicting
interpretations, and therefore not practical to test. We heard
repeatedly that some manufacturers can not easily determine whether
their product meets the requirements and that it is difficult for
purchasers to compare the claims of similar products. The Committee was
also informed that for certain types of products, the cost of the
proposed test procedures could exceed the product\'s development costs.
This is because reliable multi-scenario tests are labor-intensive and
not easily automated.

We are persuaded by these claims, but also recognize the necessity of
keeping the provision general enough to allow alternative solutions to
the underlying functional problem. As we considered each provision, we
tried to find a balance between generality and precision that is:

-   Precise and unambiguous enough to easily determine if a product
    meets the requirements of the provision.

-   Open enough, avoiding overly prescriptive language, so that the
    provision does not stifle innovation.

The Committee did not create any specific test methods for the
provisions in the recommendations. While there was discussion on what
type of test might be needed for each provision, no consensus was
reached. Including this section in the report was also a concern as this
is not a formal recommendation for test methods, but a statement of how
a test *might* be developed.

We used the terminology of "inspection," "measure (formal test)," and
"expert review," and included a reference to one of them in the
information that accompanies each provision.[^11]

-   **Inspection.** Systematic examination of the product to determine
    whether it possesses a feature or functions specified in the
    requirements. Requirements to be inspected must be either observable
    or easily measurable and require no interpretation or judgment in
    determining whether the standards are met. They may be based on
    easily taught criteria, which would be known to any professional
    with appropriate background. They may also be automated with simple
    tools.

```{=html}
<!-- -->
```
-   **Measure (Formal Test).** These tests may require specialized
    measurement equipment or software, such as a software or quality
    test tool that checks accessibility features, or may simply require
    that specific steps be followed to determine if a product meets the
    provision. In some cases, the formal test method is specified in an
    existing industry or regulator standard.

-   **Expert Evaluation/Review.** An accessibility subject matter expert
    (SME) performs a review of the product or its functionality to
    determine whether the provision is met. This method extends
    inspection by requiring expert knowledge and judgment. Expert
    evaluation has the most possibility for differences in
    interpretation. Explanatory notes and examples can help make the
    requirements of provisions clear, and have been included where
    needed.

## Assistive Technology and Sections 255 and 508

Sections 255 and 508 cover the requirements for "mainstream" ICT
products to be used by people with disabilities. Assistive technology
(AT) is often an essential part of accessibility for products that
support AT. [^12] In many cases, it provides accessibility where the IT
product can not do so on its own, and it enhances ease of use and
productivity for its users with disabilities. AT products most often
work in concert with a mainstream product to deliver to the user the
necessary interface features and flexibility. The two products must
interoperate to a high degree. In these cases it is important to
identify the requirements placed upon the ICT and AT products for
compatibility. The Committee also recognizes that for products with
closed functionality, where attaching AT is not possible, the
accessibility should be provided by the product itself.

The two laws treat the role of AT differently. Section 255 requires
accessibility in the mainstream telecommunications product, if readily
achievable. If it is not readily achievable, then Section 255 requires
compatibility with AT, again if readily achievable. In contrast, there
is no preference for mainstream ICT product accessibility in Section
508. Accessibility through AT is equally acceptable.

The Committee was fortunate to have members with long experience in
developing and using AT, as well as designing for compatibility with AT.
Below are some of the topics the Committee dealt with; some of these are
reflected in the Recommendations.

### Is AT ICT? {#is-at-ict .unnumbered}

Members of the Committee expressed concern about the status of assistive
technology products: are they subject to the Section 255 and 508
regulations themselves? In some cases this concern was expressed
regarding the need to share some of the compatibility burden equitably.
Although we did not completely resolve this issue, on one point we did
agree: whenever an AT product is acting on its own, it could be
classified as an ICT product for the purposes of these regulations. For
example, a direct-connect TTY, that is a TTY that can be plugged into a
regular phone line is not interoperating with any other device and is
considered ICT. If you are originating, routing, or terminating a call
from the TTY, then it is defined as customer premises equipment (CPE)
within Section 255.

### AT Interoperability and Testing Requirements {#at-interoperability-and-testing-requirements .unnumbered}

An application programming interface (API) is a method that establishes
interoperability between programs, or between a program and an operating
system, and is usually standardized and documented so that new
development can proceed without extensive consultations. Essentially it
is a published protocol that lays out how two or more pieces of software
shall interact with each other. It is commonly defined by a software
platform and utilized by a software application. An accessibility API
establishes mechanisms by which ICT and AT products can more easily
communicate and interoperate. Accessibility APIs exist and are used, but
none are currently mandated. In addition, some IT and AT vendors have
collaborated to achieve interoperability through other methods.

The Committee considered the possibility of recommending an API
requirement. A mandated accessibility API, if there were one that would
work across all platforms could resolve the assignment of compatibility
responsibilities between the AT software and IT software. Rather than
mandating any specific accessibility APIs, which need to be specific to
particular existing ICT products, the Committee proposed to describe the
minimum set of information that IT products must provide to AT either
through accessibility services or another method for cooperating with
AT. Further, the Committee proposed to recommend that ICT platforms
should define such a set of accessibility services, so that software
applications running on that platform can utilize those defined services
rather than needing to invent a new set. The Committee could not reach
consensus on this issue. As a result, the provision regarding AT
Interoperability is included in Section 7 "Provisions Considered but Not
Completed." For the most part the committee did agree on the text of
this provision. The concern lay in whether providing these capabilities
alone (i.e., exposing this information alone) was sufficient to pass
Section 508 or whether there had to be AT that government employees (and
the public) could get that was known to work with the product. It should
be noted that this provision is harmonized with the ISO 9241 part 171
provisions enabling compatibility with assistive technology.

The Committee discussed the use and sufficiency of accessibility APIs.
Should there be mandatory accessibility APIs? Would an ICT vendor fully
meet its responsibilities by building products to those APIs? What if
there were no AT product to perform the functionality on "the other
side" of the API? Must ICT products be tested with actual AT products?
If an API were fully comprehensive, it might be safe to assume that
testing to the API is sufficient. However, some members felt that this
may not be possible in many situations, given the complexity of, for
example, a software program and a screen reader interface. Just pairing
all the possible settings of both products might involve a large number
of tests. Both products may be going through revision cycles that are
not synchronized, adding further testing complexity.

If an API is not comprehensive, and if actual AT product compatibility
testing is required, what should be the extent of the testing? How many
versions of how many AT products should be tested against, and how
thorough should those tests be? The committee struggled with all of
these questions but could not reach a consensus.

### Reporting AT Compatibility Testing Results {#reporting-at-compatibility-testing-results .unnumbered}

The question about creating a requirement to report accessibility
testing results was discussed with no agreement reached. There was
concern regarding legal risks, indemnification clauses, and testing tool
license agreements as the reasons publishing test results should be
rejected. There was also concern that this information could be
important to the procuring agency.

During the course of a pre-procurement negotiation an ICT vendor could
be required by an agency to release its compatibility test results,
including gaps and workarounds it had discovered or developed. This was
a topic that the Committee could not reach consensus on.

## Accessibility for People with Cognitive Disabilities

The Committee considered recommendations for provisions to support
accessibility for people with cognitive, language and learning
disabilities. The Committee received presentations from two experts in
the field, Dr. Clayton Lewis and Nancy Ward, and learned about the wide
range of disabilities covered under this category. They include
intellectual and developmental disabilities, dementia (deterioration of
cognitive functioning), impairments of memory, aphasia, and a range of
specific learning disabilities. Both presenters shared examples of
products and features that help serve the needs of people with cognitive
disabilities.

Many of the provisions support people with cognitive disabilities as
well as improve access for people with other types of disability. Some
examples are the provisions on error identification (3-AA), not changing
context on input (3-Z) and on focus (3-Y). The information ICT must
provide to AT also supports the use of AT to provide for several of the
broad needs of people with cognitive disabilities that were identified
by Dr. Lewis.

Other suggested provisions included in the advisory notes for developers
are being passed on to the Access Board.

## Usability of the Standard and Guidelines

The difficulty of understanding the current regulations was one of the
recurring subjects of presentations and comments submitted throughout
our work. We heard that it is difficult for people from both government
and industry to understand the scope, detailed technical interpretation,
and applicability of the regulations.

There were many challenges in the process of working towards bringing a
high degree of usability to the standards. Our goal was to make them
effective at specifying product requirements for accessibility, and
useful in both the product development and procurement process. We had
to consider:

1.  How to organize the provisions so that it is easy for people to
    understand which requirements apply in any given situation.

2.  How to harmonize our work with other standards, fitting them into
    our own style and structure while leaving no doubt about the
    intended consistency.

3.  How to write the provisions themselves so they are clear and easy to
    understand, even when the content of the provision is technical.

### Writing Style of the Provisions {#writing-style-of-the-provisions .unnumbered}

One answer to the challenge of writing style can be found in the
approach to clear communication called "plain language." Guidance from
the National Archives' information on drafting regulations, for example,
says that "Readable regulations help the public find requirements
quickly and understand them easily. They increase compliance, strengthen
enforcement, and decrease mistakes, frustration, phone calls, appeals,
and distrust of government. Everyone gains."[^13]

Dr. Janice (Ginny) Redish presented to the Committee on "Why Plain
Language is Critical for Standards."[^14] Dr. Redish pointed out that
"Standards are not just statements of facts; they are communications to
people. If the purpose of a standard is to get people to behave in a
certain way, the standard must communicate successfully to those people.
If they do not understand what they are to do (and not to do), how will
they follow the standard?" She pointed out that plain language is not at
odds with writing a legal document, it supports the legal accuracy and
sufficiency of a standard or regulation. She defined plain language as
knowing your audiences and creating the document that works for those
audiences -- creating the document in which they can: find what they
need; understand what they find, and act appropriately on that
understanding in the time and effort that they are willing to spend on
it.

Dr. Redish offered guidelines that are similar to those found on the
Federal Register web site and on other advocacy sites such as the Center
for Plain Language and plainlanguage.gov, with examples from regulatory
writing.[^15] For example, use clear heading, keep sentences and
paragraphs short, set the context first so there is a logical order to
the sentence and use numbered lists where appropriate. In drafting the
language of the recommended provisions, we have tried to follow these
guidelines, and have worked to make the provisions and definitions as
clear and easy to understand as possible. We have also followed guidance
from the Federal Register to use the common word "must" in place of the
more legalistic (and less well understood) "shall."

We rejected two recommendations from both Dr. Redish and the Federal
Register guidance:

-   Write sections as questions and answers. This structure did not seem
    appropriate for the TEITAC provisions, but might be useful in
    guidance or advisory notes.

-   Use the term "you" for whoever must comply. There were many
    objections to this, including concerns that the provisions needed to
    identify the scope and target for each provision. Instead, we have
    tried to be specific, using phrases such as "A product must..." or
    "Any product with a keyboard must..." to make the scope clear.

### Making the Complex Clear {#making-the-complex-clear .unnumbered}

At the same time that the Committee has tried to put these
recommendations in plain language using a clear communication style, we
have had the further challenge of trying to break down complex technical
requirements into understandable requirements with simple explanations.
The Committee has used the following measures to achieve this result:

-   Many of the provisions include a "rationale" statement. This
    provided an opportunity to write an explanation for the goal of the
    provision outside of the rigorous language of regulatory
    requirements. The rationale can explain the reason the provision
    exists, identifies the disabilities or user needs the provision will
    address, or provide examples of problems it can correct.

-   Some provisions include definitions of technical formulas or other
    engineering measurements. Where this is true, we have tried to
    explain the measurement or test in simple language first, so that
    the provision can be read by both the general public and experts.

### Improving the Usability of the Requirements {#improving-the-usability-of-the-requirements .unnumbered}

Section 508 Coordinators and Access Board and FCC staff responsible for
technical assistance have gathered useful experience in communicating
about the Sections 255 and 508 requirements. We urge the Access Board to
continue to work to make the provisions as clear, unambiguous and
understandable as possible while at the same time continuing to allow
room for innovation. This ensures that people in government agencies,
industry, advocacy groups, and the general public will be able to use
the updated regulations to improve the accessibility of ICT products.

The Access Board should provide tools or other educational material to
help anyone using the regulation determine accurately (and efficiently)
which provisions apply to any specific product or procurement request.

-   Maintain links identifying harmonization to external standards.

-   Continue to work to improve the clarity of the language of the
    requirements.

-   Continue to work (through clarity of language or separate
    educational materials) to help users understand the goals of the
    requirements, especially for the more complex or deeply technical
    requirements.

## Recommendations for Research

In the course of reviewing the existing regulations the Committee
considered how those regulations have been implemented, including the
many requests for information and clarification brought to the Access
Board, GSA, the FCC, and others by federal agencies, federal employees,
and vendors. It has not always been clear how to meet the regulations,
given the diversity of ICT and the need for the regulations to be as
general as possible. Also, the Committee was aware of the many changes
in the ICT marketplace since the regulations were first finalized. Many
of these changes involve the evolution of products and services beyond
the categories embedded in the regulations due to technological changes,
market forces, or both. For example, websites have become software
applications, virtual operating systems downloaded one feature at a
time, and the use of Internet and wireless technologies for voice,
video, and text communication. We are seeing the first generation of
gesture-based interfaces that call into question many assumptions about
touchscreen technologies. The concern is how can a vendor or procurement
officer or average consumer navigate through this rapidly evolving
ecosystem?

In the hope of clarifying and possibly future-proofing the new
regulations, the Committee addressed the specific issues identified by
agencies, vendors, and consumers. Some of these questions simply can not
be answered yet, and require a certain amount of research.

As part of its work, the Committee was asked by the Access Board to
identify specific areas that would benefit from additional research. We
believe that the research needs we have identified are feasible. None
require the development of new technologies or groundbreaking scientific
work. In some cases they involve "knowledge translation" from clinical
language into a form suitable for technology standards. In other cases
what is needed is a clear review of the existing literature with an eye
towards the development of technological standards, especially in light
of the desire for international harmonization.

We have phrased the research requests as questions, with some
introductory material as needed.

### Captions {#captions .unnumbered}

What are the effects upon legibility and actual user performance of
various caption features: font, font size, style, and text display rate
for the different transmission methods (TV, PC, wireless) and display
sizes?

### Speech and Audio Volume and Quality {#speech-and-audio-volume-and-quality .unnumbered}

Although these topics first arose with respect to voice telephones, they
apply to all ICT that uses voice or other audio information features.
The current Sections 255 and 508 regulations only refer to
amplification.

What levels of amplification provide what level of functional benefit to
what kinds and numbers of users with hearing loss?

Raw amplification is not always an effective solution, especially if the
audio being amplified is noisy or unclear. Is there a definition of
"clarity" or intelligibility such that a measurable regulatory standard
is feasible and appropriate?

### Cognitive Disability {#cognitive-disability .unnumbered}

The TEITAC process was the first time that cognitive disabilities were
actively factored into the development of technological standards for
accessibility in the United States. We understand that cognitive
disabilities are diverse and complex, so the needs of these users may be
difficult to translate into clear technical requirements. For this
reason, many of our suggestions were advisory notes rather than
technical provisions. We also know that all ICT users occasionally
experience cognitive limits such as remembering passwords and
understanding product documentation. Is it currently possible to develop
technology standards for mainstream products and services that would
benefit real users with cognitive disabilities? If so, where are the
specific areas that would provide the greatest benefit? How can any AT
and ICT work together for users with cognitive disabilities?

### Biometrics {#biometrics .unnumbered}

Biometrics used for security or authorization purposes can exclude
individuals who lack certain physiological features or who can not
remain stationary long enough to be successfully registered. Are there
biometrics that are inherently inclusive? Are there any two or more
already commercially available biometrics that, if either option could
be used, would be totally inclusive?

### Audio Menus {#audio-menus .unnumbered}

There are anecdotal references that suggest that audio menus should be
limited to 4 or 6 maximum items. What does the body of research say
regarding audio menus for non-disabled users? Is there any relevant
research regarding people with either hearing or cognitive limitations?

### Low Vision: Relationship Between Clinical Metrics and Product Performance {#low-vision-relationship-between-clinical-metrics-and-product-performance .unnumbered}

The existing Section 255 and 508 regulations refer to \"20/70 vision.\"
It\'s not clear enough how this metric can be translated into a
technical specification for the performance of a product, such as
character size. While a provision has been recommended to deal with
this, it is a topic in need of more research.

### Photosensitive Seizure Disorders {#photosensitive-seizure-disorders .unnumbered}

The current Guidelines and Standard have provisions that disallow
products that flash in such a way as to cause photosensitive seizures,
but we are not sure that these provisions fully address certain research
findings regarding flash frequency, size of the flashing object, and
color of flash. Our recommendations add significant detail to the design
requirements, but a comprehensive report of existing research (e.g., a
survey article or equivalent) may be able to provide all the guidance
needed; if such a report is not sufficient, new research may be
required.

### Compatibility Between Prosthetics and Touch Sensitive Input Technologies {#compatibility-between-prosthetics-and-touch-sensitive-input-technologies .unnumbered}

Prostheses (especially their surface materials) and touch sensitive
input technologies are both evolving. How are these changes affecting
the accessibility of touchscreens by people who use prostheses? Can
requirements for prosthetic surfaces improve touchscreen accessibility,
with or without complementary touchscreen requirements?

### Gesture-based Input Technologies {#gesture-based-input-technologies .unnumbered}

There are several kinds of input devices that use gesture, and these are
rapidly finding their way into popular ICT products. The techniques
include touchscreens (both single touch and multitouch), accelerometers,
and cameras to detect a complex physical motion such as flicking across
a surface or giving the \"thumbs up\" sign. What are their positive and
negative accessibility implications? Are accessibility standards
feasible for these input systems?

# The Recommendations

### How to read these recommendations {#how-to-read-these-recommendations .unnumbered}

These recommendations include:

-   The text of the provision. This is the normative language
    recommended by the Committee.

-   Accompanying notes. There are three kinds of notes, described below.

-   Additional information. Additional information about the provision,
    described below. This text is included for informational purposes
    and is not intended to be included in the standards themselves.

In the text of the provisions, defined terms are marked with a special
style ("DEF") and a distinct visual appearance, for example:

> a [non-text object]{.smallcaps} is [synchronized media]{.smallcaps},
> live audio-only or live video-only [content]{.smallcaps}, then text
> alternatives must at least provide a descriptive [label]{.smallcaps}

#### Terminology Used in the Provisions {#terminology-used-in-the-provisions .unnumbered}

Following the guidance on writing regulations on the Federal Register
web site, we have used "***must"*** to indicate the normative
requirements.

Some provisions list more than one approach that will meet the
requirement. The use of \"or\" means that the listed options are equally
acceptable as a way to meet the requirement of the provision. For
example:

-   *\"Access may be delivered via built-in access features or through
    compatibility with assistive technology.\"* In this example, either
    of the two approaches is equally acceptable. A product is not
    required to provide both methods (for example, offering a user a
    choice between the approaches).

-   *\"A mechanism must be provided to either pause, stop, or hide
    moving or blinking content that is pure decoration.\"* In this
    example, a product may choose at least one of the three options
    listed: (1) pause, or (2) stop, or (3) hide.

#### Notes Included with the Provisions {#notes-included-with-the-provisions .unnumbered}

There are three kinds of notes included with the provision text.

-   **Notes in the provisions**. These are explanatory notes, intended
    to accompany the provision. They are informative, not normative.
    They are listed immediately below the provision text in a numbered
    list.

-   **Rationale.** These are brief text that explains the purpose of the
    provision or provides additional explanation about the deliberations
    of the Committee. They are intended to help the Access Board
    understand the provision more clearly. These notes are not part of
    the provision text.

-   **Advisory Notes to the Access Board.** In a very few cases, the
    Committee wishes to add an additional recommendation to the Access
    Board that relates directly to how the provision will be completed
    or implemented. Provisions without consensus also include viewpoints
    on the drafts from Committee members. These notes are not part of
    the provision text.

#### Additional Information Included with the Provisions {#additional-information-included-with-the-provisions .unnumbered}

Each provision includes a list of additional information. This text is
not normative, but is included for informational purposes.

-   Text from -- The subcommittee with original responsibility for the
    provision.

-   Source -- The paragraph numbers from the current Section 508 and
    Section 255 used as the starting point for the recommendation. Where
    there is no change, this is indicated.

-   External Reference -- Any other legislation, standards or guidelines
    referenced in the provision, or with which the provision is
    harmonized.

-   Impact -- The impact of the *change* in the provision from the
    current 508 and 255 language. In some cases, there are alternate
    estimates of impact included in the report.

-   Testability -- Inspection, Expert Review or Formal Test Method (see
    the section of this report on "Testability" for more information).

-   Disabilities -- The disabilities for which this recommendation is
    intended to remove barriers.

#### General Exceptions  {#general-exceptions .unnumbered}

Note that General Exceptions in Subpart A take precedence over both the
technical requirements in Subpart C and the functional performance
criteria in Subpart B.

## General Introduction

*This language was accepted from the 508/255 Task Force to be used as a
blanket rationale for the provisions regarding Section 255. It is placed
in a general introduction because it affects provisions in Parts B, C
and D. The language here, and elsewhere in the provisions are taken from
the approved Task Force report \"TF report 1. 9. 08.doc.\"*

In establishing the rules implementing Section 255, the FCC has defined
the types of products and services that must comply with the rules. The
FCC has determined that the Section 255 rules also apply to information
and documentation associated with the covered products, as well as
information and documentation necessary to use the covered products.
This information and documentation includes user guides, bills,
installation guides for end-user installable devices, and product
support and communications. Technical standards that would improve the
accessibility of any of the items covered by Section 255, whether a
phone, a printed user guide, or a web-based billing function, would be
candidates for inclusion in the Access Board's Section 255 guidelines.
Unless otherwise noted, the technical standards apply to Section 255,
because they are necessary to make the covered products accessible to
and usable by people with disabilities, consistent with Section 255.

## Subpart A  {#subpart-a-1 .unnumbered}

### 1. Purpose {#purpose .unnumbered}

*There are two versions of the application section, one for Section 255,
and one for Section 508. The Purpose did not reach consensus. This draft
language is provided for information on the deliberations of the
Committee*

The purpose of this part is to implement Section 508 of the
Rehabilitation Act of 1973, as amended (29 U.S.C. 794d) and Section 255
of the Telecommunications Act, 47 U.S.C. 255.

#### Purpose for Section 255 {#purpose-for-section-255 .unnumbered}

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

#### Purpose for Section 508 {#purpose-for-section-508 .unnumbered}

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

Rationale

Federal procurement officials and other subcommittee members requested
the addition of information to help guide them in determining when
access to data and information for individuals with disabilities was
\"comparable\" to that available for individuals without disabilities.
The subcommittee relied on information from Office of Civil Rights
decisions regarding comparable access to identify the critical concepts
of \"timely, accurate, complete and efficient.\" The explanatory note
was developed to assist in assuring understanding and consistency in
application. The subcommittee added the word \"communication\" to
\"information and data\" to clarify that communication is part of
information and data. While this information has been infused into the
Purpose section, it could alternatively be added as a new section under
Application.

Advisory Notes to the Access Board

*This explanatory material is recommended for both the Sections 255 and
508 purposes.*

**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 requirements
specified in Subpart C.

The determination of timely, accurate, complete, and efficient will not
be a quantifiable measure.

### 2. Application {#application .unnumbered}

*There are two versions of the application section, one for Section 255,
and one for Section 508*

#### Application for Section 255 {#application-for-section-255 .unnumbered}

Where [readily achievable]{.smallcaps}, [telecommunications]{.smallcaps}
and [interconnected VoIP]{.smallcaps} equipment and [customer premises
equipment]{.smallcaps} must comply with the requirements of Part
C-Technical Requirements of this \[rule\].

Where it is not [readily achievable]{.smallcaps} to comply with Part
C-Technical Requirements, [telecommunications]{.smallcaps} and
interconnected VoIP equipment and [customer premises
equipment]{.smallcaps} (CPE) must comply with the requirements of Part
B-Functional Performance Criteria, if [readily achievable]{.smallcaps}.

Product design, development and evaluation (for equipment and
[CPE]{.smallcaps} covered under Section 255)

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

\(b\) In development such a process, [manufacturers]{.smallcaps} must
consider the following factors, as the [manufacturer]{.smallcaps} deems
appropriate:

> \(1\) Where market research is undertaken, including individuals with
> disabilities in target populations of such research;
>
> \(2\) Where product design, testing, pilot demonstrations, and product
> trials are conducted, including individuals with disabilities in such
> activities;
>
> \(3\) Working cooperatively with appropriate disability-related
> organizations; and
>
> \(4\) Making reasonable efforts to validate any unproven access
> solutions through testing with individuals with disabilities or with
> appropriate disability-related organizations that have established
> expertise with individuals with disabilities.

Prohibited reduction of accessibility, usability and compatibility

\(a\) For purposes of Section 255, no change must be undertaken that
decreases or has the effect of decreasing the net accessibility,
usability, or compatibility of [telecommunications
equipment]{.smallcaps}, [interconnected VoIP equipment,]{.smallcaps} or
[customer premises equipment]{.smallcaps} used with
[telecommunications]{.smallcaps} or [interconnected VoIP
services]{.smallcaps}.

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

-   Text from: {255} §1193.21 (first paragraph) and {255} §1193.23
    (second section).

#### Application for Section 508 {#application-for-section-508 .unnumbered}

*In general, this section applies only to the consideration of
accessibility in the process of developing, procuring, maintaining, or
using* [electronic and information technology]{.smallcaps}*. (see note
#1).*

\(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]{.smallcaps}, each
[agency]{.smallcaps} shall ensure that the products comply with the
applicable provisions of this part, unless an [undue burden]{.smallcaps}
would be imposed on the [agency]{.smallcaps}.

> \(1\) When compliance with the provisions of this part imposes an
> [undue burden]{.smallcaps}, [agencies]{.smallcaps} 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 developing, procuring, maintaining, or using a product, if
> an [agency]{.smallcaps} determines that compliance with any provision
> of this part imposes an [undue burden]{.smallcaps}, the documentation
> by the [agency]{.smallcaps} supporting the development, procurement,
> maintenance, or use must explain why, and to what extent, compliance
> with each such provision creates an [undue burden]{.smallcaps}. (see
> note #2)
>
> \(3\) When determining whether application of the standards would
> result in an [undue burden]{.smallcaps}, an [agency]{.smallcaps} must
> consider all [agency]{.smallcaps} resources available to the program
> or component for which the product is being developed, procured,
> maintained, or used.
>
> \(4\) Technical infeasibility, if substantiated by empirical evidence
> or documentation, is one factor in determining whether application of
> the standards \[provisions\] would constitute an [undue
> burden]{.smallcaps}. (see note #3)

\(b\) When procuring a product, each [agency]{.smallcaps} shall procure
products that 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]{.smallcaps} cannot claim a product as a whole is not
commercially available because no product in the marketplace meets all
the standards.

*If products that meet all of the standards are not commercially
available the agency must procure the product that best meets the
applicable access standards, given the agency\'s business needs. (see
note #4)*

\(c\) Except as provided by §1194.3(b), this part applies to [electronic
and information technology]{.smallcaps} developed, procured, maintained,
or used by agencies directly or used by a contractor under a contract
with an agency that 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.

-   Source: {508}1194.2

Rationale

1\. This additional introductory 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. Agencies
are required to consider accessibility within the framework of other
regulated procurement practices such as the FAR. Consensus was not
reached on this item and the alternative position is to not add this
introductory language.

2\. The undue burden clause in prior regulations only applied to
procurement. It is assumed the application of undue burden should apply
to all areas covered by Section 508 including development, maintenance,
and use of E&IT in addition to procurement.

3\. Subsection (a)(3) was added to infuse information from the
definition of undue burden into the application section and subsection
(a)(4) was added to clarify how technical infeasibility is considered as
part of undue burden.

4\. The last sentence of subsection (b) (in italics) has been reworded
to clarify 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. The rewording is intended to improve understanding of
the sentence. A reference to business need has also been added in an
attempt to clarify the interaction between degree to which a product
conforms to the access standards and overall agency needs. The wording
"given business needs" was an attempt to parallel the direction from the
Access Board that best meets means "best meets the agency's needs in
light of the accessibility requirements of Section 508."

Consensus was not reached on this item and an alternative position is to
delete the last sentence completely, leaving subsection (b) with the
first two sentences. Deleting the last sentence would defer 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 Section 508
regulations. As a result, GSA and the Access Board could consider how to
best provide guidance for agencies to implement Section 508 within the
procurement process through the FAR rather than the Section 508
regulations.

A third alternative would be to keep the current regulatory language
without change.

Advisory Note to the Access Board

The Committee recommends that the Access Board develop supplemental
materials to assist in determining what is and is not E&IT.

### 3. General Exceptions {#general-exceptions-1 .unnumbered}

#### A - Intelligence Or Security Systems {#a---intelligence-or-security-systems .unnumbered}

This part does not apply to any [electronic and information
technology]{.smallcaps} operated by [agencies]{.smallcaps}, 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 that are critical to the direct fulfillment
of military or intelligence missions. Systems that 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).

-   Source: {508}1194.3(a), no change

#### B- Incidental To A Contract  {#b--incidental-to-a-contract .unnumbered}

This part does not apply to [electronic and information
technology]{.smallcaps} that is acquired by a contractor incidental to a
contract.

-   Source: {508}1194.3(b), no change

#### C - Employees Not Individuals With Disabilities  {#c---employees-not-individuals-with-disabilities .unnumbered}

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]{.smallcaps}
device at a workstation of a Federal employee who is not an individual
with a disability.

-   Source: {508}1194.3(c), no change

#### D - Access By Public {#d---access-by-public .unnumbered}

When agencies provide access to the public to information or data
through [electronic and information technology]{.smallcaps},
[agencies]{.smallcaps} 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]{.smallcaps} 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]{.smallcaps} is provided to the public.

-   Source: {508}1194.3(d), no change

#### E - Fundamental Alteration {#e---fundamental-alteration .unnumbered}

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

1\. A fundamental alteration occurs when the accessibility feature or
functionality would substantially reduce the overall functionality of
the product, materially render some features inoperable by those not
using the access feature, or substantially impede or deter use of the
product by those not using the access feature.

2\. With respect to [assistive technology]{.smallcaps} that is
[E&IT]{.smallcaps}, a fundamental alteration occurs when compliance with
one or more of the technical standards or functional performance
criteria would substantially reduce the overall functionality of the
[assistive technology]{.smallcaps} for its primary targeted disability
population, materially render some features inoperable by the target
population, or substantially impede or deter use of the product by the
target population.

3\. For [E&IT]{.smallcaps} subject to Section 255, in order to claim
fundamental alteration, a [manufacturer]{.smallcaps} must document that
compliance with one or more of the technical standards or functional
performance criteria would substantially or materially interfere with
the purpose and function for which the product is being developed.

-   Source: {508}1194.3(e)

#### F - Maintenance and Monitoring Aspects of Products  {#f---maintenance-and-monitoring-aspects-of-products .unnumbered}

Those portions of products whose design limits physical access, and that
are only accessed for maintenance, repair, or occasional monitoring are
not required to comply with this part. This part does apply to the
controls or interfaces of such products where the controls or interfaces
could be executed externally or remotely.

Rationale

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.

-   Source: {508}1194.3(f)

### 5. Equivalent Facilitation {#equivalent-facilitation .unnumbered}

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.

-   Source: {508}1194.5, no change

## Subpart A: Definitions

**Accessible Content Format:** *(This definition was not completed. See
Section 7 for draft text.)*

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

**Application Software:** *(This definition was not completed. See
Section 7 for draft text.)*

**Assistive Technology (AT)**: 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 for assistive
purposes, virtual assistive technology delivered as a web service and
integration of products into a system that provides assistive technology
functions that allow individuals with disabilities to access [electronic
and information technology]{.smallcaps}.

Rationale

Added language clarifying that assistive technology includes web based
and integration services, and including any general or mainstream
technology which is used for assistive purposes.

Advisory Note to the Access Board

Following agreement on the basic definition, there was an uncompleted
request to add \"service is compatible with existing peripheral devices
or specialized customer premises equipment commonly used by individuals
with disabilities to achieve access,\" for Section 255. The statutory
language from Section 255 is:

> \(d\) Compatibility: Whenever the requirements of subsections (b) and
> (c) of this section are not readily achievable, such a manufacturer or
> provider shall ensure that the equipment or service is compatible with
> existing peripheral devices or specialized customer premises equipment
> commonly used by individuals with disabilities to achieve access, if
> readily achievable.

**Authoring Tools:** *(This definition was not completed. See Section 7
for draft text.)*

**Blinking:** *(This definition was not completed. See Section 7 for
draft text.)*

**CAPTCHA:** Initialism for \"Completely Automated Public Turing test to
tell Computers and Humans Apart.\"

Note 1: CAPTCHA tests often involve asking the user to type in text that
is presented in an obscured image or audio file.

Note 2: A Turing test is any system of tests designed to differentiate a
human from a computer. It is named after famed computer scientist Alan
Turing. The term was coined by researchers at Carnegie Mellon
University.

**Captions:** *(This definition was not completed. See Section 7 for
draft text.)*

**Caption Text:** *(This definition was not completed. See Section 7 for
draft text.)*

**Closed Product Functionality:** Functionality of a product where
[assistive technology]{.smallcaps} 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]{.smallcaps} or vendor policies, etc.
    [Agencies]{.smallcaps} 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.\")

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

Examples: Word processing files, presentation files, spreadsheet files,
text files, portable document files, web based, etc.

**Content Format:** An encoding mechanism for storing information.

Examples: HTML, JPEG, SMIL, PDF, etc.

**Contrast Ratio:** The [relative luminance]{.smallcaps} of the lighter
of the foreground or background colors compared to the [relative
luminance]{.smallcaps} of the darker of the foreground or background
colors.

(L1 + 0.05) / (L2 + 0.05), where

-   L1 is the [relative luminance]{.smallcaps} of the lighter of the
    foreground or background colors, and

-   L2 is the [relative luminance]{.smallcaps} of the darker of the
    foreground or background colors.

Note 1: Contrast ratios can range from 1 to 21 (commonly written 1:1 to
21:1).

Note 2: For dithered colors, use the average values of the colors that
are dithered (average R, average G, and average B).

Note 3: Text can be evaluated with anti-aliasing turned off.

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

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

**Customer Premises Equipment**: Equipment employed on the premises of a
person (other than a carrier) to originate, route, or terminate
[telecommunications]{.smallcaps} or [interconnected VoIP
service]{.smallcaps}.

Source: Telecommunications Act of 1996; FCC Order No. 07-110

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

**Electronic and Information Technology (E&IT):** Includes [information
technology]{.smallcaps} 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]{.smallcaps} 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]{.smallcaps} that is used as an integral part of the product,
but in which [information technology]{.smallcaps} is not the principal
function of that product.

Explanatory Note

This definition is derived from Clinger-Cohen and cannot be changed.
However, this is still an issue for agencies, and the Committee 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.

**Enhanced Audio:** *(This definition was marked for removal See Section
7.)*

**Flash:** *(This definition was not completed. See Section 7 for draft
text.)*

**Free-standing:** *(This definition was not completed. See Section 7
for draft text.)*

**General Flash and Red Flash Thresholds for Hardware:** *The Committee
agreed to send this draft language for the definition that accompanies
2.1-B: Flashing to the Access Board as a basis for further work on exact
numbers in the definition and further work. (See text marked in
italics.)*

A hardware [flash]{.smallcaps} is below the threshold (i.e., software or
[content]{.smallcaps} passes) if any of the following is true:

1\. There are no more than three General Flashes and / or no more than
three Red Flashes within any one-second period; or

2\. The [flash]{.smallcaps} frequency is 50 or 60 Hz and is due to a
refresh that is intrinsically tied to the local line frequency; or

3\. The [flash]{.smallcaps} frequency is 75 hz or greater; or

4\. General [flashes]{.smallcaps} (that have less than a 590 nm
wavelength) are no more than 20 cd/m2 AND red flashes (that have a 590
nm wavelength or longer) are no more than 2.5 cd/m2; or

*5. General* [flashes]{.smallcaps} *are no more than
(1200/N\^0.3)(0.006/AREA -- 1) cd/m2 AND red flashes (that have a 590 nm
wavelength or longer) are no more than (150/\^0.3)(0.006/AREA -- 1)
cd/m2*; or

6\. There is an adaptive brightness feature that always keeps the
changes in luminance of [flashes]{.smallcaps} from all sources (that
might [flash]{.smallcaps} \> 3 hz) below the maximum of (1, ambient(in
lux)/700 lux) times the threshold values in 4 or 5 above.

-   Where N is the number of sources that are [flashing]{.smallcaps}
    together more than 3 times per second within a 0.024 steradian
    circle

-   Where AREA is the summed area of the N sources, measured in
    steradians (at the minimum typical/expected viewing distance)

-   And where sources that are separated by less than .4 degrees ( \~2mm
    at 12 inch viewing distance) are treated as a single source with
    AREA being the area from edge to edge of the group.

Note 1: Most products can safely use a minimum typical / expected
viewing distance of 12 inches where 0.006 steradians would be a circle
of 1.05 inch diameter.

Note 2: Red sources with wavelengths of 590 or more nm are especially
provocative since, due to the way the eye and brain process light with
longer wavelengths.

Note 3: Each of the following examples would meet option 5 (when viewed
from at least 12 inches) even when all of the sources are flashing
together at more than 3 Hz:

-   1 round LED with a diameter of 5 mm or less, and no more than 32,000
    cd/m2.

-   1 rectangular indicator with a size of 10 by 20 mm or less, and no
    more than 2,100 cd/m2.

-   3 square indicators (within a 2.1 inch circle) each 6 mm square or
    less, and no more than 3,500 cd/m2.

-   4 round indicators (within a 2.1 inch circle) each 8 mm in diameter
    or less, and no more than 1,400 cd/m2.

-   5 rectangular indicators (within a 2.1 inch circle) each 6 by 2 mm,
    and no more than 6,100 cd/m2.

(For light sources that are Red flashes (that have a 590 nm wavelength
or longer) the values for luminance in this note should be divided by
8.)

(For comparison, the maximum brightness of a white screen on an LCD
computer monitor is about 200 to 400 cd/m2.)

Rationale

The hardware flash values are based on the CIE Small Angle Disability
Glare Equation in Johannes J Vos \"On the cause of disability glare and
its dependence on glare angle and ocular pigmentation\" in Clinical and
Experimental Optometry 86.6, November 2003 and \"Commission
Internationale de l\'Eclairage" (CIE.) CIE equations for disability
Glare. CIE report #146. Vienna: CIE 2002. This equation also includes an
age factor. 62.5 was used as the age in generating the constants in
equation in #5 above.

Advisory Note to the Access Board

The working group came up with the definitions for "general flash and
red flash thresholds for hardware" after much effort but there was not
sufficient time to explore them as much as necessary to come to
consensus on them. The "general flash and red flash thresholds for
hardware" therefore does not have consensus. What the group did agree on
was:

1\. Very bright point sources or very bright small sources can be a
problem (per Graham Harding.)

2\. Very bright point sources or very bright small sources should be
allowed if they flash less than 3 per second.

3\. Flashing above 3 per second should be allowed if is as equivalently
safe as with the Software flash thresholds.

4\. Some metrics for identifying 'equivalently safe' were created but
more time is needed by everyone to study them and their derivation
before they are used by anyone including the Access Board.

5\. The numbers were included in this report in order to facilitate
review by different parties.

**General Flash and Red Flash Thresholds for Content and User
Interfaces:** *(This definition was not completed. See Section 7 for
draft text.)*

**Information Technology:** *(This definition was not completed. See
Section 7 for draft text.)*

**Interactive Elements:** *(This definition was not completed. See
Section 7 for draft text.)*

**Interconnected Voice over Internet Protocol (VoIP) Product:** A
product that is used to provide [interconnected VoIP
service]{.smallcaps}

Source: FCC regulations 47 C.F.R. §9.3

**Interconnected Voice over Internet Protocol (VoIP) Service:** A
service that:

1\. Enables real-time, two-way voice communications;

2\. Requires a broadband connection from the user\'s location;

3\. Requires Internet protocol-compatible [customer premises
equipment]{.smallcaps}; and

4\. Permits users generally to receive calls that originate on the
public switched telephone network and to terminate calls to the public
switched telephone network.

Source: FCC regulations 47 C.F.R. §9.3

**Keyboard**: A set of systematically arranged keys by which a machine
or device is operated and alphanumeric input is provided such as a
computer keyboard, a cell-phone keypad, or a television remote control
that can generate alphanumeric input. Tactilely discernable keys that
are used in conjunction with the main cluster of keys are included in
the definition of keyboard as long as their function also maps to keys
on any [keyboard interfaces]{.smallcaps}.

**Keyboard Interface:** A means for accepting input from a
[keyboard]{.smallcaps}. For software, this would be the ability to
accept [keyboard]{.smallcaps} input from the operating system including
on-screen [keyboards]{.smallcaps}. For hardware this would be the
ability to connect a [keyboard]{.smallcaps} via wired or wireless
connection.

**Label:** [Text]{.smallcaps} or other component with a text alternative
that is presented to a user to identify a component within
[content]{.smallcaps}.

Note: A label is presented to all users whereas the name may be hidden
and only exposed by assistive technology. In many (but not all) cases
the name and the label are the same.

Source: WCAG 2.0

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

**Manufacturer:** *(This definition was not completed. See Section 7 for
draft text.)*

**Menu:** *(This definition was not completed. See Section 7 for draft
text.)*

**Non-text Object:** Any object that is not a sequence of characters
that is [programmatically determinable]{.smallcaps} or where the
sequence is not expressing something in human language.

Note: This includes, but is not limited to, ASCII Art (a pattern of
characters), emoticons, leetspeak (character substitution), and images
representing text.

**Other Services To Cooperate With Assistive Technologies:** A method,
other than the [platform accessibility services]{.smallcaps}, used to
interoperate with [assistive technologies]{.smallcaps}.

**Platform Accessibility Services:** *(This definition was not
completed. See Section 7 for draft text.)*

**Platform Software:** Collection of software components that runs on an
underlying software or hardware layer, and that provides a set of
software services to applications that allows them to be isolated from
the underlying software or hardware layer.

Note 1: For our purposes, it is those software components/services
provided to applications for the creation or manipulation of user
interfaces and user input - that impact accessibility - which are of
concern for whether something is a platform or not. An application
offering a compute service, such as a 3D rendering engine where a
requesting application isn\'t using the software components/services to
create a user interface and interact with the user, should not be
considered a \"platform.\"

Note 2: If applications typically connect directly to the underlying
layer, rather than relying solely on the platform software components
and services, then it is likely that the software components in the
middle are not acting as a \"platform.\" For example, a program that
hosts plug-in\'s is not a platform if the plug-in can directly access
the underlying layer.

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.

**Programmatically Determinable:** *(This definition was not completed.
See Section 7 for draft text.)*

**Readily Achievable:** Easily accomplishable and able to be carried out
without much difficulty or expense.

Source: Telecommunications §1193.3

**Real-time Text:** *(This definition was not completed. See Section 7
for draft text.)*

**Simple Tactile Form***: (This definition was not completed. See
Section 7 for draft text.)*

**Specialized Customer Premises Equipment:** Equipment employed on the
premises of a person (other than a carrier) to originate, route, or
terminate [telecommunications]{.smallcaps} or VoIP services, which is
commonly used by individuals with disabilities to achieve access.

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

**Synchronized Media:** Audio or video displayed at the same time as
other time-based [content]{.smallcaps} that is required for
understanding of the complete presentation. The other
[content]{.smallcaps} that the audio or video is synchronized with to
meet this definition does not include equivalents such as
[captions]{.smallcaps}, subtitles, or [video description]{.smallcaps}.

**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]{.smallcaps} of the information as sent
and received.

Source: Telecommunications Act of 1996

**Telecommunications Equipment**: Equipment, other than [customer
premises equipment]{.smallcaps}, used by a carrier to provide
[telecommunications services]{.smallcaps}, and includes software
integral to such equipment (including upgrades).

Source: Telecommunications §1193.3

**Telecommunications Service:** The offering of
[telecommunications]{.smallcaps} for a fee directly to the public, or to
such classes of users as to be effectively available directly to the
public, regardless of the facilities used.

Source: Telecommunications §1193.3

**Terminal:** Device and/or software 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.

**Text:** *(This definition was not completed. See Section 7 for draft
text.)*

**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]{.smallcaps}
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.

**Typically Held to the Ear:** A product that is positioned immediately
adjacent to ear, either by hand or by a strap or holder of some kind, in
typical use.

-   Headphone and headsets that connect to a product via a standard
    connector are not considered as products that are \"held up to the
    ear\" but rather alternate speakers to a device.

-   Handsets are considered products or part of a product.

Note: Headphones and headsets with standard connectors are not included
in this definition because users can substitute other headphones or
headsets or neck loops that meet their individual needs and can use them
with the product.

**Unavailable Items:** Interface elements that cannot be selected, or
interacted with accept as read-only items on screen due to application
state or other reasons.

**Undue Burden:** Undue burden means significant difficulty or expense.
In determining whether an action would result in an undue burden, an
[agency]{.smallcaps} must consider all [agency]{.smallcaps} resources
available to the program or component for which the product is being
developed, procured, maintained, or used.

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

Source: Telecommunications §1193.3

**Video Description:** *(This definition was not completed. See Section
7 for draft text.)*

## Subpart B: Functional Performance Criteria {#subpart-b-functional-performance-criteria .unnumbered}

The purpose of the Functional Performance Criteria is to help Federal
departments or [agencies]{.smallcaps} determine whether products being
used, developed, procured or maintained meet the functional needs of
individuals with disabilities. The functional performance criteria have
three roles:

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

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

3.  The Functional Performance Criteria can also be used to help
    departments and agencies identify and report product functions that
    may not meet the Functional Performance Criteria and evaluate the
    importance of the lack of access to those functions relative to the
    intended use of the product.

#### A - Without Vision {#a---without-vision .unnumbered}

Products must provide at least one mode that allows access to all
functionality of the product without using vision. *(See note on
functional performance criteria and assistive technology.)*

#### B - With Limited Vision  {#b---with-limited-vision .unnumbered}

Products must provide at least one mode that allows access to all visual
functionality of the product without requiring visual acuity greater
than 20/70 and without relying on audio output. *(See note on functional
performance criteria and assistive technology.)*

#### C - With Color Vision Deficits  {#c---with-color-vision-deficits .unnumbered}

Products must provide at least one mode that allows access to all
functionality without relying on users' perception of color. *(See note
on functional performance criteria and assistive technology.)*

#### D - Without Hearing  {#d---without-hearing .unnumbered}

Products must provide at least one mode that allows access to all
functionality of the product without using hearing. *(See note on
functional performance criteria and assistive technology.)*

#### E -- With Limited Hearing (no consensus) {#e-with-limited-hearing-no-consensus .unnumbered}

*Work on this provision was not complete. Please see the drafts and
other discussion material in Section 7*

#### G - Without Speech {#g---without-speech .unnumbered}

Products must provide at least one mode that allows access to all
functionality of the product without requiring user speech. *(See note
on functional performance criteria and assistive technology.)*

#### H - With Limited Reach, Strength, or Manipulation  {#h---with-limited-reach-strength-or-manipulation .unnumbered}

Products must provide at least one mode that does not require gestures,
pinching, twisting of the wrist, tight grasping, or simultaneous
actions. In this mode, all controls must be within reach (as defined by
the reach limits in the current ADAAG). *(See note on functional
performance criteria and assistive technology.)*

#### I -- Without Physical Contact (no consensus) {#i-without-physical-contact-no-consensus .unnumbered}

*Work on this provision was not complete. Please see the drafts and
other discussion material in Section 7*

#### J -- With Cognitive, Language, or Learning Limitations (no consensus) {#j-with-cognitive-language-or-learning-limitations-no-consensus .unnumbered}

*Work on this provision was not complete. Please see the drafts and
other discussion material in Section 7*

[Note on functional performance criteria and assistive
technology]{.underline}

The Functional Performance Criteria state what should be possible with
the product, but do not specify how this may be accomplished. In some
cases the access to the functionality of the product may be direct,
without any assistive technologies. In other cases the access may be
possible if a piece of [assistive technology]{.smallcaps} is used in
conjunction with the product (screen reader, special
[keyboard]{.smallcaps}, etc.). Either means for achieving access
satisfies Section 508. For Section 255, where [readily
achievable]{.smallcaps}, products must provide access directly through
compliance with the technical requirements. Where that is not readily
achievable, products must comply with §1193 Subpart D-Requirements for
Compatibility With Peripheral Devices and [Specialized Customer Premises
Equipment]{.smallcaps}.

Advisory Note to the Access Board

The Committee was unable to come to an agreement on whether the first
two roles for the Functional Performance Criteria, as described in the
introduction to the recommendations in Subpart B are requirements
(\"must\") or an options (\"can\"). The Access Board is requested to
make this determination.

## Subpart C: Technical Requirements

For the purposes of Section 255, each [manufacturer]{.smallcaps} of a
product that is used to provide [telecommunications]{.smallcaps} or
[interconnected VoIP service]{.smallcaps} must ensure that such products
are designed, developed and fabricated to incorporate the access
features described in the technical requirements, if [readily
achievable]{.smallcaps}. Whenever it is not [readily
achievable]{.smallcaps} to incorporate such access features directly
into the products, the [manufacturer]{.smallcaps} must ensure that the
products are compatible with existing [peripheral devices]{.smallcaps}
or [specialized customer premises equipment]{.smallcaps} commonly used
by individuals with disabilities to achieve access, if [readily
achievable]{.smallcaps}. (Source: FCC Regulations 47 C.F.R. §§6.5; 7.5)

For the purposes of Section 508, compliance with the technical
requirements may be achieved directly or through [assistive
technology]{.smallcaps}, unless the [agency]{.smallcaps} can show that
such compliance would cause an [undue burden]{.smallcaps}.

### 1. General Technical Requirements {#general-technical-requirements-1 .unnumbered}

#### 1-A: Closed Functionality {#a-closed-functionality .unnumbered}

If any functionality of a product is closed for any reason including
policy constraints or technical limitations then that [closed
functionality]{.smallcaps} must be made available to and operable by
people with disabilities within the product itself. As a result, the
following provisions would not apply to the [closed
functionality]{.smallcaps}:

-   2.1-E - Connector or Connection Language

-   3-F - All Non-Text Objects

-   3-G - Human Language

-   3-H - Language of Parts

-   3-N - Link Purpose

-   3-O - Information and Relationships

-   3-P - User Interface Components (no consensus)

-   3-Q - Disruption of Access Features

-   3-U - AT Interoperability (partial consensus)

-   3-V - Accessibility Services

-   3-VV - Assistive Technology (no consensus)

Additional Information

-   Text from Self Contained, Closed

-   Source: {508}1194.25(a)

-   Testability: Expert evaluation

-   Disabilities: All

#### 1-B: Biometric ID {#b-biometric-id .unnumbered}

If a product uses a biometric form of user identification that relies on
a person possessing one unique biological characteristic that some
people may not have, an alternative method of identification must also
be provided.

[Agencies]{.smallcaps} must provide an alternate, biometric or
non-biometric, means of access for anyone who can not use the provided
biometrics-based form of identification.

Note: Fingerprints and iris patterns are two examples of \"unique
biological characteristics that some people may not have.\"

Rationale

This provision allows biometric systems in the future that are based on
circulatory system or other characteristics common to all people.

Advisory Note to the Access Board

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

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

Additional Information

-   Text from: General

-   Source: {508}1194.25(d), {508}1194.26(c) (was 1.2-D in Oct 26 draft)

-   Testability: Inspection

-   Disabilities: All that could be caused by loss of a relevant body
    part or function

#### 1-C: Pass Through {#c-pass-through .unnumbered}

Products that transmit or conduct information or communication must
preserve accessibility information that is transmitted in
non-proprietary, industry-standard codes, translation protocols, or
formats.

Technologies that use encoding, signal compression, format
transformation, or similar techniques must not remove information needed
for access, or must restore it upon delivery.

Firewalls, routers, gateways and other products that pass real-time
voice communication must also pass [real-time text]{.smallcaps}
communication signals (including mixed voice and [real-time
text]{.smallcaps}) that are standard in the United States for that
technology platform without distortion or error beyond 1%.

Additional Information

-   Text from Telecommunications

-   Source: {508}1194.23(j), {255}1193.37

-   Testability: Inspection

-   Disabilities: Hearing, vision, cognition

#### 1-D: Audio Information {#d-audio-information .unnumbered}

Products must provide a mode in which audio is not the only means of
conveying information, indicating an action, or prompting a response.

Note: Before implementing a solution, please review the introductory
material on the differences between Section 255 and Section 508, as they
treat assistive technology (AT) solutions differently.

Additional Information

-   Text from Self-Contained/Closed

-   Source: {255}1194.43(d)

-   Testability: Expert evaluation

-   Disabilities: Deafness, Hard of Hearing

#### 1-E: Visual Information (no consensus) {#e-visual-information-no-consensus .unnumbered}

*Work on this provision was not complete. Please see the drafts and
other discussion material in Section 7*

#### 1-F: Color  {#f-color .unnumbered}

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

Example: A conforming example is: mandatory form fields are identified
with colored [text]{.smallcaps} and labeled as \"Required.\"

Note: This provision is duplicated in 3-A: Color

Additional Information

-   Text from Web/Software

-   Source: {508}1194.25(g) and 1194.21(i): {255}1194.41(c)

-   Impact: No change

-   External Reference: Harmonized with [[WCAG 2.0-1.4.1 Use of Color
    (Level
    A]{.underline}](http://www.w3.org/TR/WCAG20/#visual-audio-contrast))
    and ISO 9241-171

-   Testability: Inspection

-   Disabilities: Color deficiency/Colorblindness

#### 1-G: Text Size (no consensus) {#g-text-size-no-consensus .unnumbered}

*Work on this provision was not complete. Please see the drafts and
other discussion material in Section 7*

#### 1-H: Speech Operation  {#h-speech-operation .unnumbered}

If a product includes operation via user speech, there must be an
alternative non-speech mode of operation for all functions operable by
speech.

Rationale

This provision covers both the speech operation aspect of the old
telecommunications and status information provision, (along with 1-D
Audio Information and 1-E Visual Information) and also the need in
general to have products operable by those who cannot speak.

"Speech operation" means "speech that the product interprets as a
command."

Additional Information

-   Text from Telecommunications - Section 6: Caller and Status
    Information

-   Source: {508}1194.23(e)

-   Impact:

-   External Reference:

-   Testability: Inspection

-   Disabilities: Speech

### 2. Requirements for Hardware Aspects of Products {#requirements-for-hardware-aspects-of-products-1 .unnumbered}

### 2.1 All Products with Hardware {#all-products-with-hardware .unnumbered}

#### 2.1-A: Reflectance Contrast for Legends and Passive Displays  {#a-reflectance-contrast-for-legends-and-passive-displays .unnumbered}

If passively illuminated displays, primary legends, or instructions
printed on the device are the only means of conveying information, then
the reflectance contrast must be at least 3:1.

1\. If other means of conveying the information in the
[label]{.smallcaps} or instructions exists (e.g., uniquely tactilely
discernible though shape), then the reflectance contrast requirement
does not apply.

2\. This requirement excludes product information [labels]{.smallcaps},
such as the regulatory labels, where information can be found in other
sources associated with the product either in hard- or soft copy format.

3\. Reflectance contrast (RC) is calculated in the following manner RC =
(RH +0.02)/(RL+0.02) where RH = Reflectance of high (bright) element; RL
= Reflectance of low (dark) element, where the reflectance is always a
value between 0 and 1.

4\. The secondary functions are not required to meet this provision. For
example, on [keyboards]{.smallcaps} the alphanumeric
[labels]{.smallcaps} are the primary legends and should meet this
convention; however, the secondary functions (such as the blue numbers
on an embedded numpad on a notebook) are not required to meet this
provision as they are infrequently used and in the case of the numpad
may add to visual clutter and additional confusion relative to the
[keyboard]{.smallcaps} interaction.

Additional Information

-   Text from Hardware

-   Source: {508}1194.21(j) & .25(h)

-   Testability: Formal test method

-   Disabilities: Low vision

#### 2.1-B: Flashing (Hardware) {#b-flashing-hardware .unnumbered}

*The Committee agreed to send this draft language for 2.1-B: Flashing
(Hardware) to the Access Board as a basis for further work on exact
numbers in the definition and further work.*

If products emit light in [flashes]{.smallcaps} at any time then either
there must be no more than 3 [flashes]{.smallcaps} in any 1 second
period or the [flashing]{.smallcaps} must be below the [general flash
and red flash thresholds for hardware]{.smallcaps}.

Rationale

This provides equivalent coverage for hardware. It does not cover
extremely bright point sources that might cause flare within the eye as
we could find no data at this time on which to base such a requirement.

Advisory Note to the Access Board

The working group came up with the definitions for "general flash and
red flash thresholds for hardware" after much effort but there was not
sufficient time to explore them as much as necessary to come to
consensus on them. The "general flash and red flash thresholds for
hardware" therefore does not have consensus. What the group did agree on
were the following points:

1\. Very bright point sources or very bright small sources can be a
problem (per Graham Harding).

2\. Very bright point sources or very bright small sources should be
allowed if they flash less than 3 times per second.

3\. Flashing more than 3 times per second should be allowed if is as
equivalently safe as with the Software flash thresholds.

4\. Some metrics for identifying 'equivalently safe' were created but
more time is needed by everyone to study them and their derivation
before they are used by anyone including the Access Board.

5\. The numbers were included in this report in order to facilitate
review by different parties.

There is consensus on the flash provision for software and content and
the general flash and red flash thresholds for software and content.

Additional Information

-   Text from: New

-   Source: {508}1194.21(k) 1194.22(j) 1194.25(i), and {255}1193.43(f)

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

-   Testability: Inspection

-   Disabilities: Photosensitive seizure disorder

#### 2.1-C: Mechanical Controls  {#c-mechanical-controls .unnumbered}

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.

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
requirement does not imply that a product must be entirely operable with
one hand (e.g., product could be placed on a surface).

Additional Information

-   Text from Hardware

-   Source: {508} 1194.26(a); 1194.23(k)

-   Testability: Inspection

-   Disabilities: Mobility, dexterity, vision

#### 2.1-D: Touch Operated Controls {#d-touch-operated-controls .unnumbered}

If a product uses touch screens or touch-operated controls, it must
provide functionally equivalent alternative means of operation that
meets the requirements for Mechanical Controls and does not require user
speech. At least one functionally equivalent alternative means of
operation must not require vision. Likewise, at least one functionally
equivalent alternative means of operation must not require fine motor
control.

Note: A product may also provide control via user speech in addition to
the above methods.

Rationale

This language addresses the issues associated with touch-based controls
(including biophysical, accidental activation and vision) by requiring a
redundant interaction method without assigning the control type.

Additional Information

-   Text from Hardware

-   Source: {508} 1194.26(b); {508} 1194.25(c)

-   Testability: Inspection

-   Disabilities: Mobility, dexterity, vision

#### 2.1-E: Standard User Interface Connection {#e-standard-user-interface-connection .unnumbered}

If users can access and control the user interface of a product through
a non-standard user connection, they must also be able to control that
functionality through a standard user connection using a standard
protocol if a standard protocol exists that will work with that type of
input or output. If an adapter is required to convert a non-standard
user connection on an [E&IT]{.smallcaps} device into a standard user
connection, the procuring [agency]{.smallcaps} must identify a market
source for the connector if it isn\'t a standard option for the product.

Additional Information

-   Text from Hardware and Telecommunications

-   Source: {508} 1194.26(d)

-   Testability: Inspection

-   Disabilities: All

#### 2.1-F: Installed or Free-Standing Products {#f-installed-or-free-standing-products .unnumbered}

Architecturally installed or [free-standing]{.smallcaps} non-portable
products intended to be used in one location must have all controls
needed to access full functionality positioned within reach.

Advisory Note to the Access Board

The Access Board should review the version of the ADAAG in effect at the
time of adoption, and insert the appropriate reach-range requirements.

Additional Information

-   Text from Hardware

-   Source: {508} 1194.25(j), {255}1193.41(f)

-   External Reference: Harmonized with ADAAG

-   Testability: Inspection

-   Disabilities: Mobility, dexterity

### 2.2 If the Product has Speech Output or Throughput {#if-the-product-has-speech-output-or-throughput .unnumbered}

#### 2.2-A: Magnetic Coupling {#a-magnetic-coupling .unnumbered}

Products that deliver output with an audio transducer that is [typically
held to the ear]{.smallcaps} must provide a means for effective magnetic
wireless coupling to hearing technologies that allows a user of such
hearing technology to effectively utilize the product. This does not
apply to headphone, headset, or other accessories that plug into a jack
on the product.

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

Note 2: Cellular and PCS handsets that meet a minimum of T3 or T4
measurement rating per ANSI C63.19 (2007) will meet this requirement.
Devices in other frequency bands (700 MHz, AWS) are not yet included in
this standard, but may be so at a later time. Digital wireline cordless
devices that meet TIA-1083 will meet the requirement for these types of
devices.

Additional Information

-   Text from Hardware and Telecommunications

-   Source: {508}1194.23(h), {255}1193.43(i)

-   External Reference: ANSI C63.19 (2007), TIA-1083

-   Testability: Formal test method

-   Disabilities: Hard of Hearing

#### 2.2-B: Interference with Hearing Device {#b-interference-with-hearing-device .unnumbered}

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]{.smallcaps} product.

This provision can be met by complying with applicable standards for
interference levels. At the time of this committee report the applicable
standards are:

-   For cellular and PCS handsets: M3 or M4 and T3 or T4 measurement
    rating per ANSI C63.19 (2007)

-   For digital wireline cordless devices: TIA-1083

Devices in other frequency bands (700 MHz, AWS) are not yet included in
ANSI C63.19 (2007), but maybe so at a later time.

Advisory Note to the Access Board

The Access Board should review relevant standards at the time of
adoption, and update as needed.

Additional Information

-   Text from Hardware and Telecommunications

-   Source: {508}1194.23(i), {255}1193.43(h)

-   Impact: minimal

-   External Reference: ANSI C63.19 (2007), TIA-1083

-   Testability: Formal test method

-   Disabilities: Hearing, Hard of Hearing

#### 2.2-C: Audio Connection {#c-audio-connection .unnumbered}

When products provide information via speech output or throughput, one
of the following must be true:

1\. Conforming Handset: The product is designed to be located in a
public location and auditory output is available via audio transducer
that is [typically held to the ear]{.smallcaps} that meets 2.2-A
(Magnetic Coupling), 2.2-B (Interference with Hearing Device), and 2.2-E
(Volume - gain) and product does not require simultaneous use of
[keyboard]{.smallcaps}; or

2\. Audio Jack: A standard 2.5mm or 3.5mm audio jack for
headphones/headsets that allows for private listening is provided; or

3\. Hardwire Adapter: The product is not designed to be located in a
public location and a hardwire adapter from the product\'s audio output
format to a 2.5mm or 3.5mm audio jack that allows for private listening
is commonly available or available from the [manufacturer]{.smallcaps};
or

4\. Wireless Adapter: The product is not designed to be located in a
public location and a wireless adapter is commonly available, or
available from the [manufacturer]{.smallcaps}, that provides a standard
2.5mm or 3.5mm audio jack that allows for private listening, has similar
size and battery life performance to the product, and that allows the
user the ability to pair the adapter to the product without assistance
or needing to use audio output; or

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

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

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

Rationale

-   Public phones have amplification and coupling, which meets the needs
    of almost all users, so a jack would not be needed.

-   Audio output critical to use of kiosks and other products where user
    needs to hear information from product in order to use it. (Either
    usual output or speech output.)

-   Users should not be required to carry 'all' adapters with them, so
    public systems should not require them to have an adapter to use the
    product (other than a simple 2.5 to 3.5 or 3.5 to 2.5 adapter)

-   The RJ-9/RJ-10/RJ-11/4P4C (or the final standard name) connector has
    adapters as does Bluetooth and RCA and USB. This note was added
    since there was concern that unless in a note, purchasing agents may
    not recognize it as allowable.

-   Addresses the issue of "private listening," which is provided via
    the standard handset.

-   Kiosks with keyboards usually require blind people to have both
    hands free.

-   Addresses the key need for such a connection on kiosks -- and that
    audio connection be in a standard form that people who are blind
    will have audio connector for.

-   Addresses the need to have an audio connector somewhere on public
    Audio or Audio-Video systems so that public assistive listening
    device systems can be connected.

How it would apply

-   Public phones would use (1 - Conforming Handset).

-   Office phones would likely use (3 -- Any Hardwire Connection with
    Adapter Avail) but could use (2 -- Audio Jack) or (4 -- Wireless
    Adapter).

-   Cell phones would likely use (2 -- Audio Jack) or (3 -- Any Hardwire
    Connection with Adapter Avail) but could use (4 -- Wireless Adapter)
    if small, long life Bluetooth adapters become available.

-   Computers with build in speech conversation could use (2 -- Audio
    Jack), which most have already, or (3 -- Any Hardwire Connection
    with Adapter Avail) or (4 -- Wireless Adapter).

-   Kiosks without keyboards could use (1 - Conforming Handset) or (2 --
    Audio Jack) or both.

-   Kiosks WITH keyboards would have to use (b -- Audio Jack) or, of
    course, both (1 - Conforming Handset) and (2 -- Audio Jack).

-   Television sets would use (3 -- Any Hardwire Connection with Adapter
    Avail) or (5 - Public Display Only).

-   Public address systems and custom designed public video displays
    would use (5 -- Public Display Only), which only requires an audio
    connection that users will already have.

Additional Information

-   Text from Hardware

-   Source: {508} 1194.25(e); {255}1193.51(b), {255}1193.43(g)

-   Testability: Inspection

-   Disabilities: Hard of hearing

#### 2.2-D: Volume {#d-volume .unnumbered}

For products that generate speech output delivered via speakers:

1\. Products designed for communal use must be capable of a volume level
of at least 80 dB SPL RMS.

2\. Products not designed for communal use must be capable of a volume
level of at least 65 dB SPL RMS.

3\. All products must have less than 12 dB symmetrical clipping at all
volume levels including maximum volume level.

4\. Volume on audio jacks must be user adjustable.

Note: Volume output via speakers should be measured at a typical
listener position for that product using a 2KHz (?) reference signal.

Rationale

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

Advisory Note to the Access Board

The specification for the reference signal used to measure volume output
need to be confirmed with technical experts.

Additional Information

-   Text from Self-Contained/Closed

-   Source: {508}1194.25(f), {255}1193.43(e)

-   Testability: Formal test method

-   Disabilities: Hard of hearing

#### 2.2-E - Volume (Gain) {#e---volume-gain .unnumbered}

For products that deliver voice throughput:

1\. Users must be able to adjust the audio output level.

2\. All [telecommunications]{.smallcaps} products powered solely from
analog telephone lines and having an audio transducer [typically held to
the ear]{.smallcaps}, and all cordless telephones, must comply with FCC
regulation §68.317 for volume control.

3\. All cellular telephones -- Defer to committee listed in Note 5.

4\. All other products that provide a voice communication function via
an audio transducer [typically held to the ear]{.smallcaps} must comply
with FCC regulation §68.317 for volume control. In addition, they must
provide built-in gain of at least 15 dB above the normal unamplified
level when measured as specified in FCC regulation §68.317.

Note: Headsets and earphones are not subject to this provision as long
as they use industry standard connectors that allow specialized
headsets, earphones and coupling cables for assistive listening devices
to be used in their place. 3.5mm phone, 2.5mm phone, and RJ-10 are all
examples of industry standard connectors that meet this requirement.

Advisory notes to the Access Board

The following notes are technical notes relevant to this provision. They
reflect discussions of the Committee and are included to assist the
Access Board in writing advisory notes.

1\. The provision of volume control gain is not particularly related to
whether the voice communication is carried by an analog signal, digital
encoding, packet technology (e.g., VoIP), etc. It does, however, depend
on the power available to the amplifier providing the gain function.
This distinction has been taken into account in specifying the volume
control gain requirements. For example the requirements for a
battery-powered cordless telephone applies whether the product uses
analog, digital, or VoIP technology.

2\. FCC regulation §68.317 requires both analog and digital telephones
to provide between 12 and 18 dB of gain at the maximum volume control
setting relative to their volume at the normal unamplified level. The
gain is allowed to exceed 18 dB if it is automatically reset to the
nominal level when the telephone goes back on hook. \[The FCC also has a
procedure described in Memorandum Opinion and Order DA 01-578 for
waiving the automatic reset requirement for telephones specifically
designed for use by hard of hearing persons, provided adequate warnings
are placed on the telephone.\] In addition, the volume at the normal
unamplified level has to meet requirements specified in industry
standards ANSI/EIA-470-A-1987 (for analog telephones) and
ANSI/EIA/TIA-571-1991 (for digital telephones).

3\. FCC regulation §68.317 makes reference to older industry standards
in specifying how to measure the received acoustic loudness and
determine compliance with requirements for both gain and loudness at the
normal unamplified level. Clause 15.2 of TIA TSB-31-C,
Telecommunications -- Telephone Terminal Equipment -- Rationale and
Measurement Guidelines for U.S. Network Protection, provides guidance on
how to apply these requirements to test methods specified in current
standards, including measurement procedures for analog, digital, and
VoIP telephones.

4\. Other products or systems that provide a voice communication
function, including products and systems that do not have an audio
transducer that is typically held to the ear, such as speakerphones,
should provide at least 15 dB of volume control range above the normal
unamplified listening level. In these cases of speakerphones, it is
desirable for the volume control to provide at least 15 dB of gain above
the normal unamplified level, but there is no agreed upon specification
as to what constitutes the normal unamplified level.

5\. Volume (gain) on cellular and PCS handsets is currently the focus of
review and study in Working Group 11 of the ATIS Incubator program,
which is expected to be available no later than June 2008. The Committee
will make no recommendation at this time, but urges the Access Board to
review the recommendations from the study, and update this provision if
needed.

Additional Information

-   Text from Telecommunications

-   Source: {508}1194.23(f), {255}1193.43(e)

-   External Reference: FCC §68.317, ANSI/EIA-470-A-1987 (for analog
    telephones) and ANSI/EIA/TIA-571-1991 (for digital telephones)

-   Testability: Formal test method

-   Disabilities: Hard of hearing

#### 2.2-F - Volume Reset {#f---volume-reset .unnumbered}

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 [typically held to the
ear]{.smallcaps} that are neither headsets nor headphones.

-   Text from Telecommunications

-   Source: {508}1194.23(g)

-   External Reference: FCC Memorandum Opinion and Order DA 01-578

-   Testability: Inspection

-   Disabilities: None

### 3. Requirements for User Interface and Electronic Content {#requirements-for-user-interface-and-electronic-content .unnumbered}

People designing, developing, maintaining, or procuring user interface
and electronic [content]{.smallcaps} are urged to review the entire
Subpart C, especially Section 1: General Technical Requirements. The
provisions in this section apply to all [electronic and information
technology]{.smallcaps}, including web sites, software and other user
interfaces or electronic [content]{.smallcaps}.

#### 3-A: Color {#a-color .unnumbered}

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

Example: A conforming example is mandatory form fields are identified
with colored [text]{.smallcaps} and labeled as \"Required.\"

Rationale

Beneficial for people who are color blind, which is a large portion of
the population. Programmatic exposure of color is not sufficient for
color blind users. A visually redundant means is necessary.

Advisory Note to the Access Bo[ard]{.underline}

This provision is a copy of Subpart C: 1-F - Color. This General
Technical Requirement is particularly important for the accessibility of
User Interface and Electronic Content, so is repeated here to ensure
that it is considered in creating accessible products.

Additional Information

-   Text from Web and Software

-   Source: {508}1194.21 (i), 1194.22(c) and 1194.25(h), {255}1193.41(c)

-   Impact: Minimal: Currently the Section 508 software provision on
    color is equivalent to this one so no impact for software. 255 also
    has an equivalent provision so there is no impact to telecom
    products. The Web provision allows for the color to be
    programmatically determinable so there is a slight impact there.

-   External Reference: Harmonized with [[WCAG 2.0-1.4.1 Use of Color
    (Level
    A]{.underline}](http://www.w3.org/TR/WCAG20/#visual-audio-contrast))
    and ISO 9241.171

-   Testability: Inspection

-   Disabilities: Color deficiency/Colorblindness

#### 3-B: Contrast {#b-contrast .unnumbered}

Presentation of [text]{.smallcaps}, and images of [text]{.smallcaps}, in
electronic documents must have a [contrast ratio]{.smallcaps} of at
least 5:1, except for the following:

1\. Large Print: [Large scale text]{.smallcaps} and images of [large
scale text]{.smallcaps} must have a [contrast ratio]{.smallcaps} of at
least 3:1;

2\. Incidental: [Text]{.smallcaps} or images of text that are part of an
inactive user interface component, that are pure
[decoration]{.smallcaps}, that are incidental [text]{.smallcaps} in an
image, or that are not visible to anyone, have no minimum contrast
requirement.

Additional Information

-   Text from Web and Software

-   Source: {508}1194.21(j)

-   Impact: There are two opinions about the impact of this provision\
    Version 1: Significant: There are currently no measurable criteria
    for contrast in Section 508.\
    Version 2: Minimal: Simple tools are available to evaluate contrast.

-   External Reference: Harmonized with [[WCAG 2.0-1.4.3 Contrast
    (Minimum) (Level
    AA)]{.underline}](http://www.w3.org/TR/WCAG20/#visual-audio-contrast)
    and ISO 9241-171

-   Testability: Formal test method

-   Disabilities: Low Vision, Color deficiency/Colorblindness (?)

#### 3-C: Size, Shape, Location {#c-size-shape-location .unnumbered}

Instructions provided for understanding information and operating
on-screen user interfaces must not rely solely 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 can be used to meet this provision.

Example: Rather than saying "When done press the button to the right,"
say "When done press the Submit button."

Rationa[l]{.underline}e

A user of a screen reader cannot discern which on-screen button to
trigger if the desired button is only identified by a visual
characteristic such as shape, size or location such as \"When done press
the button on the right\" or \"round button\" or \"large button\" or
\"arrow pointing to the right.\"

Additional Information

-   Text from Web and Software

-   Source: new

-   Impact: Minimal: No current requirement in Section 508.

-   External Reference: Harmonized with [[WCAG 2.0-1.3.3 Sensory
    Characteristics (Level
    A)]{.underline}](http://www.w3.org/TR/WCAG20/#content-structure-separation)

-   Testability: Inspection

-   Disabilities: Blindness

#### 3-D: User Preferences {#d-user-preferences .unnumbered}

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]{.smallcaps} (and
images of text) must have a [contrast ratio]{.smallcaps} of at least 5:1
except for the following:

1\. Large Print: [Large scale text]{.smallcaps} and images of [large
scale text]{.smallcaps} must have a [contrast ratio]{.smallcaps} of at
least 3:1;

2\. Incidental: [Text]{.smallcaps} or images of text that are part of an
inactive user interface component, that are pure
[decoration]{.smallcaps}, that are incidental [text]{.smallcaps} in an
image, or that are not visible to anyone, have no minimum contrast
requirement.

Note: Application software that is also a platform would need to 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.

Rationale

In the current Section 508 provision, the phrases \"shall not override\"
and \"other display attributes\" are vague and raise testability issues.
The reworded provision clarifies that the application should utilize a
definitive list of display settings. The reworded provision also
requires a minimum contrast for scenarios where the platform does not
provide color and contrast settings. This is needed so that users
requiring good contrast will be provided with at least a 5:1 contrast
ratio in the software user interface. The contrast requirements are
harmonized with WCAG 2.0 and with 3-B Contrast.

Additional Information

-   Text from Web and Software

-   Source: {508}1194.21(g)

-   Impact: Minimal for desktop platforms. Significant for websites and
    other types of platforms such as mobile devices.

-   External Reference: [[WCAG 2.0-1.4.3 Contrast (Minimum) (Level
    AA)]{.underline}](http://www.w3.org/TR/WCAG20/#visual-audio-contrast)

-   Testability: If platform settings, inspection; if no platform
    settings, formal test method

-   Disabilities: Low vision, Color deficiency/Colorblindness

#### 3-E: Color Adjustment {#e-color-adjustment .unnumbered}

When a user function is provided to adjust color and contrast settings,
at least one color selection capable of producing a minimum luminosity
[contrast ratio]{.smallcaps} of 7:1 must be provided.

Rationale

The current provision is weak and impossible to fail. If an application
doesn\'t permit the user to adjust color and contrast settings, it
passes. If it does permit the user to adjust them, the requirement to
provide \"a variety of color selections capable of producing a range of
contrast levels\" is so subjective that they all pass.

Additional Information

-   Text from Web and Software

-   Source: {508}1194.21(j)

-   Impact: Minimal for desktop software. Potentially significant for
    Web sites and applications and non-desktop software platforms that
    allow color and contrast adjustments. It is the same as current
    Section 508 software provision except it provides a testable
    measurement of contrast that is harmonized with WCAG 2.0. In this
    case, the higher ratio of 7:1 was chosen because this is not the
    contrast required for presentation but the contrast a user should be
    permitted to achieve through adjustments. It is therefore reasonable
    to require a higher contrast ratio.

-   External Reference: [WCAG 2.0-1.4.6 Contrast (Enhanced) (Level
    AAA](http://www.w3.org/TR/WCAG20/#visual-audio-contrast))

-   Testability: Formal test method

-   Disabilities: Color deficiency/Colorblindness, Low Vision

#### 3-F: Non-text Objects {#f-non-text-objects .unnumbered}

All [non-text objects]{.smallcaps} that are presented to the user must
have a [text]{.smallcaps} alternative that presents equivalent
information, except for the situations listed below.

1\. Controls-Input: If a [non-text object]{.smallcaps} is a control or
accepts user input, then it must have a name that describes its purpose.
(See also User Interface Components provisions.)

2\. Media: If a [non-text object]{.smallcaps} is [synchronized
media]{.smallcaps}, live audio-only or live video-only
[content]{.smallcaps}, then text alternatives must at least provide a
descriptive [label]{.smallcaps} that identifies the [non-text
object]{.smallcaps}. (For [synchronized media]{.smallcaps}, see also
Audio and/or Video provisions.)

3\. Test: If a [non-text object]{.smallcaps} is a test or exercise that
must be presented in non-text format, then text alternatives must
identify at least the [non-text object]{.smallcaps} with a descriptive
text [label]{.smallcaps}. (For [synchronized media]{.smallcaps}, see
also Audio and/or Video provisions.)

4\. Sensory: If a [non-text object]{.smallcaps} is primarily intended to
create a specific sensory experience, then text alternatives must
identify at least the [non-text object]{.smallcaps} with a descriptive
text [label]{.smallcaps}. (For [synchronized media]{.smallcaps}, see
also Audio and/or Video provisions.)

5\. [CAPTCHA]{.smallcaps}: If the purpose of a [non-text
object]{.smallcaps} is to confirm that [content]{.smallcaps} is being
accessed by a person rather than a computer then text alternatives that
identify and describe the purpose of the [non-text object]{.smallcaps}
must be provided and alternative forms in different modalities must be
provided to accommodate different disabilities.

6\. [Decoration]{.smallcaps}, Formatting, Invisible Objects: If a
[non-text object]{.smallcaps} is pure [decoration]{.smallcaps}, or used
only for visual formatting, or if it is not presented to users, then it
must be implemented such that it can be ignored by [assistive
technology]{.smallcaps}.

Note: In order to satisfy this provision, non-text objects in data
operated on by the software would need to be associated with textual
equivalents that the software can obtain as readily as it can obtain the
non-text object itself. Where a non-text object is a scanned image of
text, textual equivalents would need to allow for the inclusion of the
text of the scanned image of text. Where a non-text object is a dynamic
presentation, graphs, or other derived information from a data source,
textual equivalents would need to allow for the inclusion of the data
used.

Rationale

Harmonization with WCAG 2.0, which provides more guidance on the text
alternatives themselves. The word \"objects\" is used in this provision
to make it clear to software developers that their user interface is to
be included. If the word \"content\" was used they may not think this
applies to their work.

Additional Information

-   Text from Web and Software

-   Source: {508}1194.22(a)

-   Impact: Minimal: Section 508 already has the requirement for text
    alternatives. This provision provides more guidance on appropriate
    text alternatives and allows some things that were not allowed
    before so may even save some money.

-   External Reference: Harmonized with [[WCAG 2.0-1.1.1 Non-text
    Content (Level
    A)]{.underline}](http://www.w3.org/TR/WCAG20/#text-equiv)

-   Testability: Inspection

-   Disabilities: All

#### 3-G: Human Language {#g-human-language .unnumbered}

When supported in the technologies of electronic documents, the default
human language of electronic document must be [programmatically
determinable]{.smallcaps}.

Note: In order to achieve this provision, text encoded in data operated
on by the software would need to be associated with sufficient
information to identify both the primary language of the text, and the
language of any sections or the text that are in another language from
the primary language, that the software can obtain as readily as it can
obtain the text itself.

Additional Information

-   Text from Web and Software

-   Source: new

-   Impact: Minimal for HTML Web pages. Could be significant for other
    document types. There is no current requirement in Section 508 but
    adding the language identifier at the document level is a small
    amount of effort.

-   External Reference: Harmonized with [[WCAG 2.0-3.1.1 Language of
    Page (Level A)]{.underline}](http://www.w3.org/TR/WCAG20/#meaning)

-   Testability: Inspection

-   Disabilities: Blindness

#### 3-H: Language of Parts {#h-language-of-parts .unnumbered}

When supported in the technology of electronic documents, the human
language of each passage or phrase in electronic documents must be
[programmatically determinable]{.smallcaps}.

Additional Information

-   Text from Web and Software

-   Source: new

-   Impact:\
    Version 1: Significant: Entire documents must be scanned for changes
    in natural language and programmatically identified.\
    Version 2: Not significant over time. This is something where tools
    can and will be built that will do much or all of this
    automatically.

-   External Reference: Harmonized with [[WCAG 2.0-3.1.2 Language of
    Parts (Level AA)]{.underline}](http://www.w3.org/TR/WCAG20/#meaning)

-   Testability: Inspection

-   Disabilities: Blindness

#### 3-I: Pausing {#i-pausing .unnumbered}

A mechanism must be provided to pause moving, [blinking]{.smallcaps}, or
scrolling information that lasts for more than three seconds unless it
is part of an activity where the moving, [blinking]{.smallcaps}, or
scrolling is essential.

A mechanism must be provided to pause auto-updating information, or
allow the user to control the frequency of the update, unless it is part
of an activity where auto-updating is essential.

A mechanism must be provided to either pause, stop, or hide moving or
[blinking]{.smallcaps} [content]{.smallcaps} that is pure
[decoration]{.smallcaps}.

Rationale

Harmonization with WCAG 2.0. Needed for people with attention deficit
disorders and those using screen readers. Auto updating is not well
understood by many people and this would clarify it. It is beneficial to
anyone who has trouble reading quickly and would like to pause content
in order to have more time to read it. It is also beneficial for low
vision users who depend on screen magnifiers, which tend to loose focus
when auto-updating occurs.

Additional Information

-   Text from Web and Software

-   Source: {508}1194.21(h)

-   Impact:\
    Version 1: Significant: User agents provide support for this on some
    Web technologies. But for other Web technologies and for software,
    the application developer must provide this support.\
    Version 2: Not Significant once techniques are known (and by the
    time this is in effect) it should not be hard to do this as a
    routine step and will be appreciated by many mainstream as well.

-   External Reference: Harmonized with [[WCAG 2.0-2.2.2 Pausing (Level
    AA)]{.underline}](http://www.w3.org/TR/WCAG20/#time-limits)

-   Testability: Inspection

-   Disabilities: Blindness, Low vision, Cognitive/language/learning

#### 3-J: Flashing (Content and User Interfaces) {#j-flashing-content-and-user-interfaces .unnumbered}

[Content]{.smallcaps} or user interfaces must not contain anything that
[flashes]{.smallcaps} more than 3 times in any one second period or the
[flashing]{.smallcaps} must be below the [general flash and red flash
thresholds for content and user interfaces]{.smallcaps}.

Rationale

The current provision is too restrictive in that it prohibits flashing
within a certain range with no consideration for the size of the
flashing area. Very small areas of flashing do not cause seizures even
if the flashing falls within the specified range. The reworded provision
is harmonized with WCAG 2.0 and based on research by experts in this
field.

Additional Information

-   Text from Web and Software

-   Source: {508}1194.21(k) 1194.22(j) 1194.25(i), and {255}1193.43(f)

-   Impact: None: Currently 508 doesn\'t allow any flashing at all
    within the range of 2 to 55 Hz. This provision is less strict as it
    only applies to flashing that occupies a large area of the user\'s
    field of vision.

-   External Reference: Harmonized with [[WCAG 2.0-2.3.1 Three Flashes
    or Below Threshold (Level
    A)]{.underline}](http://www.w3.org/TR/WCAG20/#seizure)

-   Testability: Inspection (under 3 times per second) or Formal Test
    Method (using General or Red Flash Thresholds)

-   Disabilities: Photosensitive seizure disorder

#### 3-K: Consistent Identification {#k-consistent-identification .unnumbered}

Components from a single source that have the same functionality within
a product must be identified consistently.

Rationale

Helps people with cognitive disabilities. Supports use of assistive
technology.

Additional Information

-   Text from Web and Software

-   Source: {508}1194.21(e)

-   Impact:\
    Version 1: Significant: Requires manual assessment and correction.
    Cost to remediate existing applications could be very high.
    Subjectivity of the testing could also increase expense.\
    Version 2: Minimal or no impact for new material: It doesn't require
    additional work -- just using a consistent label when you label in
    the first place. Good human factors.

-   External Reference: Harmonized with [[WCAG 2.0-3.2.4 Consistent
    Identification (Level
    AA)]{.underline}](http://www.w3.org/TR/WCAG20/#consistent-behavior)

-   Testability: Inspection

-   Disabilities: Blindness, Cognitive/language/learning

#### 3-L: Audio Turnoff {#l-audio-turnoff .unnumbered}

When any audio plays automatically for more than 3 seconds, there must
be a mechanism to pause or stop the audio, or a mechanism to control
audio volume that can be set to be a different level from the system
volume level. This provision does not apply to emergency messages
regarding risk of personal injury or loss of property or data, or to
audio messages required by law.

Note 1: This provision may be met with a mechanism in a product, user
agent or platform.

Note 2: For web and software applications, if the total duration of the
audio does not exceed 3 seconds, including any repeats of the audio,
this provision does not apply.

Rationale

Audio that plays automatically interferes with screen readers. When web
browsers provide mechanisms to turn off audio in the content, the
content author does not have to provide a mechanism. Tuning off audio at
the system level is not sufficient as that turns off the screen reader
also.

Additional Information

-   Text from Web and Software

-   Source: {508}1194.25(e) - Second sentence

-   Impact: Minimal: No current Section 508 requirement but may not be a
    common occurrence.

-   External Reference: Harmonized with ISO 9241-171, HFES 200, WCAG
    2.0-1.4.2 Audio Control (Level A)

-   Testability: Inspection

-   Disabilities: Blindness, Cognitive/language/learning

#### 3-M: Reading Sequence {#m-reading-sequence .unnumbered}

When the sequence in which information is presented affects its meaning,
a reading sequence that conveys the intended meaning must be
[programmatically determinable]{.smallcaps}. The navigation sequence
must be consistent with the reading sequence.

Note 1: In order to achieve this provision, objects in data operated on
by the software that can be presented in 2 dimensions, would need to be
associated with sufficient information to identify a logical one
dimensional presentation of the same objects, that the software can
obtain as readily as it can obtain the 2 dimensional objects themselves.

Note 2: For products with closed functionality the visual and (linear)
audible presentation should match navigation

Additional Information

-   Text from Web and Software and Closed Products

-   Source: New and {508}1194.22(d)

-   Impact: Minimal for software. Significant for Web pages and other
    types of electronic content. Need tools to "linearize" content.
    Manual checking required.

-   External Reference: Harmonized with [[WCAG 2.0-1.3.2 Meaningful
    Sequence (Level
    A)]{.underline}](http://http:/www.w3.org/TR/WCAG20/#content-structure-separation)
    and [[2.4.3 Focus Order (Level
    A)]{.underline}](http://www.w3.org/TR/WCAG20/#navigation-mechanisms).
    Similar to recommendation in ISO 9241-171

-   Testability: Inspection

-   Disabilities: Blindness, Cognitive/language/learning

#### 3-N: Link Purpose {#n-link-purpose .unnumbered}

On Web pages, it must be possible to determine the purpose of each link
from the link [text]{.smallcaps} or the link [text]{.smallcaps} together
with its [programmatically determinable]{.smallcaps} link context.

Note: In order to meet this provision, links encoded in data operated on
by the software would need to be associated with link text that the
software can obtain as readily as it can obtain the link itself.

Rationale

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.

Additional Information

-   Text from Web and Software

-   Source: New

-   Impact: Significant: Impacts any page that has vague or duplicated
    link text. Requires manual testing.

-   External Reference: Harmonized with [[WCAG 2.0-2.4.4 Link Purpose
    (In Context) (Level
    A)]{.underline}](http://www.w3.org/TR/WCAG20/#navigation-mechanisms)

-   Testability: Expert evaluation

-   Disabilities: Blindness, Cognitive/language/learning

#### 3-O: Information and Relationships {#o-information-and-relationships .unnumbered}

Information and relationships conveyed through presentation of
electronic documents must be either [programmatically
determinable]{.smallcaps} or available in [text]{.smallcaps}, and
notification of changes to these must be available to user agents,
including assistive technologies. For example:

1\. Row and column headers are identified for data tables.

-   Note: In order to achieve this provision, table objects in data
    operated on by the software would need to be associated with
    sufficient information to identify any row and column headers for
    the table, that the software can obtain as readily as it can obtain
    the table itself.

2\. In data tables that have two or more logical levels of row or column
headers, data cells are associated with header cells.

-   Note: In order to achieve this provision, cells in table objects
    with multiple logical levels of headers in data operated on by the
    software would need to be associated with sufficient information to
    identify any row and column headers for the table cell, that the
    software can obtain as readily as it can obtain the table cell
    itself.

3\. Section headings are identified.

4\. Form element [labels]{.smallcaps} are associated with form fields.

Rationale

The existing Section 508 provisions on table headers are technology
specific to HTML. This more general provision is more applicable to
electronic content in other technologies.

Additional Information

-   Text from Web and Software

-   Source: {508}1194.22(g), (h), (i), & (n), .21(l)

-   Impact: Significant: Currently Section 508 only requires markup for
    tables. This provision requires that apparent section headings,
    lists, etc. be coded as such. Also extends to all types of
    electronic documents, not just Web pages. Significant positive
    impact to end users and agencies. AT-E&IT interoperability will be
    improved and less customization should be required.

-   External Reference: Harmonized with [[WCAG 2.0-1.3.1 Info and
    Relationships(Level
    A)]{.underline}](http://www.w3.org/TR/WCAG20/#content-structure-separation)

-   Testability: Inspection

-   Disabilities: Blindness, Cognitive/language/learning

#### 3-P: User Interface Components (no consensus) {#p-user-interface-components-no-consensus .unnumbered}

*Work on this provision was not complete. Please see the drafts and
other discussion material in Section 7*

#### 3-Q: Disruption of Access Features {#q-disruption-of-access-features .unnumbered}

Applications must not, except by specific user request, disrupt the
features of the platform that are defined, in the documentation intended
for application developers, as having an accessibility usage.

Rationale

This version limits the scope to accessibility features defined by the
platform, rather than the broader \"other products\" in previous
versions

Additional Information

-   Text from Web and Software

-   Source: {508}1194.21(b)

-   Impact: None: Functionally equivalent to the current 508 provision
    but clarified for testability. If a suggestion to reintroduce
    \"assistive technology\" is accepted, there will be significant
    additional cost.

-   Testability: Expert evaluation

-   Disabilities: All

#### 3-R: Timing {#r-timing .unnumbered}

For each time limit that is set by the product, at least one of the
following must happen:

1\. Turn off: the user is allowed to turn off the time limit before
encountering it; or

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

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

There are three exceptions:

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

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

3\. 20 Hour Exception: the time limit is longer than 20 hours.

Additional Information

-   Text from Web and Software

-   Source: New (incorporates {508}1194.22(p), {508}1194.23(d),
    {508}1194.25(b), {255}1193.41(g)

-   Impact: None for Web sites. Minimal for software. Currently 508 only
    allows one strategy for dealing with timeouts on Web sites. Any
    current 508 compliant Web site will continue to comply with this
    provision. New requirement for software. Large positive impact to
    end users.

-   External Reference: Harmonized with [[WCAG 2.0-2.2.1 Timing
    Adjustable (Level
    A)]{.underline}](http://www.w3.org/TR/WCAG20/#time-limits) and ISO
    9241-171

-   Testability: Inspection

-   Disabilities: Blindness, Dexterity, Cognitive/language/learning

#### 3-S: Keyboard Operation {#s-keyboard-operation .unnumbered}

Where products have a [keyboard]{.smallcaps} or a [keyboard
interface]{.smallcaps}, or run on a device that has a
[keyboard]{.smallcaps} or [keyboard interface]{.smallcaps}, all
functionality of the product operable through the electronic user
interface must be operable through the [keyboard]{.smallcaps}, or a
[keyboard interface]{.smallcaps}. Specific timing for individual
keystrokes must not be required. This provision does not apply where the
underlying function requires input that depends on the full path of the
user\'s movement, not just the endpoints.

Note 1: This does not forbid and should not discourage providing mouse
input or other input methods, such as gestures, in addition to keyboard
operation.

Note 2: The 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 3: Keyboard interface can be either a hardware keyboard interface,
a wireless interface or a software keyboard interface where AT can
generate keystrokes that would be seen by software.

Note 4: For platform software, this includes the ability to move the
keyboard focus into and out of applications.

Rationale

In the current Section 508 wording, the phrase \"textually discernible\"
is confusing and often misinterpreted to mean the provision only applies
to text documents when it should be applied more broadly. The new
wording is harmonized with WCAG 2.0.

Additional Information

-   Text from Web and Software

-   Source: {508}1194.21(a)

-   Impact: None for software. Minimal for Web pages. Functionally
    equivalent to the current Section 508 software keyboard requirement.
    New requirement for Web pages. In many cases, keyboard operation of
    Web pages is provided by the user agent. Rich Internet Applications
    must ensure keyboard operation though.

-   External Reference: Harmonized with [[WCAG 2.0-2.1.1 Keyboard (Level
    A)]{.underline}](http://www.w3.org/TR/WCAG20/#keyboard-operation)
    and ISO 9241-171

-   Testability: Inspection

-   Disabilities: Blindness, Dexterity

#### 3-SS: Visual Indication of Keyboard Shortcuts (no consensus) {#ss-visual-indication-of-keyboard-shortcuts-no-consensus .unnumbered}

*Work on this provision was not complete. Please see the drafts and
other discussion material in Section 7*

#### 3-T: Focus Indicator {#t-focus-indicator .unnumbered}

Any [keyboard]{.smallcaps} operable user interface must support a mode
of operation where the indication of [keyboard]{.smallcaps} focus has a
high degree of visibility.

Note 1: The presence of a highly visible text insertion point is
sufficient for a text area.

Note 2: A focus cursor that is visually locatable at 3.5 times the
typical viewing distance without moving the cursor by people who have
unimpaired vision and are familiar with what the focus cursor looks like
is sufficient. For example, when software is displayed on a 38 cm (15
inch) diagonal screen at 1024 x 768 pixels resolution, a focus cursor
that is visually locatable at 2.5 meters without moving the cursor by
people who are familiar with what the cursor looks like and have
unimpaired vision is sufficient.

Note 3: This can be provided by the interface itself or by the interface
in combination with focus services provided by the platform.

Rationale

In the current Section 508 provision, the term \"well-defined\" is not
testable. The new wording clarifies that a high degree of visibility is
required and provides notes that clarify how a high degree of visibility
can be achieved.

Additional Information

-   Text from Web and Software

-   Source: {508}1194.21(c)

-   Impact:\
    Version 1: Significant: \"Well-defined\" focus cursor is currently
    required by 508. New provision provides testable measurement for
    \"highly visual\". Significant work for some desktop platforms,
    applications, and for Web 2.0 style applications.\
    Version 2: Impact: None. This is simply a clarification of what
    \"well defined\' was originally intended to mean.

-   External Reference: Harmonized with [[WCAG 2.0-2.4.7 Focus Visible
    (Level
    AA)]{.underline}](http://www.w3.org/TR/WCAG20/#navigation-mechanisms)
    and ISO 9241-171

-   Testability: Inspection

-   Disabilities: Low Vision, Dexterity

#### 3-U: AT Interoperability (partial consensus) {#u-at-interoperability-partial-consensus .unnumbered}

*Work on this provision was not complete. Please see the drafts and
other discussion material in Section 7.*

#### 3-V: Accessibility Services {#v-accessibility-services .unnumbered}

[Platform software]{.smallcaps} must provide access to a set of services
that enable applications running on the platform to interact with
[assistive technology]{.smallcaps} sufficient to enable compliance with
the \"AT interoperability\" and \"User Interface Components\"
provisions. Software toolkits, and applications that are also platforms,
must support the 3-U: AT Interoperability and 3-P: User Interface
Components provisions by either making the underlying [platform
accessibility services]{.smallcaps} available to their client software,
OR using [other services to cooperate with assistive
technologies]{.smallcaps} on the underlying platform.

Rationale

Needed to improve E&IT-AT interoperability.

Additional Information

-   Text from Web and Software

-   Source: New

-   Impact: None for current desktop operating system platforms.
    Significant for applications that are also platforms and for
    non-desktop platforms. All desktop operating system platforms meet
    the requirement. Not all applications that are also platforms and
    non-desktop platforms meet the requirement.

-   External Reference: Harmonized with 9241-171. Related to [[WCAG
    2.0-4.1.2 Name, Role, Value (Level
    A)]{.underline}](http://www.w3.org/TR/WCAG20/#ensure-compat)

-   Testability:

-   Disabilities: All

#### 3-VV: Assistive Technology (no consensus) {#vv-assistive-technology-no-consensus .unnumbered}

*Work on this provision was not complete. Please see the drafts and
other discussion material in Section 7.*

#### 3-W: Multiple Ways {#w-multiple-ways .unnumbered}

There must be more than one way available to locate
[content]{.smallcaps} within a set of Web pages where
[content]{.smallcaps} is not the result of, or a step in, a process. For
example, providing a site map, index, table of contents, or search would
be sufficient

Rationale

WCAG 1.0 included a requirement to "Provide information about the
general layout of a site (e.g., a site map or table of contents)." This
is a prescriptive solution. This provision, harmonized with WCAG 2.0,
instead describes the function needed by the user and allows developers
to determine the most appropriate means to achieve the result.

Additional Information

-   Text from Web and Software

-   Source: New

-   External Reference: Harmonized with [[WCAG 2.0-2.4.5 Multiple Ways
    (Level
    AA)]{.underline}](http://http:/www.w3.org/TR/WCAG20/#ensure-compat)

-   Testability: Inspection

-   Disabilities: Blindness, Cognitive/language/learning

#### 3-X: Labels or Instructions {#x-labels-or-instructions .unnumbered}

[Labels]{.smallcaps} or instructions must be provided when
[content]{.smallcaps} requires user input.

Rationale

Harmonization with WCAG 2.0. Supports people with cognitive, language,
and learning disabilities.

Additional Information

-   Text from Web and Software

-   Source: New

-   External Reference: Harmonized with [[WCAG 2.0-3.3.2 Labels or
    Instructions(Level
    A)]{.underline}](http://www.w3.org/TR/WCAG20/#minimize-error)

-   Testability: Inspection

-   Disabilities: Blindness, Cognitive/language/learning

#### 3-Y: On Focus {#y-on-focus .unnumbered}

When any component in [content]{.smallcaps} or electronic documents
receives focus through navigation by [keyboard]{.smallcaps} or other
keypads, it must not initiate a change of context.

Rationale

Harmonization with WCAG 2.0. Supports people with cognitive, language,
and learning disabilities.

Additional Information

-   Text from Web and Software

-   Source: New

-   External Reference: Harmonized with [[WCAG 2.0-3.2.1 On Focus (Level
    A)]{.underline}](http://www.w3.org/TR/WCAG20/#consistent-behavior)

-   Testability: Inspection

-   Disabilities: Blindness, Cognitive/language/learning

#### 3-Z: On Input {#z-on-input .unnumbered}

Changing the setting of any user interface component in web pages must
not automatically cause a change of context unless the user has been
advised of the behavior before using the component.

Rationale

Harmonization with WCAG 2.0. Supports people with cognitive, language,
and learning disabilities.

Additional Information

-   Text from Web and Software

-   Source: New

-   External Reference: Harmonized with [[WCAG 2.0-3.2.2 On Input (Level
    A)]{.underline}](http://www.w3.org/TR/WCAG20/#consistent-behavior)

-   Testability: Inspection

-   Disabilities: Blindness, Cognitive/language/learning

#### 3-AA: Error Identification {#aa-error-identification .unnumbered}

If an input error is automatically detected in [content]{.smallcaps} or
electronic documents, the item that is in error must be identified and
described to the user in [text]{.smallcaps}.

Rationale

Harmonization with WCAG 2.0. Supports people with cognitive, language,
and learning disabilities.

Additional Information

-   Text from Web and Software

-   Source: New

-   External Reference: Harmonized with [[WCAG 2.0-3.3.1 Error
    Identification (Level
    A)]{.underline}](http://www.w3.org/TR/WCAG20/#minimize-error)

-   Testability: Inspection

-   Disabilities: Blindness, Cognitive/language/learning

#### 3-BB: Headings and Labels {#bb-headings-and-labels .unnumbered}

Headings and [labels]{.smallcaps} must describe the topic or purpose.

Note: Labels and headings do not need to be lengthy. A word or even a
single character may suffice if it provides an appropriate cue to
finding and navigating content.

Rationale

Harmonization with WCAG 2.0. Supports people with cognitive, language,
and learning disabilities.

Additional Information

-   Text from Web and Software

-   Source: New

-   External Reference: Harmonized with [[WCAG 2.0-2.4.6 Labels
    Descriptive (Level
    AA)]{.underline}](http://www.w3.org/TR/WCAG20/#navigation-mechanisms)

-   Testability: Inspection

-   Disabilities: Blindness, Cognitive/language/learning

### 4. Additional Requirements for Audio-Visual Players or Displays {#additional-requirements-for-audio-visual-players-or-displays-1 .unnumbered}

#### 4-A: Caption Processing {#a-caption-processing .unnumbered}

Analog television, digital television and tuners, computer equipment,
and other products must provide support for closed and open
[captions]{.smallcaps}:

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

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

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

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

Functional equivalence requires synchronized text displayed on-screen
that reflects the audio of a program. It may also include functionality
to allow user choices for background and foreground color, adjustment or
contrast, and text size for [captions]{.smallcaps} as allowed by the
[platform software]{.smallcaps} or hardware displaying the media.

Rationale

Align the provisions 4-A - Caption Processing and 4-B - Supplemental
Audio Process

Additional Information

-   Text from A/V

-   Source: {508}1194.24(a)

-   External Reference: CEA 608, CEA 708

-   Disabilities: Deafness, Hard of hearing, Cognitive/language/learning

#### 4-B: Supplemental Audio Process {#b-supplemental-audio-process .unnumbered}

Television tuners, including tuner cards for use in computers, must
support [video description]{.smallcaps} process:

-   Analog-signal tuners must be equipped with Secondary Audio Program
    (SAP) process circuitry as defined by the Multichannel Television
    Sound standard developed by the Broadcast Television Systems
    Committee (BTSC) in 1984.

-   Digital television tuners must support processing of [video
    description]{.smallcaps} when encoded as a Visually Impaired (VI)
    associated audio service that is provided as a complete program mix
    containing [video description]{.smallcaps} according to the A/53
    standard developed by the Advanced Television Systems Committee
    (ATSC).

Rationale

Align the 4-A - Caption Process provisions with the 4-B - Supplemental
Audio Process provisions.

Additional Information

-   Text from A/V

-   Source: {508}1194.24(b)

-   Testability: Inspection

-   Disabilities: Blindness, Low vision, Cognitive/language/learning

#### 4-C: Access to Caption and Video Controls {#c-access-to-caption-and-video-controls .unnumbered}

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

> For captioning:

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

2.  Caption controls on the first [menu]{.smallcaps} that appear when
    on-screen [menus]{.smallcaps} are displayed

> For [video description]{.smallcaps}: A tactile button to turn on
> [video description]{.smallcaps}.

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

Rationale

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

-   For products that are covered under 4-A.1 and 4-B, the user controls
    needed to access closed captioning and [video
    description]{.smallcaps} must be comparable in prominence to the
    play controls or channel selector.

-   For laptops, a keyboard equivalent would be acceptable.

Additional Information

-   Text from A/V

-   Source: new

-   Testability: Inspection

-   Disabilities: Deafness, Hard of hearing, Blindness, Low Vision,
    Dexterity, Mobility, Cognitive/language/learning

### 5. Requirements for Audio and/or Video Content {#requirements-for-audio-andor-video-content-1 .unnumbered}

#### 5-A: Captions and Transcripts  {#a-captions-and-transcripts .unnumbered}

Materials containing video and/or audio, regardless of format, that
contain speech or other audio information necessary for the
comprehension of the [content]{.smallcaps}, must comply with the
following:

1\. Materials containing prerecorded audio information, and no original
video or other additional time-based [content]{.smallcaps} must provide
a separate transcript of the audio information.

2\. Materials containing prerecorded video with concurrent audio
information must provide synchronized [captions]{.smallcaps}.

3\. Materials containing real-time audio, with or without video, must
provide synchronized real-time [captions]{.smallcaps}.

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

Advisory Note to the Access Board

The final version of the technical standards for captioning and
transcripts (5-A) and for video description (5-B) were revised to remove
the word \"all\" from \"all materials\" resulting in ambiguity in the
scope of materials which must conform. Without the term \"all\", the
scope of application is at some level less than 100% of materials, but
no direction is provided regarding what level less than 100% is
acceptable for which materials. The Access Board will need to address
this issue.

Additional Information

-   Text from A/V

-   Source: {508}1194.24(c)

-   External Reference: [[WCAG 2.0-1.2.1 Captions (Prerecorded) (Level
    A)]{.underline}](http://www.w3.org/TR/WCAG20/#meaning)

-   Testability: Inspection

-   Disabilities: Deafness, Hard of hearing, Cognitive/language/learning

#### 5-B: Video Description {#b-video-description .unnumbered}

Materials containing video and/or audio, regardless of format, that
contain visual information necessary for the comprehension of the
[content]{.smallcaps}, must comply with the following:

1\. Materials containing prerecorded video and no original audio or
other additional time-based [content]{.smallcaps} must provide either a
separate [tex]{.smallcaps}t description of the video or provide an
additional audio track to convey the informational [content]{.smallcaps}
of the video.

2\. When the visual informational [content]{.smallcaps} is not conveyed
through other means, materials containing prerecorded video with
concurrent audio must provide synchronized [video
descriptions]{.smallcaps}, or when space is not available in the main
program audio for synchronized [video descriptions]{.smallcaps}, a
separate [text]{.smallcaps} description of the video
[content]{.smallcaps} must be provided.

3\. Materials containing live video must provide synchronized [video
descriptions]{.smallcaps} in real time to convey any informational
[content]{.smallcaps} of the video that is not conveyed through other
means.

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

Advisory Note to the Access Board

The final version of the technical standards for captioning and
transcripts (5-A) and for video description (5-B) were revised to remove
the word \"all\" from \"all materials\" resulting in ambiguity in the
scope of materials which must conform. Without the term \"all\", the
scope of application is at some level less than 100% of materials, but
no direction is provided regarding what level less than 100% is
acceptable for which materials. The Access Board will need to address
this issue.

Additional Information

-   Text from A/V

-   Source: {508}1194.24(d)

-   External Reference: [[WCAG 2.0-1.2.2 Audio Description or Full Text
    Alternative (Level
    A)]{.underline}](http://www.w3.org/TR/WCAG20/#meaning)

-   Testability: Inspection; possibly expert evaluation regarding
    \"informational content\"

-   Disabilities: Blindness, Low vision, Cognitive/language/learning

#### 5-C: Interactive Elements {#c-interactive-elements .unnumbered}

[Synchronized media]{.smallcaps} containing [interactive
elements]{.smallcaps}, such as options for selection and access to
segments of the [content]{.smallcaps}, must include a mode of operation
for selection consistent with applicable Section 508 provisions.

Additional Information

-   Text from A/V

-   Source: {508}1194.24(d) & .22(b)

-   External Reference: Several WCAG 2.0 guidelines relate

-   Testability: Inspection; possibly expert evaluation regarding
    \"interactive elements\" and \"content\"

-   Disabilities: All

### 6. Additional Requirements for Real-Time Voice Conversation Functionality {#additional-requirements-for-real-time-voice-conversation-functionality-1 .unnumbered}

#### 6-A: Real-Time Text Reliability and Interoperability  {#a-real-time-text-reliability-and-interoperability .unnumbered}

If hardware or software provides real-time voice conversation
functionality it must provide at least one means of [real-time
text]{.smallcaps} communication where the following reliability
requirements are met:

1\. Products must use a [real-time text]{.smallcaps} (RTT) system that
meets the following requirements:

> a\. RTT format must be a standard [real-time text]{.smallcaps} format
> for the voice platform that is supported by all
> [terminal]{.smallcaps}, router, gateway and other products on that
> platform;
>
> b\. RTT format must transmit characters with less than 1 second delay
> from entry;
>
> c\. RTT system must transmit [text]{.smallcaps} with less than 1%
> Total Character Error Rate at the peak network traffic specified for
> intelligible speech transmission ([text]{.smallcaps} must work on the
> network as long as speech does);
>
> d\. The RTT system, together with the audio system, must support
> speech and [text]{.smallcaps} in both directions in the same call
> session (and support speech and [text]{.smallcaps} simultaneously in
> both directions in the same call session if IP based)
>
> e\. RTT system must not utilize audio tones for transmission of
> [real-time text]{.smallcaps} over IP. Note: this is subject to a
> waiver of the [TTY]{.smallcaps} support requirement from the FCC for
> systems that implement IP based RTT. Also subject to consumer
> acceptance of prefixes or phone numbers to direct [TTY]{.smallcaps}
> traffic to gateways capable of handling [TTY]{.smallcaps} translation.

2\. Where products or systems interoperate outside of their closed
systems, they must:

> a\. If product interfaces with PSTN, it must use TIA 825A Baudot where
> it interfaces to the PSTN.
>
> b\. If product interfaces with other VoIP products or systems (outside
> of a self-contained product-system) using SIP it must support
> transmission of [text]{.smallcaps} as per XXX where it interfaces with
> other VoIP products or systems. Note: this is subject to a waiver of
> the [TTY]{.smallcaps} support requirement from the FCC for systems
> that implement IP based RTT. Also subject to consumer acceptance of
> prefixes or phone numbers to direct [TTY]{.smallcaps} traffic to
> gateways capable of handling [TTY]{.smallcaps} translation.
>
> c\. If product connects to other products or systems using a protocol
> other than SIP it must use the standard [real-time text]{.smallcaps}
> protocol that meets provision 1 above that has been established for
> that protocol.

Note 1: RFC-4103, TIA 1001, and MSRP (RFC4975) are being explored to
fill the role of XXX. The intention is that XXX will be replaced by one
interconnection format in all places it was used.

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

Note 3: A self-contained SIP system that 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 XXX where the system-product connects
to other systems or products.

Rationale:

This provision, along with 6-B, allows people with disabilities to
communicate using standard IP methods rather than continuing to support
TTY within IP networks and devices.

Additional Information

-   Text from Telecommunications

-   Source: {508\]1194.23(b), {255}1193.51(e)

-   Impact: Difficult to assess. Short term more expensive. Long term
    less expensive. This is a new technology so initially there are high
    costs to figure out and decided on common approaches.

-   Testability: Inspection and formal test methods

-   Disabilities: Deafness, Hard of Hearing, Speech

#### 6-B: Voice Terminal Hardware and Software {#b-voice-terminal-hardware-and-software .unnumbered}

[Terminal]{.smallcaps} hardware or software that is capable of providing
voice communications in real-time must comply with the following:

1\. Receive only: If hardware or software [terminal]{.smallcaps}
provides voice conversation over IP in any form, and has a user
interface with a multi-line display or a user interface that runs on
devices that have a multi-line display, then that [terminal]{.smallcaps}
must display any [real-time text]{.smallcaps} that is received if it is
received in the format for the voice and [real-time text]{.smallcaps}
system being used on the network on which it is installed.

2\. Send and Receive: If [terminal]{.smallcaps} hardware or software
provides voice conversation over IP in any form, and has
[text]{.smallcaps} generation capability, then the
[terminal]{.smallcaps} must allow users to send [real-time
text]{.smallcaps} in the format for the voice and [real-time
text]{.smallcaps} system being used on the network on which it is
installed.

3\. If IP [terminal]{.smallcaps} hardware or software does not provide
[real-time text]{.smallcaps} send and receive capability then the
[terminal]{.smallcaps} must support the addition of
[terminals]{.smallcaps} and [terminal]{.smallcaps} peripheral equipment
that support [real-time text]{.smallcaps} functionality in conjunction
with the voice call functionality, in the same location and with the
same permissions for use as their voice [terminal]{.smallcaps}. If the
[terminal]{.smallcaps} is in a public or shared area and not in an
individual\'s private work area then the connection must be possible
\[without requiring system-administrator intervention\]. Note: the
\"without system-administrator intervention\" is a serious concern due
to security issues, but removal would prevent people from connecting
devices outside of their home system. Additional work is needed to
address this issue.\]

4\. If [terminal]{.smallcaps} is analog or TDM-digital wired
[terminal]{.smallcaps} then it must support the connection of a
[TTY]{.smallcaps} via an RJ-11 jack in the same location and with the
same permissions for use as the telephone and it must be capable of
allowing simultaneous speech and [text]{.smallcaps} conversation without
interference or its microphone must be capable of being turned on and
off to allow the user to intermix speech with text use.

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

a\. provision of the RJ-11 jack on the telephone,

b\. the use of a Y-adapter that allows both the analog telephone and the
TTY to be plugged into the same line outlet,

c\. having built in capability to support an RJ11 module that can
provide a connection point for TTYs.

Note 2: The standard format for PSTN is TIA-825A. For SIP is it XXX. For
other voice transport protocols the format is to be determined by the
entity responsible for the voice transport protocol.

Rationale:

This provision, along with 6-A, allows people with disabilities to
communicate using standard IP methods rather than continuing to support
TTY within IP networks and devices.

Ad[v]{.underline}isory Note to the Access Board

The following open items still need to be addressed

-   Need to be sure 255 is addressed for #3.

-   Need to determine the right word to use \"system\" vs. \"protocol\"
    in Note 2.

-   Need to resolve Bluetooth question.

Additional Information

-   Text from Telecommunications

-   Source: {508}1194.23(a), {255}1193.51(d)

-   Impact: Difficult to assess. Short term more expensive. Long term
    less expensive. This is a new technology so initially there are high
    costs to figure out and decided on common approaches.

-   Testability: Inspection

-   Disabilities: Deafness, Hard of Hearing, Speech

#### 6-C: IVR, Auto-Attendant and Messaging {#c-ivr-auto-attendant-and-messaging .unnumbered}

Voice mail, messaging, auto-attendant, and interactive voice response
[telecommunications systems]{.smallcaps} 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]{.smallcaps}.

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]{.smallcaps} or customer) without any background sounds that
would reduce intelligibility.

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

Additional Information

-   Text from Telecommunications

-   Source: {508}1194.23(c)

-   Testability: Inspection (#1,3,4) and Formal test method (#2)

-   Disabilities: Deafness, Hard of hearing, Cognitive/language/learning

#### 6-D: Caller and Status Information (no consensus)  {#d-caller-and-status-information-no-consensus .unnumbered}

*Work on this provision was not complete. Please see the drafts and
other discussion material in Section 7.*

#### 6-E: Video Support {#e-video-support .unnumbered}

Communication products or systems that are used to transmit video
communications in real-time between and among individuals must:

1\. Support interoperability to permit communication between and among
users of [terminals]{.smallcaps} from different
[manufacturer]{.smallcaps}s and service providers;

2\. Have a built-in non auditory alerting system or provide
compatibility with an external non-auditory alerting system that is
capable of alerting users of incoming calls; and

3\. At a minimum, support 15 frames per second, QCIF resolution, and a
latency of less than 400 milliseconds, in order to provide sufficient
quality and fluency that will support real time video communication in
which one or more parties are using sign language or is talking in the
picture.

Note 1: Twenty frames per second or better is recommended to facilitate
lip reading and fingerspelling in the video communications provided
under this section.

Note 2: Explanatory information concerning sign language and lip-reading
real-time conversation using low bit rate video communication can be
found in ITU-T H-Series Supplement 1.

Note 3: Non-auditory alerting for incoming video communications can be
achieved via flashes, vibrations and sound; the preferred method will
depend on the needs of the individual using the product.

Additional Information

-   Text from Telecommunications

-   Source: new

-   Testability: Formal test methods and inspection; will depend on how
    \"X format\" is defined.\"

-   Disabilities: Deafness

#### 6-F: Audio Clarity for Interconnected VoIP {#f-audio-clarity-for-interconnected-voip .unnumbered}

Interconnected VoIP telephones and interconnected VoIP
telephone-emulation software must be able to transmit and receive speech
that is digitally encoded in the manner specified by International
Telecommunication Union (ITU) Standards G.711.For closed systems, other
standards that provide equivalent acoustic performance may be used if
conversion to G.711 at the borders of the closed system is supported.

Note 1: It is suggested that G.722 or equivalent also be provided for
wideband interconnected VoIP audio clarity.

Additional Information

-   Text from Committee

-   Source: new

-   External Reference: ITU G.711

-   Testability: Formal test methods and inspection

-   Disabilities: Hard of hearing

#### 6-G: External Alerting Devices {#g-external-alerting-devices .unnumbered}

A mechanism must be provided where interconnected VoIP phone systems,
interconnected VoIP [Terminal]{.smallcaps} Adapters or software for
interconnected VoIP phone systems can trigger an external alerting
system or accessory, that is capable of alerting users to incoming
calls, in modes perceivable to users with disabilities (e.g., visual,
tactile, audible).

Note: With regard to accessibility configuration (see 2-C -
Accessibility Configuration) it is important that it not be difficult
for a user to get an auxiliary ringer associated with a phone number.

Rationale

This requirement addresses the need to connect an external 'ringer'
(vibrating, flashing, extra loud ringer etc.) to home or office phone
system to alert persons with hearing (and sometimes vision) disabilities
to an incoming call or communication session. Individual phones are
currently required to provide a non-audible alerts to comply the
functional performance criteria (e.g., "D -- without hearing"), but
phone systems may need to provide a way to be compatible with auxiliary
devices with special functions or features necessary to meet specific
individual needs (wake them from sleep, alert them if they turn off
hearing aids to concentrate, alert them when in side room, etc). This
requirement could be met by providing proprietary adapters by the system
[manufacturer]{.smallcaps} to existing alert devices or by utilizing
signals sent by the service provider to IP-enabled alert devices or
adapter that generates a PSTN ring signal or a simple "closed contacts"
shorting signal (making all of the current assistive technology
ring/alert systems on the market work with it). Products could of course
also provide the PSTN ring signal or 'closed contacts" directly. The
primary goal though is to address the needs of these individuals for
specialize alerting devices with maximum flexibility and minimum impact
on the phones themselves -- as was true in PSTN.

Additional Information

-   Text from Committee

-   Source: new

-   Testability: Formal test methods and inspection

-   Disabilities: Deafness

### 7. Additional Requirements for Authoring Tools {#additional-requirements-for-authoring-tools-1 .unnumbered}

For the purposes of Section 255, the provisions of this section are not
requirements but instead represent best practices for [authoring
tools]{.smallcaps}. To the extent that [authoring tools]{.smallcaps} are
used to create and publish [content]{.smallcaps} for use with a covered
service, the incorporation of these provisions will improve the
accessibility of the [content]{.smallcaps} produced. For instance, where
an IVR product or service includes software for the creation of
[content]{.smallcaps} used to populate [menu]{.smallcaps} choices, the
requirements of the [authoring tools]{.smallcaps} section represent best
practices to ensure that the [content]{.smallcaps} is accessible to and
[usable]{.smallcaps} by people with disabilities.

#### 7-A: Accessible Output {#a-accessible-output .unnumbered}

For each [accessible content format]{.smallcaps} supported, when
available, [authoring tools]{.smallcaps} must allow the author to
produce [content]{.smallcaps}, including [content]{.smallcaps} derived
from programmatic sources, which meets applicable Section 508
provisions.

Additional Information

-   Text from Web and Software

-   Source: new

-   External Reference: ATAG, ISO 9241-171

-   Testability: Inspection

-   Disabilities: All

#### 7-B: Preserve Accessibility Information {#b-preserve-accessibility-information .unnumbered}

For each [accessible content format]{.smallcaps} supported, [authoring
tools]{.smallcaps} must preserve accessibility information necessary to
meet applicable Section 508 provisions, unless the user explicitly
indicates otherwise.

Note: The phrase \"unless the user explicitly indicates otherwise\" is
necessary so that the author has the ability to override accessibility
information that may be incomplete or inadequate.

Additional Information

-   Text from Web and Software

-   Source: new

-   External Reference: ATAG, ISO 9241.71

-   Testability: Inspection; possibly some expert evaluation

-   Disabilities: All

#### 7-C: Prompts (no consensus) {#c-prompts-no-consensus .unnumbered}

*Work on this provision was not complete. Please see the drafts and
other discussion material in Section 7.*

#### 7-D: Accessible Templates (no consensus) {#d-accessible-templates-no-consensus .unnumbered}

*Work on this provision was not complete. Please see the drafts and
other discussion material in Section 7.*

## Subpart D

### 1. Information, Documentation and Support {#information-documentation-and-support-1 .unnumbered}

### 1.1 Product Documentation and Help {#product-documentation-and-help .unnumbered}

#### 1.1-A: Accessible Documentation and Features {#a-accessible-documentation-and-features .unnumbered}

Documentation for users on the installation, configuration, or use of
the product including the description, installation, and use of
accessibility and compatibility features, and all other documentation
provided must conform to the relevant accessibility provisions in 1194
Subparts B and C, and must be available to users with disabilities at no
additional charge. Features included in the product specifically to meet
accessibility requirements must be documented. This documentation
includes, but is not limited to, reports, system documentation, user
help, installation guides for end-user installable devices covered by
Section 255, and user training or technical support materials.

Rationale

This draft combines two provisions for a clearer requirement and adds a
requirement to document the accessibility features of a product, and
incorporates the requirement that documentation supporting services and
consulting engagements be accessible in addition to the requirements for
user documentation accessibility.

Advisory Note to the Access Board

There is an overlap between general features and features that support
accessibility. Guidance on how to choose what features to document
includes:

-   Anything that changes user preferences, keyboard commands, special
    accessibility features that the product supports (i.e., captioning),
    and features that allow users to adjust the product to their needs.

-   Any features that are used to meet this standard or to enhance
    accessibility

Documentation may also need to suggest how a platform should document
(for their application developers) how to support accessibility features
that the platform provides to users.

Additional Information

-   Text from Documentation and Technical Support

-   Source: {508}1194.41(a), {508}194.41(b), {255}1193.33(a)(1)and
    {255}1193.33(a)(2)

-   Impact: No Change

-   Testability: Tested according to the other provisions (ref. to
    \"provisions in 1194 Subparts B and C\")

-   Disabilities: All

#### 1.1-B: Keyboard Shortcuts (no consensus) {#b-keyboard-shortcuts-no-consensus .unnumbered}

*Work on this provision was not complete. Please see the drafts and
other discussion material in Section 7.*

### 1.2 Support and E&IT Related Services {#support-and-eit-related-services .unnumbered}

#### 1.2-A: Support Services {#a-support-services .unnumbered}

Help desk and technical support services must offer information on the
accessibility features of the product. These support services must
accommodate the communication needs of users with disabilities. For the
purposes of Section 255, such services must take into account [assistive
technology]{.smallcaps} commonly used with the product, and must be made
available at no additional charge.

Additional Information

-   Text from Documentation and Technical Support

-   Source: {508}1194.41(c) and {255}1193.33(a)(3)

-   Impact:

-   Testability: Expert evaluation

-   Disabilities: All

#### 1.2-B - Manufacturer Contact  {#b---manufacturer-contact .unnumbered}

Applying only to products under Section 255, [manufacturers]{.smallcaps}
must include in general product information the contact method for
obtaining the information required by this section.

Additional Information

-   Text from Telecommunications

-   Source: Section 255

-   Disabilities: All

#### 1.2-C - Training  {#c---training .unnumbered}

Applying only to products under Section 255, in developing or
incorporating existing training programs, [manufacturers]{.smallcaps}
shall consider the following topics:

1\. Accessibility requirements of individuals with disabilities;\
2. Means of communicating with individuals with disabilities;\
3. Commonly used adaptive technology with the
[manufacturer's]{.smallcaps} products;\
4. Designing for accessibility;\
5. Solutions for accessibility and compatibility.

Additional Information

-   Text from Telecommunications

-   Source: Section 255

-   Disabilities: All

### 2. Implementation, Operation, and Maintenance {#implementation-operation-and-maintenance-1 .unnumbered}

#### 2-A: Relay Services Accessibility  {#a-relay-services-accessibility .unnumbered}

*This provision is not relevant to the Section 255 guidelines, because
it creates obligations for federal agencies.*

In complying with this subpart, each [agency]{.smallcaps} must ensure
access to and use of all [telecommunications]{.smallcaps} 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.

Additional Information

-   Text from Telecommunications

-   Source: new

-   Testability: Inspection

-   Disabilities: Deafness, Speech

#### 2-B: Video Support {#b-video-support .unnumbered}

*This provision is not relevant to the Section 255 guidelines, because
it creates obligations for federal agencies.*

1\. Each [agency]{.smallcaps} must ensure the availability of
communication access via point to point real-time video communications
and video relay services for incoming and outgoing calls for individuals
who need such access. This includes the requirement to provide a
non-auditory means of alerting users of incoming calls.

2\. Where security concerns are present, this subpart remains in effect,
but may be achieved by measures that prevent an individual's video
communications from intermingling with packets of the general government
network, for example, through the installation of a separate line to an
isolated communications [terminal]{.smallcaps}.

Note: The requirement to permit video communications in real-time
includes the ability to send and receive video mail, much in the same
way that voice telephone users are able to send and receive voice mail.

Additional Information

-   Text from Telecommunications

-   Source: new

-   Testability: Inspection

-   Disabilities: Deafness

#### 2-C: Accessibility Configuration {#c-accessibility-configuration .unnumbered}

*This provision is not relevant to the Section 255 guidelines, because
it creates obligations for federal agencies.*

Each [agency]{.smallcaps} must activate accessibility features or
configure product and infrastructure settings so that people with
disabilities are able to activate and use accessibility features in the
products as they need them.

Note 1: Network or system-wide configurations or installation settings
are especially important in meeting this provision.

Note 2: For purposes of Section 255, \"products\" are the
[telecommunications equipment]{.smallcaps}, voicemail, and interactive
[menu]{.smallcaps} equipment, interconnected VoIP equipment, and CPE
covered by the FCC\'s rules implementing Section 255.

Note 3: This provision is not intended to prevent a product feature that
would allow the user to tie product functions together (for example
turning one on would turn another off) so long as turning on an
accessibility feature did not turn off other product functions by
default.

Note 4: For the purposes of this provision, the term
\"[usable]{.smallcaps}\" has meaning as defined in 1194.4 Definitions.

Additional Information

-   Text from Telecommunications

-   Source: new

-   Disabilities: All

#### 2-D: Accessible Content {#d-accessible-content .unnumbered}

*This provision is not relevant to the Section 255 guidelines, because
it creates obligations for federal agencies.*

[Agencies]{.smallcaps} must ensure that electronic [content]{.smallcaps}
used for official [agency]{.smallcaps} communications complies with the
applicable provisions in the Section 508 standard (in particular the
provisions in Subpart C, Section 3), regardless of the medium of
transmission or distribution. An exception to this provision may be made
when [content]{.smallcaps} is distributed only to a small group of known
recipients and accommodates their accessibility needs, or when
[content]{.smallcaps} is being stored for archival purposes only.

Note 1: Official [agency]{.smallcaps} communications include, but are
not limited to, [agency]{.smallcaps} websites, policies or procedures
for employees that are distributed via internal [agency]{.smallcaps}
e-mail, electronic newsletters, tutorials that are distributed on CDs
and other electronic media.

Note 2: When a request is made for archival material in an accessible
format, that content is then treated like any other current content
under this provision.

Rationale

This provision is a reminder that Section 508 covers all E&IT content.

Additional Information

-   Text from Web/Software

-   Source: new

-   Disabilities: All

## Advisory Notes

*These are recommendations to the Access Board for advisory notes, which
can be used to communicate best practices. They are not intended to be
full provisions.*

### Subpart A: Inherently Visual E&IT  {#subpart-a-inherently-visual-eit .unnumbered}

There are [E&IT]{.smallcaps} deliverables that do not lend themselves to
accessibility, nor do they lend themselves to equivalent facilitation
because the information they impart is intended to be analyzed using
motion, shape, color or other vision-dependent attribute, and/or because
they present an ever-changing stream of information. Examples include:

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

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

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

### Advisory Notes for User Interface and Electronic Content {#advisory-notes-for-user-interface-and-electronic-content .unnumbered}

The following are recommended best practices.

#### 1. Suppression of Unneeded Function  {#suppression-of-unneeded-function .unnumbered}

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  {#writing-guidelines .unnumbered}

Authors should follow best practices for creating [content]{.smallcaps}
that is accessible for people with disabilities. These guidelines
include:

1.  Organize the [content]{.smallcaps} 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.

-   External References: [[Plain Language Tools, Office of the Federal
    Register]{.underline}](http://www.archives.gov/federal-register/write/plain-language/)

#### 3. Interaction Guidelines  {#interaction-guidelines .unnumbered}

Applications should include user interactions 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 or cancel actions before final submission.

-   External References [[WCAG 2.0-3.3.4-Error Prevention (Legal,
    Financial,
    Data)]{.underline}](http://www.w3.org/TR/WCAG20/#minimize-error)\
    [[WCAG 2.0-3.3.6-Error Prevention
    (All)]{.underline}](http://www.w3.org/TR/WCAG20/#minimize-error)

#### 4. Parsing  {#parsing .unnumbered}

[Content]{.smallcaps} implemented using markup languages should have
elements with complete start and end tags, except as allowed by their
specifications, and are nested according to their specifications.

-   External references: [[WCAG 2.0-4.1.1 Parsing (Level
    A)]{.underline}](http://www.w3.org/TR/2007/WD-WCAG20-20071211/#ensure-compat)

#### 5. User Preferences (non-visual)  {#user-preferences-non-visual .unnumbered}

User interfaces that provide a mode of interaction other than visual
(such as vocal, aural, gustatory, olfactory, tactile) that can affect
human sensory functions, should either provide settings that allow the
user to stop and control those functions or a mode that utilizes the
platform user settings for control of those functions.

#### Recommendations for Additional Advisory Notes: {#recommendations-for-additional-advisory-notes .unnumbered}

Add an advisory note regarding the input from SSA on 3-AA regarding a
best practice for a method to navigate to the error should be provided.
This is also a reference to [[WCAG 2.0-3.3.3 Error suggestion (Level
AA)]{.underline}](http://www.w3.org/TR/2007/WD-WCAG20-20071211/#minimize-error)

Level A WCAG guidelines not included elsewhere:

-   [[3.4.2-Page
    Titles]{.underline}](http://www.w3.org/TR/WCAG20/#navigation-mechanisms)

-   [[2.4.3-Focus
    Order]{.underline}](http://www.w3.org/TR/WCAG20/#navigation-mechanisms)

-   [[2.1.2 No Keyboard
    Trap]{.underline}](http://www.w3.org/TR/WCAG20/#keyboard-operation)

-   [[2.4.1 Bypass
    Blocks]{.underline}](http://www.w3.org/TR/WCAG20/#navigation-mechanisms)

### Advisory Notes for Authoring Tools {#advisory-notes-for-authoring-tools .unnumbered}

Some best practices for authoring tools to help authors create
accessible content are:

#### 1. Assistance with Checking for Accessibility Problems  {#assistance-with-checking-for-accessibility-problems .unnumbered}

[Authoring tools]{.smallcaps} with a user interface should either
provide a mode which assists authors in checking for accessibility
problems, or be compatible with evaluation tools that provide that
function.

### Advisory Notes for Information, Documentation and Support {#advisory-notes-for-information-documentation-and-support .unnumbered}

Best practices for providing documentation to people with disabilities
include:

#### 1. Context-Sensitive Help {#context-sensitive-help .unnumbered}

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 {#text-descriptions .unnumbered}

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  {#user-interface-descriptions .unnumbered}

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

#### Recommendations for Additional Advisory Notes: {#recommendations-for-additional-advisory-notes-1 .unnumbered}

Proposal for a best practice entry for compatibility of assistive
technology with the product, so vendors can include information as to
which AT they work with, installation and configuration information.
Could be similar to Software Application Notes (SWANs) that printer
manufacturers to include for information about some applications.

### Advisory Notes for Support and E&IT Related Services {#advisory-notes-for-support-and-eit-related-services .unnumbered}

Best practices for providing support to people with disabilities
include:

#### 1. Remote Assistance {#remote-assistance .unnumbered}

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, to the extent that this
does not compromise the agency\'s network security policy.

# Provisions Considered but Not Achieving Consensus

These provisions were discussed by the Committee, but did not reach the
point of consensus. In some cases, the Committee agreed on the general
point of the text, but could not reach final wording. In others, there
was disagreement on whether it should be included as a provision at all.
Notes with each provision considered provides further explanation.

### Subpart B: Functional Performance Criteria E, I, and J {#subpart-b-functional-performance-criteria-e-i-and-j .unnumbered}

#### E -- With Limited Hearing (no consensus) {#e-with-limited-hearing-no-consensus-1 .unnumbered}

*There were three versions of this provision under discussion*

**Version 1:**

Where audio information is important for the use of a product, it must
provide at least one mode that allows user control of volume and/or
reduction of background noise. (*See note on functional performance
criteria and assistive technology.*)

**Version 2:**

Products must provide at least one mode that allows access to all
functionality of the product with limited hearing. (*See note on
functional performance criteria and assistive technology.*)

Version 3

Where audio information is required for the use of a product, the
product must provide at least one mode that allows user control of
volume and/or reduction of background noise. (*See note on functional
performance criteria and assistive technology.*)

Viewpoints from Committee Members

Trace One of the comments around the FPC was that they were untestable.
Indeed some of them were (just a few). Those have now all been made
testable and accepted except for this one. FPC E - With Limited Hearing
was one that was untestable since it said that you needed to provide
enhanced audio but it was not clear what that meant or how enhanced it
needed to be. Version 2 is similarly untestable. What does it mean to be
usable with limited hearing. Usable with NO hearing is clear and
testable. No is quantitative. But limit is wide open. Version 3 was
proposed based on the discussions of version 1. It gives very specific
means for addressing and is a proper parent of the technical provision.
If other wording can be found that is fine as long as it is testable
(e.g. a designer can tell when they have met it and 8 out of 10 people
or better would agree). We don\'t want to cast the FPC back into
untestable land because of this provision. Version 3 is best we have
now.

IBM Version 2 is worded like the other FPC. It was stated in the
discussion that an FPC for limited hearing worded like the others would
not be testable as there is no measurable specification for \"limited
hearing\" as there is for FPC B and FPC H. Version 1 was proposed as
providing volume control is the recommended solution to support people
with limited hearing. Version 3 is a slight edit of version 1 that is
more testable as it removes the word \"important,\" which is a
subjective judgment. IBM agrees that having an FPC that does not have a
measurable specification of the disability is an issue and prefers
version 3. Since Version 3 reads like a general technical requirement,
however, we prefer to see this as a provision in C-1 General Technical
Requirements.

#### I - Without Physical Contact (no consensus) {#i---without-physical-contact-no-consensus .unnumbered}

*There was one version under discussion, and disagreement about whether
it should be included at all.*

Products must provide at least one mode that allows access necessary to
operate all functionality of the product without requiring any physical
contact with the product beyond initial connection and setup of a
special interface device. This does not apply to powering product up,
changing consumables, configuration, set-up or maintenance. (*See note
on functional performance criteria and assistive technology*.)

Note: For initial setup, it is acceptable to use a physical connector
(e.g., a USB connector) to connect the user\'s special interface device.

Rationale

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

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

3\. Assistive Technology examples:

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

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

4\. Direct Access examples:

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

Viewpoints from Committee Members

Microsoft This wording sounds a lot like \"products must provide a mode
without requiring physical contact, except where physical contact is
essential\". We think this FPC is subjective as to what constitutes
\'configuration\' or \'set up\' and is essentially unworkable as is.

Panasonic FPC (I) as currently drafted would require compatibility with
assistive technology for telecom products unless it provides advanced
voice recognition capability that is not technically or economically
feasible for most consumer products. For telecommunications products, a
"press to operate voice control" feature that enables voice dialing with
a minimal physical contact is a useful way of providing accessibility
for many physically disabled individuals. A press to operate voice
control feature allows telecommunication products to initiate or finish
voice dialing via a minimal physical touch, but does not require
continuous ability to touch and operate controls on the product. Only
where such a feature is not readily achievable should compatibility with
an external special interface device be required. Panasonic proposes
separate versions for Section 508 and Section 255, and removing #1 in
the rationale.

ATIA In the refresh of Section 508 done five years ago, people with
mobility impairments who are unable to touch or make physical contact
were, for the most part, not considered in the Functional Performance
Criteria. ATIA believes it is important to make sure this significant
demographic of disabilities (second in size only to blindness and low
vision) is addressed in the current refresh of Section 508. The argument
that providing access for these individuals is too difficult should not
be reason enough to keep the provision out of the new Functional
Performance Criteria. Indeed, the same could have been said for many of
the other types of disabilities addressed in the refresh five years ago.
But since that time, spurred by the FPC in Section 508, solutions have
been developed. We believe the same will occur in the coming years for
people with no reach or touch, if the provision is included. Unless we
include a Without Physical Contact FPC provision, there is a very real
possibility that this segment of people with disabilities will continue
to be left out of the equal opportunities that Section 508 was meant to
provide to all (not just certain segments of disabilities).

#### J - With Cognitive, Language or Learning Limitations (no consensus) {#j---with-cognitive-language-or-learning-limitations-no-consensus .unnumbered}

*There was one version under discussion, and disagreement about whether
it should be included at all, or could be written in a testable way.*

Products must provide at least one mode that accommodates cognitive,
language, memory or learning impairments. (*See note on functional
performance criteria and assistive technology.*)

Rationale The telecommunications guidelines include a requirement for
provision of a mode that "minimizes the need for memory." See
§1193.41(i).

Viewpoints from Committee Members

Microsoft It is impossible to create a single FPC that covers such a
wide group of people, the kinds of impairments listed here encompass too
wide a spectrum to be meaningful. If anything like this was to be
included it would:\
a) need to be split out into much more delineated and specific
categories\
b) much more scoped in terms of severity of condition (as written it
would essentially mean products need to be operable by individuals with
no effective functional cognitive ability (e.g., in a coma).

IBM IBM does not support the inclusion of this FPC. It has the same
issue as E - With Limited Hearing. The disabilities listed (cognitive,
language, memory or learning impairments) are very broad and not
measurable. We do include a number of provisions in Subpart C that
support the needs of people with these disabilities.

Panasonic Panasonic can not agree with FPC J - With Cognitive, Language
or Learning Limitations, which is too broad, not measurable and thus
impossible to achieve. Subpart C provisions are more appropriate for
such disabilities.

### Provisions from Subpart C {#provisions-from-subpart-c .unnumbered}

#### 1-E: Visual information (no consensus) {#e-visual-information-no-consensus-1 .unnumbered}

*There was one version under discussion, and disagreement about whether
it should be included at all. This provision is linked to the incomplete
6-D. If both 1-E and 1-H reached consensus, the Committee planned to
remove 6-D*

All information that is needed for operation and use that is provided in
visual form must also be available in at least one mode in audio form or
in [simple tactile form]{.smallcaps}, either directly or through support
for the following provisions in Section 3 \<insert list\>.

Visual [content]{.smallcaps} that includes [text]{.smallcaps} and that
is closed due to Digital Rights Management (DRM) such that it cannot be
rendered in audio form by AT and other players must include an audio
form that can be.

Note 1: Section 255 and Section 508 treat AT solutions differently, so
review section XX of this document before implementing a solution.

Note 2: Braille is not a simple tactile form. It is encouraged but
cannot be used to satisfy this provision.

Viewpoints from Committee Members

Microsoft This provision seems largely redundant with respect to 3-O so
we support its removal. If kept, the onus must generally be on a content
owner to make a content product accessible. The hardware should not
create additional barriers of course, but it should not be required that
hardware remediate for failures in other peoples products.

Rights management is an orthogonal issue, which is a policy constraint
means of making a product closed, so 1-A kicks in; and that content
product must be operable in and of itself. This part is redundant and
should be removed.

IBM IBM views this provision as unnecessary. The digital rights
management issue is closed functionality and already covered by 1-A.
Keys on hardware products must be tactilely discernible per 2.1-C. As
the arrangement of keys is spatial, any hardware with keys whose layout
must be memorized by blind users would fail this provision as the keys
would not meet the definition of \"simple tactile form\". And finally,
many of the provisions in section 3 are designed to enable visual
information to be programmatically determined by screen readers which
provide the information auditorially.

Trace & AFB 1-E Visual Information is an important technical provision
for individuals who are blind. It is not covered by other technical
provisions. The AT compatibility provisions are often cited as covering
this -- but one of the key reasons this provision is necessary is for
product that have one or more (or all) features that are closed. For
these features of a product (or for products that are fully closed --
such as most public and many shared products) all of the AT
compatibility or "programmatically determined" provisions would not
apply. (According to 2.1-A - Things that are 'closed' are exempted from
all of the AT compatibility provisions including all provisions that
talk about "programmatically determinable". Instead product
functionality that is closed must meet other provisions -- and this is
the one for access to visual information by those who cannot see. So
removing this would mean that **all closed products are exempt from
being accessible to people who are blind**. (e.g. at ticket machine -
they could feel that there were buttons (per 2.1c) but not know what the
buttons did or know what was on the screen. Clearly this provision is
not redundant with existing technical provisions -- especially for a
product that has any closed function.

There was also some discussion about this not being needed because it
was covered by a Functional Performance Criterion. But ALL of the
technical provisions are covered one or more functional performance
criteria. With that argument we could remove all the technical
provisions.

It was argued in discussions that this was not reasonable because visual
interfaces are so rich and relied upon in products. This is true. That
is the reason that this provision is essential. Note that the provision
does allow (for products that are not closed) use of the other AT
compatibility provisions.

There was also concern that this one was not specific enough. It could
easily be changed to be more specific -- but this would reduce industry
options. More specific language was posted to the list on 3/28/08 but
the goal of the technical provisions generally is to be only as specific
as necessary, in order to maximize a companies options in conforming.

The latter sentence deals with media controlled by DRM. Other provisions
speak to content being programmatically determinable -- but DRM
controlled media are 'closed' and by definition are not
'programmatically determinable. Where the media meets the other
provisions -- but maintains its closed functionality due to DRM, the
media players need to then provide a DRM conformant way to play the
information in audio. (If DRM is handled in a different provision --
then the DRM sentence could be removed here.

Panasonic Panasonic supports the goal of providing access to visual
information necessary to operate E&IT and Telecommunications products.
1-E is in the technical provisions that applies to devices, but note 1
in the current draft is a requirement for content. E&IT cannot provide
access to protected content that is encrypted or otherwise protected by
digital rights management techniques. It would be technically difficult
and legally impossible for manufacturers to violate U.S. law, which has
severe penalties for circumvention, or to violate the terms of private
licenses. The Federal agency or the developer/author of the content is
the best party to assure accessibility. For example, the author of a DVD
with visual menus can provide audio tags for each menu element that the
DVD player simply plays when selected.

For telecommunications products, Section 255 requires a product to be
accessible to and useable by persons with disabilities unless readily
achievable. Only in the case it is not readily achievable to provide
direct accessibility is the manufacturer required to ensure that the
equipment or software is compatible with existing peripheral devices or
specialized customer premises equipment commonly used by individuals
with disabilities to achieve access, if readily achievable. Under
Section 255, the scope of this provision is limited by U.S. statute to
only information that is needed for operation and use the
telecommunications functions of the product.

Sun Sun feels that this provision is duplicative, unnecessary, and
burdensome. Multiple existing and consensed provisions describe in
detail the various aspects of making the visual interface accessible.
The broad and general text of this proposed provision adds almost
nothing that goes beyond the related Functional Performance Criteria
\"Without Vision\". By duplicating such general text here in a technical
provision, we would add significant uncertainty into the product
development process, as E&IT producers and procurement would have to
come to an understanding of what they are supposed to do to meet this
provision as distinct from the other detailed technical provisions for
visual interfaces. If there is some specific \"hole\" not covered by the
existing specific technical provisions, it would be better to address
that with a specific and narrowly tailored provision, rather than the
broad and general language proposed here.

Japanese Standards Association This provision overlaps with 2.1-C 4.,
3-O and 3-M.

Additional Information

-   Text from Self-Contained/Closed

-   Source: {255}1194.43(a)

-   Testability: Expert evaluation

-   Disabilities: Blindness, Low Vision

#### 1-G: Text Size (no consensus) {#g-text-size-no-consensus-1 .unnumbered}

*There is the draft that was under discussion. There were still some
open issues that prevented the Committee from reaching consensus on it.*

For all public or shared products there must be at least one mode where
all information that is required for product use and is provided in text
or images of [text]{.smallcaps} is readable by people with 20/20 vision
at 3.5 times their typical viewing distance and where the mode is the
default mode or the method for activating the mode meets this
requirement except:

\(a\) Caption display: This requirement does not apply to the caption
decoding functions of products that are governed by U.S. Federal
Communications Commission (FCC) regulations 47 CFR 15.119 or to devices
that provide equivalent functionality as stipulated by 4-A - Caption
Processing.

\(b\) Logos and Certifications: Safety [labels]{.smallcaps}, regulatory
[labels]{.smallcaps}, and other marks (such as logos and certifications)
are not included except where they are required by the user "for product
use".

\(c\) Tactile Equivalents: If other means of visually conveying the
information in the [label]{.smallcaps} or instructions exists (e.g.,
uniquely tactilely discernible through shape), and the
[text]{.smallcaps} is not \"required for product use\" then the text
size requirement does not apply.

> For example, a phone-like numeric keypad (with nib) or a tactilely
> unique cluster of arrow keys are usable without labels while softkeys
> (where the function changes and must be read from a display) would not
> be usable without the label.

\(d\) Personal devices: Personal or personally assigned devices are not
covered unless all users must use the same product (or same type of
product) (e.g., policy or in order to work with system software or
procedures). In that case it constitutes a 'shared device' since all
must use the same one (the same type) and that product (or type) would
need to meet provision.

\(e\) Use of [text]{.smallcaps} file: Providing [text]{.smallcaps} in an
accessible file on a device meets this requirement for information that
is not location specific (e.g., [labels]{.smallcaps} are location
specific).

\(f\) Application to Software: Software that is not associated or
purchased with any particular hardware (so the text does not have a
physical size until it is displayed) can be evaluated on any typical
display that the software is intended to work with.

Rationale

The goal of this provision is to support people with low vision. People
with vision worse than 20/70 typically use an assistive device, so this
provision is aimed at supporting those with vision between 20/40 and
20/70.

-   For people with 20/20 vision viewing text at 40 cm (15.7 inch), 8pt
    type is a small but acceptable type size for running text and
    somewhat smaller text could be used for common labels where it is
    mostly identifying which key is which rather than having to read
    novel and/or un-expected information.

-   For people with 20/70 vision, an acceptable size for running text is
    approximately 28pts at 40 cm viewing distance and somewhat smaller
    text could be used for common labels

-   If we assume users with low vision can move in closer (half
    distance - 20 cm) to view text (and that their glasses allow this),
    14 pt type would provide type that subtends the same visual angle
    (as 28 pt at 40 cm).

Although many users with low vision will use close vision coupled with
glasses that focus their vision -- it is too hard for designers to work
off of this -- and all glasses are custom. The 3.5 distance with 20/20
gives a measure that is repeatable and will yield text that is legible
to who need larger clearer type. It also automatically allows text to be
smaller if it is clear and requires it to be larger if it, for example,
used very thin stem width. Some users with low vision have a field of
view limitation. They can use small print modes if available. In general
though, signage and other existing access regulations are based on the
assumption that larger print is more universally accessible for people
with low vision than print that is small to accommodate people with
field of view limitations who cannot step back to shrink the size of the
text in their view. (Note also that this provision does not require very
large text -- just text that is not small.

At a workstation, it is reasonable to assume that special reading aids
(such as a moderate magnifying glass) would be available even if user's
vision is in the range of 20/30 to 20/70, and fonts can therefore be
smaller. The sizes for devices designed to be used away from a person\'s
workstation are aimed at those with low vision but not very low vision
(beyond 20/70). This is based on an assumption that:

-   People with 20/70 vision or better would not usually carry a
    magnifying device with them.

-   People with worse than 20/70 vision would usually carry portable
    optical magnifying devices (including special glasses) with them.

Advisory Note to the Access Board

The Note "Software that is not associated or purchased with any
particular hardware (so the text does not have a physical size until it
is displayed) can be evaluated on any typical display that the software
is intended to work with." eliminates all pixel calculations (which will
not remain valid) and also separates stand alone software from software
in a product. The provision is limited to public or shared products.
These are things that a person cannot modify, mark up, or buy their own
version of. It also can be things that they don\'t know about in advance
of encountering. This allows personally (or personally assigned) cell
phone, keyboards, etc to be excluded. However, this does open up the
problem talked about on other provisions -- that an agency would buy one
type of cell phone (for example) and then write software that only works
with that phone (or type of phone). The user with low vision may know of
phones they could use -- but none of them work with the software -- so
they have to use a phone that has only small print on it. In this case
we believe the issue can be addressed with a note that explains
"Personal or personally assigned devices are not covered unless all
users must use the same product (or same type of product) (e.g.,policy
or in order to work with system software or procedures). In that case it
constitutes a 'shared device' since all must use the same one (the same
type) and that product (or type) would need to meet provision."

Viewpoints from Committee Members

Microsoft \'3.5 times a typical distance\' and \'readable\' are too
subjective to be adequately testable.

bullet 3, label is inconsistent with the wording (tactile/visual).

bullet 6. Software should only be covered in this provision if it
mandates a specific display size for text regardless of display hardware
and platform (i.e., 3-D did not apply), and that no non text cues (e.g.,
icons or position) could be utilized.

IBM IBM views this provision as a potential conflict with 3-D User
Preferences. Software that runs on platforms that support system wide
settings for font size should respect the user\'s chosen font size.

TIA Rationale in opposition to Versions 1 and 2. While Version 2 is a
substantial improvement over Version 1, there are infirmities that need
to be addressed. Specifically the requirement that low vision mode be
the default mode or method of activating appears to be in contradiction
to the clause stipulating \"there must be at least one mode\". It is
preferable that the standard stipulate that a low vision setting be
easily discernable and discoverable rather than to require every device
to ship with the default on low vision. (Defaults are factory set for
shipping.) Under the Personal Device exemption, it is not acceptable
that an agency \"by policy or procedure\" could limit the opportunity
for inaccessible products to be selected in procurement, but this is the
effect of the current text. The provision should allow for adopting
products which can support software that provides access. Lastly, the
Application to Software provision needs to align with provision 3-D User
Preferences by affirmatively stating that software meets this provision
if its support 3-D and runs on platforms that provide system-wide
settings for font size.

Canon 1-G Text Size Versions 1 and 2 apply to public or shared products.
The rationale for excluding personal products is because it is assumed
that at a workstation, special reading aids (such as a moderate
magnifying glass) would be available even if users vision is in the
range of 20/30 to 20/70. However, the availability of special reading
aids would also apply to shared products in users departments or general
work area. Therefore, 1-G Text Size should apply to public products;
there is no reason based on this rationale that shared products should
be applicable.

It would be helpful to include the text sizes (previously removed) that
may be used to meet this provision. Many public products, such as
kiosks, ATMs, and copy machines may be used from a standing or seated
position. Therefore, the 3.5 times typical viewing distance approach
would depend on the height of the user which varies considerably, and
whether the user is seated. In this case, having reference to the text
sizes below from the March 11th version would be beneficial.

a\) At least 12 points if text is a label and if the user can position
their face close to the label\
b) At least 14 points for all other text\
where 1 point = 1/72.27 inches (on computer displays 1/72 inch).

Trace Version 2 represents extensive efforts to address multiple
different comments and is the language Trace recommends. It is
complementary with other provisions such as 3-D User Preferences in that
user preference can be used where they allow this size to be met (which
is true for all common OSs today). However there are often software
packages that are meant to be run in such a way that they suppress any
ability to get to the OS settings. Kiosks are a good example. In those
cases, relying on systems settings will not work.

Some cleanup of the default language may be needed to clarify. The
current language could be made clearer by saying . where EITHER 1) the
mode is the default mode or 2) the method for activating the mode meets
this requirement. to make it clear that the default doesn't need to meet
this as long as the way to turn it on does meet this.

Japanese Standards Association: This provision must be applied to
products that are used by a variety of people in public space. Please
consider to add this condition in the provision.

Additional Information

-   Text from Self-Contained/Closed

-   Source: {255}1193.43(b)

-   Testability: Inspection

-   Disabilities: Low vision

#### 3-P - User Interface Components (no consensus) {#p---user-interface-components-no-consensus .unnumbered}

*There were two versions of this provision under discussion.*

Version 1

For all user interface components, including form elements and those
generated by scripts, the name and role must be [programmatically
determinable]{.smallcaps}. States, properties, and values that can be
set by the user must be [programmatically determinable]{.smallcaps} and
can be programmatically set. Any notification of changes to these items
must be available to user agents, including [assistive
technologies]{.smallcaps}.

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

Version 2

For all user interface components, including form elements and those
generated by scripts, the name, role, states, properties, and values
must be [programmatically determinable]{.smallcaps}. States, properties,
and values that can be set by the user can also be programmatically set.
Any notification of changes to these items must be available to user
agents, including [assistive technologies.]{.smallcaps}

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

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.

Advisory Note to the Access Board

The word \"components\" was used in this provision instead of
\"objects\" since objects is a programming term and can be confusing to
vendors. By using the term components it is more generic and will
hopefully lead to less confusion.

Viewpoints from Committee Members

IBM IBM supports version 2 of this provision. While this provision is
technically redundant with 3-U, it is written to a different target
audience. 3-U is intended for developers of traditional software
applications and user agents who use programming APIs. It is harmonized
with the ISO software accessibility standard (9241 part 171). 3-P, which
is harmonized with the equivalent provision in WCAG 2.0, is targeted at
developers of user interfaces that are rendered by user agents such as
Web content that contains interactive form control elements or user
interface components implemented with scripting languages.

Additional Information

-   Text from Web and Software

-   Source: {508}1194.21(l) & .22(n)

-   Impact: Significant: Rich Internet Applications will have to
    implement the ARIA standards. Significant positive impact to end
    users and agencies. IT-AT interoperability will be improved and less
    customization should be required.

-   External Reference: Harmonized with [[WCAG 2.0-4.1.2 Name, Role,
    Value (Level
    A)]{.underline}](http://www.w3.org/TR/WCAG20/#ensure-compat)

-   Testability: Inspection

-   Disabilities: All

#### 3-SS: Visual Indication of Keyboard Shortcuts (no consensus) {#ss-visual-indication-of-keyboard-shortcuts-no-consensus-1 .unnumbered}

*There were two versions of this provision under discussion, but final
text was not agreed on.*

Version 1

All [keyboard]{.smallcaps} commands associated directly with user
interface controls must be visible within the visual user interface in
at least one mode, and available programmatically to AT on products that
support AT interoperability.

Version 2

All [keyboard]{.smallcaps} commands associated directly with user
interface controls must be visible within the visual user interface in
at least one mode.

*These notes are for both versions*

Note 1: This includes commands such as those used to active a menu item
or button (e.g.,the \"S\" of a \"Save File\" menu item), but does not
include commands that are system-wide or common conventions for using an
item (e.g.,a command to switch windows such as ALT-TAB, or a command to
advance the caret in text such as Ctrl-Arrow).

Note 2: User-configurable keyboard commands may be considered not
directly tied to interface elements. However, when possible such
user-configurable keyboard bindings should be visually presented as
configured.

Viewpoints from Committee Members

Microsoft There may be more than one keyboard sequence associated with a
user interface control, only one of these should need to be shown in the
user interface. Suggest adding \[At least one of any\] to the beginning
of this provision.

The scoping of what is a keyboard command needs more work. Suggest
removing both the notes and replacing it with the following text as part
of the provision: "A keyboard command can be considered \'associated
directly\' when it is a keyboard command associated with a specific
instance of a type of control, and that control association is not
dependant on transient conditions of operation or user configuration."

Adobe Adobe supports a more clearly scoped version of 3-SS. Providing
visual indication of keyboard shortcuts is beneficial, but has the
potential to be overwhelming in some situations. With complex controls
there may be several shortcuts for example a calendar control may have
shortcuts for moving to the first or last dates in a month, moving to
the next month, moving to the next year, as well as shortcuts for
selecting contiguous and non-contiguous date ranges. Adobe recommends
that 3-SS be an advisory note.

IBM IBM notes that this provision is not included in either of the
international accessibility standards for Web (WCAG 2.0) or software
(ISO 9241 part 171), Its inclusion would create a unique requirement for
the US assuming other countries harmonize with international standards.
For most desktop software applications, this is not a problem as this
feature is a widely accepted convention followed by most, but not all,
platforms and applications. IBM acknowledges, however, that failure to
identify the keyboard shortcuts in the user interface significantly
impacts the productivity of sighted keyboard-only users and recommends
that this provision be included as an advisory note.

W3C/WAI We support version 2. However, even with this simplification,
the remaining aspect of the provision still needed further discussion
and development beyond the time available through the TEITAC process.
Individual conversations with developers across most platforms appear to
have resulted during the final weeks of TEITAC process in acknowledgment
that there was a valid user need here for people with limited use of
their hands who need visual indication of keyboard shortcuts without
relying on pointing devices or extended sequential navigation to
discover such shortcuts. But the variability of terminology for
different forms of keyboard interaction, coupled with the varied
feasibility of supporting visual indication of keyboard shortcuts,
commands, navigation options, etc., means that the provision must be
very clearly and carefully stated. In addition, since this user need had
not been recognized at the appropriate level by ISO nor by W3C/WAI\'s
User Agent Accessibility Guidelines 1.0, there was a concern about lack
of harmonization if it became a requirement under Sec 508.

This issue has been taken up for further exploration through the
development of W3C/WAI\'s User Agent Accessibility Guidelines 2.0, and
several developers and user representatives have committed to refining
an appropriate and feasible cross-platform requirement to meet this user
need. W3C/WAI would like to offer such language to the Access Board as a
suggested approach for meeting this need, at such time as we have been
able to develop that language. This would also provide an avenue for
addressing harmonization concerns that were raised regarding this user
need.

Additional Information

-   Text from Committee

-   Source: New: Accompanies Subpart D: 1.1-B - Keyboard Shortcuts

-   External Reference: Possibly harmonized with ISO 9241-171 - 9.3.11

-   Testability: Inspection

-   Disabilities: Blindness, Dexterity

#### 3-U: AT Interoperability (partial consensus) {#u-at-interoperability-partial-consensus-1 .unnumbered}

*The Committee reached consensus on much of the text in this provision.
In the draft below, the text in **bold italics** was not agreed to.*

On platforms that support [AT]{.smallcaps}-[E&IT]{.smallcaps}
interoperability, software that provides user interface components must
either use the accessibility services provided by [platform
software]{.smallcaps} or [other services to cooperate with assistive
technologies]{.smallcaps}, when such services allow the software to meet
the accessibility provisions of this standard.

Using such services, software must:

1\. Expose object information including but not limited to:

> a\. Role, state(s), boundary, name, and description
>
> b\. The row and column a component is in, and the headers for the row
> and column for that component, if it is in a table that has row or
> column headers,
>
> c\. Current value and any minimum or maximum values, if the component
> represents one of a range of values
>
> d\. Relationship this component has as a [label]{.smallcaps} for
> another component, or being [labeled]{.smallcaps} by another component
>
> e\. Name of parent or containing element, and any children components
>
> f\. [Text]{.smallcaps} contents, [text]{.smallcaps} attributes, and
> the boundary of [text]{.smallcaps} rendered to the screen
>
> ***g. Keyboard shortcuts and implicit designators.***

In order to meet this provision, [interactive elements]{.smallcaps}
encoded in data operated on by the software must be associated with
sufficient information to programmatically determine a role, state(s),
name, and description for the interactive element, that the software can
obtain as readily as it can obtain the interactive element itself.

2\. Expose a list of actions that can be executed on an object and allow
[assistive technology]{.smallcaps} to programmatically execute any of
those actions;

3\. Expose information necessary to track and modify: focus, text
insertion point, and selection attributes of user interface components;

4\. Expose notification of events relevant to user interactions,
including but not limited to changes in the component\'s state(s),
value, name, description, or boundary

Note 1: This provision also applies to forms in the software.

Note 2: Software that provides remote access to graphical user
interfaces (GUIs) would need to ensure that AT has access to the
information required by this provision. There are two known ways to
accomplish this: run the AT remotely as well or run the AT locally and
provide a mechanism for it to communicate accessibility information with
the remote GUI.

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

Advisory Note to the Access Board:

This is one of the provisions that is affected by the difference of
opinion or position on AT. See Viewpoints from Committee Members below
for additional information.

Note: The word \"components\" was used in this provision instead of
\"objects\" since objects is a programming term and can be confusing to
vendors. By using the term components it is more generic and will
hopefully lead to less confusion.

Viewpoints from Committee Members

Microsoft In general we support this provision, which was carefully
crafted between the various stakeholders, except for bullet g, which was
added at the last minute. Bullet g. is redundant with item 2, and should
be removed; or at the very least scoped as suggested for 3-SS, so that
it refers to commands \'associated directly\' with components, that is,
when it is a keyboard command associated with a specific instance of a
type of control, and that control association is not dependant on
transient conditions of operation or user configuration.

IBM IBM strongly supports removing or rewording item 1g of this
provision to resolve issues keeping this provision from reaching
consensus. Currently, AT interoperability with software requires a high
degree of customization as software products are not exposing sufficient
information programmatically. This provision was developed
collaboratively by representatives of both IT and AT industry. When both
software and assistive technology support the requirements in this
provision in a common way which is currently supported by accessibility
services on most desktop platforms, interoperability will improve and
the need for customization will be reduced or eliminated. This is a big
step forward from the current Section 508 requirements which do not go
far enough.

Trace/AFB We support this provision as written with the caveat that
somewhere it is made clear that it means that all this information is
provided in a way that it can be accessed and used by AT that is
available to users. If the information is exposed so that AT can access
it but there is no AT that does then employees with disabilities will
not be able to use the product if it is purchased.

We acknowledge the problems with bugs in the AT and consideration need
to be made for these. But for a product to claim that it should be
purchase-able because it will meet 508 intent (that people with
disabilities can use it) through AT compatibility then there needs to be
AT that will in fact work with it. This is a general issue for all
provisions that talk about AT interoperability or programmatically
Determinable.

Adobe Adobe supports 3-U, with the exception of g, for reasons similar
to that of 3-SS, which is that this is sufficiently broad to make
testing imprecise.

Sun Sun strongly supports all of the consensed portions of 3-U AT
Interoperability - for reasons well stated already by IBM and ATIA. Like
IBM, we feel the current language of 1g (the sole portion of 3-U without
consensus) is troublesome. It is too broad, covering both \"direct\"
keyboard shortcuts (e.g. the \"Ctrl-P\" of a Print menu item in a file
menu), and \"indirect\" or \"sequence\" keyboard shortcuts (e.g. the
sequence \"Alt-F\" followed by \"P\") - when we believe only the
\"direct\" ones are intended. Likewise there are \"implicit\"
designators (such as Alt-TAB to switch between top-level windows) that
we believe are likewise not intended to be covered. As we ran out of
time to finish working through the late suggested addition of 1g, we
believe at this time it should either be removed, or re-written to
address the issues just outlined. Sun suggest renaming this provision to
"3-U Exposure via Accessibility Services"

ATIA ATIA supports the inclusion of the AT Interoperability provision
3.U. ATIA has worked closely with representatives from the consumer
groups and IT, and believes this provision is essential to improved
compatibility between AT and E&IT. Many of the other compromises reached
throughout the provisions are based upon the revisions to this section.
The language in this draft goes further and is far more specific than
the existing provisions. We believe this additional specificity is
necessary to improve interoperability between AT and E&IT. We fully
support all of the language in the draft version of this provision, and
note the importance of Section 1.g. on keyboard shortcuts (which is also
critical for access by persons with physical disabilities). ATIA also
endorses the notes attached to this provision.

Additional Information

-   Text from Web and Software

-   Source: {508}1194.21(d), (c), & (f)

-   Impact: Significant: More specificity of the information that must
    be exposed to AT. Significant positive impact to end users and
    agencies. IT-AT interoperability will be improved and less
    customization should be required.

-   External Reference: Harmonized with ISO 9241-171

-   Testability: Expert evaluation

-   Disabilities: All

#### 3-VV: Assistive Technology (no consensus) {#vv-assistive-technology-no-consensus-1 .unnumbered}

*This provision was the subject of much discussion, and no agreement to
include it was reached.*

[Assistive technology]{.smallcaps} must utilize the [platform software
accessibility services]{.smallcaps} that meet section 3-V: Accessibility
Services, to the extent that the information is appropriate to the AT
function, in order to provide the alternative user interface(s) to
people with disabilities. [Platform accessibility services]{.smallcaps}
includes but is not limited to the items listed in 3-U: AT
Interoperability.

Rationale

The purpose of 508 is to change the work environment such that people
with disabilities can be hired into positions where the E&IT is already
accessible. Since AT will remain a key component of that environment -
for efficiency & productivity of the employee with a disability - E&IT
and AT must work effectively together. Placing a burden solely on E&IT
to achieve this result doesn\'t work for numerous reasons (articulated
elsewhere). Since AT and E&IT are typically procured at different times
under different procurements, the best way to ensure they work together
is to require that both utilize the same mechanisms for inter-operating:
namely the 3-V Accessibility Services providing the information
enumerated in 3-U AT-IT Interoperability.

Advisory Note to the Access Board

When we say that \"E&IT works with AT\" or \"E&IT is accessible
\'through AT\'\" or information presented by E&IT \"programmatically
determinable\" we mean that E&IT either:

-   is known to work with AT that is available to users

or

-   has been tested with an API tool and passes where it has been shown
    that passing the tool will result in E&IT that will work with AT
    that is available to users

Viewpoints from Committee Members

ATIA ATIA vehemently opposes the inclusion of provision 3.VV in the 508
regulations. First, the professed purpose of the mandate is to improve
interoperability between AT and E&IT. Unfortunately, it is a fallacy to
believe that merely requiring AT to utilize APIs will result in
automatic plug and play interoperability. At this point in time, neither
AT nor E&IT can guarantee that the products will work seamlessly without
further efforts, testing, and some degree of customization with respect
to more complex AT. Use of an API should never serve as a proxy for
actual interoperability. Interoperability is a process, and this
provision creates the misimpression that if both E&IT and AT utilize an
API, we will have magically solved interoperability problems. Indeed, it
is quite possible for both E&IT and AT to utilize APIs and still be
incompatible. ATIA believes that APIs are a significant improvement in
technology that will go a long way towards improving interoperability.
However, there are numerous circumstances in which APIs fall short, or
improper implementation of APIs makes it impossible for AT to utilize
APIs to achieve access. To that end, AT must have the discretion to
utilize APIs as appropriate in developing AT, and E&IT should provide
those APIs. As E&IT improves the implementation and depth of their APIs,
that process alone will encourage more AT to adopt and utilize the APIs.

Additionally, the provision also misunderstands the nature of most
Federal Government acquisition of AT. Most purchases of AT are not made
under the traditional Section 508 purchase processes, but rather under
Section 504 as an accommodation for specific individuals with
disabilities. Consequently, the provision will not be applied in most AT
purchases, and will therefore not have an impact on the AT industry, or
prevent the federal government from acquiring AT that fails to use APIs.
ATIA believes this provision exceeds the mandate of the TEITAC because
it is overbroad to the extent that it touches on 504 purchases of AT.

Finally, ATIA is concerned that this provision will reduce the
cooperative effort that has existed between AT and E&IT since the first
508 regulations. For the past 5 years, AT and IT have increasingly been
working closely together to improve interoperability. These
relationships run deep, and we expect they will continue in the future.
We believe that the regulations should reflect an understanding of how
our industries work together to arrive at interoperability. We should
not encourage a situation in which E&IT could say we utilized the API,
however, there is nothing else we can or will do to ensure
interoperability with AT and we believe that the inclusion of this
provision would do just that for some companies. We do agree that
procurement officers should consider interoperability and the extent to
which AT utilizes APIs in determining the likelihood of accessibility
between the AT and E&IT it purchases, but we see this as a
recommendation that should be made in the FAR rather than in the 508
regulations.

Sun Sun feels strongly that this is an important provision which should
be adopted by the Access Board. The technical standards enumerate the
specific aspects of technology acquisitions that agencies should ensure
are present before procuring E&IT. These three components: platform,
application software, and assistive technology all have important roles
to play in forming an accessible E&IT environment, and procurement must
take this into account, else the result may be a failure of
accessibility. It is important that we provide guidance to agencies for
what needs to be present in procured AT in order for it to interoperate
with E&IT. Without this provision or one like it, only the platform E&IT
and application E&IT interoperability aspects are addressed.

Additional Information

-   Text from Web and Software

-   Source: New

-   Impact: None for current desktop operating system platforms.
    Significant for applications that are also platforms and for
    non-desktop platforms. All desktop operating system platforms meet
    the requirement. Not all applications that are also platforms and
    non-desktop platforms meet the requirement.

-   External Reference: Harmonized with 9241-171. Related to [[WCAG
    2.0-4.1.2 Name, Role, Value (Level
    A)]{.underline}](http://www.w3.org/TR/WCAG20/#ensure-compat)

-   Disabilities: All

#### 6-D: Caller and Status Information (no consensus) {#d-caller-and-status-information-no-consensus-1 .unnumbered}

*There were two versions under discussion. The Committee agreed that his
provision will be removed if 1-E and 1-H reached consensus, however 1-E
is also incomplete.*

Version 1

Products with visual interfaces that display
[telecommunications]{.smallcaps} status information (such as caller
identification and similar [telecommunications]{.smallcaps} functions)
must also make this information available for:

1\. Users of [TTYs]{.smallcaps},

2\. Users of other [text]{.smallcaps} conversation systems, and

3\. Users who cannot see displays.

These products must also meet all accessibility provisions for software
and [content]{.smallcaps}.

Version 2

Products with visual interfaces that display
[telecommunications]{.smallcaps} status information must: 1. Provide at
least one mode that does not require speech or hearing or speech to
operate the visual display 2. At least one mode where information is
available in a non-visual manner.

Examples of status or [text]{.smallcaps} information includes caller
identification.

These products must also meet all accessibility provisions for software
and [content]{.smallcaps}.

The display capability of the [telecommunications]{.smallcaps} product
must not be disabled when the phone is used in conjunction with a
[TTY]{.smallcaps} device.

Viewpoints from Committee Members

IBM IBM notes that this provision, as worded, would be applicable to
software products that display telecommunications status information.
But since TTY devices connect to telecommunications equipment, not
software, there is no known way for software to implement the
requirement. And the requirements in this provision are already covered
by 1-A, 1-D, and 1-H in the General Technical Provisions section. This
provision therefore is not needed.

Trace If provision 1-E (Visual information) is accepted then this
provision is covered by other technical provisions. If 1-E (Visual
information) is not then this is not fully covered. (Part of this would
be a subset of 1-E. so 1-E would cover this but this would cover only a
very small specific use-case of 1-E). Note that this applies both to
TTYs and to VoIP real-time text devices/software.

Additional Information

-   Text from Telecommunications

-   Source: {508}1194.23(e)

-   Testability: Inspection

-   Disabilities: Deafness, Blindness

7-C: Prompts (no consensus)

*There were several versions of this provision under active discussion,
but there was no decision as to whether it should be included.*

Version 1

[Authoring tools]{.smallcaps} with a user interface must provide a mode
that prompts authors to create accessible [content]{.smallcaps}.

Note: It is neither expected nor possible that prompts be available for
every type of accessible content.

Version 5

An [authoring tool]{.smallcaps}, or suite of tools used to author
content, whether such suite is composed of tools from a single vendor or
multiple vendors, must provide a mode which prompts authors to create
accessible [content]{.smallcaps} for accessibility problems that the
tool or suite has the capability to correct, for formats authored by
that tool or suite that support compliance as explained in the
definition of [authoring tool]{.smallcaps}.

Version 7

An [authoring tool]{.smallcaps}, or suite of tools used to author
content, must provide a mode which prompts authors to create accessible
[content]{.smallcaps}, for formats authored by that tool, for
accessibility problems that the tool or suite has the capability to
correct.

Note 1: It is neither expected nor possible that prompts be available
for every type of accessible [content]{.smallcaps}.

Note 2: A suite of [authoring tools]{.smallcaps} can be composed of
tools from a single vendor or multiple vendors.

Advisory Notes to the Access Board

The committee recommends that advisory techniques be available and
linked from this provision, regarding how to provide guidance on
effective methods of prompting, as well as techniques to avoid.

Notes regarding version 7:

-   This standard as written lacks specificity, while at the same time
    acknowledging that it is likely impossible to specifically define
    all of the prompting needed for each accessible format. The result
    is a situation where both authoring tool software engineers and
    Government procurement officers will be unable to determine if they
    are meeting the standard. If included as is, it is anticipated there
    will be procurement difficulties where common understanding needs to
    be negotiated between sales people and purchasers, potentially on a
    sale-by-sale basis.

-   It is also unclear what an HTML authoring tool \[potentially the
    most straightforward scenario\] would need to do to for prompting to
    meet this standard.

-   This standard may need to be moved to a recommendation rather than a
    full standard unless we are willing to set what some people might
    feel is a very low bar that can be applied to all possible content
    that authoring tools may create.

Viewpoints from Committee Members

SSA Provision 2-D (Accessible Content) under Subpart D places a
significant burden on federal agencies to produce accessible content, a
provision that will affect a significant number of federal employees.
Given the complexity of the 508 standards as proposed, the dependence on
authoring tools to provide appropriate prompting is significant. Lack of
clarity or resolution on what level of prompting is required will have a
deleterious effect on each agency\'s ability to implement provision 2-D.

W3C/WAI Version 7 of this provision includes several concepts which
would be important to consider retaining in any further rewording of the
provision, but it is also missing some important concepts. Specifically:

\- It is important to retain the concept that the prompting capability
can be either within an authoring tool, or within other authoring tools
that are part of a suite of tools offered by a vendor. This flexibility
would be helpful for some authoring tool vendors in meeting this
provision, and could still provide prompting functions needed to
facilitate production of accessible content, as long as prompting were
supported within the suite for all formats which meet electronic content
provisions. However this flexibility should not be so general as to
permit that prompting could be accomplished with a tool that is not part
of the suite being offered by a vendor.

\- Missing from this version however is the important concept that this
requirement should only apply to tools which have a user interface.

\- In addition, a concern was raised regarding insufficient specificity
of the provision to enable clear assessment of conformance. While we
tried to address this with a scoping note stating that it is neither
expected nor possible that prompts be available for every type of
accessible content, this was still considered open to too much
interpretation by procurement officers, leaving developers not knowing
whether they had met the requirement until they were already engaged in
procurement process around a completed product. I believe that it would
be useful to find an appropriate way to more clearly scope this
requirement, however without being overly prescriptive about which
content types to prompt for, as that may be too constraining as
technologies evolve.

\- The concept of \"a mode which prompts\" as opposed to a default
configuration is important to retain so that prompting is not active in
situations where it might interrupt the creative process; however it
should be able to be configured so that it may apply at different points
in the development process, for instance when reviewing image selection,
or prior to publishing a document.

\- The suggestion has been made that this provision should be at the
level of recommendation, not requirement. The capability for authoring
tools to prompt for accessible content would have the potential to
significantly facilitate the work of content developers in complying
with electronic content provisions, if this were to become a
requirement.

Additional Information

-   Text from Web and Software

-   Source: new

-   External Reference: ATAG, ISO9241-71

-   Testability: Inspection

-   Disabilities: All

#### 7-D: Accessible Templates (No consensus) {#d-accessible-templates-no-consensus-1 .unnumbered}

*There were several versions of this provision under active discussion,
but there was no decision as to whether it should be included.*

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

Note: This provision should not be applied to formats which are not
enabled for accessibility support; nor does it require an accessible
template for every template that is packaged with an authoring tool.

Viewpoints from Committee Members

W3C/WAI Accessible templates and accessible pre-authored content
provided with authoring tools can be highly effective in facilitating
conformance to a variety of electronic content provisions. Authoring
tool vendors know their tools better than their customers and can more
efficiently develop sample templates and pre-authored content, which can
help model how to use the tool\'s features in ways that support
accessible content provisions.

A significant concern with the wording of this provision however was
apparently a potential ambiguity with the scoping of the provision, due
to the phrasing \"\...at least one version that meets applicable Section
508 provisions,\" even with the accompanying note that this does not
require an accessible template for every template that is packaged with
an authoring tool.\" In other words, it could be interpreted as
requiring only one template in all, which would not have significant
benefit; or conversely it could be interpreted as requiring very many
accessible templates. Further discussion would be needed to arrive at
appropriate scoping of the requirement.

Additional Information

-   Text from Web and Software

-   Source: new

-   External Reference: ATAG, ISO9241-71

-   Testability: Inspection

-   Disabilities: All

#### Subpart D: 1.1-B: Keyboard Shortcuts (no consensus) {#subpart-d-1.1-b-keyboard-shortcuts-no-consensus .unnumbered}

*There were 4 versions of this provision under active discussion.*

Version 5

Information about [keyboard]{.smallcaps} shortcuts, including available
[keyboard]{.smallcaps} commands and [keyboard]{.smallcaps} navigation
mechanisms, must be listed in centrally located user documentation, and
available in context-sensitive help.

Version 7

Information about [keyboard]{.smallcaps} shortcuts and implicit
designators must be listed in centrally located user documentation, and
available in context-sensitive help.

Version 8

Information about [keyboard]{.smallcaps} operation, including available
[keyboard]{.smallcaps} commands and [keyboard]{.smallcaps} navigation
mechanisms, must be listed in user documentation, such as online help,
context-sensitive help, or printed user\'s guides.

Note: The inclusion of a comprehensive listing of keyboard shortcuts for
an application in a documented location is suggested as some users
benefit from a single, centralized resource.

Note: Centrally located user documentation can be in more than one
location, but should be able to be located through application help.

Version 9

Information about [keyboard]{.smallcaps} operations, including available
[keyboard]{.smallcaps} commands and [keyboard]{.smallcaps} navigation
mechanisms, must be listed in electronic documentation, such as online
and context-sensitive help.

Note: The inclusion of a documented comprehensive listing of
[keyboard]{.smallcaps} shortcuts for an application is suggested as some
users benefit from a single, centralized resource.

Rationale

The documentation of keyboard shortcuts can be hard to locate. This
provision would require that this information be available in a useful
form.

Viewpoints from Committee Members

Microsoft Replace "...must be listed..." with "...must be provided..."

IBM IBM supports the inclusion of version 9, but would prefer to see it
refer to *either* online *or* context-sensitive help. This version meets
the need of keyboard-only users yet allows developers the flexibility to
determine the most usable way to document them.

Wc3/WAI Because of time constraints in the final TEITAC meeting, the
language in version 9, which had apparently reached consensus between
parties who had been involved in discussing the issue, could not be
confirmed with the full committee for consensus. W3C/WAI supports that
language. Since then, a comment was also received on this topic,
suggesting substitution of \"provided\" instead of \"listed.\" W3C/WAI
would support that language equally. It is possible that on this topic,
W3C/WAI\'s User Agent Accessibility Guidelines Working Group (UAWG)
might also have more in depth discussion of appropriate and feasible
ways to meet this user need, and if so will also offer any new insights
and/or wording to the Access Board if those become available.

Additional Information

-   Text from Documentation and Technical Support

-   Source: New

-   Impact: +

-   Testability: Inspection

-   Disabilities: All

### Definitions Considered but Not Completed {#definitions-considered-but-not-completed .unnumbered}

*There were several definitions considered, but which did not reach
consensus. Some of these terms are not used in the provisions, but were
drafted for earlier versions.*

::: Definition
Accessible Content Format
:::

Version 1: A format that supports the creation of [content]{.smallcaps}
to meet Section 508 requirements.

Version 2: A data format that enables the encoding of information in
such a manner that it is consistent with the relevant provisions of
Section 508.

**Application Software:** Software which runs on and makes use of
services provided by [platform software]{.smallcaps}. This includes
\"desktop\" software bundled with an operating system, personal
productivity applications, development tools, Web browsers, and other
non-OS software.

**Authoring Tool:** *(Recommended for acceptance, but never formally
accepted.*) Any software intended to create or modify electronic
[content]{.smallcaps} for publication in one or more formats that
support compliance with the user interface and [content]{.smallcaps}
provisions.

Note: Simple text editors that can only create or modify content in
conforming formats by directly editing the code are not considered
authoring tools under this definition.

**Blinking**: Switch back and forth between two visual states in a way
that is meant to draw attention.

Note: See also flash (It is possible for something to be large enough
and blink brightly enough at the right frequency to be also classified
as a flash).

**Captions:** *(Version 3 was agreed to by the task force, but the
Committee did not have enough time to bring this definition back up for
a consensus decision.)*

Version 1:

Captions are synchronized [text]{.smallcaps} equivalents for audio
information. Captions are similar to subtitles in that they convey the
[content]{.smallcaps} of spoken dialog, but also include
[text]{.smallcaps} 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.

Version 2 (from WCAG 2.0):

[Synchronized media]{.smallcaps} or [text]{.smallcaps} equivalents for
audio information including both dialog and non-dialog audio information

Note 1: Captions are similar to dialog-only subtitles except captions
convey not only the content of spoken dialog, but also equivalents for
non-dialog audio information needed to understand the program content,
including sound effects, music, laughter, speaker identification and
location.

Note 2: Closed Captions are captions that can be turned on and off in
some players.

Note 3: Open Captions are captions that cannot be turned off. For
example, if the captions are visual equivalent images of text embedded
in video.

Note 4: Captions should not obscure or obstruct relevant information in
the video.

Note 5: In some countries, captions are called subtitles.

Note 6: Video descriptions can be, but do not need to be, captioned
since they are descriptions of information that is already presented
visually.

Version 3:

Synchronized "[text]{.smallcaps}" and symbol equivalents for audio
information.

Note 1: The term "text" in this definition refers both to electronic
text and to images of text that might be embedded in video.

Note 2: Captions are similar to dialogue-only subtitles except captions
convey not only the spoken words, but also other audio information
needed to understand the program content, including sound effects,
music, laughter, tone of voice, speaker identification, and location.

Note 3: Captions can be "closed" or "open". Captions that are "closed"
can generally be turned on and off by viewers. Captions that are "open"
are any captions that cannot be turned off. For example, captions that
are visual equivalent images of text embedded in video are "open."

Note 4: Captions should not obscure or obstruct relevant information in
the video.

Note 5: In some countries captions are called subtitles.

Note 6: Video descriptions can be, but do not need to be, captioned
because they are descriptions of information that is already presented
visually.

Rationale for version 3:

Some of the issues that came up on the side discussions that are all
addressed above are as follows.

1\. Captions are not just text but also include other symbols (music
notes etc) that should be allowed.

2\. The word 'text' is ambiguous since we allow images of text here but
images of text cannot be used as text in other parts of these same
guidelines. Need a note to clarify

3\. If we just say visual equivalents -- then sign language would
satisfy this and it shouldn't -- that shouldn't be called captioning.

4\. Open captions are not just images of text embedded in video stream
-- but can be any captions that cannot be turned off and on.

5\. Closed captions cannot be turned on and off in all players/viewers.

6\. Can we use dialogue instead of dialog to avoid confusion with dialog
boxes (in which captions can in fact be presented).

7\. Non-verbal (which means non-word) can separate out visual signing
from visual symbols like music notes but many people misread non-verbal
to mean non-vocal or non-speech and that creates all sorts of new
problems. the "non-spoken" is close here but the cue that the person is
SHOUTING is non-verbal but not non-spoken so 'non-spoken' misses some of
the important information.

8\. Keep it simple - (at one time the definition had grown to
"synchronized visual equivalents for both dialogue and non-dialogue
audio information needed to understand the media content where the
equivalents are either text or images of text combined with non-verbal
visual elements (such as music notes).") until we regrouped and went
back to the simple one we had and just applied the essential fixes
needed to it.

9\. 'symbols' doesn't cover font styling and color -- but that could be
covered by word 'text' in definition since they are characteristics of
text and adding "and font styling and color" to the definition would
make it more complete as the expense of making it more complex.

**Caption Text:** (*This definition was proposed for removal, in favor
of the term "Captions.)*

(Definition from WCAG).[Text]{.smallcaps} presented and synchronized
with [synchronized media]{.smallcaps} to provide not only the speech,
but also non-speech information conveyed through sound, including
meaningful sound effects and identification of speakers.

Note 1: In some countries, the term \"subtitle\" is used to refer to
dialogue only and \"captions\" is used as the term for dialogue plus
sounds and speaker identification. In other countries, subtitle (or its
translation) is used to refer to both.

Note 2: Video descriptions can be, but do not need to be, captioned
since they are descriptions of information that is already presented
visually.

**Enhanced Audio**: Audio which has been enhanced through amplification
and/or through a variety of audio signal processing to make it easier
for people with hearing loss to understand.

*This definition was added to support 1-E - With Limited Hearing. If the
provision is rewritten, it is not needed. Current drafts do not use this
term.*

**Flash:** A pair of opposing changes in luminance ([relative
luminance]{.smallcaps} for software and [content]{.smallcaps}) that can
cause seizures in some people if it is large enough and in the right
frequency range.

Note 1: See [general flash threshold and red flash
threshold]{.smallcaps} definitions for information about types of flash
that are not allowed.

Note 2: See also [blinking]{.smallcaps}.

**Free-Standing:** Standing on the floor and not intended to be placed
on a table or built into a structure

Example: The kiosk was a free-standing device that stood on the carpet
in front of the registration desk.

*Note: The subcommittee is requesting input on whether this should be
defined since it is used in other parts of the ADA regulations and could
have impacts there.*

::: Definition
General Flash and Red Flash Thresholds for Content and User Interfaces:
:::

A flash or rapidly changing image sequence is below the threshold (i.e.,
software or [content]{.smallcaps} passes) if any of the following is
true:

1\. There are no more than three General Flashes and / or no more than
three Red Flashes within any one-second period; or

2\. The combined area of [flashes]{.smallcaps} occurring concurrently
occupies no more than a total of .006 steradians within any 10 degree
visual field on the screen (25% of any 10 degree visual field on the
screen) at typical viewing distance where:

-   A General Flash is defined as a pair of opposing changes in
    [relative luminance]{.smallcaps} of 10% or more of the maximum
    [relative luminance]{.smallcaps} where the [relative
    luminance]{.smallcaps} of the darker image is below 0.80; and where
    \"a pair of opposing changes\" is an increase followed by a
    decrease, or a decrease followed by an increase, and

-   A Red Flash is defined as any pair of opposing transitions involving
    a saturated red.

Exception: [Flashing]{.smallcaps} that is a fine, balanced, pattern such
as white noise or an alternating checkerboard pattern with \"squares\"
smaller than 0.1 degree (of visual field at typical viewing distance) on
a side does not violate the thresholds.

Note 1: For general software or Web [content]{.smallcaps}, using a 341 x
256 pixel rectangle anywhere on the displayed screen area when the
[content]{.smallcaps} 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 (e.g.,15-17 inch screen at 22-26 inches). (Higher
resolutions displays showing the same rendering of the
[content]{.smallcaps} yield smaller and safer images so it is lower
resolutions that are used to define the thresholds.)

Note 2: A transition is the change in [relative luminance]{.smallcaps}
(or relative luminance/color for red flashing) between adjacent peaks
and valleys in a plot of relative luminance (or relative luminance/color
for Red Flashing) measurement against time. A [flash]{.smallcaps}
consists of two opposing transitions.

Note 3: The current working definition in the field for \"pair of
opposing transitions involving a saturated red\" is where, for either or
both states involved in each transition, R/(R+ G + B) \>= 0.8, and the
change in the value of (R-G-B)x320 is \> 20 (negative values of
(R-G-B)x320 are set to zero) for both transitions. R, G, B values range
from 0-1 as specified in "relative luminance" definition. (Harding and
Binnie 2002)

Note 4: Tools are available that will carry out analysis from video
screen capture. However, no tool is necessary if [flashing]{.smallcaps}
is less than or equal to 3 flashes in any one second period (content
automatically passes (see #1 and #2 above).

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

**Interactive Elements:** Elements of the user interface that are acted
on by the user.

**Manufacturer:** A manufacturer of [telecommunications]{.smallcaps} or
VoIP equipment or customer premises equipment that sells to the public
or to vendors that sell to the public; a final assembler.

*This definition was requested to support Section 255. However, it is
limited to telecommunications-related context, and is used more
generally in the recommended provisions, so needed to be changed to be
more general.*

**Menu:** Set of selectable options.

*This came from one section of provisions, but is used in several
places, and text was never created to make it more general*

**Peripheral Devices**: Devices employed in connection with
[telecommunications]{.smallcaps} or VoIP equipment or [customer premises
equipment]{.smallcaps} to translate, enhance, or otherwise transform
[telecommunications]{.smallcaps} or VoIP services into a form accessible
to individuals with disabilities.

*This definition was requested to support Section 255*

**Platform Accessibility Services**: Services provided by a platform
enabling interoperability with [assistive technology]{.smallcaps},
commonly in the form of accessibility APIs (application programming
interfaces).

**Programmatically Determinable**

Version 1

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.

Version 2

Determinable by user agents, including [assistive
technologies]{.smallcaps}, from the data provided.

Note 1: Purpose is to allow user agents including [assistive
technologies]{.smallcaps} to extract and present this information to
users in different modalities.

Note 2: Programmatically determinable requires that the information be
determinable by existing [assistive technologies]{.smallcaps}.

Version 3 (WCAG)

Determined by software from author-supplied data provided in a way that
different user agents, including assistive technologies, can extract and
present this information to users in different modalities.

Example 1: Determined in a markup language from elements and attributes
that are accessed directly by commonly available assistive technology.

Example 2: Determined from technology-specific data structures in a
non-markup language and exposed to assistive technology via an
accessibility API that is supported by commonly available assistive
technology.

**Real-time Text (RTT):** Communications that employ the transmission of
text wherein the characters are transmitted by a [terminal]{.smallcaps}
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.

**Relative Luminance:** The relative brightness of any point in a
colorspace, normalized to 0 for black and 1 for maximum white

Note 1: For the sRGB colorspace, the relative luminance of a 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](http://www.w3.org/WAI/GL/WCAG20/#sRGB|) and
[IEC-4WD](http://www.w3.org/WAI/GL/WCAG20/#IEC-4WD|).)

Note 2: Almost all systems used today to view Web [content]{.smallcaps}
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](http://www.w3.org/WAI/GL/WCAG20/WD-UNDERSTANDING-WCAG20-20080310/visual-audio-contrast-contrast.html|).

Note 3: If dithering occurs after delivery, then the source color value
is used. For colors that are dithered at the source, the average values
of the colors that are dithered should be used (average R, average G,
and average B).

Note 4: Tools are available that automatically do the calculations when
testing contrast and [flash]{.smallcaps}.

Note 5: A MathML version of relative luminance definition is available
at the WCAG web site.

**Simple Tactile Form:** Tactile form that does not require the
memorization of any spatial or temporal tactile patterns.

Note 1: Simple vibration or switch up/down positions are examples of
simple tactile forms.

Note 2: Braille, tactile Morse code, and vibration patterns are samples
of more complex tactile forms that require memorization of non-trivial
spatial and tactile patterns respectively, and therefore are not Simple
Tactile Forms.

Note 3: Different numbers of tactile buzzes, or different frequency
buzzes would be non-trivial patterns, and would not be simple tactile
forms.

**Text:** Sequence of characters that is [programmatically
determinable]{.smallcaps}, where the sequence is expressing something in
human language.

**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]{.smallcaps} 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.

Advisory Notes to the Access Board

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. This definition should not conflict with these
guidelines

### Proposed Additions to Subpart A but Not Accepted {#proposed-additions-to-subpart-a-but-not-accepted .unnumbered}

#### Exception: Narrow, Delineated Use (no consensus) {#exception-narrow-delineated-use-no-consensus .unnumbered}

*The TEITAC could not reach an agreement on whether this should be added
as a new exception, though there was general agreement that it
identifies an important issue. The Committee agreed to provide this
information to the Access Board for its consideration.*

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.

Advisory Notes to the Access Board

This exception is intended to address situations where conformance to
the technical and performance standards can create access barriers by
loading up a single product with multiple access features. For example,
requiring all calculators to have speech output, large visual display,
enlarged keys, and other access features built-in actually creates
access barriers depending on the functional limitations of individuals
with disabilities.

Despite long discussions and exploration of approaches, (such as
identifying products as \"personal-private\", the concept of a \"product
line\" approach) we have not reached consensus on a viable approach to
addressing the problem.

In favor: Some committee members support creating an exception to
address this problem

In opposition: This is a dangerous and unnecessary exception, which is
likely to be abused. \"Products with narrow delineated use\" is not
clearly defined.

#### Exception: Emergency, Field, and First Response Use (no consensus) {#exception-emergency-field-and-first-response-use-no-consensus .unnumbered}

*The Department of Homeland Security representative proposed a new
exception. The Committee discussed this provision at length and could
not reach consensus on if it was needed. It was felt "fundamental
alteration" should be used instead of creating a new exception. There
was also concern that it could create a loop hole for large groups to
avoid accessibility requirements and possibly reduce the effectiveness
of Section 508.*

This part does not apply to any [electronic and information
technology]{.smallcaps} 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.

Advisory Notes to the Access Board

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

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.

Open Issues:

-   The scope is defined as E&IT used by types of personnel, rather than
    by functions of the E&IT itself. The Committee does not believe that
    this provision should be based on (or create) disadvantaged classes
    of people with disabilities.

-   Several members of the Committee felt that this exception would be
    open to abuse. One example cited was post-911 field units which
    helped people locate their children. This could be designated a
    "first response" function, and people with disabilities would not be
    able to work in these roles.

### Provisions Considered, but Dropped {#provisions-considered-but-dropped .unnumbered}

#### Basic Input/Output System (BIOS) Settings  {#basic-inputoutput-system-bios-settings .unnumbered}

The General subcommittee considered two aspects to the question of
whether a provision was needed to cover access to BIOS settings:

-   BIOS settings that are part of normal operation

-   Events when a user ends up in the Bios unexpectedly because program
    has malfunctioned

It also discussed:

-   Whether requiring users to interact with the BIOS of a system that
    routinely fails is routine operation or failure/maintenance,
    especially if the system provides friendly feedback and instruction.

-   Whether a separate provision is needed because interaction with the
    BIOS is a routine action for developers.

The subcommittee determined that a separate provision is not needed,
because:

-   Access to the BIOS when the computer is up and running is not
    covered by the Closed Functionality Provision. All functionality
    (including setting the BIOS functions) should be operable directly
    or via AT. AT does not work during the initial \"boot\" operations,
    but these functions should be operable from OS after booting, and
    would take effect when the system is restarted.

-   If the system will not boot (and load the operating system), the
    computer or system is broken. This is covered by Subpart A: the
    scope of 508 is for normal operation, so does not apply in this
    situation.

-   If there is an operation during the boot sequence, such as a form to
    enter a password (especially where a BIOS password is required by
    agency), large enough print and an audible cue as to when to type
    the password would allow this to be accessible. Instructions can be
    given to users in advance, so only thing they need to know *when* to
    type the password.

# Source and Harmonization of Recommendations

## Source of Recommendations from the Current 508 and 255

The reorganization of the provisions has made it possible to consolidate
a number of the technical requirements from current Section 508 into a
single provision in the recommendations. An example is 3-A: Color, which
consolidates 1194.21 (i), 1194.22(c) and 1194.25(h).

Provisions from the current Section 508 which have been consolidated, or
dropped are:

-   1194.22 -- Web-based intranet and internet information and
    applications

> \(d\) Readable without a style sheet\
> Style sheets are well-supported. What is needed instead is a provision
> on reading order, which is provided in 3-M: Reading sequence
>
> \(e\) Redundant links for server-side image maps\
> Replace with a new provision on keyboard operability. Requiring
> equivalent text links is one way to make server side image maps
> accessible but there are other ways. New provision proposed below. The
> need behind this one is covered by 3-S:\
> Keyboard Operation.
>
> \(f\) Provide client side image maps\
> Since there is no area than cannot be defined with an available
> geographic shape, this provision essentially prohibits the ues of
> server side image maps. But they can be accessible as long as keyboard
> alternatives are provided. So the need behind this one is covered by
> 3-S: Keyboard Operation.
>
> \(k\) Provide a text-only page\
> A provision on alternatives is not needed because they can always be
> provided via equivalent facilitation. Note that this is still under
> debate in the subcommittee.
>
> \(l\) Use of scripting languages\
> We no longer have technology specific provisions. User interfaces
> implemented in any technology, including scripts, must meet all
> applicable checkpoints. 3-S Keyboard Operation and 3-P: UI Components
> are particularly applicable to UIs created with scripts.
>
> \(m\) Use of applets or plugins\
> We no longer have technology specific provisions. User interfaces
> implemented in any technology, including scripts, must meet all
> applicable checkpoints. 3-S Keyboard Operation and 3-U: AT
> Interoperability are particularly applicable to applets and\
> plug-ins.
>
> \(o\) Skip repetitive links\
> When 3-O: Information and Relationships is met, user agents can
> provide better means for efficient keyboard navigation. In WCAG 2.0,
> meeting the provision that is comparable to 3-O is sufficient to meet
> the WCAG 2.0 provision on bypassing repetitive blocks of content.

+----+--------------------------+------------------+-----------------+
| ** |                          | **Section 508**  | **Section 255** |
| TE |                          |                  |                 |
| IT |                          |                  |                 |
| AC |                          |                  |                 |
| R  |                          |                  |                 |
| EC |                          |                  |                 |
| OM |                          |                  |                 |
| ME |                          |                  |                 |
| ND |                          |                  |                 |
| AT |                          |                  |                 |
| IO |                          |                  |                 |
| NS |                          |                  |                 |
| ** |                          |                  |                 |
+====+==========================+==================+=================+
|    | **Subpart C**            |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | Closed Functionality     | 1194.25(a)       |                 |
| *1 |                          |                  |                 |
| -A |                          |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | Biometric ID             | 1194.25(d)       |                 |
| *1 |                          |                  |                 |
| -B |                          | 1194.26(c)       |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | Pass Through             | 1194.23(j)       | 1193.37         |
| *1 |                          |                  |                 |
| -C |                          |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | Audio information        |                  | 1193.43(d)      |
| *1 |                          |                  |                 |
| -D |                          |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | Visual Information       |                  | 1193.43(a)      |
| *1 |                          |                  |                 |
| -E |                          |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | Color                    | 1194.21(i)       | 1194.41(c)      |
| *1 |                          |                  |                 |
| -F |                          | 1194.25(g)       |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | Text size                |                  | 1193.43(b)      |
| *1 |                          |                  |                 |
| -G |                          |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | Speech Operation         | 1194.23(e)       |                 |
| *1 |                          |                  |                 |
| -H |                          |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | Reflectance Contrast for | 1194.21(j)       |                 |
| *2 | Legends and Passive      |                  |                 |
| .1 | Displays                 | 1194,25(h)       |                 |
| .A |                          |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | Flashing                 | 1194.21(i)       | 1193.43(f)      |
| *2 |                          |                  |                 |
| .1 |                          | 1194.25(j)       |                 |
| .B |                          |                  |                 |
| ** |                          | 1194.25(k)       |                 |
+----+--------------------------+------------------+-----------------+
| *  | Mechanical Controls      | 1194.23(k)       |                 |
| *2 |                          |                  |                 |
| .1 |                          | 1194.26(a)       |                 |
| .C |                          |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | Touch Operated           | 1194.25(c)       |                 |
| *2 |                          |                  |                 |
| .1 |                          | 1194.26(b)       |                 |
| .D |                          |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | Standard Connection      | 1194.26(d)       |                 |
| *2 |                          |                  |                 |
| .1 |                          |                  |                 |
| .E |                          |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | Installed or             | 1194.25(j)       | 1193.41(f)      |
| *2 | Free-Standing Products   |                  |                 |
| .1 |                          |                  |                 |
| .F |                          |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | Magnetic Coupling        | 1194.23(h)       | 1193.43(i)      |
| *2 |                          |                  |                 |
| .2 |                          |                  |                 |
| .A |                          |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | Interference with        | 1194.23(i)       | 1193.43(h)      |
| *2 | Hearing Device           |                  |                 |
| .2 |                          |                  |                 |
| .B |                          |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | Audio Connection         | 1194.25(e)       | 1193.51(b)      |
| *2 |                          |                  |                 |
| .2 |                          |                  | 1193.51(g)      |
| .C |                          |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | Volume                   | 1194.25(f)       | 1193.43(e)      |
| *2 |                          |                  |                 |
| .2 |                          |                  |                 |
| .D |                          |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | Volume (Gain)            | 1194.23(f)       | 1193.43(e)      |
| *2 |                          |                  |                 |
| .2 |                          |                  |                 |
| .E |                          |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | Volume Reset             | 1194.23(g)       |                 |
| *2 |                          |                  |                 |
| .2 |                          |                  |                 |
| .F |                          |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | Color                    | 1194.21(i)       | 1193.41(c)      |
| *3 |                          |                  |                 |
| .A |                          | 1194.22(c)       |                 |
| ** |                          |                  |                 |
|    |                          | 1194.25(h)       |                 |
+----+--------------------------+------------------+-----------------+
| *  | Contrast                 | 1194.21(j)       |                 |
| *3 |                          |                  |                 |
| .B |                          |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | Size, shape, location    |                  |                 |
| *3 |                          |                  |                 |
| .C |                          |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | User Preferences         | 1194.21(g)       |                 |
| *3 |                          |                  |                 |
| .D |                          |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | Color Adjustment         | 1194.21(j)       |                 |
| *3 |                          |                  |                 |
| .E |                          |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | Non-text Objects         | 1194.22(a)       |                 |
| *3 |                          |                  |                 |
| .F |                          |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | Human Language           |                  |                 |
| *3 |                          |                  |                 |
| .G |                          |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | Language of Parts        |                  |                 |
| *3 |                          |                  |                 |
| .H |                          |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | Pausing                  | 1194.21(h)       |                 |
| *3 |                          |                  |                 |
| .I |                          |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | Flashing (Content and    | 1194.21(k)       | 1193.43(f)      |
| *3 | User Interfaces)         |                  |                 |
| .J |                          | 1194.22(j)       |                 |
| ** |                          |                  |                 |
|    |                          | 1194.25(i)       |                 |
+----+--------------------------+------------------+-----------------+
| *  | Consistent               | 1194.21(e)       |                 |
| *3 | Identification           |                  |                 |
| .K |                          |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | Audio Turnoff            | 1194.25(e)       |                 |
| *3 |                          |                  |                 |
| .L |                          |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | Reading Sequence         |  1194.22(d)      |                 |
| *3 |                          |                  |                 |
| .M |                          |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | Link Purpose             |                  |                 |
| *3 |                          |                  |                 |
| .N |                          |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | Information and          | 1194.22(g), (h), |                 |
| *3 | Relationships            | (i), & (n), &    |                 |
| .O |                          | (o)              |                 |
| ** |                          |                  |                 |
|    |                          | 1194.21(l)       |                 |
+----+--------------------------+------------------+-----------------+
| *  | User Interface           | 1194.21(l)       |                 |
| *3 | Components               |                  |                 |
| .P |                          | 1194.22(l)       |                 |
| ** |                          |                  |                 |
|    |                          | 1194.22(n)       |                 |
+----+--------------------------+------------------+-----------------+
| *  | Disruption of Access     | 1194.21(b)       |                 |
| *3 | Features                 |                  |                 |
| .Q |                          |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | Timing                   | 1194.22(p)       | 1193.41(g)      |
| *3 |                          |                  |                 |
| .R |                          | 1194.23(d)       |                 |
| ** |                          |                  |                 |
|    |                          | 1194.25(b)       |                 |
+----+--------------------------+------------------+-----------------+
| *  | Keyboard Operation       | 1194.21(a), (e), |                 |
| *3 |                          | (f), (k), (l) &  |                 |
| .S |                          | (m)              |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| ** | Visual Indication of     |                  |                 |
| 3. | Keyboard Shortcuts       |                  |                 |
| SS |                          |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | Focus Indicator          | 1194.21(c)       |                 |
| *3 |                          |                  |                 |
| .T |                          |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | AT Interoperability      | 1194.21(d), (c), |                 |
| *3 |                          | (f) & (m)        |                 |
| .U |                          |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | Accessibility Services   |                  |                 |
| *3 |                          |                  |                 |
| .V |                          |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| ** | Assistive Technology     |                  |                 |
| 3. |                          |                  |                 |
| VV |                          |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | Multiple Ways            |                  |                 |
| *3 |                          |                  |                 |
| .W |                          |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | Labels or Instructions   |                  |                 |
| *3 |                          |                  |                 |
| .X |                          |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | On Focus                 |                  |                 |
| *3 |                          |                  |                 |
| .Y |                          |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | On Input                 |                  |                 |
| *3 |                          |                  |                 |
| .Z |                          |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| ** | Error Identification     |                  |                 |
| 3. |                          |                  |                 |
| AA |                          |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| ** | Headings and Labels      |                  |                 |
| 3. |                          |                  |                 |
| BB |                          |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | Caption Process          | 1194.24(a)       |                 |
| *4 |                          |                  |                 |
| .A |                          |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | Supplemental Audio       | 1194.24(b)       |                 |
| *4 | Playback (Process?)      |                  |                 |
| .B |                          |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | Access to Caption and    |                  |                 |
| *4 | Video Controls           |                  |                 |
| .C |                          |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | Captions and Transcripts | 1194.24(c)       |                 |
| *5 |                          |                  |                 |
| .A |                          |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | Video Description        | 1194.24(d)       |                 |
| *5 |                          |                  |                 |
| .B |                          |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | Interactive Elements     | 1194.24(d)       |                 |
| *5 |                          |                  |                 |
| .C |                          | 1194..22(b)      |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | Real-Time Text           | 1194.23(b)       | }1193.51(e)     |
| *6 | Reliability &            |                  |                 |
| .A | Interoperability         |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | Voice Terminal Hardware  | 1194.23(a)       | 1193.51(d)      |
| *6 | & Software               |                  |                 |
| .B |                          |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | IVR, Auto-Attendant and  | 1194.23(c)       |                 |
| *6 | Messaging                |                  |                 |
| .C |                          |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | Caller and Status        |                  |                 |
| *6 | Information              |                  |                 |
| .D |                          |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | Video Support            |                  |                 |
| *6 |                          |                  |                 |
| .E |                          |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | Audio clarity for VoIP   |                  |                 |
| *6 |                          |                  |                 |
| .F |                          |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | External Alerting        |                  |                 |
| *6 | Devices                  |                  |                 |
| .G |                          |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | Authoring Tools          |                  |                 |
| *7 |                          |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | Accessible Output        |                  |                 |
| *7 |                          |                  |                 |
| .A |                          |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | Preserve Accessibility   |                  |                 |
| *7 | Information              |                  |                 |
| .B |                          |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | Prompts                  |                  |                 |
| *7 |                          |                  |                 |
| .C |                          |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | Accessible Templates     |                  |                 |
| *7 |                          |                  |                 |
| .D |                          |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | **Subpart D**            |                  |                 |
| *  |                          |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | Information,             |                  |                 |
| *1 | Documentation & Support  |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | Product Documentation    |                  |                 |
| *1 | and Help                 |                  |                 |
| .1 |                          |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | Accessible Documentation | 194.41(a),       | 1193.33(a)(1),  |
| *1 | and Features             | 194.41(b)        | 1193.33(a)(2)   |
| .1 |                          |                  |                 |
| -A |                          |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | Keyboard Shortcuts       |                  |                 |
| *1 |                          |                  |                 |
| .1 |                          |                  |                 |
| -B |                          |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | Support and E&IT related |                  |                 |
| *1 | services                 |                  |                 |
| .2 |                          |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | Support Services         | 1194.41(c)       | 1193.33(a)(3)   |
| *1 |                          |                  |                 |
| .2 |                          |                  |                 |
| -A |                          |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | Manufacturer Contact     |                  |                 |
| *1 |                          |                  |                 |
| .2 |                          |                  |                 |
| -B |                          |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | Training                 |                  |                 |
| *1 |                          |                  |                 |
| .2 |                          |                  |                 |
| -C |                          |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | Relay Services           |                  |                 |
| *2 | Accessibility            |                  |                 |
| .A |                          |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | Video Support            |                  |                 |
| *2 |                          |                  |                 |
| .B |                          |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | Accessibility            |                  |                 |
| *2 | Configuration            |                  |                 |
| .C |                          |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+
| *  | Accessible Content       |                  |                 |
| *2 |                          |                  |                 |
| .D |                          |                  |                 |
| ** |                          |                  |                 |
+----+--------------------------+------------------+-----------------+

## Harmonization of the Recommendations to WCAG 2.0 

This table shows the TEITAC Technical Requirements (from Subpart C) and
the Web Content Accessibility Guidelines 2.0 with which they are
harmonized. All Level A WCAG checkpoints are listed, but Level AA and
higher checkpoints are listed only if there is a corresponding
recommended provision.[^16]

+-----+--------------------------+----+-------------------------+----+
| **  |                          | ** |                         |    |
| TEI |                          | WC |                         |    |
| TAC |                          | AG |                         |    |
| RE  |                          | 2  |                         |    |
| COM |                          | .0 |                         |    |
| MEN |                          | C  |                         |    |
| DAT |                          | HE |                         |    |
| ION |                          | CK |                         |    |
| S** |                          | PO |                         |    |
|     |                          | IN |                         |    |
|     |                          | TS |                         |    |
|     |                          | (a |                         |    |
|     |                          | nd |                         |    |
|     |                          | le |                         |    |
|     |                          | ve |                         |    |
|     |                          | l) |                         |    |
|     |                          | ** |                         |    |
+=====+==========================+====+=========================+====+
| *   | Color                    | *  | Use of Color            | A  |
| *3. |                          | *1 |                         |    |
| A** |                          | .4 |                         |    |
|     |                          | .1 |                         |    |
|     |                          | ** |                         |    |
+-----+--------------------------+----+-------------------------+----+
| *   | Contrast                 | *  | Contrast (Minimum)      | AA |
| *3. |                          | *1 |                         |    |
| B** |                          | .4 |                         |    |
|     |                          | .3 |                         |    |
|     |                          | ** |                         |    |
+-----+--------------------------+----+-------------------------+----+
| *   | Size, shape, location    | *  | Sensory Characteristics | A  |
| *3. |                          | *1 |                         |    |
| C** |                          | .3 |                         |    |
|     |                          | .3 |                         |    |
|     |                          | ** |                         |    |
+-----+--------------------------+----+-------------------------+----+
| *   | User Preferences         |    |                         |    |
| *3. |                          |    |                         |    |
| D** |                          |    |                         |    |
+-----+--------------------------+----+-------------------------+----+
| *   | Color Adjustment         |    |                         |    |
| *3. |                          |    |                         |    |
| E** |                          |    |                         |    |
+-----+--------------------------+----+-------------------------+----+
| *   | Non-text Objects         | *  | Non-text Content        | A  |
| *3. |                          | *1 |                         |    |
| F** |                          | .1 |                         |    |
|     |                          | .1 |                         |    |
|     |                          | ** |                         |    |
+-----+--------------------------+----+-------------------------+----+
| *   | Human Language           | *  | Language of Page        | A  |
| *3. |                          | *3 |                         |    |
| G** |                          | .1 |                         |    |
|     |                          | .1 |                         |    |
|     |                          | ** |                         |    |
+-----+--------------------------+----+-------------------------+----+
| *   | Language of Parts        | *  | Language of Parts       | AA |
| *3. |                          | *3 |                         |    |
| H** |                          | .1 |                         |    |
|     |                          | .2 |                         |    |
|     |                          | ** |                         |    |
+-----+--------------------------+----+-------------------------+----+
| *   | Pausing                  | *  | Pause, Stop, Hide       | A  |
| *3. |                          | *2 |                         |    |
| I** |                          | .2 |                         |    |
|     |                          | .2 |                         |    |
|     |                          | ** |                         |    |
+-----+--------------------------+----+-------------------------+----+
| *   | Flashing (Content and    | *  | Three Flashes or Below  | A  |
| *3. | User Interfaces)         | *2 | Threshold               |    |
| J** |                          | .3 |                         |    |
|     |                          | .1 |                         |    |
|     |                          | ** |                         |    |
+-----+--------------------------+----+-------------------------+----+
| *   | Consistent               | *  | Consistent              | AA |
| *3. | Identification           | *3 | Identification          |    |
| K** |                          | .2 |                         |    |
|     |                          | .4 |                         |    |
|     |                          | ** |                         |    |
+-----+--------------------------+----+-------------------------+----+
| *   | Audio Turnoff            | *  | Audio Control           | A  |
| *3. |                          | *1 |                         |    |
| L** |                          | .4 |                         |    |
|     |                          | .2 |                         |    |
|     |                          | ** |                         |    |
+-----+--------------------------+----+-------------------------+----+
| *   | Reading Sequence         | *  | Meaningful Sequence     | A  |
| *3. |                          | *1 |                         |    |
| M** |                          | .3 |                         |    |
|     |                          | .2 |                         |    |
|     |                          | ** |                         |    |
+-----+--------------------------+----+-------------------------+----+
| *   | Link Purpose             | *  | Link Purpose (In        | A  |
| *3. |                          | *2 | Context)                |    |
| N** |                          | .4 |                         |    |
|     |                          | .4 |                         |    |
|     |                          | ** |                         |    |
+-----+--------------------------+----+-------------------------+----+
| *   | Information and          | *  | Info and Relationships  | A  |
| *3. | Relationships            | *1 |                         |    |
| O** |                          | .3 |                         |    |
|     |                          | .1 |                         |    |
|     |                          | ** |                         |    |
+-----+--------------------------+----+-------------------------+----+
| *   | User Interface           | *  | Name, Role, Value       | A  |
| *3. | Components               | *4 |                         |    |
| P** |                          | .1 |                         |    |
|     |                          | .2 |                         |    |
|     |                          | ** |                         |    |
+-----+--------------------------+----+-------------------------+----+
| *   | Disruption of Access     |    |                         |    |
| *3. | Features                 |    |                         |    |
| Q** |                          |    |                         |    |
+-----+--------------------------+----+-------------------------+----+
| *   | Timing                   | *  | Timing Adjustable       | A  |
| *3. |                          | *2 |                         |    |
| R** |                          | .2 |                         |    |
|     |                          | .1 |                         |    |
|     |                          | ** |                         |    |
+-----+--------------------------+----+-------------------------+----+
| *   | Keyboard Operation       | *  | Keyboard                | A  |
| *3. |                          | *2 |                         |    |
| S** |                          | .1 | No Keyboard Trap        | A  |
|     |                          | .1 |                         |    |
|     |                          | ** |                         |    |
|     |                          |    |                         |    |
|     |                          | *  |                         |    |
|     |                          | *2 |                         |    |
|     |                          | .1 |                         |    |
|     |                          | .2 |                         |    |
|     |                          | ** |                         |    |
+-----+--------------------------+----+-------------------------+----+
| **  | Visual Indication of     |    |                         |    |
| 3.S | Keyboard Shortcuts       |    |                         |    |
| S** |                          |    |                         |    |
+-----+--------------------------+----+-------------------------+----+
| *   | Focus Indicator          | *  | Focus Visible           | AA |
| *3. |                          | *2 |                         |    |
| T** |                          | .4 |                         |    |
|     |                          | .7 |                         |    |
|     |                          | ** |                         |    |
+-----+--------------------------+----+-------------------------+----+
| *   | AT Interoperability      | *  | Name, Role, Value       | A  |
| *3. |                          | *4 |                         |    |
| U** |                          | .1 |                         |    |
|     |                          | .2 |                         |    |
|     |                          | ** |                         |    |
+-----+--------------------------+----+-------------------------+----+
| *   | Accessibility Services   |    |                         |    |
| *3. |                          |    |                         |    |
| V** |                          |    |                         |    |
+-----+--------------------------+----+-------------------------+----+
| *   | Assistive Technology     |    |                         |    |
| *3. |                          |    |                         |    |
| V   |                          |    |                         |    |
| V** |                          |    |                         |    |
+-----+--------------------------+----+-------------------------+----+
| *   | Multiple Ways            | *  | Multiple Ways           | AA |
| *3. |                          | *2 |                         |    |
| W** |                          | .4 |                         |    |
|     |                          | .5 |                         |    |
|     |                          | ** |                         |    |
+-----+--------------------------+----+-------------------------+----+
| *   | Labels or Instructions   | *  | Labels or Instructions  | A  |
| *3. |                          | *3 |                         |    |
| X** |                          | .3 |                         |    |
|     |                          | .2 |                         |    |
|     |                          | ** |                         |    |
+-----+--------------------------+----+-------------------------+----+
| *   | On Focus                 | *  | On Focus                | A  |
| *3. |                          | *3 |                         |    |
| Y** |                          | .2 |                         |    |
|     |                          | .1 |                         |    |
|     |                          | ** |                         |    |
+-----+--------------------------+----+-------------------------+----+
| *   | On Input                 | *  | On Input                | A  |
| *3. |                          | *3 |                         |    |
| Z** |                          | .2 |                         |    |
|     |                          | .2 |                         |    |
|     |                          | ** |                         |    |
+-----+--------------------------+----+-------------------------+----+
| **  | Error Identification     | *  | Error Identification    | A  |
| 3.A |                          | *3 |                         |    |
| A** |                          | .3 |                         |    |
|     |                          | .1 |                         |    |
|     |                          | ** |                         |    |
+-----+--------------------------+----+-------------------------+----+
| **  | Headings and Labels      | *  | Labels Descriptive      | AA |
| 3.B |                          | *2 |                         |    |
| B** |                          | .4 |                         |    |
|     |                          | .5 |                         |    |
|     |                          | ** |                         |    |
+-----+--------------------------+----+-------------------------+----+
| *   | Captions and Transcripts | ** | Audio-only and          | A  |
| *5. |                          | 1. | Video-only              |    |
| A** |                          | 2. | (Prerecorded) (A)       | A  |
|     |                          | 1\ |                         |    |
|     |                          | ** | Captions (Prerecorded)  | AA |
|     |                          |    | (A)                     |    |
|     |                          | *  |                         | A  |
|     |                          | *1 | Captions (Live) (AA)    | AA |
|     |                          | .2 |                         |    |
|     |                          | .2 | Live audio-only (AAA)   |    |
|     |                          | ** |                         |    |
|     |                          |    |                         |    |
|     |                          | *  |                         |    |
|     |                          | *1 |                         |    |
|     |                          | .2 |                         |    |
|     |                          | .4 |                         |    |
|     |                          | ** |                         |    |
|     |                          |    |                         |    |
|     |                          | *  |                         |    |
|     |                          | *1 |                         |    |
|     |                          | .2 |                         |    |
|     |                          | .9 |                         |    |
|     |                          | ** |                         |    |
+-----+--------------------------+----+-------------------------+----+
| *   | Video Description        | ** | Audio-only and          | A  |
| *5. |                          | 1. | Video-only              |    |
| B** |                          | 2. | (Prerecorded)           |    |
|     |                          | 1\ |                         |    |
|     |                          | ** | Audio Description or    |    |
|     |                          |    | Full Text Alternative   |    |
|     |                          | *  |                         |    |
|     |                          | *1 |                         |    |
|     |                          | .2 |                         |    |
|     |                          | .3 |                         |    |
|     |                          | ** |                         |    |
+-----+--------------------------+----+-------------------------+----+
|     | Advisory Note            | *  | Parsing                 | A  |
|     |                          | *4 |                         |    |
|     |                          | .1 |                         |    |
|     |                          | .1 |                         |    |
|     |                          | ** |                         |    |
+-----+--------------------------+----+-------------------------+----+
|     |                          | *  | Bypass Blocks           | A  |
|     |                          | *2 |                         |    |
|     |                          | .4 |                         |    |
|     |                          | .1 |                         |    |
|     |                          | ** |                         |    |
+-----+--------------------------+----+-------------------------+----+
|     |                          | *  | Page Titled             | A  |
|     |                          | *2 |                         |    |
|     |                          | .4 |                         |    |
|     |                          | .2 |                         |    |
|     |                          | ** |                         |    |
+-----+--------------------------+----+-------------------------+----+
|     |                          | *  | Focus Order             | A  |
|     |                          | *2 |                         |    |
|     |                          | .4 |                         |    |
|     |                          | .3 |                         |    |
|     |                          | ** |                         |    |
+-----+--------------------------+----+-------------------------+----+
|     |                          | *  | No Keyboard Trap        | A  |
|     |                          | *2 |                         |    |
|     |                          | .1 |                         |    |
|     |                          | .2 |                         |    |
|     |                          | ** |                         |    |
+-----+--------------------------+----+-------------------------+----+

## Identification of Provisions Supporting Functional Performance Criteria

This section uses the metadata for "Disabilities" to identify the
functional performance criteria related to each of the technical
requirements.

**Table 1: Mapping of disabilities to functional performance criteria**

These mappings are used in Table 2 to connect disabilities metadata to
the provisions

<table style="width:100%;">
<colgroup>
<col style="width: 34%" />
<col style="width: 7%" />
<col style="width: 7%" />
<col style="width: 7%" />
<col style="width: 7%" />
<col style="width: 7%" />
<col style="width: 7%" />
<col style="width: 7%" />
<col style="width: 7%" />
<col style="width: 7%" />
</colgroup>
<thead>
<tr class="header">
<th><p><strong>FPC </strong></p>
<p><strong> Disabilities</strong></p></th>
<th><strong>A</strong></th>
<th><strong>B</strong></th>
<th><strong>C</strong></th>
<th><strong>D</strong></th>
<th><strong>E</strong></th>
<th><strong>G</strong></th>
<th><strong>H</strong></th>
<th><strong>I</strong></th>
<th><strong>J</strong></th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td>Blindness</td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td>Low Vision</td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td>Color deficiency</td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td>Deafness</td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td>Hard of hearing</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td>Deaf-blindness</td>
<td>X</td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td>Other hearing/vision loss</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td>Mobility</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td>X</td>
<td></td>
</tr>
<tr class="odd">
<td>Dexterity</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td>X</td>
<td></td>
</tr>
<tr class="even">
<td>Speech</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td>Cognitive, language, learning</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
</tr>
<tr class="even">
<td></td>
<td colspan="9"><p>Functional Performance Criteria</p>
<p>A – Without Vision</p>
<p>B – With Limited Vision</p>
<p>C – With Color Vision Deficits</p>
<p>D – Without Hearing</p>
<p>E – With Limited Hearing (no consensus)</p>
<p>G – Without Speech</p>
<p>H – With Limited Reach, Strength, or Manipulation (no consensus)</p>
<p>I – Without Physical Contact (no consensus)</p>
<p>J – With Cognitive, Language and Learning Limitations</p></td>
</tr>
</tbody>
</table>

**Table 2: Mappings of Provisions to Functional Performance Criteria**

In this chart, an "X" indicates the mapping from the disabilities listed
in the metadata. An "a" indicates suggestions for additions from
Committee members.

> Key: Functional Performance Criteria
>
> A -- Without Vision
>
> B -- With Limited Vision
>
> C -- With Color Vision Deficits
>
> D -- Without Hearing
>
> E -- With Limited Hearing (no consensus)
>
> G -- Without Speech
>
> H -- With Limited Reach, Strength, or Manipulation (no consensus)
>
> I -- Without Physical Contact (no consensus)
>
> J -- With Cognitive, Language and Learning Limitations

<table style="width:100%;">
<colgroup>
<col style="width: 9%" />
<col style="width: 26%" />
<col style="width: 7%" />
<col style="width: 7%" />
<col style="width: 7%" />
<col style="width: 7%" />
<col style="width: 7%" />
<col style="width: 7%" />
<col style="width: 7%" />
<col style="width: 7%" />
<col style="width: 7%" />
</colgroup>
<thead>
<tr class="header">
<th></th>
<th><p><strong>FPC </strong></p>
<p><strong>Provision</strong></p></th>
<th><strong>A</strong></th>
<th><strong>B</strong></th>
<th><strong>C</strong></th>
<th><strong>D</strong></th>
<th><strong>E</strong></th>
<th><strong>G</strong></th>
<th><strong>H</strong></th>
<th><strong>I</strong></th>
<th><strong>J</strong></th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td><strong>1-A</strong></td>
<td>Closed Functionality</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
</tr>
<tr class="even">
<td><strong>1-B</strong></td>
<td>Biometric ID</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
</tr>
<tr class="odd">
<td><strong>1-C</strong></td>
<td>Pass Through</td>
<td>X</td>
<td>X</td>
<td></td>
<td>X</td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td>X</td>
</tr>
<tr class="even">
<td><strong>1-D</strong></td>
<td>Audio information</td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td>a</td>
</tr>
<tr class="odd">
<td><strong>1-E</strong></td>
<td>Visual Information</td>
<td>X</td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>a</td>
</tr>
<tr class="even">
<td><strong>1-F</strong></td>
<td>Color</td>
<td>X</td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>a</td>
</tr>
<tr class="odd">
<td><strong>1-G</strong></td>
<td>Text size</td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>a</td>
</tr>
<tr class="even">
<td><strong>1-H</strong></td>
<td>Speech Operation</td>
<td></td>
<td></td>
<td></td>
<td>a</td>
<td>a</td>
<td>X</td>
<td></td>
<td></td>
<td>a</td>
</tr>
<tr class="odd">
<td><strong>2.1.A</strong></td>
<td>Reflectance Contrast for Legends and Passive Displays</td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td><strong>2.1.B</strong></td>
<td>Flashing</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td><strong>2.1.C</strong></td>
<td>Mechanical Controls</td>
<td>X</td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td>X</td>
<td>a</td>
</tr>
<tr class="even">
<td><strong>2.1.D</strong></td>
<td>Touch Operated</td>
<td>X</td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td>X</td>
<td>a</td>
</tr>
<tr class="odd">
<td><strong>2.1.E</strong></td>
<td>Standard Connection</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
</tr>
<tr class="even">
<td><strong>2.1.F</strong></td>
<td>Installed or Free-Standing Products</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td>X</td>
<td></td>
</tr>
<tr class="odd">
<td><strong>2.2.A</strong></td>
<td>Magnetic Coupling</td>
<td></td>
<td></td>
<td></td>
<td>a</td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td><strong>2.2.B</strong></td>
<td>Interference with Hearing Device</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td><strong>2.2.C</strong></td>
<td>Audio Connection</td>
<td></td>
<td></td>
<td></td>
<td>a</td>
<td>X</td>
<td></td>
<td>a</td>
<td>a</td>
<td></td>
</tr>
<tr class="even">
<td><strong>2.2.D</strong></td>
<td>Volume</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td>a</td>
</tr>
<tr class="odd">
<td><strong>2.2.E</strong></td>
<td>Volume (Gain)</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td>a</td>
</tr>
<tr class="even">
<td><strong>2.2.F</strong></td>
<td>Volume Reset</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td><strong>3.A</strong></td>
<td>Color</td>
<td>X</td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>a</td>
</tr>
<tr class="even">
<td><strong>3.B</strong></td>
<td>Contrast</td>
<td></td>
<td>X</td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>a</td>
</tr>
<tr class="odd">
<td><strong>3.C</strong></td>
<td>Size, shape, location</td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>a</td>
</tr>
<tr class="even">
<td><strong>3.D</strong></td>
<td>User Preferences</td>
<td></td>
<td>X</td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>a</td>
</tr>
<tr class="odd">
<td><strong>3.E</strong></td>
<td>Color Adjustment</td>
<td></td>
<td>X</td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td><strong>3.F</strong></td>
<td>Non-text Objects</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
</tr>
<tr class="odd">
<td><strong>3.G</strong></td>
<td>Human Language</td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>a</td>
</tr>
<tr class="even">
<td><strong>3.H</strong></td>
<td>Language of Parts</td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>a</td>
</tr>
<tr class="odd">
<td><strong>3.I</strong></td>
<td>Pausing</td>
<td>X</td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
</tr>
<tr class="even">
<td><strong>3.J</strong></td>
<td>Flashing</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td><strong>3.K</strong></td>
<td>Consistent Identification</td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
</tr>
<tr class="even">
<td><strong>3.L</strong></td>
<td>Audio Turnoff</td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
</tr>
<tr class="odd">
<td><strong>3.M</strong></td>
<td>Reading Sequence</td>
<td>X</td>
<td>a</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>a</td>
<td>a</td>
<td>X</td>
</tr>
<tr class="even">
<td><strong>3.N</strong></td>
<td>Link Purpose</td>
<td>X</td>
<td>a</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
</tr>
<tr class="odd">
<td><strong>3.O</strong></td>
<td>Information and Relationships</td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
</tr>
<tr class="even">
<td><strong>3.P</strong></td>
<td>User Interface Components</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
</tr>
<tr class="odd">
<td><strong>3.Q</strong></td>
<td>Disruption of Access Features</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
</tr>
<tr class="even">
<td><strong>3.R</strong></td>
<td>Timing</td>
<td>X</td>
<td>a</td>
<td></td>
<td>a</td>
<td></td>
<td></td>
<td>X</td>
<td>X</td>
<td>X</td>
</tr>
<tr class="odd">
<td><strong>3.S</strong></td>
<td>Keyboard Operation</td>
<td>X</td>
<td>a</td>
<td></td>
<td></td>
<td></td>
<td>a</td>
<td>X</td>
<td>X</td>
<td></td>
</tr>
<tr class="even">
<td><strong>3.SS</strong></td>
<td>Visual Indication of Keyboard Shortcuts</td>
<td>X</td>
<td>a</td>
<td></td>
<td></td>
<td></td>
<td>a</td>
<td>X</td>
<td>X</td>
<td>a</td>
</tr>
<tr class="odd">
<td><strong>3.T</strong></td>
<td>Focus Indicator</td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td>X</td>
<td></td>
</tr>
<tr class="even">
<td><strong>3.U</strong></td>
<td>AT Interoperability</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
</tr>
<tr class="odd">
<td><strong>3.V</strong></td>
<td>Accessibility Services</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
</tr>
<tr class="even">
<td><strong>3.VV</strong></td>
<td>Assistive Technology</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
</tr>
<tr class="odd">
<td><strong>3.W</strong></td>
<td>Multiple Ways</td>
<td>X</td>
<td>a</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>a</td>
<td>a</td>
<td>X</td>
</tr>
<tr class="even">
<td><strong>3.X</strong></td>
<td>Labels or Instructions</td>
<td>X</td>
<td>a</td>
<td>a</td>
<td></td>
<td></td>
<td>a</td>
<td>a</td>
<td>a</td>
<td>X</td>
</tr>
<tr class="odd">
<td><strong>3.Y</strong></td>
<td>On Focus</td>
<td>X</td>
<td>a</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
</tr>
<tr class="even">
<td><strong>3.Z</strong></td>
<td>On Input</td>
<td>X</td>
<td>a</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
</tr>
<tr class="odd">
<td><strong>3.AA</strong></td>
<td>Error Identification</td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
</tr>
<tr class="even">
<td><strong>3.BB</strong></td>
<td>Headings and Labels</td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
</tr>
<tr class="odd">
<td><strong>4.A</strong></td>
<td>Caption Process</td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td>X</td>
</tr>
<tr class="even">
<td><strong>4.B</strong></td>
<td>Supplemental Audio Playback (Process?)</td>
<td>X</td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
</tr>
<tr class="odd">
<td><strong>4.C</strong></td>
<td>Access to Caption and Video Controls</td>
<td>X</td>
<td>X</td>
<td></td>
<td>X</td>
<td>X</td>
<td></td>
<td>X</td>
<td>X</td>
<td>X</td>
</tr>
<tr class="even">
<td><strong>5.A</strong></td>
<td>Captions and Transcripts</td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td>X</td>
</tr>
<tr class="odd">
<td><strong>5.B</strong></td>
<td>Video Description</td>
<td>X</td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
</tr>
<tr class="even">
<td><strong>5.C</strong></td>
<td>Interactive Elements</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
</tr>
<tr class="odd">
<td><strong>6.A</strong></td>
<td>Real-Time Text Reliability &amp; Interoperability</td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td>a</td>
<td>X</td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td><strong>6.B</strong></td>
<td>Voice Terminal Hardware &amp; Software</td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td>a</td>
<td>X</td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td><strong>6.C</strong></td>
<td>IVR, Auto-Attendant and Messaging</td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td>X</td>
</tr>
<tr class="even">
<td><strong>6.D</strong></td>
<td>Caller and Status info</td>
<td>X</td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td>a</td>
<td></td>
<td></td>
<td>a</td>
</tr>
<tr class="odd">
<td><strong>6.E</strong></td>
<td>Video Support</td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>a</td>
</tr>
<tr class="even">
<td><strong>6.F</strong></td>
<td>Audio Clarity for VoIP</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td><strong>6.G</strong></td>
<td>External alerting devices</td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td>a</td>
<td></td>
<td></td>
<td></td>
<td>a</td>
</tr>
<tr class="even">
<td><strong>7.A</strong></td>
<td>Accessible Output</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
</tr>
<tr class="odd">
<td><strong>7.B</strong></td>
<td>Preserve Accessibility Information</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
</tr>
<tr class="even">
<td><strong>7.C</strong></td>
<td>Prompts</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
</tr>
<tr class="odd">
<td><strong>7.D</strong></td>
<td>Accessible Templates</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
</tr>
<tr class="even">
<td><strong>D:1.1-A</strong></td>
<td>Accessible Documentation and Features</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
</tr>
<tr class="odd">
<td><strong>D: 1.1-B</strong></td>
<td>Keyboard Shortcuts</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
</tr>
<tr class="even">
<td><strong>D: 1.2-A</strong></td>
<td>Support Services</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
</tr>
<tr class="odd">
<td><strong>D: 1.2-B</strong></td>
<td>Manufacturer Contact</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
</tr>
<tr class="even">
<td><strong>D: 1.2-C</strong></td>
<td>Training</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
</tr>
<tr class="odd">
<td><strong>D: 2.A</strong></td>
<td>Relay Services Accessibility</td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td>a</td>
<td>X</td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td><strong>D: 2.B</strong></td>
<td>Video Support</td>
<td></td>
<td></td>
<td></td>
<td>X</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>a</td>
</tr>
<tr class="odd">
<td><strong>D: 2.C</strong></td>
<td>Accessibility Configuration</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
</tr>
<tr class="even">
<td><strong>D: 2.D</strong></td>
<td>Accessible Content</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
</tr>
</tbody>
</table>

# Annexes

## TEITAC Organizational Members List

Andrew Kirkpatrick Adobe Systems, Inc.

Greg Pisocky Adobe Systems, Inc.

Thomas Wlodkowski America Online (AOL)

Donald Evans America Online (AOL)

Jenifer Simpson American Association of People with Disabilities

Andrew Imparato American Association of People with Disabilities

Melanie Brunson American Council of the Blind

Marlaina Lieberg American Council of the Blind

Bradley Hodges American Foundation for the Blind

Paul W. Schroeder American Foundation for the Blind

Dave Michael Apple, Inc.

Mary Beth Janes Apple, Inc.

Randy Marsden Assistive Technology Industry Association

Jessica Brodey Assistive Technology Industry Association

Deborah V. Buck Association of Technology Act Programs

Brenda Dawes Association of Technology Act Programs

Ellen Blackler AT&T

Susan P. Mazrui AT&T

Paul R. Michaelis Avaya, Inc.

Aubrey Woolley Canon USA, Inc.

Karen Peltz Strauss Communication Service for the Deaf

K. Dane Snowden CTIA - The Wireless Association

Matthew Gerst CTIA - The Wireless Association

Robert C. Nerhood Dell, Inc.

Linda Rodden Dell, Inc.

Jennifer Dexter Easter Seals

Inmaculada Placencia Porrero European Commission

Martina Sindelar European Commission

Brenda Battat Hearing Loss Association of America

Katie Lee Hearing Loss Association of America

Bruce Maguire Human Rights and Equal Opportunity Commission (Australia)

Andi Snow-Weaver IBM

Phill Jenkins IBM

Jim Tobias Inclusive Technologies

Mary Frances Laughton Industry Canada

Chuck Letourneau Industry Canada

Rex C. Lint Information Technology Association of America

Olga Grkavac Information Technology Association of America

Ken J. Salaets Information Technology Industry Council

Michael Takemura Information Technology Industry Council

Hajime Yamada Japanese Standards Association

Shuji Morii Japanese Standards Association

Laura Ruby Microsoft Corporation

Sean Hayes Microsoft Corporation

Diane C. Golden National Association of State Chief Information Officers

Eric B. Perkins National Association of State Chief Information Officers

Jared Smith National Center on Disability and Access to Education

Cyndi Rowland National Center on Disability and Access to Education

Curtis Chong National Federation of the Blind

James McCarthy National Federation of the Blind

Debbie Cook National Network of Disability and Business Technical
Assistance Centers

Randy Dipner National Network of Disability and Business Technical
Assistance Centers

Anthony Jasionowski Panasonic Corporation of North America

Paul G. Schomburg Panasonic Corporation of North America

Leslie Hall Paralyzed Veterans of America

Kate Walser SRA International, Inc.

Michael Weinstein SRA International, Inc.

Peter Korn Sun Microsystems, Inc.

Michele Budris Sun Microsystems, Inc.

Mary Brooner Telecommunications Industry Association

David Dzumba Telecommunications Industry Association

Michael Paciello The Paciello Group, LLP

Brian Landrigan The Paciello Group, LLP

Gregg C. Vanderheiden Trace Research and Development Center

Gottfried Zimmermann Trace Research and Development Center

Whitney Quesenbery Usability Professionals' Association

Sarah J. Swierenga Usability Professionals' Association

Lisa Fairhall U.S. Access Board

Timothy P. Creagan U.S. Access Board

David Baquis U.S. Access Board

Bruce Bailey U.S. Access Board

Aromie Noe U.S. Access Board

David Capozzi U.S. Access Board

James J. Elekes, M.Ed, MPA, CPM Access Board liaison

Allen Hoffman U.S. Department of Homeland Security

William Peterson U.S. Department of Homeland Security

Robert Baker U.S. Social Security Administration

Mike Fratkin U.S. Social Security Administration

Larry Goldberg WGBH National Center for Accessible Media

Geoff Freed WGBH National Center for Accessible Media

Judy Brewer World Wide Web Consortium/Web Accessibility Initiative

James M. Allan World Wide Web Consortium/Web Accessibility Initiative

## Related Federal Legislation Protecting the Rights of Individuals with Disabilities

Sections 508 and 255 are not the only Federal legislation intended to
ensure access to ICT by individuals with disabilities. A number of
Federal laws preceded this legislation, setting the stage for a
barrier-free information age. Even where there is overlap with Sections
255 or 508, other Federal legislation establishing protections for
people with disabilities remain in full force. The Committee could not
reach consensus on if this additional information should be included in
the report as there was concern it could cause confusion on how Sections
255 and 508 should be implemented. There was also concern by one member
that it would imply agreement with each of these statues. While the
Committee did take these statues into consideration, there was no
specific discussion on each of them.

**Rehabilitation Act of 1973** - The Rehabilitation Act of 1973,
discussed briefly above, was the first piece of legislation designed to
ensure that Federal agencies, its contractors, and its financially
assisted programs and activities would provide access to their employees
and beneficiaries. Section 501, for example, requires Federal employers
to accommodate the individual access needs of their employees with
disabilities when necessary for those employees to carry out the
functions of their jobs, unless providing those accommodations would
impose an undue hardship. Section 503 imposes similar access obligations
on federal contractors, and Section 504 requires the provision of
reasonable accommodations when needed to enable individuals with
disabilities to participate in or benefit from federally assisted
programs. Section 508's requirements for accessible electronic and
information technology facilitates compliance with the mandates of these
various sections by providing federal agencies with some of the tools
needed to provide these accommodations. Section 508 goes further,
however, requiring federal departments or agencies that develop,
procure, maintain, or use electronic and information technology to make
sure that all such technology provides comparable access to and use of
information and data, regardless of who may use it. Similarly, the
availability of accessible information and data required under section
508 will assist Federal agencies charged with providing information to
the public under Section 504 of the Rehabilitation Act.

**Telecommunications for the Disabled Act** - The first federal law to
specifically address the need for access to telecommunications by
individuals with disabilities was the Telecommunications for the
Disabled Act of 1982 (TDA). Pub. L. No. 97-410, codified as amended at
47 U.S.C. §610 (1988). TDA directed that all "essential" telephones,
both inside and outside the Federal government, be hearing aid
compatible telephones and permitted telephone companies in the states to
continue offering specialized customer premises equipment to individuals
with disabilities at reasonable prices subsidized by their telephone
services. In the TDA, Congress, already envisioning the dawn of major
technological changes, proposed a new national policy to ensure access
for people with disabilities as these changes occurred. This policy was
announced in the House Report accompanying the bill: \"\[M\]aking the
benefits of the technological revolution in telecommunications available
to all Americans, including those with disabilities, should be a
priority of our national telecommunications policy.\" H. Rep. No. 888,
97th Cong., 2d Sess. 5 (1982). Setting the stage for Section 508 as well
as other pieces of Federal legislation, the legislative history of the
TDA revealed a new understanding by Congress that the costs to society
of denying such access, by \"depriv\[ing\] many individuals of the
opportunity to have gainful employment\" and \"impair\[ing\] . . . the
quality of life for disabled Americans\" far exceeded the costs of
ensuring such access. Id. at 4.

**Hearing Aid Compatibility Act** - The Telecommunications for the
Disabled Act of 1982 was followed by two pieces of legislation in 1988
that again addressed the telecommunications access needs of individuals
who are deaf and hard of hearing. The first of these, the Hearing Aid
Compatibility Act, Pub. L. No. 100-394, codified at 47 U.S.C. §610
(1988), created a mandate for nearly all telephones made or imported
into the United States after August 16, 1989, to be hearing aid
compatible. Various FCC proceedings that followed produced rules that
are intended to ensure nearly ubiquitous access to landline and wireless
telephones by hearing aid wearers early in the twenty-first century.

**Telecommunications Accessibility Enhancement Act** - The second law
enacted in 1988 was the Telecommunications Accessibility Enhancement Act
(TAEA), Pub. L. No. 100-542, codified at 40 U.S.C. §762 (1988). TAEA
created a Federal relay system for calls to, from, and within the
Federal government. It also directed Congressional members to acquire
TTYs for their offices, created a Federal directory of TTY numbers, and
directed the FCC to complete an inquiry into the establishment of a
nationwide interstate telecommunications relay system. TAEA's provisions
bear a relationship to the present Section 508 in that it was designed
to specifically reduce technological barriers for Federal employees.
Toward this end, the Senate's Report on TAEA explained \"\[i\]t has long
been recognized that all employers should take whatever steps possible
to fully integrate persons with physical impairments into the work
force.\" S. Rep. No. 464, 100th Cong., 2d Sess. 2 (1988). Again,
Congress concluded that the costs of installing accessible equipment and
providing accessible telecommunications services were outweighed by the
overriding benefits that such access created.

**Americans with Disabilities Act** -The Americans with Disabilities Act
(ADA), Pub. L. No. 101-336, codified at 42 U.S.C. §12101, et. seq., was
passed in 1990. This landmark legislation created new and comprehensive
civil right protections for individuals with disabilities in the private
sector. Its provisions under Title IV mandate the provision of
round-the-clock nationwide telecommunications relay services, designed
to make our nation's telecommunications networks more accessible to
people who are deaf, hard of hearing, or speech impaired. Other parts of
the ADA led to requirements for certain forms of telecommunications
access, including requirements for hearing aid compatibility, volume
control, and TTYs. They also provide standards on reach ranges, for
access to fixed equipment control consoles and operable parts.

**Television Decoder Circuitry Act of 1990** - The Television Decoder
Circuitry Act, 47 U.S.C. §§303(u); 330(b), was passed in 1990. It
requires all television receivers with picture screens 13 inches or
larger to contain built-in decoder circuitry designed to display closed
captioned television transmissions. The FCC has also applied this
mandate to computers equipped with television circuitry that are sold
together with monitors that have viewable pictures at least thirteen
inches in diameter, digital television sets that have screens measuring
7.8 inches vertically (approximately the equivalent of a 13-inch
diagonal analog screen), and stand-alone DTV tuners and set top boxes,
regardless of the screen size with which these are marketed or sold. The
Act also contains a provision directing the FCC to ensure that closed
captioning services continue to be available to consumers as new video
technology is developed.

**Section 713 of the Communications Act** **-** Section 713 of the
Communications Act, added by the Telecommunications Act of 1996, 47
U.S.C. §613, requires video programming distributors to make their
television programming accessible through the provision of closed
captioning. In 1998, the FCC released a detailed schedule of captioning
requirements that already require closed captioning on 100 percent of
new, nonexempt English video programming. Other rules are in place for
older and Spanish language programming. Exemptions are available for
certain defined situations, for example, when the programming is
primarily textual or primarily non-vocal music, and when compliance with
the rule would result in an "undue burden," meaning significant
difficulty or expense.

**Help America Vote Act** -The Help America Vote Act (HAVA, Pub.L.
107-252) was passed in 2002. The relevant part of the law is \"Subtitle
A, Section 301 Voting System Standards (3) Accessibility for Individuals
with Disabilities. The voting system shall: (A) be accessible for
individuals with disabilities, including non-visual accessibility for
the blind and visually impaired, in a manner that provides the same
opportunity for access and participation (including privacy and
independence) as for other voters.\"

## Charter

1\. PURPOSE: This charter establishes the "Telecommunications and
Electronic and Information Technology Advisory Committee" (Committee)
for the Architectural and Transportation Barriers Compliance Board
(Access Board) in accordance with the Federal Advisory Committee Act
(FACA), 5 U.S.C. App. 2, and the administrative guidelines issued by the
General Services Administration\'s Committee Management Secretariat, 41
C.F.R. Part 101 6.

2\. AUTHORITY: The establishment of the Committee is in the public
interest and supports the Access Board in performing its duties and
responsibilities under the Telecommunications Act of 1996 (47 U.S.C. §
255) and the Rehabilitation Act Amendments of 1998 (29 U.S.C. § 794
(d)).

3\. SPONSOR AND OFFICE SUPPORT: The Committee shall report to the Access
Board as its sponsor. Support services shall be provided or arranged by
the Access Board.

4\. SCOPE AND OBJECTIVES: The Committee shall advise the Access Board on
issues related to revising and updating accessibility guidelines for
telecommunications equipment and customer premises equipment and
accessibility standards for electronic and information technology. The
Committee shall act solely in an advisory capacity to the Access Board
and shall neither exercise any program management responsibility nor
make decisions directly affecting the matters on which it provides
advice.

5\. DUTIES AND FUNCTIONS: Consistent with the scope and objectives
described in paragraph 4 of this charter, the Committee is authorized to
make recommendations to the Access Board on:

\(a\) types of products to be covered;

\(b\) barriers to the use of such products by persons with disabilities;

\(c\) solutions to such barriers, if known, and research on such
barriers;

\(d\) harmonization with international standards efforts in this area;
and

\(e\) contents of the revised and updated guidelines and standards.

6\. MEMBERSHIP: The membership will be balanced in terms of points of
view represented, including Federal agencies; the telecommunications and
electronic and information technology industry, including manufacturers;
organizations representing the access needs of individuals with
disabilities; representatives from other countries and international
standards setting organizations; and other organizations affected by the
accessibility guidelines and standards. Representatives of each of these
interests shall be selected by the Chairperson of the Access Board and
appointed as Committee members for the duration of the Committee's
existence.

7\. SUBCOMMITTEES: The Committee may form subcommittees for any purpose
consistent with this charter. The subcommittees shall report to the
Committee.

8\. CHAIRPERSON: The Chairperson of the Committee shall be appointed by
the Chairperson of the Access Board. The Chairperson of any
subcommittees shall be appointed by the Chairperson of the Committee.

9\. MEETINGS: Meetings shall be held as necessary at the call of the
Chairperson of the Committee, with the approval of the designated
Federal official. Meetings shall be open to the public and timely notice
of each meeting shall be published in the Federal Register. Meetings
shall be conducted and records of the proceedings kept, as required by
applicable laws and regulations.

10\. COMPENSATION OF MEMBERS: The Access Board will not compensate
Committee members for their service. Committee members will be
responsible for their own expenses for participation in the Committee,
except that the Access Board may pay for a member's reasonable travel
expenses if the member certifies a lack of adequate financial resources
to participate in the Committee and the Access Board determines that the
member's participation in the Committee is necessary to assure adequate
representation of the various interests potentially affected by the
accessibility guidelines and standards.

11\. ESTIMATED ANNUAL COSTS: The costs for the Committee, excluding the
cost of Board staff, are estimated at \$105,000. No government staff
positions are being allocated to the Committee on a full time basis.

12\. DURATION: The Committee will terminate two years from the date of
filing this charter with the appropriate Committees of Congress, unless
the Committee is renewed or terminated sooner.

November 9, 2005, Board Approval Date

April 27, 2006, GSA Review Date

July 30, 2006, Date Filed with Congress

## Operating Protocols

Introduction

The goal of this advisory committee is to make recommendations to the
Access Board regarding accessibility standards for electronic and
information technology and accessibility guidelines for
telecommunications equipment covered by section 508 of the
Rehabilitation Act Amendments of 1998 and Section 255(e) of the
Telecommunications Act of 1996. The recommendations should address
issues such as: types of technologies to be covered by the standards and
guidelines; barriers to the use of such technologies by persons with
disabilities; solutions to such barriers, if known, and research on such
barriers; contents of the standards and guidelines; and harmonization
with international standards efforts in this area.

The advisory committee process is intended to facilitate discussion
among its members. Participants enter the proceedings in good faith in
an effort to reach a speedy and amicable set of recommendations on a
variety of issues. Participants agree to participate fully and openly in
the discussions with a sincere desire to explore alternatives and
solutions to a variety of concerns. All members agree to exchange
information to the fullest extent practicable and agree not to divulge
information shared by others in confidence. Nothing in these protocols
shall prevent a member from making public or using its own proposals in
any future proceeding.

Participation

1\. Interests Represented. The committee will be composed of a cross
section of organizations representing a variety of interests regarding
telecommunications and electronic and information technology access.

2\. The Advisory Committee. The committee will be composed of those
organizations appointed to serve by the Chairperson of the Access Board.
Each member may designate an alternate member(s) representing the same
interest as the designated member. The members will fully brief the
alternates on the progress of the discussions and will give them full
authority when they serve on the committee. Alternates are encouraged to
attend committee meetings. No person may represent more than two groups
during the same meeting. The Chairperson or co-chairs of the committee
shall be appointed by the Chairperson of the Access Board.

3\. Attendance at Meetings. Each committee member will make a good faith
effort to attend each full advisory committee session. Attendance in
person is preferred, but if that is not possible, attendance may be by
teleconference or by videoconference. If a given organization is
unrepresented for two consecutive meetings, the Chairperson or co-chairs
of the committee has the discretion to ask the Chairperson of the Access
Board to remove that organization from the committee.

Committee members may be accompanied by other advisors as that member
believes are appropriate to represent his/her interest. Technical
advisors and other persons may speak openly during discussions. Should
the open discussion become unwieldy, any member may request a more
formal process in which advisors are recognized to speak only by the
Chairperson or co-chairs of the committee.

4\. Additional Committee Members. Additional committee members shall be
added solely to provide representation of stakeholder interests not
already represented on the committee. Committee members may only be
added during the first and/or second meeting of the committee.
Additional committee members may join the committee by a vote of
three-quarters of the committee. Discussion and voting on additional
committee members shall be conducted only once during each of the first
two committee meetings. New committee members shall begin service upon
completion of voting for proposed new committee members.

5\. Constituents' Interests. Committee members are encouraged, to the
extent possible, to communicate with other organizations similarly
situated. Committee members are expected to make a good faith effort to
represent the concerns and interests of their constituents and to ensure
that any recommendation developed by the committee is acceptable to the
organization that the committee member represents.

6\. Right to Withdraw. Any member may withdraw from the committee at any
time without prejudice.

7\. Subcommittees. Subcommittees may be formed to address specific
issues within the scope of the advisory committee's responsibilities.
Subcommittees are open to anyone although balance among interests should
be maintained. Subcommittees may meet at the same time the full
committee meets, or in between full committee meetings. However,
subcommittees are encouraged to meet in between full committee meetings.
Subcommittees may offer recommendations to the committee. However,
subcommittees are not authorized to make recommendations for the
committee. In subcommittees, anyone in attendance can participate.
Subcommittee leadership and methods of work shall be decided by the
subcommittee. Subcommittee meetings shall be conducted in a manner that
is accessible to all those in attendance. Chairs of subcommittees shall
be members of the committee. Subcommittees shall publish their meeting
schedules and other work mechanisms in advance to the public.

Meetings

8\. FACA. The advisory committee meetings will be conducted under the
rules of the Federal Advisory Committee Act (FACA).

9\. Open Meetings. Advisory committee meetings will be announced in the
Federal Register prior to the meeting and, consistent with FACA
requirements, will be open to the public. During each day of the
advisory committee meetings, there shall be time for public comment.

10\. Quorum. A quorum of two thirds of the committee membership will be
required to conduct substantive business of the committee. In the
absence of a quorum, those present will proceed with committee work, but
may not make substantive committee recommendations.

11\. Minutes. Minutes of the committee meetings will be prepared by the
Designated Federal Official (DFO) and distributed as expeditiously as
possible to the committee and will be ratified by the committee at its
next meeting. A progress report of subcommittee meetings shall be
prepared and sent by subcommittee chairs to committee members prior to
the next meeting.

12\. Media Announcements. No member will make unauthorized announcements
to the media or hold discussions with the media characterizing the
position of the committee (until recommendations are final) or ascribing
the position of any member, even if that member withdraws from the
committee.

13\. Agendas. Meeting agendas will be developed by the DFO in
consultation with the Chairperson or co-chairs of the committee.

14\. Ad Hoc Meetings. An ad hoc meeting break can be requested by any
committee member at any time. Ad hoc meetings will not be considered
open meetings. Members are asked to keep such ad hoc meetings to a
minimum and estimate the time needed. Proposals made and positions taken
by any participant during ad hoc meetings shall be confidential and
shall not be used in any future regulatory or legal proceedings.

15\. Accessibility of Meetings. Full committee and subcommittee meetings
will be held in accessible locations and provide for communications and
print access. Persons attending committee meetings are requested to
refrain from using perfume, cologne, and other fragrances for the
comfort of other participants.

16\. Schedule. Advisory committee meetings will be held approximately
once each four to six weeks as determined by the committee. The
committee will submit a report with final recommendations to the Access
Board at a future meeting of the Access Board.

17\. Discontinue if Unproductive. The Access Board in consultation with
the committee Chairperson or co-chairs may discontinue the advisory
committee meetings at any time if the meetings do not appear productive.

18\. Written Materials. Written materials that are distributed to the
committee should be in print and accessible electronic format. Persons
who distribute written materials during committee meetings should
provide 100 print copies and sufficient copies in a variety of
accessible formats, including, but not necessarily limited to large
print, Braille and accessible electronic format. Persons intending to
provide written materials should contact the DFO for detailed
instructions on the requirements for accessible formats and the number
of accessible copies. If written materials to be distributed to the
committee are provided to the Access Board seven days in advance of a
meeting the Access Board will provide sufficient print and accessible
format copies.

Recommendations

19\. Product of Advisory Committee Meetings. The intended product of the
advisory committee is a set of recommendations in the form of a written
statement, which should be signed by all committee members. The
recommendations will be used by the Access Board in developing a
proposed rule for accessibility standards for electronic and information
technology and for accessibility guidelines for telecommunications
products.

Committee meetings should be conducted and work performed in a spirit of
collegiality and consensus should be achieved to the extent possible.
Nothing in these protocols shall require any member to agree on any
specific issue. The purpose of the committee is to give advice and
recommendations, not make decisions. Members should strive to find
common ground and articulate it in its recommendations. Any committee
member may prepare a minority report for the record. Minority reports
will be incorporated into the committee's final report.

Protocol Amendments

20\. The members may amend the protocols at any time.

Approved, September 27, 2006

[^1]: Section 255 covers telecommunications products and services.
    Section 508 covers electronic and information technologies (E&IT).
    For convenience and clarity, wherever these two categories are taken
    together, we are using the common term "information and
    communication technologies," or ICT. In addition, we will use the
    word "product" to refer to both products and services, whether
    purchased, leased or developed "in-house."

[^2]: The Access Board's Guidelines cover customer premises equipment
    and telecommunications equipment, but do not address services.

[^3]: Section 508 requires the Access Board to review and update its
    regulations periodically. Similarly, Section 255 requires the Access
    Board to review and update its Section 255 guidelines periodically.
    Under both statues the timing of the review is left up to the Access
    Board.

[^4]: The phrase "accessible to and usable by" appears in Section 255
    but not in Section 508. In using the entire phrase or the word
    "usable" in this report, we do not intend to add any obligation
    concerning Section 508, nor do we imply the full meaning of the term
    as used in the field usability or human factors, which is outside
    the scope of both regulations. In its Telecommunications Act
    Accessibility Guidelines the Access Board defined "usable" as
    follows: "Means that individuals with disabilities have access to
    the full functionality and documentation for the product, including
    instructions, product information (including accessible feature
    information), documentation, and technical support functionally
    equivalent to that provided to individuals without disabilities."

[^5]: We recognize that many stakeholders will not use the "raw" form of
    the regulations, but will create tools to help them focus on their
    specific accessibility obligations.

[^6]: Section 3 of the Act defines \"telecommunications\" as \"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.\"  The FCC adopted
    a Report & Order (FCC 99-181) on July 14, 1999, which determined
    that adjunct-to-basic services should also be covered by Section
    255.  Adjunct-to-basic services include such services as call
    waiting, speed dialing, call forwarding, computer-provided directory
    assistance, call monitoring, caller identification, call tracing,
    and repeat dialing.  The FCC also asserted its ancillary
    jurisdiction to extend the accessibility requirements to providers
    of voicemail and interactive menu service, as well as to
    manufacturers of equipment that performs those functions.  On May
    31, 2007, the FCC adopted a Report & Order (FCC 07-110) to extend
    the disability access requirements to providers of "interconnected
    voice over Internet Protocol (VoIP) services," and to manufacturers
    of specially designed equipment used to provide those services. 

[^7]: The full FCC analysis of the readily achievable standard is
    contained at *In the Matter of Implementation of Sections 255 Report
    and Order and Further Notice of Inquiry*, WT Dkt 96-198, FCC 99-181,
    16 FCC Rcd 6417 (September 29, 1999), ¶¶43-74; 47 CFR §§6.3(g);
    §7.3(g).

[^8]: These examples are not exhaustive, nor do they indicate specific
    recommendations.

[^9]: http://www.w3.org/WAI/WCAG20/quickref

[^10]: We also considered additional information for user activities,
    product characteristics and product types relevant to the
    provisions, but were not able to complete this work.

[^11]: These categories of test methods were used in the Accessibility
    and Usability section of IEEE P1583-Voting System Standards. This
    draft standard was balloted, but then abandoned in favor of the US
    Election Assistance Commission Voluntary Voting System Guidelines
    2005.

[^12]: Section 255 refers not to assistive technology but to "existing
    peripheral devices or specialized CPE commonly used by individuals
    with disabilities."

[^13]: "Making Regulations Readable," retrieved from
    http://www.archives.gov/federal-register/write/plain-language/readable-regulations.html

[^14]: Webinar materials: Why Plain Language is Critical for Standards,
    retrieved from
    http://teitac.org/wiki/Theme:Usability_of_the_Standard:Redish

[^15]: A full list of references and resources can be found on the
    TEITAC wiki. http://teitac.org/wiki/Theme:Usability_of_the_Standards

[^16]: Web Content Accessibility Guidelines 2.0,
    [[http://www.w3.org/TR/2007/WD-WCAG20-20071211/]{.underline}](http://www.w3.org/TR/2007/WD-WCAG20-20071211/),
    11 December 2007, W3C Working Draft. Latest version at
    [[http://www.w3.org/TR/WCAG20/]{.underline}](http://www.w3.org/TR/WCAG20/)
    . Copyright, 2007 W3C (MIT, ERCIM, Keio)
    [[http://www.w3.org/Consortium/Legal/2002/copyright-documents-20021231]{.underline}](http://www.w3.org/Consortium/Legal/2002/copyright-documents-20021231).