EWG:Draft Oct 26

Editorial Working Group > October 26 Draft

This draft is "locked" and released for review from October 29 - November 12 (2 weeks) and will be used at the November plenary meeting

Related Pages

• Status Spreadsheet - an overview of the status of the work
• The Sandbox (The Updates Page) - Any updated text, comments (and minority report comments) and suggested text for provisions are collected on a single page, and cross-linked from each affected provision.

Subpart A

Section 1194.1 Purpose

(This section has alternate versions. All rationale text is at the end of this section.)

Version 1
The purpose of this part is to implement section 508 of the Rehabilitation Act of 1973, as amended (29 U.S.C. 794d). Section 508 requires that when Federal agencies develop, procure, maintain, or use electronic and information technology, Federal employees with disabilities have access to and use of information and data 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.

Version 2
Insert provision to address comparable access in Section 1194.2 Application

Notes:
(This explanatory material is recommended for inclusion with both versions)

• 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 X. It should be noted that the determination of timely, accurate, complete, and efficient will not be a quantifiable measure.

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.

Discussion of Work in Progress
* EWG needs to insert Subpart name.

• Status: Done ' See additional proposals for this provision to incorporate 255
• Text from Subpart A Subcommittee
• Source: {508}1194.1
• Impact:
• External Reference:

Section 1194.2 Application

(This section has alternate versions for some paragraphs. Rationales are listed at the end of the section)

Current provision:

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

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

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

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

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

Version 1: Recommended New Introduction:

In general, this section applies only to the consideration of accessibility in the process of developing, procuring, maintaining, or using electronic and information technology.

Version 2: Alternatives for Paragraph (a)(2) and Paragraph (b)

(a)(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 shall explain why, and to what extent, compliance with each such provision creates an undue burden.

(b) When procuring a product, each agency shall procure products which comply with the provisions in this part when such products are available in the commercial marketplace or when such products are developed in response to a Government solicitation. Agencies cannot claim a product as a whole is not commercially available because no product in the marketplace meets all the standards. If products 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.

Version 3: Alternative for Paragraph (b)

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

Rationales:

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

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

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

• Rationale for Version 3: paragraph (b): 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 508 regulations. This presents an opportune time for GSA and the Access Board to consider how to ensure best provide guidance for agencies to implement 508 within the procurement process.

Recommendation to the Access Board: Develop supplemental materials to assist in determining what is and is not E&IT.

• Status: Done See additional proposals for this provision to incorporate 255
• Text from Subpart A Subcommittee
• Source: {508}1194.2
• Impact:
• External Reference:

Section 1194.3 General Exceptions

See additional proposals for these provisions to incorporate 255

See new exception proposed for Inherently Visual EIT Assets

1194.3 - A - Intelligence Or Security Systems

This part does not apply to any electronic and information technology operated by agencies, the function, operation, or use of which involves intelligence activities, cryptologic activities related to national security, command and control of military forces, equipment that is an integral part of a weapon or weapons system, or systems which are critical to the direct fulfillment of military or intelligence missions. Systems which are critical to the direct fulfillment of military or intelligence missions do not include a system that is to be used for routine administrative and business applications (including payroll, finance, logistics, and personnel management applications).

• Status: Done
  
• Text from Subpart A Subcommittee
• Source: {508}1194.3(a), no change

1194.3 - NEW - Emergency, Field and First Response Use

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

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

• Impact:

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

• External Reference:

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

• Status: In Progress, no consensus reached
• Text from Subpart A Subcommittee
• Source: New

1194.3 - B- Incidental To A Contract

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

• Status: Done
  
• Text from Subpart A Subcommittee
• Source: {508}1194.3(b), no change

1194.3 - C - Employees Not Individuals With Disabilities

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

Rationale: The subcommittee has determined this provision is clear as written and does not need any changes

• Status: Done
  
• Text from Subpart A Subcommittee
• Source: {508}1194.3(c), no change

1194.3 - D - Access By Public

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

• Status: Done
• Text from Subpart A Subcommittee
• Source: {508}1194.3(d), no change

1194.3 - E - Fundamental Alteration

(This section has alternate versions. Rationales are listed at the end of the section.)

Version 1
This part shall not be construed to require a fundamental alteration in the nature of the E&IT, or its components, given the agency's specified product requirements, or business need.

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

Rationale for Version 1: This proposed language specifically reminds agencies that their implementation of Section 508 must support both the agency's mission as well as their responsibilities under Section 508. This version also links the fundamental alteration to the agency's specified requirements (if they are able to specify their requirements), or their business need (if they are not able to specify the requirements up front).

Rationale for Version 2: Some TEITAC members indicated the additional language in version 1 is not needed as it is implicit. They recommend keeping the provision as it currently is.

• Status: Done See notes in sandbox page
  
• Text from Subpart A Subcommittee
• Source: {508}1194.3(e)

1194.3 - F - Service Areas

(This section has alternate versions. Rationales are listed at the end of the section.)

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

Version 1
Products designed for spaces frequented only by service personnel for maintenance, repair, or occasional monitoring of equipment and whose controls or interfaces can be executed solely from these spaces are not required to comply with this part. This part does apply to E&IT designed for spaces frequented only by service personnel, but whose controls or interfaces can be executed externally or remotely.

Version 2
Remove the provision entirely.

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

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

• Status: In Progress, no consensus reached, See additional input in sandbox page
  
• Text from Subpart A Subcommittee
• Source: {508}1194.3(f)

1194.3 - NEW - Narrow, Delineated Use

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

Rationale: Much discussion has transpired regarding the need to address situations where conformance to the technical and performance standards creates access barriers by loading up a single product with multiple access features. For example, requiring all calculators to have speech output, large visual display, enlarged keys, and other access features built-in actually creates access barriers depending on the functional limitations of individuals with disabilities. While some committee members are supportive of creating an exception to address this problem, other do not support pursuing this idea. While much discussion has taken place and alternatives have been explored, such as identifying products as "personal-private" that could be considered as part of a product line (see proposed personal-private definition), consensus has not been reached on a viable approach to addressing the problem.

• Status: In Progress, no consensus reached, See additional input in sandbox page
  
• Text from Subpart A Subcommittee
• Source: New

Section 1194.4 Definitions

The following definitions apply to this part:

See proposed added definitions from Section 255/FCC

• Customer premises equipment
• Interconnected Voice over Internet Protocol (VoIP) Product
• Interconnected Voice over Internet Protocol (VoIP) Service
• Manufacturer
• Peripheral devices
• Readily achievable
• Specialized customer premises equipment
• Telecommunications equipment
• Telecommunications service
• Usable

Agency

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

Status: Done
Text from: Subpart A

Application Software

Software which runs on and makes use of services provided by platform software. This includes "desktop" software bundled with an operating system, personal productivity applications, development tools, Web browsers, and other non-OS software.

Status: Done
Text from: Web and Software Subcommittee.

Assistive Technology

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

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

Note: Abbreviated as "AT"

Status: Done
Text from: Subpart A

Authoring Tools

Any software intended to create or modify content for publication.

• Note: This is intended to include only tools where the software is able to create or modify content in that format for publication, and the format is enabled to support compliance with the user interface and content provisions.

editorial suggestion for the note: This definition covers authoring tools which are able to create or modify content in a format that supports compliance with the user interface and content provisions.

Status: Done
Text from: Web and Software

Captions

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

Status: Done
Text from: Audio/Visual

Closed Product Functionality

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

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

Status: Done
Text from: Self-Contained/Closed

Content

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

Status: Done See comment in sandbox page
Text from: Web and Software

Content Format

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

Status: Done
Text from: Web/Software

Contrast Ratio

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

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

Notes:

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

Status: Done
Text from: Web/Software

Decoration

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

Status: Done See notes in sandbox page
Text from: Web and Software

Electronic and Information Technology

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

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

Status: Done See notes in sandbox page
Text from: Subpart A
Source: Clinger-Cohen

Free-Standing

Discussion of Work in Progress
* The subcommittee is requesting input on whether this should be defined 
  since it is used in other parts of the ADA regulations and could have impacts there.

Status: In Progress
Text coming from Hardware

Functional equivalent to TV closed captions

User-controllable features equivalent to CEA 708 display of caption text must comply with 3.B (Contrast), 3.E (Color Adjustment), and 1.2.J (Text size) directly or through assistive technology in order to provide a functional equivalent of the primary FCC user-controllable features.

Status: Done
Text from Audio/Visual

General Flash and Red Flash Thresholds

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

1. There are more than 3 General Flashes and/or more than 3 Red Flashes within any one-second period; and
2. The flashing is below 50 Hz; and
3. The combined area of flashes occurring concurrently occupy an area of 0.006 steradians or more of any 10 degrees of visual field on the screen (25% of 10 degrees of visual field) at typical viewing distance, and where:
   • A General Flash is defined as a pair of opposing changes in relative luminance of 10% or more and the relative luminance of the darker image is below 0.80; where an "a pair of opposing changes" is an increase followed by a decrease, or a decrease followed by an increase, and
   • A Red Flash is defined as any pair of opposing transitions involving a saturated red.

Exception: The flashing is a fine balanced alternating pattern such a white noise or a checkerboard-like pattern with ‘squares’ smaller than 0.5 degree on a side (area less than .000125 steradians).

Note 1: For general software or Web content, using a 341 x 256 pixel rectangle anywhere on the displayed screen area when the content is viewed at 1024 x 768 pixels will provide a good estimate of a 10 degree visual field for standard screen sizes and viewing distances (e.g. 15-17 inch screen at 22-24 inches). (Higher resolutions yield smaller and safer images so lower resolutions are used to define the thresholds.)

Note 2: The current working definition of 'opposing transitions involving a saturated red' is where, for either or both states involved in each transition, R/(R+ G + B) >= 0.8, and the change in the value of (R-G-B)x320 is > 20 (negative values of (R-G-B)x320 are set to zero) for both transitions. R, G, B values range from 0-1 as specified in “relative luminance” definition. (Harding and Binnie 2002)

Note 3: Tools are available that will carry out analysis from video screen capture.

Note 4: No tool is necessary to evaluate for this condition if flashing is less than or equal to 3 in any one second or greater than 50Hz. Content automatically passes (see #1 and #2 above)

Note 5: 50Hz is used to coincide with the AC line frequency in Europe and other countries. However almost half of the population is susceptible to 50Hz flashing whereas only 15% are susceptible to 60Hz. 75Hz or higher is recommended where possible.

Status: Done
Text from: Web/Software

Information Technology

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

Status: Done
Text from: Subpart A

Interactive Elements

• Text coming from A/V Subcommittee

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

Large Scale Text

At least 18 point or 14 point bold

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

Status: Done
Text from: Web/Software

Menu

Set of selectable options.

Status: Done See notes in sandbox page
Text from: Telecommunications
Source: HFES 200

Non-text Object

Any object that is not a sequence of characters that can be programmatically determined or where the sequence is not expressing something in human language

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

Status: Done
Text from: Web/Software

Other Services To Cooperate With Assistive Technologies

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

Status: Done
Text from: Web and Software

Peak Non-crisis Network Traffic

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

Status: Done
Text from: Telecommunications

Platform Accessibility Services

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

Status: Done
Text from: Web/Software

Platform Software

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

1. Note: 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".
2. Note: 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 which hosts plug-in's is not a platform if the plug-in can directly access the underlying layer.
3. Note: 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.

Status: Done
Text from: Web/Software

Programatically Determinable

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

Status: Done
Text from: Web/Software

Real-time Text

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

Status: Done See notes in sandbox page
Text from: Telecommunications

Relative Luminance

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

Notes:
The relative luminance of an sRGB color is defined as L = 0.2126 * R + 0.7152 * G + 0.0722 * B where R, G and B are defined as:

• if RsRGB <= 0.03928 then R = RsRGB/12.92 else R = ((RsRGB+0.055)/1.055) ^ 2.4
• if GsRGB <= 0.03928 then G = GsRGB/12.92 else G = ((GsRGB+0.055)/1.055) ^ 2.4
• if BsRGB <= 0.03928 then B = BsRGB/12.92 else B = ((BsRGB+0.055)/1.055) ^ 2.4 and RsRGB, GsRGB, and BsRGB are defined as:
  • RsRGB = R8bit/255
  • GsRGB = G8bit/255
  • BsRGB = B8bit/255

Notes on the formulas

• The "^" character is the exponentiation operator. (Formula taken from [sRGB] and [IEC-4WD]).
• Almost all systems used today to view Web content assume sRGB encoding. Unless it is known that another color space will be used to process and display the content, authors should evaluate using sRGB colorspace. If using other color spaces, see Understanding Success Criterion 1.4.3.
• For dithered colors, use average values of the colors used (average R, average G, and average B).
• Tools are available that automatically do the calculations when testing contrast and flash.
• A MathML version of the relative luminance definition is available.

Status: Done
Text from: Web/Software

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.

Status: Done
Text from: A/V

Telecommunications

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

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

Terminal

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

Status: Done
Text from: Telecommunications

TTY

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

Status: Done
Text from: Telecommunications

Undue Burden

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

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

Video Description

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

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

Status: Done
Text from: Audio-Video
External Reference: Guidelines (draft) from the Described and Captioned Media Program (U.S. Department of Education)

Section 1194.5 Equivalent Facilitation

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

Rationale: The subcommittee has determined this provision is clear as written and does not need any changes

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

Technical Provisions

1. Requirements for All Product and Services

1.1 Functional Performance Criteria

• See proposed updates to provisions in this section
• See new proposed provision

The functional performance criteria have three roles:

1. If any of the technical provisions are not met, the Functional Performance Criteria can be used to see if access is provided in another way (i.e. through equivalent facilitation).
2. The Functional Performance Criteria 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 be used to help identify and report functions (of a partially conforming product) that would not meet the Functional Performance Criteria (and would therefore not work with employees and/or public users with disabilities) so that agency can evaluate the importance of lack of access to those functions to the intended use of the product.

1.1-A - Without Vision

Products must provide at least one mode that allows access to all functionality of the product without using vision. This access may be provided directly or through assistive technology.

• Status: Done See proposed updates to this provision
• Text from General
• Source: {508}1194.31(a), {255}1193.31
• Impact:
• External Reference:
• Testability: Expert evaluation
• Metadata
  • Disabilities: Blindness
  • User Activities: All
  • Product Characteristics: All
  • Product Types: All

1.1-B - With Limited Vision

Products must provide at least one mode that allows access to all functionality of the product visually without requiring visual acuity greater than 20/70. This access may be provided directly or through assistive technology.

• Status: Done See proposed updates to this provision
• Text from General
• Source: {508}1194.31(b), {255}1193.41(b)
• Impact:
• External Reference:
• Testability: Expert evaluation
• Metadata
  • Disabilities: Low vision
  • User Activities: All
  • Product Characteristics: All
  • Product Types: All

1.1-C - With Color Vision Deficits

Products must provide at least one mode that allows access to all functionality of the product for people with color vision deficits.

Note: This provision can be met by meeting the color and contrast requirements below.

• Status: Done See proposed updates to this provision
• Text from General
• Source: new
• Impact:
• External Reference:
• Testability: Expert evaluation
• Metadata
  • Disabilities: Color deficiency/Colorblindness
  • User Activities: All
  • Product Characteristics: All
  • Product Types: All

1.1-D - Without Hearing

Products must provide at least one mode that allows access to all functionality of the product without using hearing. This access may be provided directly or through assistive technology.

• Status: Done See proposed updates to this provision
• Text from General
• Source: {508}1194.31(c), {255}1193.41(d)
• Impact:
• External Reference:
• Testability: Expert evaluation
• Metadata
  • Disabilities: Deafness, Deaf-blindness, Other combined hearing/vision loss
  • User Activities: All
  • Product Characteristics: All
  • Product Types: All

1.1-E - With Limited Hearing

Where audio information is important for the use of a product, it must provide at least one mode that allows access to all functionality of the product with enhanced audio. This access may be provided directly or through assistive technology.

• Status: Done See proposed updates to this provision
• Text from General
• Source: {508}1194.31(d), {255}1193.41(b)
• Impact:
• External Reference:
• Testability: Expert evaluation
• Metadata
  • Disabilities: Hard of hearing,
  • User Activities: All
  • Product Characteristics: All
  • Product Types: All

1.1-F - Without Speech

Products must provide at least one mode that allows access to all functionality of the product without user speech. This access may be provided directly or through assistive technology.

• Status: Done See proposed updates to this provision
• Text from General
• Source: {508}1194.31(e), {255}1193.41(h)
• Impact:
• External Reference:
• Testability: Expert evaluation
• Metadata
  • Disabilities: Speech
  • User Activities: All
  • Product Characteristics: All
  • Product Types: All

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

Products must provide at least one mode that allows access to all functionality of the product for people with limited reach and strength, and that does not require simultaneous actions. This access may be provided directly or through assistive technology.

• Status: Done See proposed updates to this provision
• Text from General
• Source: {255}1193.41(e)
• Impact:
• External Reference:
• Testability: Expert evaluation
• Metadata
  • Disabilities: Dexterity, Mobility
  • User Activities: All
  • Product Characteristics: All
  • Product Types: All

1.1-H - Without Physical Contact

Products must provide at least one mode that allows access to all functionality of the product without requiring any physical contact with the product beyond initial connection and setup of a special interface device. This access may be provided directly or through assistive technology.

Note: While it is preferable that no contact at all be required, the use of a standard physical connection such as a USB would meet this provision.

Explanatory Notes

• Use of cameras to monitor user movement to control input would meet this provision.
• Allowing users to control the product using their own communication or control via a universal wireless connection would also meet this provision.
  • ANSI/INCITS URC standard would be one
  • Wireless USB would be another solution
• A connection is allowed since it may be necessary. Individuals could have a companion or bystander connect them and still allow them privacy in completing the transaction. Methods not requiring any contact or assistance of course are preferred.

Rationale: A large population of people with physical disabilities cannot reach out to touch a product or cannot reach out long enough to actually operate a product physically. The Forrester Study by Microsoft cited people with physical disabilities as being second only to blindness and low vision as providing difficulties in using computers.

• Status: In Progress See proposed updates to this provision'
• Text from General
• Source: new
• Impact:
• External Reference:
• Testability: Expert evaluation
• Metadata
  • Disabilities: Dexterity, Mobility
  • User Activities: All
  • Product Characteristics: All
  • Product Types: All

1.1-I - With Cognitive, Language or Learning Limitations

This provision need different language from others in this section, and decisions about inclusion and language have not been made yet.

• Status: In Progress See proposed updates to this provision
• Text from General
• Source: {255}1194.41(i)
• Impact:
• External Reference:
• Testability: Expert evaluation
• Metadata
  • Disabilities: Cognitive language/learning
  • User Activities: All
  • Product Characteristics: All
  • Product Types: All

1.2 General Technical Requirements

1.2-A - Accessibility Configuration

In complying with this subpart, each agency must activate accessibility features and configure products so that they are accessible to and usable by people with disabilities.

• Status: Done See proposed updates for this provision
• Text from Telecommunications
• Source: new
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities: All
  • User Activities: All
  • Product Characteristics: All
  • Product Types: All

1.2-B - Accessible Content

Go to the text proposal created at the November plenary

In complying with this subpart, each agency must operate software in a manner such that output from the software that is distributed or archived by the agency is made accessible to people with disabilities.

Rationale:

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

1.2-C - 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 and the following provisions would not apply to that 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
• 3-U - AT Interoperability
• 3-W - Accessibility Services

Rationale:

• Status: Done - updated 19 Oct (was 1.2-B in Sept 14 draft) See proposed updates for this provision
• Text from Self Contained, Closed
• Source: {508}1194.25(a)
• Impact:
• External Reference:
• Testability: Expert evaluation
• Metadata
  • Disabilities: All
  • User Activities: All
  • Product Characteristics: All
  • Product Types: All

1.2-D - Biometric ID

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

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

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

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

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

• Status: Done See minority report comments
• Text from: General
• Source: {508}1194.25(d), {508}1194.26(c)
• Impact:
• External Reference:
• Testability: Inspection
• Metadata
  • Disabilities: All (that could be caused by loss body part or function)
  • User Activities: All
  • Product Characteristics: All
  • Product Types: All

1.2-E - Pass Through

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

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

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

Rationale:

• Status: Done See proposed updates to this provision
• Text from Telecommunications
• Source: {508}1194.23(j), {255}1193.37
• Impact:
• External Reference:
• Testability: Inspection
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

1.2-F - Audio information

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

Note: Audio content that includes spoken content and that is closed due to DRM such that it cannot be rendered in visual form by AT and other players must include an visual form that can be.

• Status: Done See proposed updates
• Text from Self-Contained/Closed
• Source: {255}1194.43(d)
• Impact:
• External Reference:
• Testability: Expert evaluation
• Metadata
  • Disabilities: Deaf, Hard of Hearing
  • User Activities: All
  • Product Characteristics: Sound output – speech, Sound output (other than speech)
  • Product Types: All

1.2-G - Visual Information

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

Note: Visual content that includes text and that is closed due to DRM such that it cannot be rendered in audio form by AT and other players must include an audio form that can be.

• Status: Done - updated 19 Oct See proposed updates
• Text from Self-Contained/Closed
• Source: {255}1194.43(a)
• Impact:
• External Reference:
• Testability: Expert evaluation
• Metadata
  • Disabilities: Blind, Low Vision
  • User Activities: All
  • Product Characteristics: Visual display with text, Visual display with graphics
  • Product Types: All

1.2-H - Color

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

Note: This provision is harmonized with 3.A

Rationale:

• Status: In Progress
• Text from Web/Software
• Source: {508}1194.25(g) and 1194.21(i)
• Impact:
• External Reference: Harmonized with WCAG 2.0 and ISO 9241.171
• Testability: Expert evaluation
• Metadata
  • Disabilities: Color deficiency/Colorblindness
  • User Activities: All
  • Product Characteristics: Uses Color (on keys, labels, displays, indicators, anywhere etc.)
  • Product Types: All

1.2-I - Text size

There must be at least one mode where all information that is required for product use and is provided in text is readable by people with 20/20 vision at 3.5 times their typical viewing distance. This mode must be the default mode unless the activation method for that mode can be done at 3.5 times the typical viewing distance or the product automatically sets itself to that mode for users who require it.

Note: Providing text in an accessible file on a device meets this requirement for information that is not location specific (e.g. labels are location specific).

Rationale:

• This is harmonized with the measurements for 3-U (focus cursor size), but neutral to the size of screen. For text on screen, this measurement might be sufficient, or this note can be incorporated:
  • "A focus cursor that is visually locatable by people with unimpaired vision at 2.5 meters when software is displayed on a 38 cm (15 inch) diagonal screen at 1024 x 768 pixels resolution, without moving the cursor is sufficient."

 Work in Progress
 * The SC has asked a vision scientist for input on how to word this 
   provision, and is waiting for his reply.

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

2. Hardware Aspects of Products

2.1 All Products with Hardware

2.1-A - Luminance Contrast Ratio for Display

Version 1:
For displays on products, at least one mode must exist where the contrast ratio between the luminance at light state compared to luminance at dark state shall be 5:1.

• Note: Light (or high) state typically refers to the lighter condition for the display. For example, white content/background on an LCD. Dark (or low) state typically refers to the darker condition for the display. For example, black content/background on an LCD.

Version 2:
Remove this provision since display technologies have changed.

Rationale:

• Status: In Progress See work in progress list
• Text from Hardware
• Source: {508} 1194.26(b); {508} 1194.25(c)
• Impact:
• External Reference:
• Testability: Formal test method
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

2.1-B - Reflectance Contrast for Legends and Passive Displays

If the legend or instructions on the device are the only means of conveying information, then the luminance contrast shall be at least 3:1.

Note: If other means of conveying the information in the label or instructions exists (e.g. uniquely tactilely discernible though shape), then the luminance contrast requirement does not apply.

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

Note: Reflectance contrast (RC) is calculated in the following manner RC = (R(h) +0.02)/(R(l)+0.02) where R(h) = Reflectance of high (bright) element; R(s) = Reflectance of low (dark) element. Where the reflectance is always a value between 0 and 1.

Note: Additionally, I think we need to convey at least for computers that there are different levels. E.G the alphanumeric labels are the primary labels and should meet this convention; however, the secondary functions (such as the blue numbers on an embedded numpad on a notebook) should not meet this convention 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.

Rationale:

• Status: In Progress See work in progress list
• Text from Hardware
• Source: {508} 1194.26(b); {508} 1194.25(c)
• Impact:
• External Reference:
• Testability: Formal test method
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

2.1-C - Flashing

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

• Flashing created by software or content is under the general flash and red flash threshold provisions in Section 3.

• Flashing created by hardware is either:
  • less than YYY candelas; or
  • less than 20 candelas/sq meter and contiguously occupies more than a total

of 0.006 steradians or more within any 10 degrees of visual field (25% of any 10 degree visual field).

• Status: In Progress (was 1.2-C in Sept 14 draft)
• Text from (General transfer to Hardware and Web/Software)
• Source: {508}1194.21(k) 1194.22(j) 1194.25(i), and {255}1193.43(f)
• Impact:
• External Reference:
• Testability: Inspection
• Metadata
  • Disabilities: All
  • User Activities: All
  • Product Characteristics: All
  • Product Types: All

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

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

2.1-E - Touch Operated Controls

Version 1
If a product utilizes touch screens or touch-operated controls then the product must provide, without requiring user-speech:

1. A functionally equivalent, alternate means of operation that uses Mechanical Controls and does not require vision.
2. A functionally equivalent, alternate means of operation that does not require fine motor control.

Note: This provision should not discourage the provision of control via user speech in addition to the above methods.

Version 2 (proposal from plenary)
If a product uses touch screens or touch-operated controls, it must provide a functionally equivalent alternative means of operation that meets the requirements for Mechanical Controls. This alternative must not require either vision or 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.

• Status: In Progress See work in progress list
• Text from Hardware
• Source: {508} 1194.26(b); {508} 1194.25(c)
• Impact:
• External Reference:
• Testability: Inspection
• Metadata
  • Disabilities: All
  • User Activities: Conversations, data analysis, document sharing and reviewing, media (audio/video) creation and editing
  • Product Characteristics: Physical controls or connectors, touchscreen or touch sensitive buttons
  • Product Types: Hardware, telephone, telephone system, audiovisual equipment, public information terminal, desktop computer system, portable computer system, copier, printer, scanner, other similar peripheral

2.1-F - Standard 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 standard protocols for 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, it shall be the responsibility of the E&IT vendor to offer such adapter.

Note: "Standard Connection" shall be deemed to be a connection that has been readily adopted by industry and is in common and current use. For example, while a serial port with a DB25 connector used for mouse input was a standard connection many years ago, it is no longer in common and current use on modern computers, and would no longer be considered a standard connection.

Rationale: The change to the word "connection" allows for wireless

• Status: Done See work in progress list
• Text from Hardware and Telecommunications
• Source: {508} 1194.26(d)
• Impact:
• External Reference:
• Testability: Inspection
• Metadata
  • Disabilities: All
  • User Activities: Conversations, data analysis, document sharing and reviewing, media (audio/video) creation and editing
  • Product Characteristics: Physical controls or connectors, touchscreen or touch sensitive buttons
  • Product Types: Hardware, telephone, telephone system, audiovisual equipment, public information terminal, desktop computer system, portable computer system, copier, printer, scanner, other similar peripheral

2.1-G - Installed or Free-Standing Products

Architecturally installed or free-standing non-portable products intended to be used in one location must have any operable controls positioned within reach.

Note: The Access Board should insert the appropriate reach-range ADAAG requirements at time of adoption.

Rationale: This provision should be coordinated with the ADAAG, which is currently the process of being updated.

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

2.2 If the Product has Speech Output or Throughput

2.2-A - Magnetic Coupling

Products that deliver output with an audio transducer that is normally held up to the ear must provide a means for effective magnetic wireless coupling to hearing technologies that allows a user to effectively utilize the product. This does not apply to headphone, headset, OR other accessories that plug into a jack on the product.

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

Rationale:

• Status: Done See work in progress list
• Text from Hardware and Telecommunications
• Source: {508}1194.23(h), {255}11943.43(i)
• Impact:
• External Reference: ANSI C63.19 (2007), TIA-1083
• Testability: Formal test method
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

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.

NOTE: Cellular and PCS handsets that meet a minimum of M3 or M4 and T3 or T4 measurement rating per ANSI C63.19 (2007) will meet this requirement for “lowest possible level.” 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 “lowest possible level” standard for those types of devices.

Rationale:

• Status: In Progress See work in progress list
• Text from Hardware and Telecommunications
• Source: {508}1194.23(i), {255}1193.43(h)
• Impact: minimal
• External Reference: (see note above)
• Testability: Formal test method
• Metadata
  • Disabilities: Hearing, Hard of Hearing
  • User Activities:
  • Product Characteristics:
  • Product Types:

2.2-C - Audio Connection

Version 1:

When products provide auditory output beyond simple tonal feedback or signaling, the audio signal must be provided at a standard signal level through an industry standard connection that will allow for private listening.

• If the product is a public-shared product then the connection must be via a standard 2.5mm or 3.5mm audio jack.

• If the product is personal-private product then the connection can be wired or wireless as long as a 2.5mm or 3.5mm phone jack adapter is available from the manufacturer.

Alternate wording for clarity

• Public-shared products must provide the connection via a standard 2.5mm or 3.5mm audio jack.

• Personal-private products may provide either a wired or wireless connection. A wired connection must be via a standard 2.5mm or 3.5mm audio jack. A wireless connection may be used as long as a 2.5mm or 3.5mm phone jack adapter is available from the manufacturer.

Version 2, posted to plenary email Oct 19, 2007:

When products provide auditory output beyond simple tonal feedback or signaling, the audio signal must be provided through an industry standard connection that will allow for private listening.

• Public-shared products must provide the connection via a standard 2.5mm or 3.5mm phone jack or RCA audio jack.

• Personal-private products must provide either a 2.5mm or 3.5mm phone jack or a wired or wireless connection that has a 2.5mm or 3.5mm phone jack adapter that is commonly available.

Version 3, posted to plenary email Oct 20, 2007:

When products provide auditory output beyond simple tonal feedback or signaling, one of the following must be true:

1. Conforming Handset: Auditory output is available via audio transducer that is designed to be held up 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. Phone Jack: A standard 2.5mm or 3.5mm audio jack for headphones/headsets is provided or
3. Any Connection with Adapter avail: Product is a not designed to be located in a public location and an adapter from the product's audio output format to a 2.5mm or 3.5mm phone jack is commonly available or available from the manufacturer.
4. Public Display only: 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: RJ-9, RCA, USB, and Bluetooth connections 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-(c)

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

Rationale:

• Status: In Progress See work in progress list
• Text from Hardware
• Source: {508} 1194.25(e); {255} 1193.51(b) & (g)
• Impact:
• External Reference:
• Testability: Inspection
• Metadata
  • Disabilities: All
  • User Activities: Conversations, data analysis, document sharing and reviewing, media (audio/video) creation and editing.
  • Product Characteristics: Physical controls or connectors, touchscreen or touch sensitive buttons
  • Product Types: Hardware, telephone, telephone system, audiovisual equipment, public information terminal, desktop computer system, portable computer system, copier, printer, scanner, other similar peripherals

2.2-D - Volume

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

• For products located in a public place, the maximum volume level must be at least 80 dB SPL RMS, measured at xx centimeters from the device at maximum volume setting [possible without XXX distortion].
• For products that will not be used in public places or where the volume of the public place is controlled to be under 50 dBA SPL RMS, the maximum volume level must be at least 65 dB SPL RMS.

Rationale:

• Status: In Progress See work in progress list
• Text from Self-Contained/Closed
• Source: {508}1194.25(f), {255}1193.43(e)
• Impact:
• External Reference:
• Testability: Formal test method
• Metadata
  • Disabilities: Hard of hearing
  • User Activities: All
  • Product Characteristics: Sound output – speech, Sound output (other than speech)
  • Product Types: All

2.2-E - Volume (Gain)

For incoming voice signals:

1. 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 normally held to the ear, and all cordless telephones, must comply with FCC regulation §68.317 for volume control.
3. All cellular telephones – TBD.
4. All other products that provide a voice communication function via an audio transducer normally 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.

Rationale: The following notes are to be included either within the provision or advisory notes. Location is to be determined by EWG.

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

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

NOTE 3: FCC regulation §68.317 makes reference to older industry standards in specifying how to measure the receive 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.

NOTE 4: Other products or systems that provide a voice communication function, including products and systems that do not have an audio transducer that is normally 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.

NOTE 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. It is recommended that no recommendation be made at this time by the TEITAC, but rather, the recommendations from the study can be given to the Access Board.

• Status: In Progress See work in progress list
• Text from Telecommunications
• Source: {508}1194.23(f)
• Impact:
• External Reference: FCC §68.317
• Testability: Formal test method
• Metadata
  • Disabilities: Hard of hearing
  • User Activities: Real-time voice conversation, IVR
  • Product Characteristics: Audio output
  • Product Types: Telephones, IVRs

2.2-F - Volume Reset

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

Rationale:

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

3. User Interface and Electronic Content Provisions

These provisions apply to software and Web user interfaces and electronic content including Web pages.

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. For example, mandatory form fields are identified with red text and labeled as "mandatory".

Rationale:Harmonizes 508 Web, software, and closed product requirements with WCAG 2.0 and ISO 9241-171. Programmatic exposure of color is not sufficient for color blind users. A visually redundant means is necessary.

• Status: Done See work in progress list
• Text from Web and Software
• Source: {508}1194.21 (i), 1194.22(c) and 1194.25(h)
• 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.
  • Beneficial for people who are color blind which is a large portion of the population.
• External Reference: Harmonized with WCAG 2.0 and ISO 9241-171
• Testability: Expert evaluation
• Metadata
  • Disabilities: Color deficiency/Colorblindness
  • User Activities: All
  • Product Characteristics: Uses Color (on buttons, labels, displays, indicators, anywhere etc.)
  • Product Types: Software (installed or through browser); Network Interface to devices; Desktop Computer Systems; Portable Computer Systems

3-B - Contrast

Presentation of text (and images of text) in electronic documents must have a default contrast ratio of at least 5:1, except if the text is unavailable items or pure decoration. Large-scale text (or images of large-scale text) can allow a contrast ratio of at least 3:1.

Rationale: Harmonization with WCAG 2.0.

• Status: Done See work in progress list
• Text from Web and Software
• Source: {508}1194.21(j)
• Impact:
  • Significant
  • There are currently no measurable criteria for contrast in Section 508.
  • Simple tools are available to evaluate contrast.
• External Reference: Harmonized with WCAG 2.0 and ISO 9241-171
• Testability: Formal test method
• Metadata
  • Disabilities: Color deficiency/Colorblindness, Low Vision
  • User Activities: All
  • Product Characteristics: All
  • Product Types: Software (installed or through browser); Network Interface to devices; Desktop Computer Systems; Portable Computer Systems

3-C - Size, shape, location

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

• Note: Object information provided per the "Information and Relationships", "User Interface Components", or "AT interoperability" provision that describes the necessary visual cues or relationships can be used to meet this provision.
• Note: This applies to onscreen information only.

Rationale: This applies to instructional text in the interface or other onscreen information. Harmonization with WCAG 2.0.

• Status: Done See work in progress list
• Text from Web and Software
• Source: new
• Impact:
  • Minimal
  • No current requirement in Section 508.
• External Reference: Harmonized with WCAG 2.0
• Testability: Inspection
• Metadata
  • Disabilities: All
  • User Activities: All
  • Product Characteristics: All
  • Product Types: Software (installed or through browser); Network Interface to devices; Desktop Computer Systems; Portable Computer Systems

3-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 unavailable items or pure decoration. Large scale text (or images of large scale text) must allow a contrast ratio of at least 3:1.

• Note: Application software that is 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 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.

• Status: Done See work in progress list
• 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:
• Testability: If platform settings, inspection; if no platform settings, formal test method
• Metadata
  • Disabilities: All
  • User Activities: All
  • Product Characteristics: All
  • Product Types: Software (installed or through browser); Network Interface to devices; Desktop Computer Systems; Portable Computer Systems

3-E - Color Adjustment

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

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

Rationale: Current provision is weak and unfailable. 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.

• Status: Done See work in progress list
• Text from Web and Software
• Source: new
• Impact:
  • Minimal for desktop software. Potentially significant for Web sites and applications and non-desktop software platforms that allow color and contrast adjustments.
  • Same as current 508 software provision except it provides a testable measurement of contrast.
• External Reference:
• Testability: Formal test method
• Metadata
  • Disabilities: Color deficiency/Colorblindness, Low Vision
  • User Activities: All
  • Product Characteristics: All
  • Product Types: Software (installed or through browser); Network Interface to devices; Desktop Computer Systems; Portable Computer Systems

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.

• Controls-Input: If a non-text objects is a control or accepts user input, then it must have a name that describes its purpose. (See also User Interface Components provisions)
• Media: If a non-text object is synchronized media, live audio-only or live video-only content, 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)
• 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)
• 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)
• CAPTCHA: If the purpose of a non-text object is to confirm that content is being accessed by a person rather than a computer then text alternatives that identify and describe the purpose of the non-text object must be provided and alternative forms in different modalities must be provided to accommodate different disabilities.
• Decoration, Formatting, Invisible Objects: If a non-text object is pure decoration, or used only for visual formatting, or if it is not presented to users, then it is implemented such that it can be ignored by assistive technology.

• Note: In order to achieve 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.

• Status: Done See minority report comments
• 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
• Testability: Expert evaluation
• Metadata
  • Disabilities: All
  • User Activities: All
  • Product Characteristics: All
  • Product Types: Software (installed or through browser); Network Interface to devices; Desktop Computer Systems; Portable Computer Systems

3-G - Human Language

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

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

Rationale: Harmonization with WCAG 2.0.

• Status: Done See comments on this provision
• Text from Web and Software
• Source: new
• Impact:
  • Minimal for HTML Web pages. Could be significant for other document types.
  • 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
• Testability: Inspection
• Metadata
  • Disabilities: All
  • User Activities: All
  • Product Characteristics: All
  • Product Types: Software (installed or through browser); Network Interface to devices; Desktop Computer Systems; Portable Computer Systems

3-H - Language of Parts

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

Rationale: Harmonization with WCAG 2.0.

• Status: Done See comments on this provision
• Text from Web and Software
• Source: new
• Impact:
  • Significant
  • Entire documents must be scanned for changes in natural language and programmatically identified.
• External Reference: Harmonized with WCAG 2.0
• Testability: Inspection
• Metadata
  • Disabilities: All
  • User Activities: All
  • Product Characteristics: All
  • Product Types: Software (installed or through browser); Network Interface to devices; Desktop Computer Systems; Portable Computer Systems

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

• Status: Done See work in progress list
• Text from Web and Software
• Source: new
• Impact:
  • 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.
• External Reference: Harmonized with WCAG 2.0
• Testability: Inspection
• Metadata
  • Disabilities: All
  • User Activities: All
  • Product Characteristics: All
  • Product Types: Software (installed or through browser); Network Interface to devices; Desktop Computer Systems; Portable Computer Systems

3-J - Flashing

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

editorial suggestion: Content and user interfaces must not contain anything that flashes more than 3 times in any one second period. Any flashing elements must be below the general flash and red flash thresholds.

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.

• Status: Done See work in progress list
• 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
• Testability: Inspection
• Metadata
  • Disabilities: Flash sensitive
  • User Activities: All
  • Product Characteristics: All
  • Product Types: Software (installed or through browser); Network Interface to devices; Desktop Computer Systems; Portable Computer Systems

3-K - Consistent Identification

Components that have the same functionality within a product must be identified consistently.

Rationale: Helps people with cognitive disabilities. Supports use of assistive technology. Harmonization with WCAG 2.0.

• Status: Done See work in progress list
• Text from Web and Software
• Source: New
• Impact:
  • Significant
  • Requires manual assessment and correction. Cost to remediate existing applications could be very high. Subjectivity of the testing could also increase expense.
• External Reference: Harmonized with WCAG 2.0
• Testability: Inspection
• Metadata
  • Disabilities: All
  • User Activities: All
  • Product Characteristics: All
  • Product Types: Software (installed or through browser); Network Interface to devices; Desktop Computer Systems; Portable Computer Systems

3-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 which can be set independently of the system volume.

Rationale: Harmonization with WCAG 2.0.

• Status: Done See proposed updates to this provision
• 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
• Testability:
• Metadata
  • Disabilities: All
  • User Activities: All
  • Product Characteristics: All
  • Product Types: Software (installed or through browser); Network Interface to devices; Desktop Computer Systems; Portable Computer Systems

3-M - Reading Sequence

When the sequence in which information is presented affects its meaning, a correct reading sequence must be programmatically determinable. The navigation sequence must be consistent with the reading sequence.

• Note: In order to achieve this provision, objects in data operated on by the software which 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: For products with closed functionality the visual and (linear) audible presentation should match navigation

Rationale: Harmonization with WCAG 2.0.

• Status: Done See work in progress list
• Text from Web/Software and Closed Products
• Source: New
• 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. Similar to recommendation in ISO 9241-171
• Testability: Inspection
• Metadata
  • Disabilities: All
  • User Activities: All
  • Product Characteristics: All
  • Product Types: Software (installed or through browser); Network Interface to devices; Desktop Computer Systems; Portable Computer Systems

3-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 determined link context.

• Note: In order to achieve 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. Harmonization with WCAG 2.0.

• Status: Done
• Text from Subcommittee
• Source: New
• Impact:
  • Significant
  • Impacts any page that has vague or duplicated link text. Requires manual testing.
• External Reference: Harmonized with WCAG 2.0
• Testability: Expert evaluation
• Metadata
  • Disabilities: All
  • User Activities: All
  • Product Characteristics: All
  • Product Types: Software (installed or through browser); Network Interface to devices; Desktop Computer Systems; Portable Computer Systems

3-O - Information and Relationships

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

1. row and column headers are identified for data tables
   • 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. markup is used to associate data cells and header cells for data tables that have two or more logical levels of row or column headers.
   • 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. markup is used to identify section headings
4. markup is used to identify form element labels

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

Rationale: The existing 508 provisions on table headers are technology specific to HTML. This more general provision is more applicable to Web content in other technologies. Harmonization with WCAG 2.0.

• Status: Done See work in progress list
• Text from Web and Software
• Source: New
• 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. IT-AT interoperability will be improved and less customization should be required.
• External Reference: Harmonized with WCAG 2.0
• Testability: Inspection
• Metadata
  • Disabilities: All
  • User Activities: All
  • Product Characteristics: All
  • Product Types: Software (installed or through browser); Network Interface to devices; Desktop Computer Systems; Portable Computer Systems

3-P - User Interface Components

For all user interface components, including form elements and those generated by scripts, the name and role must be programmatically determined. States, properties, and values that can be set by the user must be programmatically determined and can be programmatically set. Notification of changes to these items must be available to user agents, including assistive technologies. For example: Frames must be titled with text that facilitates frame identification and navigation.

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

• Note: The word "components" was used in this provision instead of "objects" since objects is a programming term and can be confusing to vendors. By using the term components it is more generic and will hopefully lead to less confusion.

• Status: Done See work in progress list
• Text from Web and Software
• Source: New
• Impact:
  • Significant
  • Rich Internet Applications will have to implement the ARIA standards. Significant positive impact to end users and agencies. IT-AT interoperability will be improved and less customization should be required.
• External Reference: Harmonized with WCAG 2.0
• Testability: Inspection
• Metadata
  • Disabilities: All
  • User Activities: All
  • Product Characteristics: All
  • Product Types: Software (installed or through browser); Network Interface to devices; Desktop Computer Systems; Portable Computer Systems

3-Q - Disruption of Access Features

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

Rationale: "other products" is a testability issue. New wording limits to accessibility features defined by the platform.

• Status: Done See work in progress list
• Text from Web and Software
• Source: {508}1194.21(b)
• Impact:
  • None
  • Functionally equivalent to the current 508 provision but clarified for testability. If Allen Hoffman's suggestion to reintroduce "assistive technology" is accepted, there will be significant additional cost.
• External Reference:
• Testability: Expert evaluation
• Metadata
  • Disabilities: All
  • User Activities: All
  • Product Characteristics: All
  • Product Types: Software (installed or through browser); Network Interface to devices; Desktop Computer Systems; Portable Computer Systems

3-R - Timing

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

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

Rationale: The recommended change is harmonized with both the ISO 9241-171 Software Accessibility standard and WCAG 2.0. "Sufficient time" is not objectively testable, except through human performance (summative) testing. There are other acceptable strategies for addressing the needs of users who need more time.

• Status: Done See work in progress list
• Text from Web and Software
• Source: New (incorporates {508}1194.22(p), {508}1194.23(d), {508}1194.25(b)
• 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 and ISO 9241-171
• Testability: Inspection
• Metadata
  • Disabilities: All
  • User Activities: All
  • Product Characteristics: All
  • Product Types: Software (installed or through browser); Network Interface to devices; Desktop Computer Systems; Portable Computer Systems

3-S - Keyboard Operation

Where products have a keyboard or a keyboard interface, all functionality of the product operable through the 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: This does not forbid and should not discourage providing mouse input or other input methods, such as gestures, in addition to keyboard operation.
• Note: 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: 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: For platform software, this includes the ability to move the keyboard focus into and out of applications.

Rationale: In the current 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.

• Status: Done See minority report feedback
• 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 and ISO 9241-171
• Testability: Inspection
• Metadata
  • Disabilities: Blindness, Physical
  • User Activities: All
  • Product Characteristics: Uses Keyboard (Physical - touch typeable)
  • Product Types: Web Content; Telephone only device; IVR (Voicemail, Autoattendant, Audiotext); Software (installed or through browser); Copiers; AudioVisual equipment (Video Monitor, TV, Projector); KIOSKS; Network Interface to devices; Desktop Computer Systems

3-T - Focus Indicator

version 1 from subcommittee:

Any keyboard operable user interface must have a mode of operation where the indication of keyboard focus has a high degree of visibility. This can be provided by the interface itself or by the interface in combination with focus services provided by the platform.

• Note: The presence of a highly visible text insertion point can be considered a visual indication of keyboard focus for a text area.
• Note: A focus cursor that is visually locatable by people (familiar with what the focus cursor would look like) who have 20/20 vision at 3.5 times the typical viewing distance without moving the cursor is sufficient.
• Note: Since computer software would be displayed on unknown screen sizes: for computer software a focus cursor that is visually locatable by people (familiar with the cursor) who have 20/20 vision at 2.5 meters when software is displayed on a 38 cm (15 inch) diagonal screen at 1024 x 768 pixels resolution, without moving the cursor is sufficient.
• Note: Since computer software would be displayed on unknown screen sizes: for computer software a focus cursor that is visually locatable by people (familiar with the cursor) who have 20/20 vision at 2.5 meters when software is displayed on a 38 cm (15 inch) diagonal screen at 1024 x 768 pixels resolution, without moving the cursor is sufficient.

Version 2 from Allen H, Oct 19, 2007: Software must support at least one mode that provides a highly visual indication of which user interface object currently has the keyboard focus.

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

Rationale: In the current 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.

• Status: Done See work in progress list
• Text from Web and Software
• Source: {508}1194.21(c)
• Impact:
  • 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.
• External Reference: Harmonized with ISO 9241-171
• Testability: Inspection
• Metadata
  • Disabilities: Low Vision, Physical
  • User Activities: All
  • Product Characteristics: Involves Web Content or Applications
  • Product Types: Web Content; Software (installed or through browser); Network Interface to devices; Desktop Computer Systems; Portable Computer Systems

3-U - AT Interoperability

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

• provide assistive technology with object information including but not limited to:
  • role, state(s), boundary, name, and description
  • the row and column a component is in, and the headers for the row and column for that component if it is in a table that has row or column headers.
  • current value and any minimum or maximum values, if the component represents one of a range of values
  • relationship this component has as a label for another component, or being labeled by another component
  • parent or containing element, and any children components
  • text contents, text attributes, and the boundary of text rendered to the screen
  • Note: In order to achieve this provision, interactive elements encoded in data operated on by the software would need to be associated with sufficient information to determine a role, state(s), name, and description for the interactive element, that the software can obtain as readily as it can obtain the interactive element itself.

• provide assistive technology with a list of actions that can be executed on an object and allow assistive technology to programmatically execute any of those actions;
• allow assistive technology to track and modify focus, text insertion point, and selection attributes of user interface components;
• provide assistive technology with notification of events relevant to user interactions, including but not limited to changes in the component's state(s), value, name, description, or boundary

• Note: This provision applies to forms in the software.
• Note: Software that provides remote access to graphical user interfaces (GUIs) would need to ensure that AT has access to the information required by this provision. There are two known ways to accomplish this: run the AT remotely as well or run the AT locally and provide a mechanism for it to communicate accessibility information with the remote GUI.

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

Note: The word "components" was used in this provision instead of "objects" since objects is a programming term and can be confuising to vendors. By using the term components it is more generic and will hopefully lead to less confusion.

• Status: Done See work in progress list
• Text from Web and Software
• Source: {508}1194.21(d)
• Impact:
  • Significant
  • More specificity of the information that must be exposed to AT. Significant positive impact to end users and agencies. IT-AT interoperability will be improved and less customization should be required.
• External Reference: Harmonized with ISO 9241-171
• Testability: Expert evaluation
• Metadata
  • Disabilities: Blindness
  • User Activities: All
  • Product Characteristics: Has OS that supports installed AT and user can install
  • Product Types: Telephone only device; Software (installed or through browser); Network Interface to devices; Desktop Computer Systems; Portable Computer Systems

3-V - Accessibility Services

Platform software must provide access to a set of services that enable applications running on the platform to interact with other assistive technology sufficient to enable compliance with the "AT interoperability" and "User Interface Components" provisions. If accessibility services are provided by the platform on which they are run, software toolkits and applications that are also platforms must make these services available to their client software.

Rationale: Harmonization with ISO 9241-171. Needed to improve IT-AT interoperability.

• Status: Done (was 3-W in Sept 14 draft) See minority report input
• 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
• Testability:
• Metadata
  • Disabilities: All
  • User Activities: All
  • Product Characteristics: All
  • Product Types: Software (installed or through browser); Network Interface to devices; Desktop Computer Systems; Portable Computer Systems

3-W - Multiple Ways (New provision)

More than one way is available to locate content within a set of Web pages where content is not the result of, or a step in, a process.

Rationale: Harmonization with WCAG 2.0

• Status: Done See work in progress list
• Text from Web and Software
• Source: New
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities: All
  • User Activities: All
  • Product Characteristics: All
  • Product Types: Software (installed or through browser); Network Interface to devices; Desktop Computer Systems; Portable Computer Systems

3-X - Labels or Instructions (New provision)

Labels or instructions must be provided when content requires user input.

Rationale: Harmonization with WCAG 2.0

• Status: Done See work in progress list
• Text from Web and Software
• Source: New
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities: All
  • User Activities: All
  • Product Characteristics: All
  • Product Types: Software (installed or through browser); Network Interface to devices; Desktop Computer Systems; Portable Computer Systems

3-Y - On Focus (New provision)

When any component in content or electronic documents receives focus, it must not initiate a change of context.

Rationale: Harmonization with WCAG 2.0

• Status: Done See work in progress list
• Text from Web and Software
• Source: New
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities: All
  • User Activities: All
  • Product Characteristics: All
  • Product Types: Software (installed or through browser); Network Interface to devices; Desktop Computer Systems; Portable Computer Systems

3-Z - On Input (New provision)

Changing the setting of any user interface component in content or electronic documents 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

• Status: Done See work in progress list
• Text from Web and Software
• Source: New
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities: All
  • User Activities: All
  • Product Characteristics: All
  • Product Types: Software (installed or through browser); Network Interface to devices; Desktop Computer Systems; Portable Computer Systems

3-AA - Error Identification (New provision)

If an input error is automatically detected in content or electronic documents, the item that is in error is identified and described to the user in text.

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

• Status: Done See work in progress list
• Text from Web and Software
• Source: New
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities: All
  • User Activities: All
  • Product Characteristics: All
  • Product Types: Software (installed or through browser); Network Interface to devices; Desktop Computer Systems; Portable Computer Systems

3-BB - Labels Descriptive (New provision)

The function [or purpose] of form controls can be determined from the label.

editorial suggestion: The function or purpose of form controls must be determinable from the label.

Rationale:

• Status: Done See work in progress list
• Text from Web and Software
• Source: New
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities: All
  • User Activities: All
  • Product Characteristics: All
  • Product Types: Software (installed or through browser); Network Interface to devices; Desktop Computer Systems; Portable Computer Systems

3- CC - Advisory Notes

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

1. Suppression of unneeded function

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

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

2. Writing guidelines

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

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

3. Interaction guidelines

Applications should design user interactions that are accessible for people with disabilities including:

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

4. Parsing

Content implemented using markup languages has elements with complete start and end tags, except as allowed by their specifications, and are nested according to their specifications.

5. User Preferences (non-visual)

User interfaces which 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.

Rationale:

• Status: Done See work in progress list
• Text from Web and Software
• Source: new
• Impact:
• External Reference:
• Testability: Many of these are testable
• Metadata
  • Disabilities: All
  • User Activities: All
  • Product Characteristics: All
  • Product Types: Software (installed or through browser); Network Interface to devices; Desktop Computer Systems; Portable Computer Systems

4. Additional Provisions for Audio-Visual Players or Displays

4-A - Caption Playback

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), including 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.

• Status: Done See work in progress list
• Text from A/V
• Source: new
• Impact:
• External Reference: CEA 608, CEA 708
• Testability: Inspection
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

4-B - Supplemental Audio Playback

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

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

• Status: Done See work in progress list
• Text from A/V
• Source: new
• Impact:
• External Reference:
• Testability: Inspection
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

4-C - Access to Caption Controls

Version 1 (Karen PS)
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 and program selection. At a minimum, this requires placement of such controls on either the product's physical apparatus or its remote control.

For example:
1. For captioning:

• A caption on/off button on a TV remote comparable in prominence to the volume control on that remote;
• Caption controls on the first menu that appear when on-screen menus are displayed

2. Audio equivalents to on-screen information and visual menu selections
3. A tactile button to turn on audio equivalents;
4. A user preferences dialog that is accessible and directly reachable from a login screen.

For products that are covered under 4-A.2, the user controls needed to access closed captioning and video description must be comparable in prominence to the play controls or channel selector.

Version 2 (Sean H)
No new provision here, but additional text added to 6C - Open or Closed Captions/Descriptions

For products as defined in 4-A.1 the controls to turn on or off captions and/or video descriptions must be comparable in prominence, in at least one location, to controls provided to control volume, or perform program selection, where the ability to control these features is otherwise provided.

• Status: In Progress See proposed updates to this provision
• Text from A/V
• Source: new
• Impact:
• External Reference:
• Testability: Inspection
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

5. Additional Provisions for Real-time Voice Conversation Functionality

5-A - Relay Services Accessibility

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.

Rationale:

• Status: Done See work in progress list
• Text from Telecommunications
• Source: new
• Impact:
• External Reference:
• Testability: #2 is testable by inspection
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

5-B - Real-Time Text Reliability and Interoperability

Version 1:

If hardware or software provides real-time voice conversation functionality it must provide at least one means of real-time text communication where the following reliability requirements are met:

1. Products must use a real-time text (RTT) format that meets the following requirements:
   • RTT format must be the standard real-time text format for the voice platform (one that is supported by all terminal, router, gateway and other products on that platform);
   • RTT format must transmit characters with less than 1 second delay from entry;
   • RTT format must transmit text with less than 1% Total Character Error Rate at the peak network traffic specified for intelligible speech transmission (text must work on the network as long as speech does);
   • RTT format must support intermixing of speech and text in both directions (and support speech and text simultaneously in both directions if IP based);
   • If product is IP based RTT format must not not rely upon audio tones for transmission of real-time text over IP.
2. Products and self-contained system of all types may use any real-time text format internally that meets reliability provision above as long as it support the following interoperability provisions where it connects to other systems and products:
   • If product interfaces with PSTN, it must use TIA 825 Baudot where it interfaces to the PSTN.
   • If product interfaces with other VoIP products or systems (outside of a self contained product-system) using SIP it must support RFC-4103 where it interfaces with other VoIP products or systems. If product uses SIP to interface with VoIP-to-PSTN Gateways it must also support RFC-4351. Gateways must support RFC-4103 and may support RFC-4351.
   • If product connects to other products or systems using a protocol other than SIP it must use the standard real-time text protocol that meets provision 1 above that has been established for that protocol.

NOTE: All products may support and use other protocols in addition to these as long as the meet the 5 requirements of 5-B(1) above.
NOTE: A self-contained SIP system that all uses the same real-time text protocol can be treated as a single product and can use any protocol internally as long as it supports RFC-4103 where the system-product connects to other systems or products.

• Status: In Progress See additional proposals for this provision
• Text from Telecommunications
• Source: {508]1194.23(b), {255}1193.51(e)
• Impact:
• External Reference:
• Testability: Inspection and formal test methods
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

5-C - Voice Terminal Hardware and Software

Terminal hardware or software that is capable of providing voice communications in real-time must comply with the following:

1. If hardware or software provides voice conversation over IP in any form, and has a user interface with a multi-line display or runs on devices that have a multi-line display, then terminal must display any real-time text that is received if it is received in the standard real-time text format for that voice transmission format or platform.
2. If terminal hardware or software provides voice conversation over IP in any form, and has text generation capability, then the terminal must allow user to send real-time text in the standard format for that voice transmission format in parallel with the voice.
3. If IP voice terminal hardware or software does not provide real-time text send and receive capability then the terminal must support the addition of terminals and terminal peripheral equipment that do support real-time text functionality in conjunction with the voice call functionality, in the same location and with the same permissions for use as their voice terminal. If the terminal is in a pubic or shared area and not in an individual's private work area then the connection must be possible without requiring system-administrator intervention.
4. If terminal is analog or TDM-digital wired terminal then it must support the connection of a TTY via an RJ-11 jack in the same location and with the same permissions for use as the telephone and it must be capable of allowing simultaneous speech and text conversation without interference or its microphone shall be capable of being turned on and off to allow the user to intermix speech with text use.

Note: Provision of the RJ-11 jack may be accomplished by through one of the following techniques:

• provision of the RJ-11 jack on the telephone,
• the use of a Y-adapter that allows both the analog telephone and the TTY to be plugged into the same line outlet,
• having built in capability to support an RJ11 module that can provide a connection point for TTYs;

Rationale:

• Status: In Progress See work in progress list
• Text from Telecommunications
• Source: {508}1194.23(a), {255}1193.51(d)
• Impact:
• External Reference:
• Testability: Inspection
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

5-D - IVR, Auto-Attendant and Messaging

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

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

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

Rationale:

• Status: In Progress See work in progress list
• Text from Telecommunications
• Source: {508}1194.23(c)
• Impact:
• External Reference:
• Testability: Inspection (#1,3,4) and Formal test method (#2)
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

5-E - Caller and Status Information

Products with visual interfaces that display telecommunications status information (such as caller identification and similar telecommunications functions) must also make this information available for:

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

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

Rationale:

• Status: Done See work in progress list
• Text from Telecommunications
• Source: {508}1194.23(e)
• Impact:
• External Reference:
• Testability: Inspection
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

5-F - Video Support

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. Communication products or systems that are used to transmit video communications in real-time between and among individuals must:
   • support interoperability to permit communication between and among users of terminals from different manufacturers and service providers;
   • 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
   • 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.
3. 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.

NOTES:

1. 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.
2. Twenty frames per second or better is recommended to facilitate lip reading and fingerspelling in the video communications provided under this section.
3. 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. http://www.itu.int/rec/T-REC-H.Sup1/en.
4. 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.

Rationale:

• Status: In Progress See work in progress list
• Text from Telecommunications
• Source: new
• Impact:
• External Reference:
• Testability: Formal test methods and inspection; will depend on how "X format" is defined."
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

6. Audio and/or Video Content

6-A - Captions and Transcripts

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

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

• Status: Done See comments on this provision
• Text from A/V
• Source: {508}1194.24(c) (was 6.B in Sept 14 draft)
• Impact:
• External Reference:
• Testability: Inspection
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

6-B - Video Description

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

1. materials containing prerecorded video and no original audio or other additional time-based content must provide either a separate text description of the video or provide an additional audio track to convey the informational content of the video.

2. materials containing prerecorded video with concurrent audio must provide synchronized video descriptions, or a separate text description of the video, to convey the informational content of the video.

3. materials containing live video must provide synchronized video descriptions in real time to convey the informational content of the video.

Version 2: Change #2 and #3:
2) materials containing prerecorded video with concurrent audio must provide synchronized video descriptions, or a separate text description of the video, to convey any informational content of the video that is not conveyed through other means.

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.

• Status: Done See comments on this provision
• Text from A/V
• Source: {508}1194.24(d) (was 6.C in Sept 14 draft)
• Impact:
• External Reference:
• Testability: Inspection; possibly expert evaluation regarding "informational content"
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

6-C - Open or Closed Captions/Descriptions

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

Proposed Addition
Proposal to add text here, rather than add new provision 4C - Access to Captions:

For products as defined in 4-A.1 the controls to turn on or off captions and/or video descriptions must be comparable in prominence, in at least one location, to controls provided to control volume, or perform program selection, where the ability to control these features is otherwise provided.

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

6-D - Interactive Elements

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

• Status: Done
• Text from A/V
• Source: new (was 6.E in Sept 14 draft)
• Impact:
• External Reference:
• Testability: Inspection; possibly expert evaluation regarding "interactive elements" and "content"
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

7. Information, Documentation and Support

There is a proposal to merge 7.1 and 7.2 since frequent current use of blended documentation and support styles, such as the self-service support on the web (look at our docs/Q&A database first, then ask a question through a form, email, call-back or live chat), are effectively blending the two.

This was not resolved due to not having clear text for the provisions. This will be addressed again once the provision text is complete.

7.1 Product Documentation and Help

New provisions proposed in this section for compatibility with 255

7.1-A - Accessible Documentation and Features

Documentation for users on the installation, configuration, or use of the product including the description, installation, and use of accessibility and compatibility features, must conform to the relevant accessibility provisions in 1194 Subparts B and C. This includes, but is not limited to, reports, system documentation, user help, and user training or technical support materials. Features included in the product specifically to meet accessibility requirements must be documented. The documentation must be available in alternate formats upon request.

Rationale: This draft combines two provisions for a clearer requirement and adds a requirement to document the accessibility features of a product.

Advisory Note: There is an overlap between general features and features that support accessiblity. 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
• Any features identified when completing the VPAT

• Status: Done See proposed updates to this provision
• Text from Documentation and Technical Support
• Source: {508}194.41(a), {508}194.41(b), {255}1193.33(a)(1)and {255}1193.33(a)(2)
• Impact: No Change
• External Reference:
• Testability: Tested according to the other provisions (ref. to "provisions in 1194 Subparts B and C")
• Metadata
  • Disabilities: All
  • User Activities: Training/learning
  • Product Characteristics: User documentation (any type – electronic or print)
  • Product Types: All

7.1-B - Keyboard Shortcuts

Version 1: Information about keyboard shortcuts must be made available in documentation.

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

Version 2: Information about keyboard shortcuts must be made available in documentation.

1. Keyboard shortcuts unique to the product or content must be programmatically determined, listed in context-sensitive help, or listed centrally for easy reference.
2. When the documentation lists specific pointing device based actions that are unique to the product or content, the keyboard commands must also be listed.

Version 3: Information about keyboard shortcuts not inherited from the operating system must be made available in documentation.

1. Shortcuts for keyboard operation must be listed for easy reference in contextual help, a central location, or other online documentation.
2. Shortcuts must be programmatically determinable for AT.
3. When the documentation lists specific pointing device based actions that are unique to the product or content, the keyboard commands must also be listed.

Rationale: The documentation of keyboard shortcuts can be hard to locate. This provision would require that this information be available in a useful form.

Rationale for Version 2: The requirement for information being "in one place" has the potential to add a large volume of pages (1,000's), and is too prescriptive. It could also lead to requiring multiple versions of the documentation since one application that can run on multiple platforms encounters different keyboard shortcuts based on the platform.

Rationale for Version 3: Clarification

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

7.1-X - Advisory Notes

Best practices for providing documentation to people with disabilities include:

1. Context-sensitive help

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

2. Text descriptions

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

3. User interface descriptions

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

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

7.2 Support and E&IT related services

7.2-A - Support Services

Version 1: Help desk and technical support services must offer information on the both basic use of the product and the accessibility features of the product, as well as information on how to install and configure assistive technology to work with the product. These support services must accommodate the communication needs of users with disabilities.

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

Discussion or Rationale:

Rationale for Version 1: This version ensures that users have access to support for both the product and any assistive technology they are using in one place.

Rationale for Version 2: This version is more specific regarding the type of support required. It eliminates the phrase "installing and configuring AT" in Version 1. Vendors feel they should be giving support information about their own product, not the AT. This input was also received from the AT vendors.

• Status: In Process See proposed updates and other discussion for this provision
• Text from Documentation and Technical Support
• Source: {508}194.41(c) and {255}1193.33(a)(3)
• Impact:
• External Reference:
• Testability: Expert evaluation
• Metadata
  • Disabilities: All
  • User Activities: Training/learning
  • Product Characteristics: All
  • Product Types: All

7.2-X - Advisory Notes

Best practices for providing support to people with disabilities include:

1. Remote assistance

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

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

8. Additional Provisions for Authoring Tools

• Note: Section 8.1 (If a Content Format) in the Sept 14 draft has been removed per instruction from the Web and Software Subcommittee.

8-A - Accessible Output

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

Rationale:

• Status: Done (was 8.2-A in Sept 14 draft) See work in progress list
• Text from Web and Software
• Source: new
• Impact:
• External Reference: ATAG, ISO 9241.71
• Testability: Inspection
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

8-B - Preserve Accessibility Information

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

Rationale:

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

• Status: Done (was 8.2-B in Sept 14 draft) See work in progress list
• Text from Web and Software
• Source: new
• Impact:
• External Reference: ATAG, ISO 9241.71
• Testability: Inspection; possibly some expert evaluation
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

8-C - Prompts

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

• Note: It is neither expected nor possible that prompts be available for every type of accessible content.

Rationale:

• Note: The committee recommends that advisory techniques be available and linked from this provision, regarding how to provide guidance on effective methods of prompting, as well as techniques to avoid.

• Status: Done (was 8.2-C in Sept 14 draft) See work in progress list
• Text from Web and Software
• Source: new
• Impact:
• External Reference: ATAG, ISO 9241.71
• Testability: Inspection
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

8-D - Accessible Templates

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

Rationale:

• Note: This provision may need two further clarifications, which could be in the form of advisory notes, to the effect that (1) this provision should not be applied to formats which are not enabled for accessibility support, and that (2) this provision is not intended to require an accessible template for every template that is packaged with an authoring tool, however neither is it intended to imply that, where there are many different types of templates with unique features, only one accessible template would be provided.

• Status: Done (was 8.2-E in Sept 14 draft) See work in progress list
• Text from Web and Software
• Source: new
• Impact:
• External Reference: ATAG, ISO 9241.71
• Testability: Expert evaluation
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

8-X - Advisory Notes

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.

Rationale:

• Status: Done per committee (was 8.2-D in Sept 14 draft) See work in progress list''
• Text from Web and Software
• Source: new
• Impact:
• External Reference: 'ATAG, ISO 9241.71'
• Testability: Inspection
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types: