Telecommunications and Electronic and Information Technology Advisory Committee

Report to the Access Board: 
Refreshed Accessibility Standards and Guidelines in Telecommunications
and Electronic and Information Technology

April 2008

NOTE:  This report is a set of recommendations from the Advisory Committee to the Access Board.  Any proposed revisions to the Section 508 standards or the Section 255 accessibility guidelines will be made through the Federal rulemaking process.  This report is not a regulation.

 

Developed for:
U.S. Architectural and Transportation Barriers Compliance Board

Table of Contents

1   Executive Summary
2   Summary of Recommendations
3   Background
4   Updates to the Standard and Guidelines
5   Implementation Recommendations
6   The Recommendations
7   Provisions Considered but Not Achieving Consensus
8   Source and Harmonization of Recommendations
9   Annexes

Minority Reports

 


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

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.

 


2   Summary of Recommendations

2.1   Subpart A
2.2   Subpart B - Functional Performance Criteria
2.3   New Organization of the Technical Requirements in Subpart C
2.4   Sections on Support and Implementation in Subpart D
2.5   New Advisory Notes
2.6   Provisions Considered, But Not Recommended
2.7   Applying the Recommendations to Sections 508 and 255


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:

2.1   Subpart A

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

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

2.3   New Organization of the Technical Requirements in Subpart C

General Technical Requirements
Requirements for Hardware Aspects of Products
Requirements for User Interfaces and Electronic Content
Additional Requirements for Audio-Visual Players or Displays
Requirements for Audio and/or Video Content
Additional Requirements for Real-time Voice Conversation Functionality
Additional Requirements for Authoring Tools

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

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

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

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

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

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

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

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.

2.4 Sections on Support and Implementation in Subpart D

Information, Documentation and Support
Implementation, Operation and Maintenance

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

Information, Documentation and Support

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

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.

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

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

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

 


3   Background

3.1   A History of Section 508
3.2   A History of Section 255

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

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

 


4   Updates to the Standard and Guidelines

4.1   Federal Agency and Consumer Experiences Driving the Refresh
4.2   Technological Changes Driving the 255/508 Refresh
4.3   Harmonization
4.4   Economic Impact

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.

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

The following was considered to be out of scope:

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

4.2   Technological Changes Driving the 255/508 Refresh

Introduction
Specific technologies

Introduction

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

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.

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

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

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.

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

 


5   Implementation Recommendations

5.1   Serving Multiple Audiences
5.2   Testability
5.3   Assistive Technology and Sections 255 and 508
5.4   Accessibility for People with Cognitive Disabilities
5.5   Usability of the Standard and Guidelines
5.6   Recommendations for Research

5.1   Serving Multiple Audiences

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

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:

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.

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

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

5.3   Assistive Technology and Sections 255 and 508

Is AT ICT?
AT Interoperability and Testing Requirements
Reporting AT Compatibility Testing Results

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

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.

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

5.5   Usability of the Standard and Guidelines

Writing Style of the Provisions
Making the Complex Clear
Improving the Usability of the Requirements


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

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:

Making the Complex Clear

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:

Improving the Usability of the Requirements

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.

5.6   Recommendations for Research

Captions
Speech and Audio Volume and Quality
Cognitive Disability
Biometrics
Audio Menus
Low Vision:  Relationship Between Clinical Metrics and Product Performance
Photosensitive Seizure Disorders
Compatibility Between Prosthetics and Touch Sensitive Input Technologies
Gesture-based Input Technologies

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

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

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

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

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

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

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

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

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?

 


6   The Recommendations

How to read these recommendations
General Introduction
Subpart A
Subpart B:  Functional Performance Criteria
Subpart C:  Technical Requirements
Subpart D
Advisory Notes

How to read these recommendations

Terminology Used in the Provisions
Notes Included with the Provisions
Additional Information Included with the Provisions
General Exceptions

These recommendations include:

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 is SYNCHRONIZED MEDIA, live audio-only or live video-only CONTENT, then text alternatives must at least provide a descriptive LABEL

Terminology Used in the Provisions

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:

Notes Included with the Provisions

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

Additional Information Included with the Provisions

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

General Exceptions

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

1. Purpose
2. Application
3. General Exceptions
4. Equivalent Facilitation
5. Definitions

1. Purpose

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

Pursuant to Section 255 of the Telecommunications Act, this part provides requirements for accessibility, usability, and compatibility of new TELECOMMUNICATIONS and INTERCONNECTED VOICE OVER INTERNET PROTOCOL (VOIP) PRODUCTS and CUSTOMER PREMISES EQUIPMENT (CPE) used to provide TELECOMMUNICATIONS SERVICES or INTERCONNECTED VOIP SERVICE, as well as existing products and CPE that undergo substantial change or upgrade, or for which new releases are distributed. This part does not apply to minor or insubstantial changes to existing products and CPE that do not affect functionality

Purpose for Section 508

Section 508 of the Rehabilitation Act requires that when Federal agencies develop, procure, maintain, or use TELECOMMUNICATIONS, ELECTRONIC AND INFORMATION TECHNOLOGY, Federal employees with disabilities have access to and use of information and data including communication that are as timely, accurate, complete, and efficient as compared to the access and use by Federal employees who are not individuals with disabilities, unless an UNDUE BURDEN would be imposed on the agency. Section 508 also requires that individuals with disabilities, who are members of the public seeking information or services from a Federal agency, have access to and use of information and data including communication that are as timely, accurate, complete, and efficient as compared to that provided to the public who are not individuals with disabilities, unless an UNDUE BURDEN would be imposed on the agency.

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

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

Application for Section 255

Where READILY ACHIEVABLE, TELECOMMUNICATIONS and INTERCONNECTED VOIP equipment and CUSTOMER PREMISES EQUIPMENT must comply with the requirements of Part C-Technical Requirements of this [rule].

Where it is not READILY ACHIEVABLE to comply with Part C-Technical Requirements, TELECOMMUNICATIONS and interconnected VoIP equipment and CUSTOMER PREMISES EQUIPMENT (CPE) must comply with the requirements of Part B-Functional Performance Criteria, if READILY ACHIEVABLE.

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

(a) MANUFACTURERS must evaluate the accessibility, usability, and compatibility of equipment and CUSTOMER PREMISES EQUIPMENT used to provide TELECOMMUNICATIONS and INTERCONNECTED VOIP SERVICES and must incorporate such evaluation throughout product design, development, and fabrication, as early and consistently as possible. MANUFACTURERS must identify barriers to accessibility and usability as part of such a product design and development process.

(b) In development such a process, MANUFACTURERS must consider the following factors, as the MANUFACTURER deems appropriate:

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

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, INTERCONNECTED VOIP EQUIPMENT, or CUSTOMER PREMISES EQUIPMENT used with TELECOMMUNICATIONS or INTERCONNECTED VOIP SERVICES.

(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
In general, this section applies only to the consideration of accessibility in the process of developing, procuring, maintaining, or using ELECTRONIC AND INFORMATION TECHNOLOGY. (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, each AGENCY shall ensure that the products comply with the applicable provisions of this part, unless an UNDUE BURDEN would be imposed on the AGENCY.

(1) When compliance with the provisions of this part imposes an UNDUE BURDEN, AGENCIES shall provide individuals with disabilities with the information and data involved by an alternative means of access that allows the individual to use the information and data.
(2) When developing, procuring, maintaining, or using a product, if an AGENCY determines that compliance with any provision of this part imposes an UNDUE BURDEN, the documentation by the AGENCY supporting the development, procurement, maintenance, or use must explain why, and to what extent, compliance with each such provision creates an UNDUE BURDEN. (see note #2)
(3) When determining whether application of the standards would result in an UNDUE BURDEN, an AGENCY must consider all AGENCY 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. (see note #3)

(b) When procuring a product, each AGENCY 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 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 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

A - Intelligence Or Security Systems

This part does not apply to any ELECTRONIC AND INFORMATION TECHNOLOGY operated by AGENCIES, the function, operation, or use of which involves intelligence activities, cryptologic activities related to national security, command and control of military forces, equipment that is an integral part of a weapon or weapons system, or systems 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
This part does not apply to ELECTRONIC AND INFORMATION TECHNOLOGY that is acquired by a contractor incidental to a contract.

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

C - Employees Not Individuals With Disabilities
Except as required to comply with the provisions in this part, this part does not require the installation of specific accessibility-related software or the attachment of an ASSISTIVE TECHNOLOGY device at a workstation of a Federal employee who is not an individual with a disability.

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

D - Access By Public
When agencies provide access to the public to information or data through ELECTRONIC AND INFORMATION TECHNOLOGY, AGENCIES are not required to make products owned by the agency available for access and use by individuals with disabilities at a location other than that where the ELECTRONIC AND INFORMATION TECHNOLOGY is provided to the public, or to purchase products for access and use by individuals with disabilities at a location other than that where the ELECTRONIC AND INFORMATION TECHNOLOGY is provided to the public.

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

E - Fundamental Alteration
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 that is E&IT, 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 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 subject to Section 255, in order to claim fundamental alteration, a MANUFACTURER 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
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)

4. Equivalent Facilitation

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

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.

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

Content:  Information and sensory experience to be communicated to the user by means of software, including but not limited to:  TEXT, images, sounds, videos, controls, and animations, as well as the encoding that defines the structure, presentation, and interactions associated with those elements.
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 of the lighter of the foreground or background colors compared to the RELATIVE LUMINANCE of the darker of the foreground or background colors.
(L1 + 0.05) / (L2 + 0.05), where

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 or INTERCONNECTED VOIP SERVICE.
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 and any equipment or interconnected system or subsystem of equipment that is used in the creation, conversion, or duplication of data or information. The term electronic and information technology includes, but is not limited to, TELECOMMUNICATIONS products (such as telephones), information kiosks and transaction machines, World Wide Web sites, multimedia, and office equipment such as copiers and fax machines. The term does not include any equipment that contains embedded INFORMATION TECHNOLOGY that is used as an integral part of the product, but in which INFORMATION TECHNOLOGY is not the principal function of that product.

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 is below the threshold (i.e., software or CONTENT 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 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 frequency is 75 hz or greater; or
4. General FLASHES (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 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 from all sources (that might FLASH > 3 hz) below the maximum of (1, ambient(in lux)/700 lux) times the threshold values in 4 or 5 above.

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:

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

Keyboard Interface:  A means for accepting input from a KEYBOARD. For software, this would be the ability to accept KEYBOARD input from the operating system including on-screen KEYBOARDS. For hardware this would be the ability to connect a KEYBOARD via wired or wireless connection.

Label:  TEXT or other component with a text alternative that is presented to a user to identify a component within CONTENT.
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 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, used to interoperate with ASSISTIVE TECHNOLOGIES.

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 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 that is required for understanding of the complete presentation. The other CONTENT that the audio or video is synchronized with to meet this definition does not include equivalents such as CAPTIONS, subtitles, or VIDEO DESCRIPTION.

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

Telecommunications Equipment:  Equipment, other than CUSTOMER PREMISES EQUIPMENT, used by a carrier to provide TELECOMMUNICATIONS SERVICES, and includes software integral to such equipment (including upgrades).
Source:  Telecommunications §1193.3

Telecommunications Service:  The offering of TELECOMMUNICATIONS for a fee directly to the public, or to such classes of users as to be effectively available directly to the public, regardless of the facilities used.
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 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.

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 must consider all AGENCY 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

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
I – Without Physical Contact (no consensus)
J – With Cognitive, Language, or Learning Limitations (no consensus)

The purpose of the Functional Performance Criteria is to help Federal departments or AGENCIES determine whether products being used, developed, procured or maintained meet the functional needs of individuals with disabilities. The functional performance criteria 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
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
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
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
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)
Work on this provision was not complete. Please see the drafts and other discussion material in Section 7

G - Without Speech
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
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)
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)
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
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 is used in conjunction with the product (screen reader, special KEYBOARD, etc.). Either means for achieving access satisfies Section 508. For Section 255, where READILY ACHIEVABLE, 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.

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

1. General Technical Requirements
2. Requirements for Hardware Aspects of Products
3. Requirements for User Interface and Electronic Content
4. Additional Requirements for Audio-Visual Players or Displays
5. Requirements for Audio and/or Video Content
6. Additional Requirements for Real-Time Voice Conversation Functionality
7. Additional Requirements for Authoring Tools

For the purposes of Section 255, each MANUFACTURER of a product that is used to provide TELECOMMUNICATIONS or INTERCONNECTED VOIP SERVICE must ensure that such products are designed, developed and fabricated to incorporate the access features described in the technical requirements, if READILY ACHIEVABLE. Whenever it is not READILY ACHIEVABLE to incorporate such access features directly into the products, the MANUFACTURER must ensure that the products are compatible with existing PERIPHERAL DEVICES or SPECIALIZED CUSTOMER PREMISES EQUIPMENT commonly used by individuals with disabilities to achieve access, if READILY ACHIEVABLE. (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, unless the AGENCY can show that such compliance would cause an UNDUE BURDEN.

1. General Technical Requirements

1-A:  Closed Functionality
If any functionality of a product is closed for any reason including policy constraints or technical limitations then that CLOSED FUNCTIONALITY must be made available to and operable by people with disabilities within the product itself. As a result, the following provisions would not apply to the CLOSED FUNCTIONALITY:

Additional Information

1-B:  Biometric ID
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 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

1-C:  Pass Through
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 communication signals (including mixed voice and REAL-TIME TEXT) that are standard in the United States for that technology platform without distortion or error beyond 1%.

Additional Information

1-D:  Audio Information
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

1-E:  Visual Information (no consensus)
Work on this provision was not complete. Please see the drafts and other discussion material in Section 7

1-F:  Color
Color must not be used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.
Example:  A conforming example is:  mandatory form fields are identified with colored TEXT and labeled as "Required."

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

Additional Information

1-G:  Text Size (no consensus)
Work on this provision was not complete. Please see the drafts and other discussion material in Section 7.

1-H:  Speech Operation
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

2. Requirements for Hardware Aspects of Products

2.1 All Products with Hardware
2.1-A:  Reflectance Contrast for Legends and Passive Displays
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 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, 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 the alphanumeric LABELS 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 interaction.

Additional Information

2.1-B:  Flashing (Hardware)
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 at any time then either there must be no more than 3 FLASHES in any 1 second period or the FLASHING must be below the GENERAL FLASH AND RED FLASH THRESHOLDS FOR HARDWARE.

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

2.1-C:  Mechanical Controls
All mechanically operated controls and keys:

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

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

2.1-D:  Touch Operated Controls
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

2.1-E:  Standard User Interface Connection
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 device into a standard user connection, the procuring AGENCY must identify a market source for the connector if it isn't a standard option for the product.

Additional Information

2.1-F:  Installed or Free-Standing Products
Architecturally installed or FREE-STANDING 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.

2.2 If the Product has Speech Output or Throughput

2.2-A:  Magnetic Coupling
Products that deliver output with an audio transducer that is TYPICALLY HELD TO THE EAR 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

2.2-B:  Interference with Hearing Device
Interference to hearing technologies (including hearing aids, cochlear implants, and assistive listening devices) must be reduced to the lowest possible level that allows a user of hearing technologies to utilize the TELECOMMUNICATIONS product.

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

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

2.2-C:  Audio Connection
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 that meets 2.2-A (Magnetic Coupling), 2.2-B (Interference with Hearing Device), and 2.2-E (Volume - gain) and product does not require simultaneous use of KEYBOARD; or
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; 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, 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

How it would apply

Additional Information

2.2-D:  Volume
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

2.2-E - Volume (Gain)
For products that deliver voice throughput:

1. Users must be able to adjust the audio output level.
2. All TELECOMMUNICATIONS products powered solely from analog telephone lines and having an audio transducer TYPICALLY HELD TO THE EAR, 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 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

2.2-F - Volume Reset
If the product allows a user to adjust the receive volume to a level greater than 18 dB above normal unamplified level, a function must be provided to automatically reset the volume to a level not greater than 18 dB above normal unamplified level after every use. A manual override control may be provided to prevent the automatic reset, subject to the conditions specified in FCC Memorandum Opinion and Order DA 01-578. This applies to products with transducers TYPICALLY HELD TO THE EAR that are neither headsets nor headphones.

3. Requirements for User Interface and Electronic Content

People designing, developing, maintaining, or procuring user interface and electronic CONTENT 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, including web sites, software and other user interfaces or electronic CONTENT.

3-A:  Color
Color must not be used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.
Example:  A conforming example is mandatory form fields are identified with colored TEXT 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 Board
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

3-B:  Contrast
Presentation of TEXT, and images of TEXT, in electronic documents must have a CONTRAST RATIO of at least 5:1, except for the following:

1. Large Print:  LARGE SCALE TEXT and images of LARGE SCALE TEXT must have a CONTRAST RATIO of at least 3:1;
2. Incidental:  TEXT or images of text that are part of an inactive user interface component, that are pure DECORATION, that are incidental TEXT in an image, or that are not visible to anyone, have no minimum contrast requirement.

Additional Information

3-C:  Size, Shape, Location
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.”

Rationale
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

3-D:  User Preferences
Applications must provide a mode that utilizes platform settings for color, contrast, font type, font size, and focus cursor. In the absence of platform settings for color and contrast, all TEXT (and images of text) must have a CONTRAST RATIO of at least 5:1 except for the following:

1. Large Print:  LARGE SCALE TEXT and images of LARGE SCALE TEXT must have a CONTRAST RATIO of at least 3:1;
2. Incidental:  TEXT or images of text that are part of an inactive user interface component, that are pure DECORATION, that are incidental TEXT 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

3-E:  Color Adjustment
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 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

3-F:  Non-text Objects
All NON-TEXT OBJECTS that are presented to the user must have a TEXT alternative that presents equivalent information, except for the situations listed below.

1. Controls-Input:  If a NON-TEXT OBJECT is a control or accepts user input, then it must have a name that describes its purpose. (See also User Interface Components provisions.)
2. Media:  If a NON-TEXT OBJECT is SYNCHRONIZED MEDIA, live audio-only or live video-only CONTENT, then text alternatives must at least provide a descriptive LABEL that identifies the NON-TEXT OBJECT. (For SYNCHRONIZED MEDIA, see also Audio and/or Video provisions.)
3. Test:  If a NON-TEXT OBJECT is a test or exercise that must be presented in non-text format, then text alternatives must identify at least the NON-TEXT OBJECT with a descriptive text LABEL. (For SYNCHRONIZED MEDIA, see also Audio and/or Video provisions.)
4. Sensory:  If a NON-TEXT OBJECT is primarily intended to create a specific sensory experience, then text alternatives must identify at least the NON-TEXT OBJECT with a descriptive text LABEL. (For SYNCHRONIZED MEDIA, see also Audio and/or Video provisions.)
5. CAPTCHA:  If the purpose of a NON-TEXT OBJECT is to confirm that CONTENT is being accessed by a person rather than a computer then text alternatives that identify and describe the purpose of the NON-TEXT OBJECT must be provided and alternative forms in different modalities must be provided to accommodate different disabilities.
6. DECORATION, Formatting, Invisible Objects:  If a NON-TEXT OBJECT is pure DECORATION, or used only for visual formatting, or if it is not presented to users, then it must be implemented such that it can be ignored by ASSISTIVE TECHNOLOGY.

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

3-G:  Human Language
When supported in the technologies of electronic documents, the default human language of electronic document must be PROGRAMMATICALLY DETERMINABLE.

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

3-H:  Language of Parts
When supported in the technology of electronic documents, the human language of each passage or phrase in electronic documents must be PROGRAMMATICALLY DETERMINABLE.

Additional Information

3-I:  Pausing
A mechanism must be provided to pause moving, BLINKING, or scrolling information that lasts for more than three seconds unless it is part of an activity where the moving, BLINKING, 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 CONTENT that is pure DECORATION.

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

3-J:  Flashing (Content and User Interfaces)
CONTENT or user interfaces must not contain anything that FLASHES more than 3 times in any one second period or the FLASHING must be below the GENERAL FLASH AND RED FLASH THRESHOLDS FOR CONTENT AND USER INTERFACES.

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

3-K:  Consistent Identification
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

3-L:  Audio Turnoff
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

3-M:  Reading Sequence
When the sequence in which information is presented affects its meaning, a reading sequence that conveys the intended meaning must be PROGRAMMATICALLY DETERMINABLE. 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

3-N:  Link Purpose
On Web pages, it must be possible to determine the purpose of each link from the link TEXT or the link TEXT together with its PROGRAMMATICALLY DETERMINABLE 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

3-O:  Information and Relationships
Information and relationships conveyed through presentation of electronic documents must be either PROGRAMMATICALLY DETERMINABLE or available in TEXT, 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 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

3-P:  User Interface Components (no consensus)
Work on this provision was not complete. Please see the drafts and other discussion material in Section 7

3-Q:  Disruption of Access Features
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

3-R:  Timing
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

3-S:  Keyboard Operation
Where products have a KEYBOARD or a KEYBOARD INTERFACE, or run on a device that has a KEYBOARD or KEYBOARD INTERFACE, all functionality of the product operable through the electronic user interface must be operable through the KEYBOARD, or a KEYBOARD INTERFACE. 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

3-SS:  Visual Indication of Keyboard Shortcuts (no consensus)
Work on this provision was not complete. Please see the drafts and other discussion material in Section 7

3-T:  Focus Indicator
Any KEYBOARD operable user interface must support a mode of operation where the indication of KEYBOARD 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

3-U:  AT Interoperability (partial consensus)
Work on this provision was not complete. Please see the drafts and other discussion material in Section 7.

3-V:  Accessibility Services
PLATFORM SOFTWARE must provide access to a set of services that enable applications running on the platform to interact with ASSISTIVE TECHNOLOGY 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 available to their client software, OR using OTHER SERVICES TO COOPERATE WITH ASSISTIVE TECHNOLOGIES on the underlying platform.

Rationale
Needed to improve E&IT-AT interoperability.

Additional Information

3-VV:  Assistive Technology (no consensus)
Work on this provision was not complete. Please see the drafts and other discussion material in Section 7.

3-W:  Multiple Ways
There must be more than one way available to locate CONTENT within a set of Web pages where CONTENT 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

3-X:  Labels or Instructions
LABELS or instructions must be provided when CONTENT requires user input.

Rationale
Harmonization with WCAG 2.0. Supports people with cognitive, language, and learning disabilities.

Additional Information

3-Y:  On Focus
When any component in CONTENT or electronic documents receives focus through navigation by KEYBOARD 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

3-Z:  On Input
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

3-AA:  Error Identification
If an input error is automatically detected in CONTENT or electronic documents, the item that is in error must be identified and described to the user in TEXT.

Rationale
Harmonization with WCAG 2.0. Supports people with cognitive, language, and learning disabilities.

Additional Information

3-BB:  Headings and Labels
Headings and LABELS 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

4. Additional Requirements for Audio-Visual Players or Displays

4-A:  Caption Processing
Analog television, digital television and tuners, computer equipment, and other products must provide support for closed and open CAPTIONS:

1. Products that are governed by U.S. Federal Communications Commission (FCC) regulations 47 CFR 15.119 (Closed caption decoder requirements for analog television receivers) and 47 CFR 15.122 (Closed caption decoder requirements for digital television receivers and converter boxes) must provide support for TV closed CAPTIONS and open CAPTIONS.
Such equipment must either pass TV caption data to the caption decoding circuitry of analog and DTV displays for decoding as displayed TEXT, or decode TV CAPTION data and pass on a decoded ("open-captioned") video signal to the display.
2. Products that do not fall under the regulation of the U.S. Federal Communications Commission (FCC), personal video display devices and software players, must provide support for a functional equivalent to TV closed CAPTIONS.
Such products must either pass TV CAPTION data to the CAPTION decoding circuitry of DTV displays for decoding as displayed TEXT or decode a functional equivalent to TV closed CAPTIONS and pass on a decoded ("open-captioned") video signal to the display.
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 as allowed by the PLATFORM SOFTWARE or hardware displaying the media.

Rationale
Align the provisions 4-A - Caption Processing and 4-B - Supplemental Audio Process

Additional Information

4-B:  Supplemental Audio Process
Television tuners, including tuner cards for use in computers, must support VIDEO DESCRIPTION process:

Rationale
Align the 4-A - Caption Process provisions with the 4-B - Supplemental Audio Process provisions.

Additional Information

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

For captioning:

1. A caption on/off button on a TV remote comparable in prominence to the volume control on that remote
2. Caption controls on the first MENU that appear when on-screen MENUS are displayed
For VIDEO DESCRIPTION:  A tactile button to turn on VIDEO DESCRIPTION.
Note:  Comparable in prominence does not require exact equivalence in size, location, or shape.

Rationale

Additional Information

5. Requirements for Audio and/or Video Content

5-A:  Captions and Transcripts
Materials containing video and/or audio, regardless of format, that contain speech or other audio information necessary for the comprehension of the CONTENT, must comply with the following:

1. Materials containing prerecorded audio information, and no original video or other additional time-based CONTENT must provide a separate transcript of the audio information.
2. Materials containing prerecorded video with concurrent audio information must provide synchronized CAPTIONS.
3. Materials containing real-time audio, with or without video, must provide synchronized real-time CAPTIONS.
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

5-B:  Video Description
Materials containing video and/or audio, regardless of format, that contain visual information necessary for the comprehension of the CONTENT, must comply with the following:

1. Materials containing prerecorded video and no original audio or other additional time-based CONTENT must provide either a separate TEXt description of the video or provide an additional audio track to convey the informational CONTENT of the video.
2. When the visual informational CONTENT is not conveyed through other means, materials containing prerecorded video with concurrent audio must provide synchronized VIDEO DESCRIPTIONS, or when space is not available in the main program audio for synchronized VIDEO DESCRIPTIONS, a separate TEXT description of the video CONTENT must be provided.
3. Materials containing live video must provide synchronized VIDEO DESCRIPTIONS in real time to convey any informational CONTENT 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

5-C:  Interactive Elements
SYNCHRONIZED MEDIA containing INTERACTIVE ELEMENTS, such as options for selection and access to segments of the CONTENT, must include a mode of operation for selection consistent with applicable Section 508 provisions.

Additional Information

6. Additional Requirements for Real-Time Voice Conversation Functionality

6-A:  Real-Time Text Reliability and Interoperability
If hardware or software provides real-time voice conversation functionality it must provide at least one means of REAL-TIME TEXT communication where the following reliability requirements are met:

1. Products must use a REAL-TIME TEXT (RTT) system that meets the following requirements:

a. RTT format must be a standard REAL-TIME TEXT format for the voice platform that is supported by all TERMINAL, 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 with less than 1% Total Character Error Rate at the peak network traffic specified for intelligible speech transmission (TEXT must work on the network as long as speech does);
d. The RTT system, together with the audio system, must support speech and TEXT in both directions in the same call session (and support speech and TEXT 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 over IP. Note:  this is subject to a waiver of the TTY 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 traffic to gateways capable of handling TTY 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 as per XXX where it interfaces with other VoIP products or systems. Note:  this is subject to a waiver of the TTY 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 traffic to gateways capable of handling TTY translation.
c. If product connects to other products or systems using a protocol other than SIP it must use the standard REAL-TIME TEXT protocol that meets provision 1 above that has been established for that protocol.
Note 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

6-B:  Voice Terminal Hardware and Software
TERMINAL hardware or software that is capable of providing voice communications in real-time must comply with the following:

1. Receive only:  If hardware or software TERMINAL 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 must display any REAL-TIME TEXT that is received if it is received in the format for the voice and REAL-TIME TEXT system being used on the network on which it is installed.
2. Send and Receive:  If TERMINAL hardware or software provides voice conversation over IP in any form, and has TEXT generation capability, then the TERMINAL must allow users to send REAL-TIME TEXT in the format for the voice and REAL-TIME TEXT system being used on the network on which it is installed.
3. If IP TERMINAL hardware or software does not provide REAL-TIME TEXT send and receive capability then the TERMINAL must support the addition of TERMINALS and TERMINAL peripheral equipment that support REAL-TIME TEXT functionality in conjunction with the voice call functionality, in the same location and with the same permissions for use as their voice TERMINAL. If the TERMINAL is in a 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 is analog or TDM-digital wired TERMINAL then it must support the connection of a TTY via an RJ-11 jack in the same location and with the same permissions for use as the telephone and it must be capable of allowing simultaneous speech and TEXT conversation without interference or its microphone 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.

Advisory Note to the Access Board
The following open items still need to be addressed

Additional Information

6-C:  IVR, Auto-Attendant and Messaging
Voice mail, messaging, auto-attendant, and interactive voice response TELECOMMUNICATIONS SYSTEMS must provide access in the following manner:

1. All functions that are accessible to voice users must also be directly accessible to users of REAL-TIME TEXT.
2. Use the ITU-T G.711 recommendation for encoding and storing audio information. If an audio encoder other than G711 is employed, the vendor must provide evidence that the intelligibility is equal to or better than that provided by G.711;
3. Provide full player controls that allow users to pause, rewind, slow down and repeat all messages and prompts;
4. Provide prompts (either as provided by the vendor, or by the AGENCY or customer) without any background sounds that would reduce intelligibility.
Note:  Relay services are not considered to be "directly accessible."

Additional Information

6-D:  Caller and Status Information (no consensus)
Work on this provision was not complete. Please see the drafts and other discussion material in Section 7.

6-E:  Video Support
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 from different MANUFACTURERs 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

6-F:  Audio Clarity for Interconnected VoIP
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

6-G:  External Alerting Devices
A mechanism must be provided where interconnected VoIP phone systems, interconnected VoIP TERMINAL 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 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

7. Additional Requirements for Authoring Tools

For the purposes of Section 255, the provisions of this section are not requirements but instead represent best practices for AUTHORING TOOLS. To the extent that AUTHORING TOOLS are used to create and publish CONTENT for use with a covered service, the incorporation of these provisions will improve the accessibility of the CONTENT produced. For instance, where an IVR product or service includes software for the creation of CONTENT used to populate MENU choices, the requirements of the AUTHORING TOOLS section represent best practices to ensure that the CONTENT is accessible to and USABLE by people with disabilities.

7-A:  Accessible Output
For each ACCESSIBLE CONTENT FORMAT supported, when available, AUTHORING TOOLS must allow the author to produce CONTENT, including CONTENT derived from programmatic sources, which meets applicable Section 508 provisions.

Additional Information

7-B:  Preserve Accessibility Information
For each ACCESSIBLE CONTENT FORMAT supported, AUTHORING TOOLS must preserve accessibility information necessary to meet applicable Section 508 provisions, unless the user explicitly indicates otherwise.
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

7-C:  Prompts (no consensus)
Work on this provision was not complete. Please see the drafts and other discussion material in Section 7.

7-D:  Accessible Templates (no consensus)
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

1.1 Product Documentation and Help

1.1-A:  Accessible Documentation and Features
Documentation for users on the installation, configuration, or use of the product including the description, installation, and use of accessibility and compatibility features, 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:

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

1.1-B:  Keyboard Shortcuts (no consensus)
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

1.2-A:  Support Services
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 commonly used with the product, and must be made available at no additional charge.

Additional Information

1.2-B - Manufacturer Contact
Applying only to products under Section 255, MANUFACTURERS must include in general product information the contact method for obtaining the information required by this section.

Additional Information

1.2-C - Training
Applying only to products under Section 255, in developing or incorporating existing training programs, MANUFACTURERS 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 products;
4. Designing for accessibility;
5. Solutions for accessibility and compatibility.

Additional Information

2. Implementation, Operation, and Maintenance

2-A:  Relay Services Accessibility
This provision is not relevant to the Section 255 guidelines, because it creates obligations for federal agencies.
In complying with this subpart, each AGENCY must ensure access to and use of all TELECOMMUNICATIONS relay services as approved by the Federal Communications Commission pursuant to its authority under 47 U.S.C. Sec. 225, for incoming and outgoing calls, as needed to achieve functionally equivalent communication access by people with disabilities.

Additional Information

2-B:  Video Support
This provision is not relevant to the Section 255 guidelines, because it creates obligations for federal agencies.

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

2-C:  Accessibility Configuration
This provision is not relevant to the Section 255 guidelines, because it creates obligations for federal agencies.

Each AGENCY 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, voicemail, and interactive MENU 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" has meaning as defined in 1194.4 Definitions.

Additional Information

2-D:  Accessible Content
This provision is not relevant to the Section 255 guidelines, because it creates obligations for federal agencies.
AGENCIES must ensure that electronic CONTENT used for official AGENCY 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 is distributed only to a small group of known recipients and accommodates their accessibility needs, or when CONTENT is being stored for archival purposes only.

Note 1:  Official AGENCY communications include, but are not limited to, AGENCY websites, policies or procedures for employees that are distributed via internal AGENCY 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

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
There are E&IT 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
The following are recommended best practices.

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

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

2. Writing Guidelines
Authors should follow best practices for creating CONTENT that is accessible for people with disabilities. These guidelines include:

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

3. Interaction Guidelines
Applications should 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.

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

5. User Preferences (non-visual)
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:

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)
Level A WCAG guidelines not included elsewhere:

Advisory Notes for Authoring Tools
Some best practices for authoring tools to help authors create accessible content are:

1. Assistance with Checking for Accessibility Problems
AUTHORING TOOLS 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
Best practices for providing documentation to people with disabilities include:

1. Context-Sensitive Help
Context-sensitive help, which offers documentation or support for the features and functions of the current page, screen or window should be offered, using a consistent set of accessible commands to access it.
2. Text Descriptions
Documentation and training materials should include text descriptions of the interface. These descriptions should stand on their own and be understandable without relying on graphic images in the materials.
3. User Interface Descriptions
Descriptions of a user interface should refer to elements by name or function, in addition to their location in the visual interface.

Recommendations for Additional Advisory Notes:
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
Best practices for providing support to people with disabilities include: 

1. Remote Assistance
Remote assistance programs allow someone to access a computer system remotely to provide support or instruction. This ability to demonstrate features of the computer software or hardware is helpful to people with cognitive disabilities. Applications should either make such a feature available or not disrupt tools that provide it, to the extent that this does not compromise the agency's network security policy.

 



7   Provisions Considered but Not Achieving Consensus

Subpart B:  Functional Performance Criteria E, I, and J
Provisions from Subpart C

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

E – With Limited Hearing (no consensus)
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)
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:

4. Direct Access examples:

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

1-E:  Visual information (no consensus)

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, either directly or through support for the following provisions in Section 3 <insert list>.

Visual CONTENT that includes TEXT 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

1-G:  Text Size (no consensus)
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 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, regulatory LABELS, 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 or instructions exists (e.g., uniquely tactilely discernible through shape), and the TEXT 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 file:  Providing TEXT in an accessible file on a device meets this requirement for information that is not location specific (e.g., LABELS are location specific).
(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.

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:

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

3-P - User Interface Components (no consensus)
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. States, properties, and values that can be set by the user must be PROGRAMMATICALLY DETERMINABLE and can be programmatically set. Any notification of changes to these items must be available to user agents, including ASSISTIVE TECHNOLOGIES.
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. 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.
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

3-SS:  Visual Indication of Keyboard Shortcuts (no consensus)
There were two versions of this provision under discussion, but final text was not agreed on.

Version 1
All KEYBOARD 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 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

3-U:  AT Interoperability (partial consensus)
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-E&IT interoperability, software that provides user interface components must either use the accessibility services provided by PLATFORM SOFTWARE or OTHER SERVICES TO COOPERATE WITH ASSISTIVE TECHNOLOGIES, when such services allow the software to meet the accessibility provisions of this standard.

Using such services, software must:
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 for another component, or being LABELED by another component
e. Name of parent or containing element, and any children components
f. TEXT contents, TEXT attributes, and the boundary of TEXT rendered to the screen
g. Keyboard shortcuts and implicit designators.

In order to meet this provision, INTERACTIVE ELEMENTS 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 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

3-VV:  Assistive Technology (no consensus)
This provision was the subject of much discussion, and no agreement to include it was reached.

ASSISTIVE TECHNOLOGY must utilize the PLATFORM SOFTWARE ACCESSIBILITY SERVICES 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 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

6-D:  Caller and Status Information (no consensus)
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 status information (such as caller identification and similar TELECOMMUNICATIONS functions) must also make this information available for:

1. Users of TTYS,
2. Users of other TEXT conversation systems, and
3. Users who cannot see displays.

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

Version 2
Products with visual interfaces that display TELECOMMUNICATIONS 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 information includes caller identification.

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

The display capability of the TELECOMMUNICATIONS product must not be disabled when the phone is used in conjunction with a TTY 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

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 with a user interface must provide a mode that prompts authors to create accessible CONTENT.
Note:  It is neither expected nor possible that prompts be available for every type of accessible content.

Version 5
An AUTHORING TOOL, 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 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.

Version 7
An AUTHORING TOOL, or suite of tools used to author content, must provide a mode which prompts authors to create accessible CONTENT, 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.
Note 2:  A suite of AUTHORING TOOLS 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:

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

7-D:  Accessible Templates (No consensus)
There were several versions of this provision under active discussion, but there was no decision as to whether it should be included.

AUTHORING TOOLS which provide pre-authored CONTENT, or templates to facilitate production of CONTENT, must provide at least one version that meets applicable Section 508 provisions.
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

Subpart D:  1.1-B:  Keyboard Shortcuts (no consensus)
There were 4 versions of this provision under active discussion.

Version 5
Information about KEYBOARD shortcuts, including available KEYBOARD commands and KEYBOARD navigation mechanisms, must be listed in centrally located user documentation, and available in context-sensitive help.

Version 7
Information about KEYBOARD shortcuts and implicit designators must be listed in centrally located user documentation, and available in context-sensitive help.

Version 8
Information about KEYBOARD operation, including available KEYBOARD commands and KEYBOARD 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 operations, including available KEYBOARD commands and KEYBOARD 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 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

Definitions Considered but Not Completed
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.

Accessible Content Format
Version 1:  A format that supports the creation of CONTENT 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. 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 for publication in one or more formats that support compliance with the user interface and CONTENT 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 equivalents for audio information. Captions are similar to subtitles in that they convey the CONTENT of spoken dialog, but also include TEXT for non-spoken information such as important sound effects, music, laughter, and speaker identification and location. Captions should not obscure or obstruct relevant or key information. In some countries captions are called subtitles.

Version 2 (from WCAG 2.0):
SYNCHRONIZED MEDIA or TEXT 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” 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 presented and synchronized with SYNCHRONIZED MEDIA 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 for software and CONTENT) 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 definitions for information about types of flash that are not allowed.
Note 2:  See also BLINKING.

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.

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 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 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 of 10% or more of the maximum RELATIVE LUMINANCE where the RELATIVE LUMINANCE 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 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, using a 341 x 256 pixel rectangle anywhere on the displayed screen area when the CONTENT is viewed at 1024 x 768 pixels will provide a good estimate of a 10 degree visual field for standard screen sizes and viewing distances (e.g.,15-17 inch screen at 22-26 inches). (Higher resolutions displays showing the same rendering of the CONTENT 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 (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 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 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 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 or VoIP equipment or CUSTOMER PREMISES EQUIPMENT to translate, enhance, or otherwise transform TELECOMMUNICATIONS or VoIP services into a form accessible to individuals with disabilities.
This definition was requested to support Section 255

Platform Accessibility Services:  Services provided by a platform enabling interoperability with ASSISTIVE TECHNOLOGY, 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, from the data provided.
Note 1:  Purpose is to allow user agents including ASSISTIVE TECHNOLOGIES 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.

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 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 and IEC-4WD.)

Note 2:  Almost all systems used today to view Web CONTENT assume sRGB encoding. Unless it is known that another color space will be used to process and display the content, authors should evaluate using sRGB colorspace. If using other color spaces, see Understanding Success Criterion 1.4.3.
Note 3:  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.
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, 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 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
Exception:  Narrow, Delineated Use (no consensus)
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)
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 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:

Provisions Considered, but Dropped
Basic Input/Output System (BIOS) Settings
The General subcommittee considered two aspects to the question of whether a provision was needed to cover access to BIOS settings:

It also discussed:

The subcommittee determined that a separate provision is not needed, because:



 

8   Source and Harmonization of Recommendations

8.1   Source of Recommendations from the Current 8 and 255
8.2   Harmonization of the Recommendations to WCAG 2.0
8.3   Identification of Provisions Supporting Functional Performance Criteria

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

 

TEITAC RECOMMENDATIONS

Section 508

Section 255

  Subpart C    

1-A

Closed Functionality

1194.25(a)

 

1-B

Biometric ID

1194.25(d)
1194.26(c)

 

1-C

Pass Through

1194.23(j)

1193.37

1-D

Audio information

 

1193.43(d)

1-E

Visual Information

 

1193.43(a)

1-F

Color

1194.21(i)
1194.25(g)

1194.41(c)

1-G

Text size

 

1193.43(b)

1-H

Speech Operation

1194.23(e)

 

2.1.A

Reflectance Contrast for Legends and Passive Displays

1194.21(j)
1194,25(h)

 

2.1.B

Flashing

1194.21(i)
1194.25(j)
1194.25(k)

1193.43(f)

2.1.C

Mechanical Controls

1194.23(k)
1194.26(a)

 

2.1.D

Touch Operated

1194.25(c)
1194.26(b)

 

2.1.E

Standard Connection

1194.26(d)

 

2.1.F

Installed or Free-Standing Products

1194.25(j)

1193.41(f)

2.2.A

Magnetic Coupling

1194.23(h)

1193.43(i)

2.2.B

Interference with Hearing Device

1194.23(i)

1193.43(h)

2.2.C

Audio Connection

1194.25(e)

1193.51(b)
1193.51(g)

2.2.D

Volume

1194.25(f)

1193.43(e)

2.2.E

Volume (Gain)

1194.23(f)

1193.43(e)

2.2.F

Volume Reset

1194.23(g)

 

3.A

Color

1194.21(i)
1194.22(c)
1194.25(h)

1193.41(c)

3.B

Contrast

1194.21(j)

 

3.C

Size, shape, location

   

3.D

User Preferences

1194.21(g)

 

3.E

Color Adjustment

1194.21(j)

 

3.F

Non-text Objects

1194.22(a)

 

3.G

Human Language

   

3.H

Language of Parts

   

3.I

Pausing

1194.21(h)

 

3.J

Flashing (Content and User Interfaces)

1194.21(k)
1194.22(j)
1194.25(i)

1193.43(f)

3.K

Consistent Identification

1194.21(e)

 

3.L

Audio Turnoff

1194.25(e)

 

3.M

Reading Sequence

1194.22(d)

 

3.N

Link Purpose

   

3.O

Information and Relationships

1194.22(g), (h), (i), & (n), & (o)
1194.21(l)

 

3.P

User Interface Components

1194.21(l)
1194.22(l)
1194.22(n)

 

3.Q

Disruption of Access Features

1194.21(b)

 

3.R

Timing

1194.22(p)
1194.23(d)
1194.25(b)

1193.41(g)

3.S

Keyboard Operation

1194.21(a), (e), (f), (k), (l) & (m)

 

3.SS

Visual Indication of Keyboard Shortcuts

   

3.T

Focus Indicator

1194.21(c)

 

3.U

AT Interoperability

1194.21(d), (c), (f) & (m)

 

3.V

Accessibility Services

   

3.VV

Assistive Technology

   

3.W

Multiple Ways

   

3.X

Labels or Instructions

   

3.Y

On Focus

   

3.Z

On Input

   

3.AA

Error Identification

   

3.BB

Headings and Labels

   

4.A

Caption Process

1194.24(a)

 

4.B

Supplemental Audio Playback (Process?)

1194.24(b)

 

4.C

Access to Caption and Video Controls

   

5.A

Captions and Transcripts

1194.24(c)

 

5.B

Video Description

1194.24(d)

 

5.C

Interactive Elements

1194.24(d)
1194..22(b)

 

6.A

Real-Time Text Reliability & Interoperability

1194.23(b)

1193.51(e)

6.B

Voice Terminal Hardware & Software

1194.23(a)

1193.51(d)

6.C

IVR, Auto-Attendant and Messaging

1194.23(c)

 

6.D

Caller and Status Information

   

6.E

Video Support

   

6.F

Audio clarity for VoIP

   

6.G

External Alerting Devices

   

7

Authoring Tools

   

7.A

Accessible Output

   

7.B

Preserve Accessibility Information

   

7.C

Prompts

   

7.D

Accessible Templates

   
  Subpart D    

1

Information, Documentation & Support

   

1.1

Product Documentation and Help

   

1.1-A

Accessible Documentation and Features

194.41(a), 194.41(b)

1193.33(a)(1), 1193.33(a)(2)

1.1-B

Keyboard Shortcuts

   

1.2

Support and E&IT related services

   

1.2-A

Support Services

1194.41(c)

1193.33(a)(3)

1.2-B

Manufacturer Contact

   

1.2-C

Training

   

2.A

Relay Services Accessibility

   

2.B

Video Support

   

2.C

Accessibility Configuration

   

2.D

Accessible Content

   

8.2 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

TEITAC RECOMMENDATIONS WCAG 2.0 CHECKPOINTS (and level)

3.A

Color

1.4.1

Use of Color

A

3.B

Contrast

1.4.3

Contrast (Minimum)

AA

3.C

Size, shape, location

1.3.3

Sensory Characteristics

A

3.D

User Preferences

     

3.E

Color Adjustment

     

3.F

Non-text Objects

1.1.1

Non-text Content

A

3.G

Human Language

3.1.1

Language of Page

A

3.H

Language of Parts

3.1.2

Language of Parts

AA

3.I

Pausing

2.2.2

Pause, Stop, Hide

A

3.J

Flashing (Content and User Interfaces)

2.3.1

Three Flashes or Below Threshold

A

3.K

Consistent Identification

3.2.4

Consistent Identification

AA

3.L

Audio Turnoff

1.4.2

Audio Control

A

3.M

Reading Sequence

1.3.2

Meaningful Sequence

A

3.N

Link Purpose

2.4.4

Link Purpose (In Context)

A

3.O

Information and Relationships

1.3.1

Info and Relationships

A

3.P

User Interface Components

4.1.2

Name, Role, Value

A

3.Q

Disruption of Access Features

     

3.R

Timing

2.2.1

Timing Adjustable

A

3.S

Keyboard Operation

2.1.1
2.1.2

Keyboard
No Keyboard Trap

A
A

3.SS

Visual Indication of Keyboard Shortcuts

     

3.T

Focus Indicator

2.4.7

Focus Visible

AA

3.U

AT Interoperability

4.1.2

Name, Role, Value

A

3.V

Accessibility Services

     

3.VV

Assistive Technology

     

3.W

Multiple Ways

2.4.5

Multiple Ways

AA

3.X

Labels or Instructions

3.3.2

Labels or Instructions

A

3.Y

On Focus

3.2.1

On Focus

A

3.Z

On Input

3.2.2

On Input

A

3.AA Error Identificatio 3.3.1 Error Identificatio A
3.BB Headings and Labels 2.4.5 Labels Descriptive AA
5.A Captions and Transcripts 1.2.1

1.2.2 1.2.4 1.2.9
Audio-only and Video-only (Prerecorded)
Captions (Prerecorded)
Captions (Live)
Live audio-only

A

A
AA
AAA

5.B Video Description 1.2.1

1.2.3
Audio-only and Video-only (Prerecorded)
Audio Description or Full Text Alternative
A
  Advisory Note 4.1.1 Parsing A
    2.4.1 Bypass Blocks A
    2.4.2 Page Titled A
    2.4.3 Focus Order A
    2.1.1 No Keyboard Trap

A


8.3   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

FPC —>

Disabilities

A

B

C

D

E

G

H

I

J

Blindness

X                

Low Vision

  X              

Color deficiency

    X            

Deafness

      X          

Hard of hearing

        X        

Deaf-blindness

X     X          

Other hearing/vision loss

                 

Mobility

            X X  

Dexterity

            X X  

Speech

          X      

Cognitive, language, learning

                X

 

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

FPC —>

Provision

A

B

C

D

E

G

H

I

J

1-A

Closed Functionality

X X X X X X X X X

1-B

Biometric ID

X X X X X X X X X

1-C

Pass Through

X X   X X       X

1-D

Audio information

      X X       a

1-E

Visual Information

X X             a

1-F

Color

X   X           a

1-G

Text size

  X             a

1-H

Speech Operation

      a a X     a

2.1.A

Reflectance Contrast for Legends and Passive Displays

  X       X      

2.1.B

Flashing

                 

2.1.C

Mechanical Controls

X X         X X a

2.1.D

Touch Operated

X X         X X a

2.1.E

Standard Connection

X X X X X X X X X

2.1.F

Installed or Free-Standing Products

            X X  

2.2.A

Magnetic Coupling

      a X        

2.2.B

Interference with Hearing Device

        X        

2.2.C

Audio Connection

      a X   a a  

2.2.D

Volume

        X       a

2.2.E

Volume (Gain)

        X       a

2.2.F

Volume Reset

        X        

3.A

Color

X   X           a

3.B

Contrast

  X X           a

3.C

Size, shape, location

X               a

3.D

User Preferences

  X X           a

3.E

Color Adjustment

  X X            

3.F

Non-text Objects

X X X X X X X X X

3.G

Human Language

X               a

3.H

Language of Parts

X               a

3.I

Pausing

X X             X

3.J

Flashing

                 

3.K

Consistent Identification

X               X

3.L

Audio Turnoff

X               X

3.M

Reading Sequence

X a         a a X

3.N

Link Purpose

X a             X

3.O

Information and Relationships

X               X

3.P

User Interface Components

X X X X X X X X X

3.Q

Disruption of Access Features

X X X X X X X X X

3.R

Timing

X a   a     X X X

3.S

Keyboard Operation

X a       a X X  

3.SS

Visual Indication of Keyboard Shortcuts

X a       a X X a

3.T

Focus Indicator

  X         X X  

3.U

AT Interoperability

X X X X X X X X X

3.V

Accessibility Services

X X X X X X X X X

3.VV

Assistive Technology

X X X X X X X X X

3.W

Multiple Ways

X a         a a X

3.X

Labels or Instructions

X a a     a a a X

3.Y

On Focus

X a             X

3.Z

On Input

X a             X

3.AA

Error Identification

X               X

3.BB

Headings and Labels

X               X

4.A

Caption Process

      X X       X

4.B

Supplemental Audio Playback (Process?)

X X             X

4.C

Access to Caption and Video Controls

X X   X X   X X X

5.A

Captions and Transcripts

      X X       X

5.B

Video Description

X X             X

5.C

Interactive Elements

X X X X X X X X X

6.A

Real-Time Text Reliability & Interoperability

      X a X      

6.B

Voice Terminal Hardware & Software

      X a X      

6.C

IVR, Auto-Attendant and Messaging

      X X       X

6.D

Caller and Status info

X     X   a     a

6.E

Video Support

      X         a

6.F

Audio Clarity for VoIP

        X        

6.G

External alerting devices

      X a       a

7.A

Accessible Output

X X X X X X X X X

7.B

Preserve Accessibility Information

X X X X X X X X X

7.C

Prompts

X X X X X X X X X

7.D

Accessible Templates

X X X X X X X X X

D:1.1-A

Accessible Documentation and Features

X X X X X X X X X

D:1.1-B

Keyboard Shortcuts

X X X X X X X X X

D:1.2-A

Support Services

X X X X X X X X X

D:1.2-B

Manufacturer Contact

X X X X X X X X X

D:1.2-C

Training

X X X X X X X X X

D:2.A

Relay Services Accessibility

      X a X      

D:2.B

Video Support

      X         a

D:2.C

Accessibility Configuration

X X X X X X X X X

D:2.D

Accessible Content

X X X X X X X X X


 


 

9   Annexes

9.1   TEITAC Organizational Members List
9.2   Related Federal Legislation Protecting the Rights of Individuals with Disabilities
9.3   Charter
9.4   Operating Protocols

9.1   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

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

9.3   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

9.4   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

 


 

Notes

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/, 11 December 2007, W3C Working Draft.  Latest version at http://www.w3.org/TR/WCAG20/.  Copyright, 2007 W3C (MIT, ERCIM, Keio) http://www.w3.org/Consortium/Legal/2002/copyright-documents-20021231.