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:

  • The text of the provision.  This is the normative language recommended by the Committee.
  • Accompanying notes.  There are three kinds of notes, described below.
  • Additional information.  Additional information about the provision, described below.  This text is included for informational purposes and is not intended to be included in the standards themselves.

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

a NON-TEXT OBJECT 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:

  • "Access may be delivered via built-in access features or through compatibility with assistive technology."  In this example, either of the two approaches is equally acceptable.  A product is not required to provide both methods (for example, offering a user a choice between the approaches).
  • "A mechanism must be provided to either pause, stop, or hide moving or blinking content that is pure decoration." In this example, a product may choose at least one of the three options listed:  (1) pause, or (2) stop, or (3) hide.

Notes Included with the Provisions

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

  • Notes in the provisions.  These are explanatory notes, intended to accompany the provision. They are informative, not normative.  They are listed immediately below the provision text in a numbered list.
  • Rationale.  These are brief text that explains the purpose of the provision or provides additional explanation about the deliberations of the Committee. They are intended to help the Access Board understand the provision more clearly. These notes are not part of the provision text.
  • Advisory Notes to the Access Board. In a very few cases, the Committee wishes to add an additional recommendation to the Access Board that relates directly to how the provision will be completed or implemented. Provisions without consensus also include viewpoints on the drafts from Committee members. These notes are not part of the provision text.

Additional Information Included with the Provisions

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

  • Text from – The subcommittee with original responsibility for the provision.
  • Source – The paragraph numbers from the current Section 508 and Section 255 used as the starting point for the recommendation. Where there is no change, this is indicated.
  • External Reference – Any other legislation, standards or guidelines referenced in the provision, or with which the provision is harmonized.
  • Impact – The impact of the change in the provision from the current 508 and 255 language. In some cases, there are alternate estimates of impact included in the report.
  • Testability – Inspection, Expert Review or Formal Test Method (see the section of this report on “Testability” for more information).
  • Disabilities – The disabilities for which this recommendation is intended to remove barriers.

General Exceptions

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.

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

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

  • L1 is the RELATIVE LUMINANCE of the lighter of the foreground or background colors, and
  • L2 is the RELATIVE LUMINANCE of the darker of the foreground or background colors.

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.

  • Where N is the number of sources that are FLASHING together more than 3 times per second within a 0.024 steradian circle
  • Where AREA is the summed area of the N sources, measured in steradians (at the minimum typical/expected viewing distance)
  • And where sources that are separated by less than .4 degrees ( ~2mm at 12 inch viewing distance) are treated as a single source with AREA being the area from edge to edge of the group.

Note 1:  Most products can safely use a minimum typical / expected viewing distance of 12 inches where 0.006 steradians would be a circle of 1.05 inch diameter.
Note 2:  Red sources with wavelengths of 590 or more nm are especially provocative since, due to the way the eye and brain process light with longer wavelengths.
Note 3:  Each of the following examples would meet option 5 (when viewed from at least 12 inches) even when all of the sources are flashing together at more than 3 Hz:

  • 1 round LED with a diameter of 5 mm or less, and no more than 32,000 cd/m2.
  • 1 rectangular indicator with a size of 10 by 20 mm or less, and no more than 2,100 cd/m2.
  • 3 square indicators (within a 2.1 inch circle) each 6 mm square or less, and no more than 3,500 cd/m2.
  • 4 round indicators (within a 2.1 inch circle) each 8 mm in diameter or less, and no more than 1,400 cd/m2.
  • 5 rectangular indicators (within a 2.1 inch circle) each 6 by 2 mm, and no more than 6,100 cd/m2.

(For light sources that are Red flashes (that have a 590 nm wavelength or longer) the values for luminance in this note should be divided by 8.)
(For comparison, the maximum brightness of a white screen on an LCD computer monitor is about 200 to 400 cd/m2.)


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

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

1. Very bright point sources or very bright small sources can be a problem (per Graham Harding.)
2. Very bright point sources or very bright small sources should be allowed if they flash less than 3 per second.
3. Flashing above 3 per second should be allowed if is as equivalently safe as with the Software flash thresholds.
4. Some metrics for identifying ‘equivalently safe’ were created but more time is needed by everyone to study them and their derivation before they are used by anyone including the Access Board.
5. The numbers were included in this report in order to facilitate review by different parties.

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

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

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

Interconnected Voice over Internet Protocol (VoIP) Product:  A product that is used to provide INTERCONNECTED VOIP SERVICE
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.

  • Headphone and headsets that connect to a product via a standard connector are not considered as products that are "held up to the ear" but rather alternate speakers to a device.
  • Handsets are considered products or part of a product.

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

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

Undue Burden:  Undue burden means significant difficulty or expense. In determining whether an action would result in an undue burden, an AGENCY 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:

  • 2.1-E - Connector or Connection Language
  • 3-F - All Non-Text Objects
  • 3-G - Human Language
  • 3-H - Language of Parts
  • 3-N - Link Purpose
  • 3-O - Information and Relationships
  • 3-P - User Interface Components (no consensus)
  • 3-Q - Disruption of Access Features
  • 3-U - AT Interoperability (partial consensus)
  • 3-V - Accessibility Services
  • 3-VV - Assistive Technology (no consensus)

Additional Information

  • Text from Self Contained, Closed
  • Source:  {508}1194.25(a)
  • Testability:  Expert evaluation
  • Disabilities:  All

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

  • Text from:  General
  • Source:  {508}1194.25(d), {508}1194.26(c) (was 1.2-D in Oct 26 draft)
  • Testability:  Inspection
  • Disabilities:  All that could be caused by loss of a relevant body part or function

1-C:  Pass Through
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

  • Text from Telecommunications
  • Source:  {508}1194.23(j), {255}1193.37
  • Testability:  Inspection
  • Disabilities:  Hearing, vision, cognition

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

  • Text from Self-Contained/Closed
  • Source:  {255}1194.43(d)
  • Testability:  Expert evaluation
  • Disabilities:  Deafness, Hard of Hearing

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

  • Text from Web/Software
  • Source:  {508}1194.25(g) and 1194.21(i):  {255}1194.41(c)
  • Impact:  No change
  • External Reference:  Harmonized with WCAG 2.0-1.4.1 Use of Color (Level A) and ISO 9241-171
  • Testability:  Inspection
  • Disabilities:  Color deficiency/Colorblindness

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

  • Text from Telecommunications - Section 6:  Caller and Status Information
  • Source:  {508}1194.23(e)
  • Impact: 
  • External Reference: 
  • Testability:  Inspection
  • Disabilities:  Speech

2. Requirements for Hardware Aspects of Products

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

  • Text from Hardware
  • Source:  {508}1194.21(j) & .25(h)
  • Testability:  Formal test method
  • Disabilities:  Low vision

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

  • Text from:  New
  • Source:  {508}1194.21(k) 1194.22(j) 1194.25(i), and {255}1193.43(f)
  • Impact:  Negative cost - The change saves money (e.g., special circuitry not needed to control frequency of status LEDs) and provides additional flexibility to industry for non-critical stimuli.
  • Testability:  Inspection
  • Disabilities:  Photosensitive seizure disorder

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

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

Rationale
Changes in this section were limited to the addition of the "Simultaneous controls" to the operability requirements and reordering requirements to align the adjective "tight" with "grasping". This requirement does not imply that a product must be entirely operable with one hand (e.g., product could be placed on a surface).

Additional Information

  • Text from Hardware
  • Source:  {508} 1194.26(a); 1194.23(k)
  • Testability:  Inspection
  • Disabilities:  Mobility, dexterity, vision

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

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

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

Additional Information

  • Text from Hardware
  • Source:  {508} 1194.26(b); {508} 1194.25(c)
  • Testability:  Inspection
  • Disabilities:  Mobility, dexterity, vision

2.1-E:  Standard User Interface Connection
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

  • Text from Hardware and Telecommunications
  • Source:  {508} 1194.26(d)
  • Testability:  Inspection
  • Disabilities:  All

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.

  • Additional Information
  • Text from Hardware
  • Source:  {508} 1194.25(j), {255}1193.41(f)
  • External Reference:  Harmonized with ADAAG
  • Testability:  Inspection
  • Disabilities:  Mobility, dexterity

2.2 If the Product has Speech Output or Throughput

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

  • Text from Hardware and Telecommunications
  • Source:  {508}1194.23(h), {255}1193.43(i)
  • External Reference:  ANSI C63.19 (2007), TIA-1083
  • Testability:  Formal test method
  • Disabilities:  Hard of Hearing

2.2-B:  Interference with Hearing Device
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:

  • For cellular and PCS handsets:  M3 or M4 and T3 or T4 measurement rating per ANSI C63.19 (2007)
  • For digital wireline cordless devices:  TIA-1083

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

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

Additional Information

  • Text from Hardware and Telecommunications
  • Source:  {508}1194.23(i), {255}1193.43(h)
  • Impact:  minimal
  • External Reference:  ANSI C63.19 (2007), TIA-1083
  • Testability:  Formal test method
  • Disabilities:  Hearing, Hard of Hearing

2.2-C:  Audio Connection
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

  • Public phones have amplification and coupling, which meets the needs of almost all users, so a jack would not be needed.
  • Audio output critical to use of kiosks and other products where user needs to hear information from product in order to use it. (Either usual output or speech output.)
  • Users should not be required to carry ‘all’ adapters with them, so public systems should not require them to have an adapter to use the product (other than a simple 2.5 to 3.5 or 3.5 to 2.5 adapter)
  • The RJ-9/RJ-10/RJ-11/4P4C (or the final standard name) connector has adapters as does Bluetooth and RCA and USB. This note was added since there was concern that unless in a note, purchasing agents may not recognize it as allowable.
  • Addresses the issue of “private listening,” which is provided via the standard handset.
  • Kiosks with keyboards usually require blind people to have both hands free.
  • Addresses the key need for such a connection on kiosks – and that audio connection be in a standard form that people who are blind will have audio connector for.
  • Addresses the need to have an audio connector somewhere on public Audio or Audio-Video systems so that public assistive listening device systems can be connected.

How it would apply

  • Public phones would use (1 - Conforming Handset).
  • Office phones would likely use (3 – Any Hardwire Connection with Adapter Avail) but could use (2 – Audio Jack) or (4 – Wireless Adapter).
  • Cell phones would likely use (2 – Audio Jack) or (3 – Any Hardwire Connection with Adapter Avail) but could use (4 – Wireless Adapter) if small, long life Bluetooth adapters become available.
  • Computers with build in speech conversation could use (2 – Audio Jack), which most have already, or (3 – Any Hardwire Connection with Adapter Avail) or (4 – Wireless Adapter).
  • Kiosks without keyboards could use (1 - Conforming Handset) or (2 – Audio Jack) or both.
  • Kiosks WITH keyboards would have to use (b – Audio Jack) or, of course, both (1 - Conforming Handset) and (2 – Audio Jack).
  • Television sets would use (3 – Any Hardwire Connection with Adapter Avail) or (5 - Public Display Only).
  • Public address systems and custom designed public video displays would use (5 – Public Display Only), which only requires an audio connection that users will already have.

Additional Information

  • Text from Hardware
  • Source:  {508} 1194.25(e); {255}1193.51(b), {255}1193.43(g)
  • Testability:  Inspection
  • Disabilities:  Hard of hearing

2.2-D:  Volume
For products that generate speech output delivered via speakers:

1. Products designed for communal use must be capable of a volume level of at least 80 dB SPL RMS.
2. Products not designed for communal use must be capable of a volume level of at least 65 dB SPL RMS.
3. All products must have less than 12 dB symmetrical clipping at all volume levels including maximum volume level.
4. Volume on audio jacks must be user adjustable.

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

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

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

Additional Information

  • Text from Self-Contained/Closed
  • Source:  {508}1194.25(f), {255}1193.43(e)
  • Testability:  Formal test method
  • Disabilities:  Hard of hearing

2.2-E - Volume (Gain)
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

  • Text from Telecommunications
  • Source:  {508}1194.23(f), {255}1193.43(e)
  • External Reference:  FCC §68.317, ANSI/EIA-470-A-1987 (for analog telephones) and ANSI/EIA/TIA-571-1991 (for digital telephones)
  • Testability:  Formal test method
  • Disabilities:  Hard of hearing

2.2-F - Volume Reset
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.

  • Text from Telecommunications
  • Source:  {508}1194.23(g)
  • External Reference:  FCC Memorandum Opinion and Order DA 01-578
  • Testability:  Inspection
  • Disabilities:  None

3. Requirements for User Interface and Electronic Content

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

  • Text from Web and Software
  • Source:  {508}1194.21 (i), 1194.22(c) and 1194.25(h), {255}1193.41(c)
  • Impact:  Minimal:  Currently the Section 508 software provision on color is equivalent to this one so no impact for software. 255 also has an equivalent provision so there is no impact to telecom products. The Web provision allows for the color to be programmatically determinable so there is a slight impact there.
  • External Reference:  Harmonized with WCAG 2.0-1.4.1 Use of Color (Level A) and ISO 9241.171
  • Testability:  Inspection
  • Disabilities:  Color deficiency/Colorblindness

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

  • Text from Web and Software
  • Source:  {508}1194.21(j)
  • Impact:  There are two opinions about the impact of this provision
    Version 1:  Significant:  There are currently no measurable criteria for contrast in Section 508.
    Version 2:  Minimal:  Simple tools are available to evaluate contrast.
  • External Reference:  Harmonized with WCAG 2.0-1.4.3 Contrast (Minimum) (Level AA) and ISO 9241-171
  • Testability:  Formal test method
  • Disabilities:  Low Vision, Color deficiency/Colorblindness (?)

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

  • Text from Web and Software
  • Source:  new
  • Impact:  Minimal:  No current requirement in Section 508.
  • External Reference:  Harmonized with WCAG 2.0-1.3.3 Sensory Characteristics (Level A)
  • Testability:  Inspection
  • Disabilities:  Blindness

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

  • Text from Web and Software
  • Source:  {508}1194.21(g)
  • Impact:  Minimal for desktop platforms. Significant for websites and other types of platforms such as mobile devices.
  • External Reference:  WCAG 2.0-1.4.3 Contrast (Minimum) (Level AA)
  • Testability:  If platform settings, inspection; if no platform settings, formal test method
  • Disabilities:  Low vision, Color deficiency/Colorblindness

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

  • Text from Web and Software
  • Source:  {508}1194.21(j)
  • Impact:  Minimal for desktop software. Potentially significant for Web sites and applications and non-desktop software platforms that allow color and contrast adjustments. It is the same as current Section 508 software provision except it provides a testable measurement of contrast that is harmonized with WCAG 2.0. In this case, the higher ratio of 7:1 was chosen because this is not the contrast required for presentation but the contrast a user should be permitted to achieve through adjustments. It is therefore reasonable to require a higher contrast ratio.
  • External Reference:  WCAG 2.0-1.4.6 Contrast (Enhanced) (Level AAA)
  • Testability:  Formal test method
  • Disabilities:  Color deficiency/Colorblindness, Low Vision

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

  • Text from Web and Software
  • Source:  {508}1194.22(a)
  • Impact:  Minimal:  Section 508 already has the requirement for text alternatives. This provision provides more guidance on appropriate text alternatives and allows some things that were not allowed before so may even save some money.
  • External Reference:  Harmonized with WCAG 2.0-1.1.1 Non-text Content (Level A)
  • Testability:  Inspection
  • Disabilities:  All

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

  • Text from Web and Software
  • Source:  new
  • Impact:  Minimal for HTML Web pages. Could be significant for other document types.  There is no current requirement in Section 508 but adding the language identifier at the document level is a small amount of effort.
  • External Reference:  Harmonized with WCAG 2.0-3.1.1 Language of Page (Level A)
  • Testability:  Inspection
  • Disabilities:  Blindness

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

  • Text from Web and Software
  • Source:  new
  • Impact: 
    Version 1:  Significant:  Entire documents must be scanned for changes in natural language and programmatically identified.
    Version 2:  Not significant over time. This is something where tools can and will be built that will do much or all of this automatically.
  • External Reference:  Harmonized with WCAG 2.0-3.1.2 Language of Parts (Level AA)
  • Testability:  Inspection
  • Disabilities:  Blindness

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

  • Text from Web and Software
  • Source:  {508}1194.21(h)
  • Impact: 
    Version 1:  Significant:  User agents provide support for this on some Web technologies. But for other Web technologies and for software, the application developer must provide this support.
    Version 2:  Not Significant once techniques are known (and by the time this is in effect) it should not be hard to do this as a routine step and will be appreciated by many mainstream as well.
  • External Reference:  Harmonized with WCAG 2.0-2.2.2 Pausing (Level AA)
  • Testability:  Inspection
  • Disabilities:  Blindness, Low vision, Cognitive/language/learning

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

  • Text from Web and Software
  • Source:  {508}1194.21(k) 1194.22(j) 1194.25(i), and {255}1193.43(f)
  • Impact:  None:  Currently 508 doesn't allow any flashing at all within the range of 2 to 55 Hz. This provision is less strict as it only applies to flashing that occupies a large area of the user's field of vision.
  • External Reference:  Harmonized with WCAG 2.0-2.3.1 Three Flashes or Below Threshold (Level A)
  • Testability:  Inspection (under 3 times per second) or Formal Test Method (using General or Red Flash Thresholds)
  • Disabilities:  Photosensitive seizure disorder

3-K:  Consistent Identification
Components from a single source that have the same functionality within a product must be identified consistently.

Rationale
Helps people with cognitive disabilities. Supports use of assistive technology.

Additional Information

  • Text from Web and Software
  • Source:  {508}1194.21(e)
  • Impact: 
    Version 1:  Significant:  Requires manual assessment and correction. Cost to remediate existing applications could be very high. Subjectivity of the testing could also increase expense.
    Version 2:  Minimal or no impact for new material:  It doesn’t require additional work – just using a consistent label when you label in the first place.  Good human factors.
  • External Reference:  Harmonized with WCAG 2.0-3.2.4 Consistent Identification (Level AA)
  • Testability:  Inspection
  • Disabilities:  Blindness, Cognitive/language/learning

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

  • Text from Web and Software
  • Source:  {508}1194.25(e) - Second sentence
  • Impact:  Minimal:  No current Section 508 requirement but may not be a common occurrence.
  • External Reference:  Harmonized with ISO 9241-171, HFES 200, WCAG 2.0-1.4.2 Audio Control (Level A)
  • Testability:  Inspection
  • Disabilities:  Blindness, Cognitive/language/learning

3-M:  Reading Sequence
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

  • Text from Web and Software and Closed Products
  • Source:  New and {508}1194.22(d)
  • Impact:  Minimal for software. Significant for Web pages and other types of electronic content. Need tools to “linearize” content. Manual checking required.
  • External Reference:  Harmonized with WCAG 2.0-1.3.2 Meaningful Sequence (Level A) and 2.4.3 Focus Order (Level A). Similar to recommendation in ISO 9241-171
  • Testability:  Inspection
  • Disabilities:  Blindness, Cognitive/language/learning

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

  • Text from Web and Software
  • Source:  New
  • Impact:  Significant:  Impacts any page that has vague or duplicated link text. Requires manual testing.
  • External Reference:  Harmonized with WCAG 2.0-2.4.4 Link Purpose (In Context) (Level A)
  • Testability:  Expert evaluation
  • Disabilities:  Blindness, Cognitive/language/learning

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

  • Text from Web and Software
  • Source:  {508}1194.22(g), (h), (i), & (n), .21(l)
  • Impact:  Significant:  Currently Section 508 only requires markup for tables. This provision requires that apparent section headings, lists, etc. be coded as such. Also extends to all types of electronic documents, not just Web pages. Significant positive impact to end users and agencies. AT-E&IT interoperability will be improved and less customization should be required.
  • External Reference:  Harmonized with WCAG 2.0-1.3.1 Info and Relationships(Level A)
  • Testability:  Inspection
  • Disabilities:  Blindness, Cognitive/language/learning

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

  • Text from Web and Software
  • Source:  {508}1194.21(b)
  • Impact:  None:  Functionally equivalent to the current 508 provision but clarified for testability. If a suggestion to reintroduce "assistive technology" is accepted, there will be significant additional cost.
  • Testability:  Expert evaluation
  • Disabilities:  All

3-R:  Timing
For each time limit that is set by the product, at least one of the following must happen:

1. Turn off:  the user is allowed to turn off the time limit before encountering it; or
2. Adjust:  the user is allowed to adjust the time limit before encountering it over a wide range that is at least ten times the length of the default setting; or
3. Extend:  the user is warned before time expires and given at least 20 seconds to extend the time limit with a simple action (for example, "hit any key"), and the user is allowed to extend the time limit at least ten times.

There are three exceptions:

1. Real-time Exception:  the time limit is a required part of a real-time event (for example, an auction), and no alternative to the time limit is possible; or
2. Essential Exception:  the time limit is part of an activity where timing is essential and time limits can not be extended further without invalidating the activity.
3. 20 Hour Exception:  the time limit is longer than 20 hours.

Additional Information

  • Text from Web and Software
  • Source:  New (incorporates {508}1194.22(p), {508}1194.23(d), {508}1194.25(b), {255}1193.41(g)
  • Impact:  None for Web sites. Minimal for software. Currently 508 only allows one strategy for dealing with timeouts on Web sites. Any current 508 compliant Web site will continue to comply with this provision. New requirement for software. Large positive impact to end users.
  • External Reference:  Harmonized with WCAG 2.0-2.2.1 Timing Adjustable (Level A) and ISO 9241-171
  • Testability:  Inspection
  • Disabilities:  Blindness, Dexterity, Cognitive/language/learning

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

  • Text from Web and Software
  • Source:  {508}1194.21(a)
  • Impact:  None for software. Minimal for Web pages. Functionally equivalent to the current Section 508 software keyboard requirement. New requirement for Web pages. In many cases, keyboard operation of Web pages is provided by the user agent. Rich Internet Applications must ensure keyboard operation though.
  • External Reference:  Harmonized with WCAG 2.0-2.1.1 Keyboard (Level A) and ISO 9241-171
  • Testability:  Inspection
  • Disabilities:  Blindness, Dexterity

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

  • Text from Web and Software
  • Source:  {508}1194.21(c)
  • Impact: 
    Version 1:  Significant:  "Well-defined" focus cursor is currently required by 508. New provision provides testable measurement for "highly visual". Significant work for some desktop platforms, applications, and for Web 2.0 style applications.
    Version 2:  Impact:  None.  This is simply a clarification of what "well defined' was originally intended to mean.
  • External Reference:  Harmonized with WCAG 2.0-2.4.7 Focus Visible (Level AA) and ISO 9241-171
  • Testability:  Inspection
  • Disabilities:  Low Vision, Dexterity

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

  • Text from Web and Software
  • Source:  New
  • Impact:  None for current desktop operating system platforms. Significant for applications that are also platforms and for non-desktop platforms. All desktop operating system platforms meet the requirement. Not all applications that are also platforms and non-desktop platforms meet the requirement.
  • External Reference:  Harmonized with 9241-171. Related to WCAG 2.0-4.1.2 Name, Role, Value (Level A)
  • Testability:
  • Disabilities:  All

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

  • Text from Web and Software
  • Source:  New
  • External Reference:  Harmonized with WCAG 2.0-2.4.5 Multiple Ways (Level AA)
  • Testability:  Inspection
  • Disabilities:  Blindness, Cognitive/language/learning

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

  • Text from Web and Software
  • Source:  New
  • External Reference:  Harmonized with WCAG 2.0-3.3.2 Labels or Instructions(Level A)
  • Testability:  Inspection
  • Disabilities:  Blindness, Cognitive/language/learning

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

  • Text from Web and Software
  • Source:  New
  • External Reference:  Harmonized with WCAG 2.0-3.2.1 On Focus (Level A)
  • Testability:  Inspection
  • Disabilities:  Blindness, Cognitive/language/learning

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

  • Text from Web and Software
  • Source:  New
  • External Reference:  Harmonized with WCAG 2.0-3.2.2 On Input (Level A)
  • Testability:  Inspection
  • Disabilities:  Blindness, Cognitive/language/learning

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

  • Text from Web and Software
  • Source:  New
  • External Reference:  Harmonized with WCAG 2.0-3.3.1 Error Identification (Level A)
  • Testability:  Inspection
  • Disabilities:  Blindness, Cognitive/language/learning

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

  • Text from Web and Software
  • Source:  New
  • External Reference:  Harmonized with WCAG 2.0-2.4.6 Labels Descriptive (Level AA)
  • Testability:  Inspection
  • Disabilities:  Blindness, Cognitive/language/learning

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

  • Text from A/V
  • Source:  {508}1194.24(a)
  • External Reference:  CEA 608, CEA 708
  • Disabilities:  Deafness, Hard of hearing, Cognitive/language/learning

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

  • Analog-signal tuners must be equipped with Secondary Audio Program (SAP) process circuitry as defined by the Multichannel Television Sound standard developed by the Broadcast Television Systems Committee (BTSC) in 1984.
  • Digital television tuners must support processing of VIDEO DESCRIPTION when encoded as a Visually Impaired (VI) associated audio service that is provided as a complete program mix containing VIDEO DESCRIPTION according to the A/53 standard developed by the Advanced Television Systems Committee (ATSC).

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

Additional Information

  • Text from A/V
  • Source:  {508}1194.24(b)
  • Testability:  Inspection
  • Disabilities:  Blindness, Low vision, Cognitive/language/learning

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

For captioning:

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

Rationale

  • Manufacturers are encouraged to use buttons with unique shapes to enable persons with low vision to make a tactile distinction among them.
  • For products that are covered under 4-A.1 and 4-B, the user controls needed to access closed captioning and VIDEO DESCRIPTION must be comparable in prominence to the play controls or channel selector.
  • For laptops, a keyboard equivalent would be acceptable.

Additional Information

  • Text from A/V
  • Source:  new
  • Testability:  Inspection
  • Disabilities:  Deafness, Hard of hearing, Blindness, Low Vision, Dexterity, Mobility, Cognitive/language/learning

5. Requirements for Audio and/or Video Content

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

  • Text from A/V
  • Source:  {508}1194.24(c)
  • External Reference:  WCAG 2.0-1.2.1 Captions (Prerecorded) (Level A)
  • Testability:  Inspection
  • Disabilities:  Deafness, Hard of hearing, Cognitive/language/learning

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

  • Text from A/V
  • Source:  {508}1194.24(d)
  • External Reference:  WCAG 2.0-1.2.2 Audio Description or Full Text Alternative (Level A)
  • Testability:  Inspection; possibly expert evaluation regarding "informational content"
  • Disabilities:  Blindness, Low vision, Cognitive/language/learning

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

  • Text from A/V
  • Source:  {508}1194.24(d) & .22(b)
  • External Reference:  Several WCAG 2.0 guidelines relate
  • Testability:  Inspection; possibly expert evaluation regarding "interactive elements" and "content"
  • Disabilities:  All

6. Additional Requirements for Real-Time Voice Conversation Functionality

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

  • Text from Telecommunications
  • Source:  {508]1194.23(b), {255}1193.51(e)
  • Impact:  Difficult to assess. Short term more expensive. Long term less expensive. This is a new technology so initially there are high costs to figure out and decided on common approaches.
  • Testability:  Inspection and formal test methods
  • Disabilities:  Deafness, Hard of Hearing, Speech

6-B:  Voice Terminal Hardware and Software
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

  • Need to be sure 255 is addressed for #3.
  • Need to determine the right word to use "system" vs. "protocol" in Note 2.
  • Need to resolve Bluetooth question.

Additional Information

  • Text from Telecommunications
  • Source:  {508}1194.23(a), {255}1193.51(d)
  • Impact:  Difficult to assess. Short term more expensive. Long term less expensive. This is a new technology so initially there are high costs to figure out and decided on common approaches.
  • Testability:  Inspection
  • Disabilities:  Deafness, Hard of Hearing, Speech

6-C:  IVR, Auto-Attendant and Messaging
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

  • Text from Telecommunications
  • Source:  {508}1194.23(c)
  • Testability:  Inspection (#1,3,4) and Formal test method (#2)
  • Disabilities:  Deafness, Hard of hearing, Cognitive/language/learning

6-D:  Caller and Status Information (no consensus)
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

  • Text from Telecommunications
  • Source:  new
  • Testability:  Formal test methods and inspection; will depend on how "X format" is defined."
  • Disabilities:  Deafness

6-F:  Audio Clarity for Interconnected VoIP
Interconnected VoIP telephones and interconnected VoIP telephone-emulation software must be able to transmit and receive speech that is digitally encoded in the manner specified by International Telecommunication Union (ITU) Standards G.711.For closed systems, other standards that provide equivalent acoustic performance may be used if conversion to G.711 at the borders of the closed system is supported.
Note 1: It is suggested that G.722 or equivalent also be provided for wideband interconnected VoIP audio clarity.

Additional Information

  • Text from Committee
  • Source:  new
  • External Reference:  ITU G.711
  • Testability:  Formal test methods and inspection
  • Disabilities:  Hard of hearing

6-G:  External Alerting Devices
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

  • Text from Committee
  • Source:  new
  • Testability:  Formal test methods and inspection
  • Disabilities:  Deafness

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

  • Text from Web and Software
  • Source:  new
  • External Reference:  ATAG, ISO 9241-171
  • Testability:  Inspection
  • Disabilities:  All

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

  • Text from Web and Software
  • Source:  new
  • External Reference:  ATAG, ISO 9241.71
  • Testability:  Inspection; possibly some expert evaluation
  • Disabilities:  All

7-C:  Prompts (no consensus)
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:

  • Anything that changes user preferences, keyboard commands, special accessibility features that the product supports (i.e., captioning), and features that allow users to adjust the product to their needs.
  • Any features that are used to meet this standard or to enhance accessibility

Documentation may also need to suggest how a platform should document (for their application developers) how to support accessibility features that the platform provides to users.

Additional Information

  • Text from Documentation and Technical Support
  • Source:  {508}1194.41(a), {508}194.41(b), {255}1193.33(a)(1)and {255}1193.33(a)(2)
  • Impact:  No Change
  • Testability:  Tested according to the other provisions (ref. to "provisions in 1194 Subparts B and C")
  • Disabilities:  All

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

  • Text from Documentation and Technical Support
  • Source:  {508}1194.41(c) and {255}1193.33(a)(3)
  • Impact: 
  • Testability:  Expert evaluation
  • Disabilities:  All

1.2-B - Manufacturer Contact
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

  • Text from Telecommunications
  • Source:  Section 255
  • Disabilities:  All

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

  • Text from Telecommunications
  • Source:  Section 255
  • Disabilities:  All

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

  • Text from Telecommunications
  • Source:  new
  • Testability:  Inspection
  • Disabilities:  Deafness, Speech

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

  • Text from Telecommunications
  • Source:  new
  • Testability:  Inspection
  • Disabilities:  Deafness

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

  • Text from Telecommunications
  • Source:  new
  • Disabilities:  All

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

  • Text from Web/Software
  • Source:  new
  • Disabilities:  All

Advisory Notes
These are recommendations to the Access Board for advisory notes, which can be used to communicate best practices. They are not intended to be full provisions.

Subpart A:  Inherently Visual E&IT
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.

  • External References:  Plain Language Tools, Office of the Federal Register

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.

  • External References:
    • WCAG 2.0-3.3.4-Error Prevention (Legal, Financial, Data)
    • WCAG 2.0-3.3.6-Error Prevention (All)

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.

  • External references:  WCAG 2.0-4.1.1 Parsing (Level A)

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:

  • 3.4.2-Page Titles
  • 2.4.3-Focus Order
  • 2.1.2 No Keyboard Trap
  • 2.4.1 Bypass Blocks

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.