EWG:Draft Jan 7

Editorial Working Group > Current Draft

The final report of the Committee, and all minority reports can be found on The Access Board web site. Just scroll down to the end of the chronological listing for both HTML and .DOC versions.

This page reflects the work of the Committee from the January in-person 
meeting the end of the committee work on April 3. This page was updated 
through the March 25 meeting, but final editorial adjustments to the 
provisions made as the final report was prepared may not be reflected 
in the version on this page. Please see the TEITAC final report. 

* Status Spreadsheet - an overview of the status of the work 

General Introduction

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

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

Subpart A

Section 1194.1 Purpose

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

Purpose for Section 255

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

Text from: Telecommunications §1193.2; FCC Report and Order No. 07-110, released June 15, 2007) – amended to include interconnected VoIP equipment and CPE (new material in italics)

Purpose for Section 508

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

Explanatory Notes (for both 255 and 508 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 C.

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.

• Status from on November plenary: Could not reach consensus
• Text from Subpart A Subcommittee
• Source: {508}1194.1
• Impact:
• External Reference:

Section 1194.2 Application

Multiple versions will be sent to the Access Board.

Application for Section 255

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

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

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

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

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

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

Prohibited reduction of accessibility, usability and compatibility

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

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

Text from: Telecommunications §1193.21 (first paragraph) and Telecommunications §1193.23 (second section).

Application for Section 508

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

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

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

(2) When developing, procuring, maintaining, or using a product, if an agency determines that compliance with any provision of this part imposes an undue burden, the documentation by the agency supporting the development, procurement, maintenance, or use must explain why, and to what extent, compliance with each such provision creates an undue burden. (see note #2)

(3) When determining whether application of the standards would result in an undue burden, an agency must consider all agency resources available to the program or component for which the product is being developed, procured, maintained, or used.

(4) Technical infeasibility, if substantiated by empirical evidence or documentation, is one factor in determining whether application of the standards [provisions] would consitute an undue burden. (see note #3)

(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. (see note #4)

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

Rationale and Notes

Note 1: This additional introductory language is intended to clarify that all of the regulations in this section that impact agency procurement procedures, apply only to the consideration of accessibility. The additional language is not intended to provide regulatory direction regarding how agencies consider other factors, such as business and technical needs and requirements, when making an acquisition. The FAR defines procurement parameters for a number of agencies and agencies need to determine how to address accessibility within the parameters of other required procurement considerations and processes. The workgroup has discussed the fact that there have been varying interpretations of how Section 508 should be applied when making an acquisition. Agencies are required to consider accessibility within the framework of other regulated procurement practices such as the FAR. Consensus was not reached on this item and the alternative position is to not add this introductory language.

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

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

Note 4: The last sentence of this subsection (in italics) has been reworded to clarify the use of “best meets” when products are not commercially available that comprehensively meet each and every standard, but might partially meet one or more individual standards or meet some but not all of the standards. The rewording is intended to improve understanding of the sentence. A reference to business need has also been added in an attempt to clarify the interaction between degree to which a product conforms to the access standards and overall agency needs. The wording “given business needs” was an attempt to parallel the direction from the Access Board that best meets means “best meets the agency’s needs in light of the accessibility requirements of Section 508.”

Consensus was not reached on this item and an alternative position is to delete the last sentence completely, leaving the subsection with the first two sentences. Deleting the last sentence would defer all procurement decision-making procedures to the Federal Acquisition Regulations (FAR) and/or other governing procurement policies. The Access Board and FAR will be simultaneously considering the 508 regulations. As a result, GSA and the Access Board could consider how to ensure best provide guidance for agencies to implement 508 within the procurement process through the FAR rather than the Section 508 regulations.

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

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

Notes from Plenary Call, March 4, 2008:

Peter: Regarding #4, Technical infeasability issue. Wants a reference to fundamental alteration or expand this to encompass fundamental alteration. Peter given AI to write a proposal.

• Status: Consensus on March 4
• Text from Subpart A Subcommittee
• Source: {508}1194.2, {255}1193.21 (first paragraph,) {255} 1193.23 (second section)
• Impact:
• External Reference:

Section 1194.3 General Exceptions

1194.3 - A - Intelligence Or Security Systems

This part does not apply to any electronic and information technology operated by agencies, the function, operation, or use of which involves intelligence activities, cryptologic activities related to national security, command and control of military forces, equipment that is an integral part of a weapon or weapons system, or systems that 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: Consensus on Dec 4
• Text from Subpart A Subcommittee
• Source: {508}1194.3(a), no change

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: Consensus on Dec 4
• 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: Consensus on Dec 4
• 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: Consensus on Dec 4
• Text from Subpart A Subcommittee
• Source: {508}1194.3(d), no change

1194.3 - E - Fundamental Alteration

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

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

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

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

1194.3 - F - Maintenance and Monitoring Aspects of Products

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

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

• Status: Consensus on Jan 9
• Text from Subpart A Subcommittee
• Source: {508}1194.3(f)

Section 1194.4 Definitions

Accessible Content Format (no consensus)

Version 1:
A format that supports the creation of content to meet Section 508 requirements.

Version 2, proposed in email by Judy B, March 18:
A data format that enables the encoding of information in such a manner that it is consistent with the relevant provisions of Section 508.

Status: Discussion via email

Agency

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

Status: Consensus on Dec 18
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.

NOTE: This term is currently not used in the provisions. If it continues to not be used, it will be removed.

Status: Consensus on Dec 18 (recommend removal, if no longer used)
Text from: Web and Software Subcommittee.

Assistive Technology

Version 1 - Consensus on Dec 18
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.

Note: Abbreviated as "AT"

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

Version 2 - added language for 255, per request on March 11
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 or software, mainstream technology used as assistive technology, virtual assistive technology delivered as a web service, the integration of products into a system that provides assistive technology functions which allow individuals with disabilities to access electronic and information technology, and existing peripheral devices or specialized customer premises equipment commonly used by individuals with disabilities to achieve access.

Rationale for change: Need to add language for section 255. The following is how the statutory language be somehow defined as AT when used in the context of Section 255.
(d) Compatibility
Whenever the requirements of subsections (b) and (c) of this section are not readily achievable, such a manufacturer or provider shall ensure that the equipment or service is compatible with existing peripheral devices or specialized customer premises equipment commonly used by individuals with disabilities to achieve access, if readily achievable.

Status: Consensus on Dec 18, request to add information for Section 255 on March 11, no quorum on call
Text from: Subpart A

Authoring Tools (no consensus)

Any software intended to create or modify electronic content for publication in one or more formats that support compliance with the user interface and content provisions.

Note: Simple text editors that can only create or modify content in conforming formats by directly editing the code are not considered authoring tools under this definition.

Status: Jan 2 - agreement on sense of definition, but no quorum, no final decision; March 10 added "electronic"
Text from: Web and Software

Blinking (no consensus)

Switch back and forth between two visual states in a way that is meant to draw attention.

Note: See also flash (It is possible for something to be large enough and blink brightly enough at the right frequency to be also classified as a flash).

Status: New proposal, March 17
Text from: General, WCAG

CAPTCHA

Initialism for "Completely Automated Public Turing test to tell Computers and Humans Apart"

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

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

Status: Consensus on Dec 18
Text from: Web and Software

Captions (no consensus)

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

Version 2 - WCAG 2.0
Synchronized media or text equivalents for audio information including both dialog and non-dialog audio information

Note 1: Captions are similar to dialog-only subtitles except captions convey not only the content of spoken dialog, but also equivalents for non-dialog audio information needed to understand the program content, including sound effects, music, laughter, speaker identification and location.

Note 2: Closed Captions are captions that can be turned on and off in some players.

Note 3: Open Captions are captions that cannot be turned off. For example, if the captions are visual equivalent images of text embedded in video.

Note 4: Captions should not obscure or obstruct relevant information in the video.

Note 5: In some countries, captions are called subtitles.

Note 6: Video descriptions can be, but do not need to be, captioned since they are descriptions of information that is already presented visually.

Version 3 (email March 16, with agreement from Gregg, Karen, Geoff):
Synchronized “text” and symbol equivalents for audio information.

Note 1: The term “text” in this definition refers both to electronic text and to images of text that might be embedded in the video.

Note 2: Captions are similar to dialogue-only subtitles except captions convey not only the spoken words, but also other audio information needed to understand the program content, including sound effects, music, laughter, tone of voice, speaker identification, and location.

Note 3: Captions can be “closed” or “open”. Captions that are “closed” can generally be turned on and off by viewers. Captions that are “open” are any captions that cannot be turned off. For example, captions that are visual equivalent images of text embedded in video are “open”.

Note 4: Captions should not obscure or obstruct relevant information in the video.

Note 5: In some countries captions are called subtitles.

Note 6: Video descriptions can be, but do not need to be, captioned because they are descriptions of information that is already presented visually.

Rationale for version 3:
Some of the issues that came up on the side discussions that are all addressed above are as follows.

1. Captions are not just text but also include other symbols (music notes etc) that should be allowed

2. The word ‘text’ is ambiguous since we allow images of text here but images of text cannot be used as text in other parts of these same guidelines. Need a note to clarify

3. If we just say visual equivalents – then sign language would satisfy this and it shouldn’t – that shouldn’t be called captioning

4. Open captions are not just images of text embedded in video stream – but can be any captions that cannot be turned off and on.

5. Closed captions cannot be turned on and off in all players/viewers

6. Can we use dialogue instead of dialog to avoid confusion with dialog boxes (in which captions can in fact be presented)

7. Non-verbal (which means non-word) can separate out visual signing from visual symbols like music notes but many people misread non-verbal to mean non-vocal or non-speech and that creates all sorts of new problems. the “non-spoken” is close here but the cue that the person is SHOUTING is non-verbal but not non-spoken so ‘non-spoken’ misses some of the important information.

8. Keep it simple - (at one time the definition had grown to “synchronized visual equivalents for both dialogue and non-dialogue audio information needed to understand the media content where the equivalents are either text or images of text combined with non-verbal visual elements (such as music notes).”) until we regrouped and went back to the simple one we had and just applied the essential fixes needed to it.

9. ‘symbols’ doesn’t cover font styling and color – but that could be covered by word ‘text’ in definition since they are characteristics of text and adding “and font styling and color” to the definition would make it more complete as the expense of making it more complex.

Open Issues

• Version 3 was agreed to by the task force, but the committee did not have enough time to bring this definition back up for a consensus decision.

Status: Consensus on Dec 18- reopened in email Feb 15, updated via email March 9
Text from: Audio/Visual

Caption Text (no consensus)

Definition from WCAG:
Text presented and synchronized with synchronized media to provide not only the speech, but also non-speech information conveyed through sound, including meaningful sound effects and identification of speakers

Note 1: In some countries, the term "subtitle" is used to refer to dialogue only and "captions" is used as the term for dialogue plus sounds and speaker identification. In other countries, subtitle (or its translation) is used to refer to both.

Note 2: Video descriptions can be, but do not need to be, captioned since they are descriptions of information that is already presented visually.

Comments to Resolve:
There is a proposal to remove this definition and use only "captions."

Status: Discussion via email
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: Consensus on Dec 18
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. For example: word processing files, presentation files, spreadsheet files, text files, portable document files, web based content, etc.

Status: Consensus reached Jan 7
Text from: Web and Software

Content Format

An encoding mechanism for storing information.

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

Status: Consensus reached Jan 7
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.

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

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

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

Note 4: Background color is the specified color of content over which the text is to be rendered in normal usage. If no background color is specified, then white is assumed.

Note 5: For text displayed over gradients and background images, authors should ensure that sufficient contrast exists for each part of each character in the content.

Status: Consensus reached Jan 7
Text from: Web/Software

Customer Premises Equipment (Consensed)

Equipment employed on the premises of a person (other than a carrier) to originate, route, or terminate telecommunications or interconnected VoIP service.

Status: Consensus on Dec 18
Text from: Telecommunications §1193.3
Source: Telecommunications Act of 1996; FCC Order No. 07-110

Decoration

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

Status: Consensus reached Jan 7)
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.

Note suggested by CSD/Trace Center (no consensus)
E&IT that is combined with non-E&IT is covered but the coverage does not extend to the non-E&IT. There are many compound products that are clearly IT with something added. For example, a computer mounted on the door of a refrigerator should count as a computer – but the refrigerator should not be included.

(Note on when AT is E&IT moved for discussion to Collection on AT-IT )

Status: Definition part of Clinger-Cohen. Notes still to be discussed
Text from: Subpart A
Source: Clinger-Cohen

Enhanced Audio (no consensus)

Audio which has been enhanced through amplification and/or through a variety of audio signal processing to make it easier for people with hearing loss to understand.

• NOTE: The definition was added to support 1.1-E - With Limited Hearing. If rewrite provision, the definition is not needed.

Status: Jan 2: Since the provision that uses this is not resolved, not able to consider this definition consensed. Updated March 10
Text from: General

Flash (no consensus)

A pair of opposing changes in luminance (relative luminance for software and content) that can cause seizures in some people if it is large enough and in the right frequency range

Note 1: See general flash threshold and red flash threshold definitions for information about types of flash that are not allowed.

Note 2: See also blinking.

Status: New proposal, March 17
Text from: WCAG, General

Free-Standing (no consensus)

Proposed definition from Trace
Standing on the floor and not intended to be placed on a table or built into a structure

Example: The kiosk was a free standing device that stood on the carpet in front of the registration desk.

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

Status from on November plenary: Not discussed
Text coming from Hardware

General Flash and Red Flash Thresholds for Hardware (Consensus on Concept)

The Committee agreed that this draft language for 2.1-B-Flashing (Hardware) and the related definition General Flash and Red Flash Thresholds for Hardware be sent to the Access Board as a basis for further work on exact numbers in the definition and further work.

A hardware flash is below the threshold (i.e. software or content passes) if any of the following is true:

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

2. The flash frequency is 50 or 60 Hz and is due to a refresh that is intrinsically tied to the local line frequency OR

3. The flash frequency is 75 hz or greater OR

4. General flashes (that have less than a 590 nm wavelength) are no more than 20 cd/m2 AND red flashes (that have a 590 nm wavelength or longer) are no more than 2.5 cd/m2 OR

5. General flashes are no more than (1200/N^0.3)(0.006/AREA – 1) cd/m2 AND red flashes (that have a 590 nm wavelength or longer) are no more than (150/^0.3)(0.006/AREA – 1) cd/m2 OR

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Text from: Hardware/New

General Flash and Red Flash Thresholds for Content and User Interfaces (no consensus)

A flash or rapidly changing image sequence is below the threshold (i.e. software or content passes) if any of the following is true:

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

2. The combined area of flashes occurring concurrently occupies no more than a total of .006 steradians within any 10 degree visual field on the screen (25% of any 10 degree visual field on the screen) at typical viewing distance where:

• A general flash is defined as a pair of opposing changes in relative luminance of 10% or more of the maximum relative luminance where the relative luminance of the darker image is below 0.80; and where "a pair of opposing changes" is an increase followed by a decrease, or a decrease followed by an increase, and

• A red flash is defined as any pair of opposing transitions involving a saturated red.

Exception: Flashing that is a fine, balanced, pattern such as white noise or an alternating checkerboard pattern with "squares" smaller than 0.1 degree (of visual field at typical viewing distance) on a side does not violate the thresholds.

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

Note 2: A transition is the change in relative luminance (or relative luminance/color for red flashing) between adjacent peaks and valleys in a plot of relative luminance (or relative luminance/color for red flashing) measurement against time. A flash consists of two opposing transitions.

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

Note 4: Tools are available that will carry out analysis from video screen capture. However, no tool is necessary if flashing is less than or equal to 3 flashes in any one second period (content automatically passes (see #1 and #2 above)).

• Status: March 17 New text proposed, replaces earlier versoin

Text from: Web/Software

Information Technology (no consensus)

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 from on November plenary: Not discussed
Text from: Subpart A

Interactive Elements (no consensus)

Proposed definition from GV
Elements of the user interface that are acted on by the user.

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

Status from on November plenary: Not discussed
Text coming from A/V Subcommittee

Interconnected Voice over Internet Protocol (VoIP) Product

A product that is used to provide interconnected VoIP service

Status: Consensus on Dec 18
Text from: FCC regulations 47 C.F.R. §9.3

Interconnected Voice over Internet Protocol (VoIP) Service

A service that:

1. Enables real-time, two-way voice communications;
2. Requires a broadband connection from the user's location;
3. Requires Internet protocol-compatible customer premises equipment; and
4. Permits users generally to receive calls that originate on the public switched telephone network and to terminate calls to the public switched telephone network.

Status: Consensus on Dec 18
Text from: FCC regulations 47 C.F.R. §9.3

Keyboard

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

Status: Consensus on Dec 18
Text from: Web and Software

Keyboard Interface

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

Status: Consensus on Dec 18
Text from: Web and Software

Label

Text or other component with a text alternative that is presented to a user to identify a component within content.

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

Status: Consensus on Feb 26
Text from: WCAG

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: Consensus on Dec 18
Text from: Web/Software

Manufacturer (no consensus)

A manufacturer of telecommunications or VoIP equipment or customer premises equipment that sells to the public or to vendors that sell to the public; a final assembler.

• Requested this definition be added to support Section 255.
• (GV) Change so that it is not limited to VOIP since it is used more generally in the provisions and this would limit all those provisions.

Status from on November plenary: Not discussed
Text from: Telecommunications §1193.3
Source: Telecommunications Act of 1996; FCC Order No. 07-110

Menu (no consensus)

Set of selectable options.

Comments to be resolved:

• (Peter K) this needs to be scoped, perhaps just to telecom or “audio menus”. As it reads now, things like a collection of radio buttons would be considered a menu. Also, where is this term used in 508? three things to consider: instead of “Set of selectable options”, what about “Presentation of a set of selectable options”, or “Presentation of a set of user-selectable options”. But in either case, we should note that this is an audio/aural presentations
• (Gregg V) Menu is used in a number of places. We need to be careful of each one.
• (CSD/Trace Center) Agree with Peter K and Gregg V comments. Menu is used in 2 places: 3-CC advisory note example referring to software menus and in 4-C to refer to menu's on television display like device. No suggested text.

• This was discussed at the November plenary and the term removed from provision 6C - Interactive Elements, but the term is still used and the definition can not be removed as proposed.

Status from on November plenary: Discussed but not completed
Text from: Telecommunications
Source: HFES 200

Non-text Object

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

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

Status: Consensus on Dec 18
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: Consensus on Dec 18
Text from: Web and Software

Peripheral Devices (no consensus)

Devices employed in connection with telecommunications or VoIP equipment or customer premises equipment to translate, enhance, or otherwise transform telecommunications or VoIP services into a form accessible to individuals with disabilities

• Requested this definition be added to support Section 255.

Status from on November plenary: Not discussed
Text from: Telecommunications §1193.3
Source: Telecommunications Act of 1996; FCC Order No. 07-110

Platform Accessibility Services

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

NOTE: This term is currently not used in the provisions. If it continues to not be used, it will be removed.

Status: Consensus on Dec 18 (recommend removal, if no longer used)
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 that allows them to be isolated from the underlying software or hardware layer.

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

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

Note 3: A particular software component may play the role of a platform in some situations and not in others. Platforms can include such things as Internet browsers, operating systems, plug-ins to internet browsers or other software applications, and under some situations, byte-code interpreted virtual environments, and other "programming within another programming" environments.

Status: Consensus on Dec 18
Text from: Web/Software

Programmatically Determinable (no consensus)

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

Version 2 (Trace)
Determinable by user agents, including assistive technologies, from the data provided.

Note 1: Purpose is to allow user agents including assistive technologies to extract and present this information to users in different modalities.

Note 2: Programmatically determinable requires that the information be determinable by existing assistive technologies.

Version 3 (WCAG)
Determined by software from author-supplied data provided in a way that different user agents, including assistive technologies, can extract and present this information to users in different modalities

Example 1: Determined in a markup language from elements and attributes that are accessed directly by commonly available assistive technology.

Example 2: Determined from technology-specific data structures in a non-markup language and exposed to assistive technology via an accessibility API that is supported by commonly available assistive technology.

Comments to Resolve:

• Peter K: Disagree with second note - and that goes to the heart of the 3-New Assistive Technologies provision. I believe something should be "programmatically determinable" [full stop] whether or not AT is in the picture. If and where we want to mean "programmatically determinable by existing AT", then we should spell that out in those places. I think this is particularly important in light of common engineering understanding of this term (and will cause significant confusion if we define it to mean more).
• Randy M, Gregg V: Prefer to keep AT in the definition.
• Allen H: In note 2, "existing" assistive technology indicates "at a point in time". Wen the product is designed, developed, or delivered, used, upgraded, replaced? I can work with the items up to the second note.

Status from on November plenary: Not discussed
Text from: Web/Software

Readily Achievable

Easily accomplishable and able to be carried out without much difficulty or expense.

Status: Consensus on Dec 18
Text from: Telecommunications §1193.3 (no change)
Source: Telecommunications Act of 1996

Real-time Text (no consensus)

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.

Comments to be resolved:

• (Peter K) Do we need "by a terminal"
• (Gregg V) I believe that phrase was included to prevent the 1 second from being applied to things that retransmit the text enroute.
• (CSD/Trace Center) After the word "terminal" add "(hardware or software)" to clarify since that is how it is used in the provisions.

Status from on November plenary: Not discussed
Text from: Telecommunications

Relative Luminance (no consensus)

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

Note 1: For the sRGB colorspace, the relative luminance of a color is defined as L = 0.2126 * R + 0.7152 * G + 0.0722 * B where R, G and B are defined as:

• if RsRGB <= 0.03928 then R = RsRGB/12.92 else R = ((RsRGB+0.055)/1.055) ^ 2.4
• if GsRGB <= 0.03928 then G = GsRGB/12.92 else G = ((GsRGB+0.055)/1.055) ^ 2.4
• if BsRGB <= 0.03928 then B = BsRGB/12.92 else B = ((BsRGB+0.055)/1.055) ^ 2.4

and RsRGB, GsRGB, and BsRGB are defined as:

• RsRGB = R8bit/255
• GsRGB = G8bit/255
• BsRGB = B8bit/255

The "^" character is the exponentiation operator. (Formula taken from sRGB and IEC-4WD.)

Note 2: Almost all systems used today to view Web content assume sRGB encoding. Unless it is known that another color space will be used to process and display the content, authors should evaluate using sRGB colorspace. If using other color spaces, see Understanding Success Criterion 1.4.3.

Note 3: If dithering occurs after delivery, then the source color value is used. For colors that are dithered at the source, the average values of the colors that are dithered should be used (average R, average G, and average B).

Note 4: Tools are available that automatically do the calculations when testing contrast and flash.

Note 5: A MathML version of relative luminance definition is available WGAC.

Status from on November plenary: Not discussed, updated by Gregg March 18 to add "in a colorspace"
Text from: Web/Software

Simple Tactile Form (no consensus)

Tactile form that does not require the memorization of any spatial or temporal tactile patterns.

Note 1: Simple vibration or switch up/down positions are examples of simple tactile forms.

Note 2: Braille, tactile Morse code, and vibration patterns are samples of more complex tactile forms that require memorization of non-trivial spatial and tactile patterns respectively, and therefore are not Simple Tactile Forms.

Note 3: Different numbers of tactile buzzes, or different frequency buzzes would be non-trivial patterns, and would not be simple tactile forms.

Status: Updated from emails, March 11, March 12
Text from: Provision 1-E

Specialized Customer Premises Equipment

Equipment, employed on the premises of a person (other than a carrier) to originate, route, or terminate telecommunications or VoIP services, which is commonly used by individuals with disabilities to achieve access..

Status: Consensus on Dec 18
Text from: Telecommunications §1193.3; FCC Order No. 07-110

Synchronized Media

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

Status: Consensus on Dec 18
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: Consensus on Dec 18
Text from: Telecommunications
Source: Telecommunications Act of 1996

Telecommunications Equipment

Equipment, other than customer premises equipment, used by a carrier to provide telecommunications services, and includes software integral to such equipment (including upgrades).

Status: Consensus on Dec 18
Text from: Telecommunications §1193.3 (no change)
Source: Telecommunications Act of 1996

Telecommunications Service

The offering of telecommunications for a fee directly to the public, or to such classes of users as to be effectively available directly to the public, regardless of the facilities used.

Status: Consensus on Dec 18
Text from: Telecommunications §1193.3 (no change)
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: Consensus reached Jan 7
Text from: Telecommunications

Text (no consensus)

Sequence of characters that is programmatically determinable, where the sequence is expressing something in human language.

Status: New - 26 Feb. Proposed to ensure harmonization
Text from: WCAG

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: Consensus on Dec 18
Text from: Telecommunications

Typically Held to the Ear

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

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

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

Status: Consensus on Jan 9
Text from: Hardware/Telecommunications

Unavailable Items

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

Status: Consensus on Dec 18
Text from: Web and Software, listed in provision 3-D User Preferences

Undue Burden

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

Status: Consensus on Dec 18
Text from: Subpart A (no change)

Usable

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

Status: Consensus on Dec 18
Source: Telecommunications §1193.3 (no change)

Video Description (no consensus)

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: Discussed Jan 7, Larry to resolve email issues
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 (Consensed)

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: Consensus reached on Jan 9
Source: {508}1194.5, no change

Subpart B: Functional Performance Criteria

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

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

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

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

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

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

C - With Color Vision Deficits
Products must provide at least one mode that allows access to all functionality without relying on users’ perception of color. (See note on functional performance criteria and assistive technology.)

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

E - With Limited Hearing (No Consensus)
TEXT AS OF MARCH 25
Version 1:
Where audio information is important for the use of a product, it must provide at least one mode that allows user control of volume and/or reduction of background noise. (See note on functional performance criteria and assistive technology.)

Version 2:
Products must provide at least one mode that allows access to all functionality of the product with limited hearing. (See note on functional performance criteria and assistive technology.)

Version 3, proposed in email from Gregg, March 17:
Where audio information is required for the use of a product, the product must provide at least one mode that allows user control of volume and/or reduction of background noise. (See note on functional performance criteria and assistive technology.)

• IBM/Sun: seems to be more of a general technical provision. Recommend change the FPC entry using the wording similar to that used in "without hearing"

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

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

I - Without Physical Contact (No Consensus)
TEXT AS OF MARCH 25
Products must provide at least one mode that allows access necessary to operate all functionality of the product without requiring any physical contact with the product beyond initial connection and setup of a special interface device. This does not apply to powering product up, changing consumables, configuration, set-up or maintenance. (See note on functional performance criteria and assistive technology.)

Note: For initial setup, it is acceptable to use a physical connector (eg. a USB connector) to connect the user's special interface device.

Rationale and Notes 1. It is well known that a large population of people with physical disabilities cannot reach out to touch a product or cannot reach out long enough to actually operate a product physically.

2. While it is preferable that no contact at all be required, some physical contact may be needed to turn power on, initialize a telephone call, load or remove paper or consumables, or change mode of operation. In some cases it may be required for the user to be assisted by a companion or bystander with these operations.

3. Assistive Technology examples:

• The use of a standard network interface (e.g. USB, Ethernet, IEEE 1394, Wi-Fi,

Bluetooth, etc.) that allows users to control the product using software via a wired or wireless network connection would meet this provision.

• The use of the infra-red (“IR”) port used for remote controls in consumer electronics

products would meet this provision.

4. Direct Access examples:

• Voice dialing or voice control is an example of direct access. Access to voice

dialing or voice control may require physical contact with the product to initiate the call or change mode of operation to enable voice recognition.

Open issues for I

• TIA cannot agree to this in its current wording. The concern is the phrase

"all functionality" even when you consider use with Bluetooth, etc. because those technologies still require a "push to talk" action for general operation.

• Avaya: This would add expense to low-end products, so more comfortable with

this just for 508.

J - With Cognitive, Language or Learning Limitations (No Consensus)
TEXT AS OF MARCH 25
Version 1: proposed by Karen PS, Trace, CSD in FPC version 1 above:
Products must provide at least one mode that accommodates cognitive, language, memory or learning impairments. (See note on functional performance criteria and assistive technology.)

Rationale for J: The telecommunications guidelines include a requirement for provision of a mode that “minimizes the need for memory.” §1193.41(i). This version adds the word "memory".

Version 2
{This provision subject to wording that would be testable}.

Open issues for J:

• Sun: include in the narrative a list of technical provisions that support CLL disabilities. Should include info in the narrative explaining the info we have and how we were unable to specifically address the criteria.
• Allen: Regarding "J" make the list of which provisions apply, and write guidelines noting evaluation guidelines for how evaluate.
• Note to plenary regarding provision "J", this is part of Section 255. § 1193.41 Input, control, and mechanical functions.
  

Input, control, and mechanical functions shall be locatable, identifiable, and operable in accordance with each of the following, assessed independently:
(i) Operable with limited cognitive skills. Provide at least one mode that minimizes the cognitive, memory, language, and learning skills required of the user.

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

Advisory Note to the Access Board: The Committee was unable to come to an agreement on whether items #1 and #2 above are required ("must") or an option ("can"). The Access Board is requested to make this determination.

Note for EWG or Access Board: We need a note explaining what "provide at least one mode" means, and that one mode does not exclude another.

• Randy: Agreed to not address multiple disabilities at the beginning of this TEITAC review, so each of these FPC are mutually exclusive.
• Karen to look for notes regarding FPCs and multiple disabilities.

Subpart C: Technical Provisions

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

For the purposes of Section 508, compliance with the functional performance and technical criteria contained in this part may be achieved directly or through assistive technology by each federal agency, unless the agency can show that such compliance would cause an undue burden.

1 General Technical Requirements

1-A - Closed Functionality

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

• 2.1-E - Standard User Interface Connection
• 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-Q - Disruption of Access Features
• 3-P - User Interface Components
• 3-U - AT Interoperability
• 3-V - Accessibility Services
• 3-VV - Assistive Technology

• Status: Consensus reached at November Plenary
• Text from Self Contained, Closed
• Source: {508}1194.25(a)
• Impact:
• External Reference:
• Testability: Expert evaluation
• Disabilities: All

1-B - 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 method of identification must also be provided.

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

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

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

TEITAC Discussion to be sent to the Access Board:
People who do not have fingers, eyes, etc are not able to make use of biometrics-based E&IT simply because currently these solutions rely upon only one unique biometric measurement, such as a fingerprint. Allowing such solutions to accept alternative biometrics will greatly decrease the number of people who are unable to use such biometrics solutions, since people with multiple disabilities of this type are a smaller portion of the population. This, however, is only an interim step until biometric or 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.

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

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

1-C - Pass Through

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

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

• Status: Consensus reached on Jan 7
• Text from Telecommunications
• Source: {508}1194.23(j), {255}1193.37
• Impact:
• External Reference:
• Testability: Inspection
• Disabilities: Hearing, vision, cognition

1-D - Audio Information

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

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

• Status: Consensus reached on Jan 8
• Text from Self-Contained/Closed
• Source: {255}1194.43(d)
• Impact:
• External Reference:
• Testability: Expert evaluation
• Disabilities: Deafness, Hard of Hearing

1-E - Visual Information (no consensus)

TEXT AS OF MARCH 25

Version 3 - Sun
Remove entirely. This provision should not exist at all.

Version 4 (3/18)
All information that is needed for operation and use that is provided in visual form must also be available in at least one mode in audio form or in simple tactile form, either directly or through support for the following provisions in Section 3 <insert list>.

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

Note 1: Section 255 and Section 508 treat AT solutions differently, so review section XX of this document before implementing a solution.

Note 2: Braille is not a simple tactile form. It is encouraged but cannot be used to satisfy this provision.

• Status: Discussed Feb 6, Recommended accepting basic wording, but AT issue still open. Recommended accepting definition. Discussed Feb 26: formed task force to look at this. Updated 3/3 to use "Simple Tactile Forms" in provision, and updated version 2, and note from Sean
• Text from Self-Contained/Closed
• Source: {255}1194.43(a)
• Impact:
• External Reference:
• Testability: Expert evaluation
• Disabilities: Blindness, Low Vision

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

• Status: Consensus reached at November Plenary
• Text from Web/Software
• Source: {508}1194.25(g) and 1194.21(i): {255}1194.41(c)
• Impact:
• External Reference: Harmonized with WCAG 2.0-1.4.1 Use of Color (Level A) and ISO 9241-171
• Testability: Expert evaluation
• Disabilities: Color deficiency/Colorblindness

1-G - Text size (no consensus)

TEXT AS OF MARCH 25

Version 1 (GV email 3/22)
For all public or shared products, there must be at least one mode where all information that is required for product use and is provided in text or images of text is readable by people with 20/20 vision at 3.5 times their typical viewing distance. 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. This requirement does not apply to the caption decoding functions of products that are governed by U.S. Federal Communications Commission (FCC) regulations 47 CFR 15.119 or to devices that provide equivalent functionality as stipulated by 4-A - Caption Processing.

Note 1: Safety labels, regulatory labels, and other marks (such as logos and certifications) are not included unless for some reason they are required by the user “for product use”.

Note 2: If other means of visually conveying the information in the label or instructions exists (e.g. uniquely tactilely discernible through shape), then the text is not "required for product use" and the text size requirement does not apply. For example, a phone-like numeric keypad (with nib) or a tactilely unique cluster of arrow keys are usable without labels while softkeys (where the function changes and must be read from a display) would not be usable without the label.

Note 3: Personal or personally assigned devices are not covered unless all users must use the same product (or same type of product) (e.g. policy or in order to work with system software or procedures). In that case it constitutes a ‘shared device’ since all must use the same one (the same type) and that product (or type) would need to meet provision.

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

Note 5: Software that is not associated or purchased with any particular hardware (so the text does not have a physical size until it is displayed) can be evaluated on any typical display that the software is intended to work with.

Version 2 (Trace 3/24)
For all public or shared products there must be at least one mode where all information that is required for product use and is provided in text or images of text is readable by people with 20/20 vision at 3.5 times their typical viewing distance and where the mode is the default mode or the method for activating the mode meets this requirement except:

(a) Caption display: This requirement does not apply to the caption decoding functions of products that are governed by U.S. Federal Communications Commission (FCC) regulations 47 CFR 15.119 or to devices that provide equivalent functionality as stipulated by 4-A - Caption Processing.
(b) Logos and Certifications: Safety labels, regulatory labels, and other marks (such as logos and certifications) are not included except where they are required by the user “for product use”.
(c) Tactile Equivalents: If other means of visually conveying the information in the label or instructions exists (e.g. uniquely tactilely discernible through shape), and the text is not "required for product use" then the text size requirement does not apply.

• For example, a phone-like numeric keypad (with nib) or a tactilely unique cluster of arrow keys are usable without labels while softkeys (where the function changes and must be read from a display) would not be usable without the label.
  

(d) Personal devices: Personal or personally assigned devices are not covered unless all users must use the same product (or same type of product) (e.g. policy or in order to work with system software or procedures). In that case it constitutes a ‘shared device’ since all must use the same one (the same type) and that product (or type) would need to meet provision.
(e) Use of text file: Providing text in an accessible file on a device meets this requirement for information that is not location specific (e.g. labels are location specific). (f) Application to Software: Software that is not associated or purchased with any particular hardware (so the text does not have a physical size until it is displayed) can be evaluated on any typical display that the software is intended to work with.

Rationale
The goal of this provision is to support people with low vision. People with vision worse than 20/70 typically use an assistive device, so this provision is aimed at supporting those with vision between 20/40 and 20/70.

• For people with 20/20 vision viewing text at 40 cm (15.7 inch), 8pt type is a small but acceptable type size for running text and somewhat smaller text could be used for common labels where it is mostly identifying which key is which rather than having to read novel and/or un-expected information.
• For people with 20/70 vision, an acceptable size for running text is approximately 28pts at 40 cm viewing distance and somewhat smaller text could be used for common labels
• If we assume users with low vision can move in closer (half distance - 20 cm) to view text (and that their glasses allow this), 14 pt type would provide type that subtends the same visual angle (as 28 pt at 40 cm).

Although many users with low vision will use close vision coupled with glasses that focus their vision – it is too hard for designers to work off of this – and all glasses are custom. The 3.5 distance with 20/20 gives a measure that is repeatable and will yield text that is legible to who need larger clearer type. It also automatically allows text to be smaller if it is clear and requires it to be larger if it, for example, used very thin stem width. Some users with low vision have a field of view limitation. They can use small print modes if available. In general though, signage and other existing access regulations are based on the assumption that larger print is more universally accessible for people with low vision than print that is small to accommodate people with field of view limitations who cannot step back to shrink the size of the text in their view. (Note also that this provision does not require very large text – just text that is not small.

At a workstation, it is reasonable to assume that special reading aids (such as a moderate magnifying glass) would be available even if user’s vision is in the range of 20/30 to 20/70, and fonts can therefore be smaller. The sizes for devices designed to be used away from a person's workstation are aimed at those with low vision but not very low vision (beyond 20/70). This is based on an assumption that:

• People with 20/70 vision or better would not usually carry a magnifying device with them.
• People with worse than 20/70 vision would usually carry portable optical magnifying devices (including special glasses) with them.

The Note “Software that is not associated or purchased with any particular hardware (so the text does not have a physical size until it is displayed) can be evaluated on any typical display that the software is intended to work with.” eliminates all pixel calculations (which will not remain valid) and also separates stand alone software from software in a product. The provision is limited to public or shared products. These are things that a person cannot modify, mark up, or buy their own version of. It also can be things that they don't know about in advance of encountering. This allows personally (or personally assigned) cell phone, keyboards, etc to be excluded. However, this does open up the problem talked about on other provisions – that an agency would buy one type of cell phone (for example) and then write software that only works with that phone (or type of phone). The user with low vision may know of phones they could use – but none of them work with the software – so they have to use a phone that has only small print on it. In this case we believe the issue can be addressed with a note that explains “Personal or personally assigned devices are not covered unless all users must use the same product (or same type of product) (e.g. policy or in order to work with system software or procedures). In that case it constitutes a ‘shared device’ since all must use the same one (the same type) and that product (or type) would need to meet provision.”

Notes from March 25 plenary call:

• Concern with personal devices list
• Concern with size of info for buttons.
• Concern with note "application for software" could be a conflict with 3-D User Interfaces.
• The question was raised if a manufacturer could simply print an enlargement of the keyboard and meet this provision.

• Status: Feb 19: new issues with small devices and captions - Workgroup: Rob, Paul, Gregg, Ken, + someone from telecom. Additions from Panasonic added.
• Text from Self-Contained/Closed
• Source: {255}1193.43(b)
• Impact:
• External Reference:
• Testability: Inspection
• Disabilities: Low vision

1-H - Speech Operation

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

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

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

2. Requirements for Hardware Aspects of Products

2.1 All Products with Hardware

2.1-A - Reflectance Contrast for Legends and Passive Displays

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

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

Note 2: This requirement excludes product information labels, such as the regulatory labels, where information can be found in other sources associated with the product either in hard- or soft copy format.

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

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

• Status: Consensus on Dec 4
• Text from Hardware
• Source: {508}1194.21(j) & .25(h)
• Impact:
• External Reference:
• Testability: Formal test method
• Disabilities: Low vision

2.1-B - Flashing (Hardware) (Consensus on concept)

The Committee agreed that this draft language for 2.1-B-Flashing (Hardware) and the related definition General Flash and Red Flash Thresholds for Hardware be sent to the Access Board as a basis for further work on exact numbers in the definition and further work.

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

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

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

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

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

• Status: Agreement on this as draft to send to Access Board for further work - March 18
• Text from Hardware
• Source: {508}1194.21(k) 1194.22(j) 1194.25(i), and {255}1193.43(f)
• Impact: Negative cost - The change saves money (e.g. special circuitry not needed to control frequency of status LEDs) and provides additional flexibility to industry for non-critical stimuli.
• External Reference:
• Testability: Inspection
• Disabilities: Photosensitive seizure disorder

2.1-C - Mechanical Controls

All mechanically operated controls and keys:

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

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

• Status: Consensus on Dec 4
• Text from Hardware
• Source: {508} 1194.26(a); 1194.23(k)
• Impact:
• External Reference:
• Testability: Inspection
• Disabilities: Mobility, dexterity, vision

2.1-D - Touch Operated Controls

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

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

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

• Status: Consensus on Jan 9
• Text from Hardware
• Source: {508} 1194.26(b); {508} 1194.25(c)
• Impact:
• External Reference:
• Testability: Inspection
• Disabilities: Mobility, dexterity, vision

2.1-E - Standard User Interface Connection

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

• Status: Consensus on Dec 4
• Text from Hardware and Telecommunications
• Source: {508} 1194.26(d)
• Impact:
• External Reference:
• Testability: Inspection
• Disabilities: All

2.1-F - Installed or Free-Standing Products

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

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

• Status: Consensus on Dec 4
• Text from Hardware
• Source: {508} 1194.25(j), {255}1193.41(f)
• Impact:
• External Reference: Harmonized with ADAAG
• Testability: Inspection
• Disabilities: Mobility, dexterity

2.2 If the Product has Speech Output or Throughput

2.2-A - Magnetic Coupling

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

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

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

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

2.2-B - Interference with Hearing Device

Interference to hearing technologies (including hearing aids, cochlear implants, and assistive listening devices) must be reduced to the lowest possible level that allows a user of hearing technologies to utilize the telecommunications product.

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

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

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

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

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

2.2-C - Audio Connection

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

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

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

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

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

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

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

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

Rationale

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

How it would apply

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

• Status: Consensus on Feb 12
• Text from Hardware
• Source: {508} 1194.25(e); {255}1193.51(b), {255}1193.43(g)
• Impact:
• External Reference:
• Testability: Inspection
• Disabilities: Hard of hearing

2.2-D - Volume

For products that generate speech output delivered via speakers:

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

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

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

• Status: Consensus on Feb 12
• Text from Self-Contained/Closed
• Source: {508}1194.25(f), {255}1193.43(e)
• Impact:
• External Reference:
• Testability: Formal test method
• Disabilities: Hard of hearing

2.2-E - Volume (Gain)

For products that deliver voice throughput:

1. Users must be able to adjust the audio output level.
2. All telecommunications products powered solely from analog telephone lines and having an audio transducer typically held to the ear, and all cordless telephones, must comply with FCC regulation §68.317 for volume control.
3. All cellular telephones – Defer to committee listed in Note 5.
4. All other products that provide a voice communication function via an audio transducer typically held to the ear must comply with FCC regulation §68.317 for volume control. In addition, they must provide built-in gain of at least 15 dB above the normal unamplified level when measured as specified in FCC regulation §68.317.

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

Technical notes on this provision
The following notes are to be included either within the provision or advisory notes. Location will 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 typically held to the ear, such as speakerphones, should provide at least 15 dB of volume control range above the normal unamplified listening level. In these cases of speakerphones, it is desirable for the volume control to provide at least 15 dB of gain above the normal unamplified level, but there is no agreed upon specification as to what constitutes the normal unamplified level.

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. The TEITAC will make noo recommendation at this time, but urges the Access Board to review the recommendations from the study, and update this provision if neeed.

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

2.2-F - Volume Reset

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

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

3. Requirements for User Interface and Electronic Content

People designing, developing or procuring User Interface and Electronic Content are urged to review the entire Subpart C, especially Section 1: General Technical Requirements. The provisions in this section apply to all electronic and information technology, including web sites, software and other user interfaces or electronic content.

3-A - Color

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

Example: A conforming example is mandatory form fields are identified with colored text and labeled as "Required".

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

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

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

3-B - Contrast

Presentation of text, and images of text, in electronic documents must have a contrast ratio of at least 5:1, except for the following:

• Large Print: Large-scale text and images of large-scale text must have a contrast ratio of at least 3:1;
• Incidental: Text or images of text that are part of an inactive user interface component, that are pure decoration, that are incidental text in an image, or that are not visible to anyone, have no minimum contrast requirement.

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

3-C - Size, Shape, Location

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

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

Example: Rather than saying when done press the button to the right, say when done press the submit button.

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

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

3-D - User Preferences

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

• Large Print: Large-scale text and images of large-scale text must have a contrast ratio of at least 3:1;
• Incidental: Text or images of text that are part of an inactive user interface component, that are pure decoration, that are incidental text in an image, or that are not visible to anyone, have no minimum contrast requirement.

Note: Application software that is 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: Consensus on Dec 11
• Text from Web and Software
• Source: {508}1194.21(g)
• Impact: Minimal for desktop platforms. Significant for websites and other types of platforms such as mobile devices.
• External Reference: WCAG 2.0 (contrast only)
• Testability: If platform settings, inspection; if no platform settings, formal test method
• Disabilities: Low vision, Color deficiency/Colorblindness

3-E - Color Adjustment

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

Rationale: 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: Consensus on Dec 11
• Text from Web and Software
• Source: {508}1194.21(j)
• Impact: Minimal for desktop software. Potentially significant for Web sites and applications and non-desktop software platforms that allow color and contrast adjustments.
  • Same as current 508 software provision except it provides a testable measurement of contrast.
• External Reference:
• Testability: Formal test method
• Disabilities: Color deficiency/Colorblindness, Low Vision

3-F - Non-text Objects

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

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

2. Media: If a non-text object is synchronized media, live audio-only or live video-only content, then text alternatives must at least provide a descriptive label that identifies the non-text object. (For synchronized media, see also Audio and/or Video provisions)

3. Test: If a non-text object is a test or exercise that must be presented in non-text format, then text alternatives must identify at least the non-text object with a descriptive text label. (For synchronized media, see also Audio and/or Video provisions)

4. Sensory: If a non-text object is primarily intended to create a specific sensory experience, then text alternatives must identify at least the non-text object with a descriptive text label. (For synchronized media, see also Audio and/or Video provisions)

5. CAPTCHA: If the purpose of a non-text object is to confirm that content is being accessed by a person rather than a computer then text alternatives that identify and describe the purpose of the non-text object must be provided and alternative forms in different modalities must be provided to accommodate different disabilities.

6. Decoration, Formatting, Invisible Objects: If a non-text object is pure decoration, or used only for visual formatting, or if it is not presented to users, then it must be implemented such that it can be ignored by assistive technology.

Note: In order to satisfy this provision, non text objects in data operated on by the software would need to be associated with textual equivalents that the software can obtain as readily as it can obtain the non-text object itself. Where a non-text object is a scanned image of text, textual equivalents would need to allow for the inclusion of the text of the scanned image of text. Where a non-text object is a dynamic presentation, graphs, or other derived information from a data source, textual equivalents would need to allow for the inclusion of the data used.

Rationale: Harmonization with WCAG 2.0 which provides more guidance on the text alternatives themselves. The word "objects" is used in this provision to make it clear to software developers that their user interface is to be included. If the word "content" was used they may not think this applies to their work.

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

3-G - Human Language

When supported in the technologies of electronic documents, the default human language of electronic document must be programmatically determinable.

Note: In order to achieve this provision, text encoded in data operated on by the software would need to be associated with sufficient information to identify both the primary language of the text, and the language of any sections or the text that are in another language from the primary language, that the software can obtain as readily as it can obtain the text itself.

• Status; Consensus on Nov 27
• 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-3.1.1 Language of Page (Level A)
• Testability: Inspection
• Disabilities: Blindness

3-H - Language of Parts

When supported in the technology of electronic documents, the human language of each passage or phrase in electronic documents must be programmatically determinable.

• Status: Consensus on Nov 27
• 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-3.1.2 Language of Parts (Level A)
• Testability: Inspection
• Disabilities: Blindness

3-I - Pausing

A mechanism must be provided to pause moving, blinking, or scrolling information that lasts for more than three seconds unless it is part of an activity where the moving, blinking, or scrolling is essential.

A mechanism must be provided to pause auto-updating information, or allow the user to control the frequency of the update, unless it is part of an activity where auto-updating is essential.

A mechanism must be provided to either pause, stop, or hide moving or blinking content that is pure decoration.

Rationale: Harmonization with WCAG 2.0. Needed for people with attention deficit disorders and those using screen readers. Auto updating is not well understood by many people and this would clarify it. It is beneficial to anyone who has trouble reading quickly and would like to pause content in order to have more time to read it. It is also beneficial for low vision users who depend on screen magnifiers, which tend to loose focus when auto-updating occurs.

• Status: Consensus on Jan 7
• Text from Web and Software
• Source: {508}1194.21(h)
• 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-2.2.2 Pausing (Level AA)
• Testability: Inspection
• Disabilities: Blindness, Low vision, Cognitive/language/learning

3-J - Flashing (Content and User Interfaces)

Content or user interfaces must not contain anything that flashes more than 3 times in any one second period or the flashing must be below the general flash and red flash thresholds for content and user interfaces.

Rationale The current provision is too restrictive in that it prohibits flashing within a certain range with no consideration for the size of the flashing area. Very small areas of flashing do not cause seizures even if the flashing falls within the specified range. The reworded provision is harmonized with WCAG 2.0 and based on research by experts in this field.

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

3-K - Consistent Identification

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

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

• Status: Consensus on Jan 7
• Text from Web and Software
• Source: {508}1194.21(e)
• 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-3.2.4 Consistent Identification (Level AA)
• Testability: Inspection
• Disabilities: Blindness, Cognitive/language/learning

3-L - Audio Turnoff

When any audio plays automatically for more than 3 seconds, there must be a mechanism to pause or stop the audio, or a mechanism to control audio volume which can be set to be a different level from the system volume level. This provision does not apply to emergency messages regarding risk of personal injury or loss of property or data, or to audio messages required by law.

Note 1: This provision may be met with a mechanism in a product, user agent or platform.

Note 2: For web and software applications, the total duration of the audio should not exceed 3 seconds, including any repeats of the audio, for this provision to apply.

Rationale: Audio that plays automatically interferes with screen readers. When web browsers provide mechanisms to turn off audio in the content, the content author does not have to provide a mechanism. Tuning off audio at the system level is not sufficient as that turns off the screen reader also.

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

3-M - Reading Sequence

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

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

• Status: Consensus on Jan 7
• 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-1.3.2 Meaningful Sequence (Level A) and 2.4.3 Focus Order (Level A). Relates to WCAG 2.0-2.4.11 Focus Order (Visual) (Level AAA) Similar to recommendation in ISO 9241-171
• Testability: Inspection
• Disabilities: Blindness, Cognitive/language/learning

3-N - Link Purpose

On Web pages, it must be possible to determine the purpose of each link from the link text or the link text together with its programmatically determinable link context.

Note: In order to meet this provision, links encoded in data operated on by the software would need to be associated with link text that the software can obtain as readily as it can obtain the link itself.

Rationale: Unlike the restrictive requirement in WCAG 1.0 which requires unique link text for each link within the page, this provision is more flexible. There are cases where it is actually more usable to have identical link text on several links such as on a page that lists document titles and provides links to versions of the document in different formats. This provision allows links within a page to have the same link text as long as the purpose of the link can be determined from the link text and its context, such as the table row or column header, list item, sentence, etc.

• Status: Consensus on Jan 7
• 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-2.4.4 Link Purpose (In Context) (Level A)
• Testability: Expert evaluation
• Disabilities: Blindness, Cognitive/language/learning

3-O - Information and Relationships

Information and relationships conveyed through presentation of electronic documents must be either programmatically determinable or available in text, and notification of changes to these 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. in data tables that have two or more logical levels of row or column headers, data cells are associated with header cells.

• Note: In order to achieve this provision, cells in table objects with

multiple logical levels of headers in data operated on by the software would need to be associated with sufficient information to identify any row and column headers for the table cell, that the software can obtain as readily as it can obtain the table cell itself

3. section headings are identified

4. form element labels are associated with form fields

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

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

3-P - User Interface Components (no consensus)

TEXT AS OF MARCH 25

Version 1
For all user interface components, including form elements and those generated by scripts, the name and role must be programmatically determinable. States, properties, and values that can be set by the user must be programmatically determinable and can be programmatically set. Any notification of changes to these items must be available to user agents, including assistive technologies.

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

Version 2
For all user interface components, including form elements and those generated by scripts, the name, role, states, properties, and values must be programmatically determinable. States, properties, and values that can be set by the user can also be programmatically set. Any notification of changes to these items must be available to user agents, including assistive technologies.

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

Explanation from Andi of new version Based on feedback from Allen, we have discovered an error in the wording of 3-P User Interface Components. The current wording requires that states, properties, and values be programmatically determinable only for user interface components that can be set by the user. But this information is also important for UI components that cannot be modified by the user. This is not an intentional omission but rather an oversight.

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.

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.

Comments to be resolved:

• Same comments as 3O - Information and Relationship. Recommend remove this provision.
• Disagree with removing
• See notes from October15 General SC meeting: the meeting notes
• ITI: This is really about (web) documents; everything in it is covered by 3-U. We should either remove it as redundant, or scope to it web documents. Please specifically note the final text of 3-U: "Note: This provision applies to forms in the software."
• Jan 8 meeting: Need to resolve the AT issue (Peter and Andi S to review)

• Status: Discussed Jan 8, No Consensus
• Text from Web and Software
• Source: {508}1194.21(l) & .22(n)
• Impact: Significant
  • Rich Internet Applications will have to implement the ARIA standards. Significant positive impact to end users and agencies. IT-AT interoperability will be improved and less customization should be required.
• External Reference: Harmonized with WCAG 2.0-4.1.2 Name, Role, Value (Level A)
• Testability: Inspection
• Disabilities: All

3-Q - Disruption of Access Features

Applications must not, except by specific user request, disrupt the features of the platform that are defined, in the documentation intended for application developers, as having an accessibility usage.

Rationale: This version limits the scope to accessibility features defined by the platform, rather than the broader "other products" in previous versions

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

3-R - Timing

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

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

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

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

3-S - Keyboard Operation

Where products have a keyboard or a keyboard interface, or run on a device that have a keyboard or keyboard interface, all functionality of the product operable through the electronic user interface must be operable through the keyboard, or a keyboard interface. Specific timing for individual keystrokes must not be required. This provision does not apply where the underlying function requires input that depends on the full path of the user's movement, not just the endpoints.

Note 1: This does not forbid and should not discourage providing mouse input or other input methods, such as gestures, in addition to keyboard operation.

Note 2: The exception relates to the underlying function, not the input technique. For example, if using handwriting to enter text, the input technique (handwriting) requires path dependent input but the underlying function (text input) does not.

Note 3: Keyboard interface can be either a hardware keyboard interface, a wireless interface or a software keyboard interface where AT can generate keystrokes that would be seen by software.

Note 4: For platform software, this includes the ability to move the keyboard focus into and out of applications.

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

3-SS - Visual Indication of Keyboard Shortcuts (no consensus)

TEXT AS OF MARCH 25

Version 1
All keyboard commands associated directly with user interface controls must be visible within the visual user interface in at least one mode, and available programmatically to AT on products that support AT interoperability.

Version 2 (Judy B. 3/24)
All keyboard commands associated directly with user interface controls must be visible within the visual user interface in at least one mode.

Notes for both version
Note 1: This includes commands such as those used to active a menu item or button (e.g. the "S" of a "Save File" menu item), but does not include commands that are system-wide or common conventions for using an item (e.g. a command to switch windows such as ALT-TAB, or a command to advance the caret in text such as Ctrl-Arrow).

Note 2: User-configurable keyboard commands may be considered not directly tied to interface elements. However, when possible such user-configurable keyboard bindings should be visually presented as configured.

• Status: 12 Feb: Discussed need work on harmonization issues (Andi, Peter, Judy)
• Text from committee
• Source: New: Accompanies Subpart D: 1.1-B - Keyboard Shortcuts
• Impact:
• External Reference: Possibly harmonized with ISO 9241-171 - 9.3.11
• Testability: Inspection
• Disabilities: Blindness, Dexterity

3-T - Focus Indicator

Any keyboard operable user interface must support a mode of operation where the indication of keyboard focus has a high degree of visibility.

Note 1: The presence of a highly visible text insertion point is sufficient for a text area.

Note 2: A focus cursor that is visually locatable at 3.5 times the typical viewing distance without moving the cursor by people who have unimpaired vision and are familiar with what the focus cursor looks like is sufficient. For example, when software is displayed on a 38 cm (15 inch) diagonal screen at 1024 x 768 pixels resolution, a focus cursor that is visually locatable at 2.5 meters without moving the cursor by people who are familiar with what the cursor looks like and have unimpaired vision is sufficient.

Note 3: This can be provided by the interface itself or by the interface in combination with focus services provided by the platform.

Rationale: In the current 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: Consensus on Jan 8
• 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 WCAG 2.0-2.4.7 Focus Visible (Level AA) and ISO 9241-171
• Testability: Inspection
• Disabilities: Low Vision, Dexterity

3-U - AT Interoperability (partial consensus)

[In this provision, text in plain text is consensed and text in bold italics is not agreed to.]

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

Using such services, software must:

1. expose object information including but not limited to:
a. role, state(s), boundary, name, and description
b. the row and column a component is in, and the headers for the row and column for that component, if it is in a table that has row or column headers,
c. current value and any minimum or maximum values, if the component represents one of a range of values
d. relationship this component has as a label for another component, or being labeled by another component
e. name of parent or containing element, and any children components
f. text contents, text attributes, and the boundary of text rendered to the screen
g. keyboard shortcuts and implicit designators.

In order to meet this provision, interactive elements encoded in data operated on by the software must be associated with sufficient information to programmatically determine a role, state(s), name, and description for the interactive element, that the software can obtain as readily as it can obtain the interactive element itself.

2. expose a list of actions that can be executed on an object and allow assistive technology to programmatically execute any of those actions;

3. expose information necessary to track and modify: focus, text insertion point, and selection attributes of user interface components;

4. expose notification of events relevant to user interactions, including but not limited to changes in the component's state(s), value, name, description, or boundary

Note 1: This provision also applies to forms in the software.

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

Advisory Note to the Access Board: This is one of the provisions that is affected by the difference of opinion or position on AT. See XXXXXXX located YYYYYY for more information on this and on effect to this provision.

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 confusing to vendors. By using the term components it is more generic and will hopefully lead to less confusion.

Notes March 18, 2008:

• Microsoft/WAI - Need to reconsider: "g. keyboard shortcuts and implicit designators."
• TIA issues as this applies to 255: The provisions of these sections have not been adequately vetted for Telecommunications hardware user interfaces and application. These requirements were designed for web and software in an IT computing environment, not telecommunications hardware displays, and are platform specific. These provisions are of special concern for handheld Telecom devices many of which are unable to meet the AT interoperability provisions and have a different perspective for platform and application interaction.

• Status: Partial consensus
• Text from Web and Software
• Source: {508}1194.21(d), (c), & (f)
• Impact: Significant
  • More specificity of the information that must be exposed to AT. Significant positive impact to end users and agencies. IT-AT interoperability will be improved and less customization should be required.
• External Reference: Harmonized with ISO 9241-171
• Testability: Expert evaluation
• Disabilities: All

3-V - Accessibility Services

Platform software must provide access to a set of services that enable applications running on the platform to interact with assistive technology sufficient to enable compliance with the "AT interoperability" and "User Interface Components" provisions. Software toolkits, and applications that are also platforms, must support the 'AT Interoperability' and "User Interface Components" provisions by either making the underlying platform accessibility services available to their client software, OR using other services to cooperate with assistive technologies on the underlying platform.

Rationale: Needed to improve E&IT-AT interoperability.

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

3-VV - Assistive Technology (no consensus)

TEXT AS OF MARCH 25

Assistive technology must utilize the accessibility services provided by platform software that meets section 3-V Accessibility Services, to the extent that the information is appropriate to the AT function, in order to provide the alternative user interface(s) to people with disabilities. Platform software "accessibility services" includes but is not limited to the items listed in 3-U AT Interoperability.

Rationale: The purpose of 508 is to change the work environment such that people with disabilities can be hired into positions where the E&IT is already accessible. Since AT will remain a key component of that environment - for efficiency & productivity of the employee with a disability - E&IT and AT must work effectively together. Placing a burden solely on E&IT to achieve this result doesn't work for numerous reasons (articulated elsewhere). Since AT and E&IT are typically procured at different times under different procurements, the best way to ensure they work together is to require that both utilize the same mechanisms for inter-operating: namely the 3-V Accessibility Services providing the information enumerated in 3-U AT-IT Interoperability.

General Note: When we say that "E&IT works with AT" or "E&IT is accessible 'through AT'" or information presented by E&IT "programmatically determinable" we mean that E&IT is either:

• known to work with AT that is available to users

or

• has been tested with an API tool and passes where it has been shown that passing the tool will result in E&IT that will work with AT that is available to users

• Status: New - added 25 Feb
• Text from members
• Source: New
• Impact:
• External Reference:
• Testability:
• Disabilities: All

3-W - Multiple Ways

There must be more than one way available to locate content within a set of Web pages where content is not the result of, or a step in, a process. For example, providing a site map, index, table of contents, or search would be sufficient

Rationale: Based on the old requirements for a "site map" or search.

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

3-X - Labels or Instructions

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

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

3-Y - On Focus (Consensed)

When any component in content or electronic documents receives focus through navigation by keyboard or other keypads, it must not initiate a change of context.

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

3-Z - On Input

Changing the setting of any user interface component in web pages must not automatically cause a change of context unless the user has been advised of the behavior before using the component.

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

3-AA - Error Identification

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

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

3-BB - Headings and Labels

Headings and labels must describe the topic or purpose.

Note: Labels and headings do not need to be lengthy. A word or even a single character may suffice if it provides an appropriate cue to finding and navigating content.

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

4. Additional Requirements for Audio-Visual Players or Displays

4-A - Caption Processing

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

1. Products that are governed by U.S. Federal Communications Commission (FCC) regulations 47 CFR 15.119 (Closed caption decoder requirements for analog television receivers) and 47 CFR 15.122 (Closed caption decoder requirements for digital television receivers and converter boxes) must provide support for TV closed captions and open captions.

Such equipment must either pass TV caption data to the caption decoding circuitry of analog and DTV displays for decoding as displayed text, or decode TV caption data and pass on a decoded ("open-captioned") video signal to the display.

2. Products that do not fall under the regulation of the U.S. Federal Communications Commission (FCC), personal video display devices and software players, must provide support for a functional equivalent to TV closed captions.

Such products must either pass TV caption data to the caption decoding circuitry of DTV displays for decoding as displayed text or decode a functional equivalent to TV closed captions and pass on a decoded ("open-captioned") video signal to the display.

Functional equivalence requires synchronized text displayed on-screen that reflects the audio of a program. It may also include functionality to allow user choices for background and foreground color, adjustment or contrast, and text size for captions as allowed by the platform software or hardware displaying the media.

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

• Status: Consensus on Feb 12
• Text from A/V
• Source: {508}1194.24(a)
• Impact:
• External Reference: CEA 608, CEA 708
• Testability: Inspection
• Disabilities: Deafness, Hard of hearing, Cognitive/language/learning

4-B - Supplemental Audio Process

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

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

Rationale: An attempt to align the 4-A - Caption Process provisions with the 4-B - Supplemental Audio Process provisions.

• Status: Consensus on Nov 14
• Text from A/V
• Source: {508}1194.24(b)
• Impact:
• External Reference:
• Testability: Inspection
• Disabilities: Blindness, Low vision, Cognitive/language/learning

4-C - Access to Caption and Video Controls

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

For example:

For captioning:

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

For video description: A tactile button to turn on video description.

Note: Comparable in prominence does not require exact equivalence in size, location, or shape.

Rationale:

• Manufacturers are encouraged to use buttons with unique shapes to enable persons with low vision to make a tactile distinction among them.

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

• For laptops, a keyboard equivalent would be acceptable.

• Status: Consensus on Nov 14
• Text from A/V
• Source: new
• Impact:
• External Reference:
• Testability: Inspection
• Disabilities: Deafness, Hard of hearing, Blindness, Low Vision, Dexterity, Mobility, Cognitive/language/learning

5. Requirements for Audio and/or Video Content

5-A - Captions and Transcripts

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

1. Materials containing prerecorded audio information, and no original video or other additional time-based content must provide a separate transcript of the audio information.

2. Materials containing prerecorded video with concurrent audio information must provide synchronized captions.

3. Materials containing real-time audio, with or without video, must provide synchronized real-time captions.

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

Advisory Note to the Access Board The final version of the technical standards for captioning and transcripts (5-A) and for video description (5-B) were revised to remove the word "all" from "all materials" resulting in ambiguity in the scope of materials which must conform. Without the term "all", the scope of application is at some level less than 100% of materials, but no direction is provided regarding what level less than 100% is acceptable for which materials. The Access Board will need to address this issue.

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

5-B - Video Description

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

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

2. When the visual informational content is not conveyed through other means, materials containing prerecorded video with concurrent audio must provide synchronized video descriptions, or when space is not available in the main program audio for synchronized video descriptions, a separate text description of the video content must be provided.

3. Materials containing live video must provide synchronized video descriptions in real time to convey any informational content of the video that is not conveyed through other means.

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

Comment to the Access Board The final version of the technical standards for captioning and transcripts (5-A) and for video description (5-B) were revised to remove the word "all" from "all materials" resulting in ambiguity in the scope of materials which must conform. Without the term "all", the scope of application is at some level less than 100% of materials, but no direction is provided regarding what level less than 100% is acceptable for which materials. The Access Board will need to address this issue.

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

5-C - Interactive Elements

Synchronized media containing interactive elements, such as options for selection and access to segments of the content, must include a mode of operation for selection consistent with applicable Section 508 provisions.

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

6. Additional Requirements for Real-time Voice Conversation Functionality

6-A - Real-Time Text Reliability and Interoperability

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

1. Products must use a real-time text (RTT) system that meets the following requirements:

• a. RTT format must be a standard real-time text format for the voice platform that is supported by all terminal, router, gateway and other products on that platform;
• b. RTT format must transmit characters with less than 1 second delay from entry;
• c. RTT system must transmit text with less than 1% Total Character Error Rate at the peak network traffic specified for intelligible speech transmission (text must work on the network as long as speech does);
• d. The RTT system, together with the audio system, must support speech and text in both directions in the same call session (and support speech and text simultaneously in both directions in the same call session if IP based)
• e. RTT system must not utilize audio tones for transmission of real-time text over IP. Note: this is subject to a waiver of the TTY support requirement from the FCC for systems that implement IP based RTT. Also subject to consumer acceptance of prefixes or phone numbers to direct TTY traffic to gateways capable of handling TTY translation.

2. Where products or systems interoperate outside of their closed systems, they must:

• a. If product interfaces with PSTN, it must use TIA 825A Baudot where it interfaces to the PSTN.
• b. If product interfaces with other VoIP products or systems (outside of a self-contained product-system) using SIP it must support transmission of text as per XXX where it interfaces with other VoIP products or systems. Note: this is subject to a waiver of the TTY support requirement from the FCC for systems that implement IP based RTT. Also subject to consumer acceptance of prefixes or phone numbers to direct TTY traffic to gateways capable of handling TTY translation.
• c. If product connects to other products or systems using a protocol other than SIP it must use the standard real-time text protocol that meets provision 1 above that has been established for that protocol.

Note 1: RFC-4103, TIA 1001, and MSRP (RFC4975) are being explored to fill the role of XXX. The intention is that XXX will be replaced by one interconnection format in all places it was used.
Note 2: All products may support and use other protocols in addition to these as long as they meet the 5 requirements of 5-B(1) above.
Note 3: A self-contained SIP system that uses the same real-time text protocol can be treated as a single product and can use any protocol internally as long as it supports XXX where the system-product connects to other systems or products.

• Status: Consensus on Nov 14
• Text from Telecommunications
• Source: {508]1194.23(b), {255}1193.51(e)
• Impact:
• External Reference:
• Testability: Inspection and formal test methods
• Disabilities: Deafness, Speech

6-B - Voice Terminal Hardware and Software

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

1. Receive only: If hardware or software terminal provides voice conversation over IP in any form, and has a user interface with a multi-line display or a user interface that runs on devices that have a multi-line display, then that terminal must display any real-time text that is received if it is received in the format for the voice and real-time text system being used on the network on which it is installed.

2. Send and Receive: If terminal hardware or software provides voice conversation over IP in any form, and has text generation capability, then the terminal must allow users to send real-time text in the format for the voice and real-time text system being used on the network on which it is installed.

3. If IP terminal hardware or software does not provide real-time text send and receive capability then the terminal must support the addition of terminals and terminal peripheral equipment that 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 public or shared area and not in an individual's private work area then the connection must be possible [without requiring system-administrator intervention]. Note: the "without system-administrator intervention" is a serious concern due to security issues, but removal would prevent people from connecting devices outside of their home system. Additional work is needed to address this issue.]

4. If terminal is analog or TDM-digital wired terminal then it must support the connection of a TTY via an RJ-11 jack in the same location and with the same permissions for use as the telephone and it must be capable of allowing simultaneous speech and text conversation without interference or its microphone must be capable of being turned on and off to allow the user to intermix speech with text use.

Note 1: Provision of the RJ-11 jack may be accomplished through one of the following techniques:
a. provision of the RJ-11 jack on the telephone,
b. the use of a Y-adapter that allows both the analog telephone and the TTY to be plugged into the same line outlet,
c. having built in capability to support an RJ11 module that can provide a connection point for TTYs.

Note 2: The standard format for PSTN is TIA-825A. For SIP is it XXX. For other voice transport protocols the format is to be determined by the entity responsible for the voice transport protocol.

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

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

• Status: Consensus on Nov 14
• Text from Telecommunications
• Source: {508}1194.23(a), {255}1193.51(d)
• Impact:
• External Reference:
• Testability: Inspection
• Disabilities: Deafness, Speech

6-C - IVR, Auto-Attendant and Messaging

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

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

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

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

6-D - Caller and Status Information (no consensus)

TEXT AS OF MARCH 25

This provision will be removed if 1-E and 1-H are consensed

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

1. Users of TTYs, 2. Users of other text conversation systems, and 3. Users who cannot see displays.

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

Version 2 proposed by Gregg, Jan 9: Products with visual interfaces that display telecommunications status information must: 1. Provide at least one mode that does not require speech or hearing or speech to operate the visual display 2. At least one mode where information is available in a non-visual manner.

Examples of status or text information includes caller identification.

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

The display capability of the telecommunications product must not be disabled when the phone is used in conjunction with a TTY device.

Comments to be resolved:

• ITI: This says that products with visual interfaces that display status info must make the info available for TTYs among others. We don't know how to do this for many classes of products (e.g. making Skype's connection information available to a TTY). This provision is making assumptions about the device that don't match the text of the provision.
• IBM: Agree with comment about TTYs.
  • #3 of this requirement is covered by 1.2-G Visual information for closed products and by 3-U AT interoperability for products that are compatible with AT. Should be removed.
  • The last sentence actually refers to the "software and content" provisions.
  • The #2 raises testability concerns and should be removed

• Status: Discussed Jan 9, No Consensus
• Text from Telecommunications
• Source: {508}1194.23(e)
• Impact:
• External Reference:
• Testability: Inspection
• Disabilities: Deafness, Blindness

6-E - Video Support

Communication products or systems that are used to transmit video communications in real-time between and among individuals must:

1. support interoperability to permit communication between and among users of terminals from different manufacturers and service providers;
2. have a built-in non auditory alerting system or provide compatibility with an external non-auditory alerting system that is capable of alerting users of incoming calls; and
3. at a minimum, support 15 frames per second, QCIF resolution, and a latency of less than 400 milliseconds, in order to provide sufficient quality and fluency that will support real time video communication in which one or more parties are using sign language or is talking in the picture.

Note 1: Twenty frames per second or better is recommended to facilitate lip reading and fingerspelling in the video communications provided under this section.

Note 2: Explanatory information concerning sign language and lip-reading real-time conversation using low bit rate video communication can be found in ITU-T H-Series Supplement 1 ([1]).

Note 3: Non-auditory alerting for incoming video communications can be achieved via flashes, vibrations and sound; the preferred method will depend on the needs of the individual using the product.

• Status: Consensus on Nov 14
• Text from Telecommunications
• Source: new
• Impact:
• External Reference:
• Testability: Formal test methods and inspection; will depend on how "X format" is defined."
• Disabilities: Deafness

6-F - Audio Clarity for Interconnected VoIP

Interconnected VoIP telephones and interconnected VoIP telephone-emulation software must be able to transmit and receive speech that is digitally encoded in the manner specified by International Telecommunication Union (ITU) Standards G.711.For closed systems, other standards that provide equivalent acoustic performance may be used if conversion to G.711 at the borders of the closed system is supported.

Note 1: It is suggested that G.722 or equivalent also be provided for wideband interconnected VoIP audio clarity.

• Status: Consensus reached March 25
• Text from Committee
• Source: new
• Impact:
• External Reference:
• Testability: Formal test methods and inspection
• Disabilities: Hard of hearing

6-G - External Alerting Devices

A mechanism must be provided where interconnected VoIP phone systems, interconnected VoIP Terminal Adapters or software for interconnected VoIP phone systems can trigger an external alerting system or accessory, that is capable of alerting users to incoming calls, in modes perceivable to users with disabilities (e.g. visual, tactile, audible).

Note: With regard to accessibility configuration (see 2-C - Accessibility Configuration) it is important that it not be difficult for a user to get an auxiliary ringer associated with a phone number.

Rationale: This requirement addresses the need to connect an external ‘ringer’ (vibrating, flashing, extra loud ringer etc.) to home or office phone system to alert persons with hearing (and sometimes vision) disabilities to an incoming call or communication session. Individual phones are currently required to provide a non-audible alerts to comply the functional performance criteria (e.g. “D – without hearing”), but phone systems may need to provide a way to be compatible with auxiliary devices with special functions or features necessary to meet specific individual needs (wake them from sleep, alert them if they turn off hearing aids to concentrate, alert them when in side room, etc). This requirement could be met by providing proprietary adapters by the system manufacturer to existing alert devices or by utilizing signals sent by the service provider to IP-enabled alert devices or adapter that generates a PSTN ring signal or a simple “closed contacts” shorting signal (making all of the current assistive technology ring/alert systems on the market work with it). Products could of course also provide the PSTN ring signal or ‘closed contacts” directly. The primary goal though is to address the needs of these individuals for specialize alerting devices with maximum flexibility and minimum impact on the phones themselves – as was true in PSTN.

• Status: Consensus reached on March 25
• Text from Trace
• Source: new
• Impact:
• External Reference:
• Testability: Formal test methods and inspection
• Disabilities: Deafness

7. Additional Requirements for Authoring Tools

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

7-A - Accessible Output

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

• Status: Consensus on Jan 9
• Text from Web and Software
• Source: new
• Impact:
• External Reference: ATAG, ISO 9241-171
• Testability: Inspection
• Disabilities: All

7-B - Preserve Accessibility Information

For each accessible content format supported, authoring tools must preserve accessibility information necessary to meet applicable Section 508 provisions, unless the user explicitly indicates otherwise.

Note: The phrase "unless the user explicitly indicates otherwise" is necessary so that the author has the ability to override accessibility information that may be incomplete or inadequate.

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

7-C - Prompts (no consensus)

TEXT AS OF MARCH 25

Version 1:
Authoring tools with a user interface must provide a mode that prompts authors to create accessible content.

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

Version 5, Judy, March 18:
An authoring tool, or suite of tools used to author content, whether such suite is composed of tools from a single vendor or multiple vendors, must provide a mode which prompts authors to create accessible content for accessibility problems that the tool or suite has the capability to correct, for formats authored by that tool or suite that support compliance as explained in the definition of authoring tool.

Version 7, Judy, March 24
An authoring tool, or suite of tools used to author content, must provide a mode which prompts authors to create accessible content, for formats authored by that tool, for accessibility problems that the tool or suite has the capability to correct.

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

Note 2: A suite of authoring tools can be composed of tools from a single vendor or multiple vendors.

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

Notes regarding version 7:
This standard as written lacks specificity, while at the same time acknowledging that it is likely impossible to specifically define all of the prompting needed for each accessible format. The result is a situation where both authoring tool software engineers and Government procurement officers will be unable to determine if they are meeting the standard. If included as is, it is anticipated there will be procurement difficulties where common understanding needs to be negotiated between sales people and purchasers, potentially on a sale-by-sale basis.

It is also unclear what an HTML authoring tool [potentially the most straightforward scenario] would need to do to for prompting to meet this standard.

This standard may need to be moved to a recommendation rather than a full standard unless we are willing to set what some people might feel is a very low bar that can be applied to all possible content that authoring tools may create.

Notes from March 25 plenary call:

• Concerns about knowing how much your tool should be prompting. How do you know when you have met the provision.
• Unable to write the provision in a testable way so can determine what is sufficient.
• In write up asked to include that there was preference for version 1 from some due to it limiting to tools with a user interface.

• Status: Discussed Dec 4,11, Jan 9, March 25, no consensus reached
• Text from Web and Software
• Source: new
• Impact:
• External Reference: ATAG, ISO9241-71
• Testability: Inspection
• Disabilities: All

7-D - Accessible Templates (no consensus)

TEXT AS OF MARCH 25

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

Note: (Judy B, 3/24) This provision should not be applied to formats which are not enabled for accessibility support; nor does it require an accessible template for every template that is packaged with an authoring tool.

Comment to be resolved:

• 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.
• ITI: Templates are often supplied as a convenience and are not necessarily supported by the original product. This provision could be interpreted as meaning one of each type of template would need to be made accessible. For some products, this would be a very burdensome task and we feel that resources would be better spent building more accessible authoring tools. Accordingly, ITI recommends that this provision be removed.
• Jan 9: It’s a training issue – how does an agency (or other) learn to use a new tool. Could be docs, templates, samples, examples…
• Jan 9: Templates are a special type and have some specific issues
• Jan 9: Request from info from agencies on how they use templates.
• Recommendation to make it an advisory note, changing "must" to "should"

• Status: Discussed Jan 9, No Consensus
• Text from Web and Software
• Source: new
• Impact:
• External Reference: ATAG, ISO 9241-71
• Testability: Expert evaluation
• Disabilities: All

Subpart D

1. Information, Documentation and Support

1.1 Product Documentation and Help

1.1-A - Accessible Documentation and Features

Documentation for users on the installation, configuration, or use of the product including the description, installation, and use of accessibility and compatibility features, and all other documentation provided must conform to the relevant accessibility provisions in 1194 Subparts B and C, and must be available to users with disabilities at no additional charge. Features included in the product specifically to meet accessibility requirements must be documented. This documentation includes, but is not limited to, reports, system documentation, user help, installation guides for end-user installable devices covered by Section 255, and user training or technical support materials.

Rationale: This draft combines two provisions for a clearer requirement and adds a requirement to document the accessibility features of a product, and incorporates the requirement that documentation supporting services and consulting engagements be accessible in addition to the requirements for user documentation accessibility.

Advisory Note to Access Board: There is an overlap between general features and features that support accessibility. Guidance on how to choose what features to document includes:
1. 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.
2. Any features that are used to meet this standard or to enhance accessibility
3. Based on discussion of 3-Q: May need to suggest how a platform should document (for their application developers) how to support accessibility features that the platform provides to users.

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

1.1-B - Keyboard Shortcuts (no consensus)

VERSION AS OF MARCH 25Version 5: (second proposal from Judy/Peter):
Information about keyboard shortcuts, including available keyboard commands and keyboard navigation mechanisms, must be listed in centrally located user documentation, and available in context-sensitive help.

Version 7: (Judy March 24)
Information about keyboard shortcuts and implicit designators must be listed in centrally located user documentation, and available in context-sensitive help.

Version 8: (Andi/Andrew March 25 )
Information about keyboard operation, including available keyboard commands and keyboard navigation mechanisms, must be listed in user documentation, such as online help, context-sensitive help, or printed user's guides.

Note: The inclusion of a comprehensive listing of keyboard shortcuts for an application in a documented location is suggested as some users benefit from a single, centralized resource.

Note: Centrally located user documentation can be in more than one location, but should be able to be located through application help.

Version 9: (Judy/Andi, March 25):
Information about keyboard operations, including available keyboard commands and keyboard navigation mechanisms, must be listed in electronic documentation, such as online and context-sensitive help.

Note: The inclusion of a documented comprehensive listing of keyboard shortcuts for an application is suggested as some users benefit from a single, centralized resource.

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

Comments to be resolved from prior versions:

• How to express this provision that will meet the needs of all users (for example allowing for inclusion in either contextual help or consolidated documentation.
• How to address applications that run on multiple platforms which can result in different shortcuts for the same action.
• Adobe: what is the distinction between a keyboard shortcut and keyboard convention. Is it that conventions are general to an entire app or type of control and shortcuts are for a specific instance of a control?
• See 3-SS - Visual Indication of Keyboard Shortcuts that goes with this provision: http://teitac.org/wiki/EWG:OpenProvisions_March_12#3-SS_-_Visual_Indication_of_Keyboard_Shortcuts

• Status: March 25: Additional work, but no consensus
• Text from Documentation and Technical Support
• Source: New
• Impact: +
• External Reference:
• Testability: Inspection
• Disabilities: All

1.2 Support and E&IT related services

1.2-A - Support Services

Help desk and technical support services must offer information on the accessibility features of the product. These support services must accommodate the communication needs of users with disabilities. For the purposes of Section 255, such services must take into account assistive technology commonly used with the product, and must be made available at no additional charge.

• Status: Consensus on Feb 12
• Text from Documentation and Technical Support
• Source: {508}1194.41(c) and {255}1193.33(a)(3)
• Impact:
• External Reference:
• Testability: Expert evaluation
• Disabilities: All

1.2-B - Manufacturer Contact

Applying only to products under Section 255, manufacturers must include in general product information the contact method for obtaining the information required by this section.

• Status: Consensus reached on Dec 18
• Text from: Telecommunications
• Source:
• Impact:
• External Reference:
• Testability:
• Disabilities: All

1.2-C - Training

Applying only to products under Section 255, in developing or incorporating existing training programs, manufacturers shall consider the following topics:

1. Accessibility requirements of individuals with disabilities;
2. Means of communicating with individuals with disabilities;
3. Commonly used adaptive technology with the manufacturer’s products;
4. Designing for accessibility;
5. Solutions for accessibility and compatibility.

• Status: Consensus reached on Dec 18
• Text from: Telecommunications
• Source:
• Impact:
• External Reference:
• Testability:
• Disabilities: All

2. Implementation, Operation and Maintenance

2-A - Relay Services Accessibility

This provision is not relevant to the Section 255 guidelines, because it creates obligations for federal agencies

In complying with this subpart, each agency must ensure access to and use of all telecommunications relay services as approved by the Federal Communications Commission pursuant to its authority under 47 U.S.C. Sec. 225, for incoming and outgoing calls, as needed to achieve functionally equivalent communication access by people with disabilities.

• Status: Consensus on Nov 14
• Text from Telecommunications
• Source: new
• Impact:
• External Reference:
• Testability: Inspection
• Disabilities: Deafness, Speech

2-B - Video Support

This provision is not relevant to the Section 255 guidelines, because they would create obligations for federal agencies

1. Each agency must ensure the availability of communication access via point to point real-time video communications and video relay services for incoming and outgoing calls for individuals who need such access. This includes the requirement to provide a non-auditory means of alerting users of incoming calls.

2. Where security concerns are present, this subpart remains in effect, but may be achieved by measures that prevent an individual’s video communications from intermingling with packets of the general government network, for example, through the installation of a separate line to an isolated communications terminal.

Note: The requirement to permit video communications in real-time includes the ability to send and receive video mail, much in the same way that voice telephone users are able to send and receive voice mail.

• Status: Consensus on Nov 14
• Text from Telecommunications
• Source: new
• Impact:
• External Reference:
• Testability: Inspection
• Disabilities: Deafness

2-C - Accessibility Configuration

Each agency must activate accessibility features or configure product and infrastructure settings so that people with disabilities are able to activate and use accessibility features in the products as they need them.

Note 1: Network or system-wide configurations or installation settings are especially important in meeting this provision.

Note 2: For purposes of Section 255, "products" are the telecommunications equipment, voicemail, and interactive menu equipment, interconnected VoIP equipment, and CPE covered by the FCC's rules implementing Section 255.

Note 3: This provision is not intended to prevent a product feature that would allow the user to tie product functions together (for example turning one on would turn another off) so long as turning on an accessibility feature did not turn off other product functions by default.

Note 4: For the purposes of this provision, the term "usable" has meaning as defined in 1194.4 Definitions.

• Status: Consensus reached on Feb 19
• Text from Telecommunications
• Source: new
• Impact:
• External Reference:
• Testability:
• Disabilities: All

2-D - Accessible Content

This provision is not relevant to the Section 255 guidelines, because it creates obligations for federal agencies

Agencies must ensure that electronic content used for official agency communications complies with the applicable provisions in the Section 508 standard (in particular the provisions in Subpart C, Section 3), regardless of the medium of transmission or distribution. An exception to this provision may be made when content is distributed only to a small group of known recipients and accommodates their accessibility needs, or when content is being stored for archival purposes only.

Note 1: Official agency communications include, but are not limited to, agency websites, policies or procedures for employees that are distributed via internal agency e-mail, electronic newsletters, tutorials that are distributed on CDs and other electronic media.

Note 2: When a request is made for archival material in an accessible format, that content is then treated like any other current content under this provision.

Rationale: This provision is a reminder that Section 508 covers all E&IT content.

• Status: Consensus on Feb 26
• Text from Web/Software
• Source: new
• Impact:
• External Reference:
• Testability:
• Disabilities: All

Advisory Notes

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

Advisory Notes from Subpart A

Inherently Visual E&IT

There are E&IT deliverables that do not lend themselves to accessibility, nor do they lend themselves to equivalent facilitation because the information they impart is intended to be analyzed using motion, shape, color or other vision-dependent attribute, and/or because they present an ever-changing stream of information. Examples include:

1. Weather simulation imagery that presents a moving visualizations of weather systems (required by National Weather Service)
2. Modeling and simulation results of physical phenomena that provides information (e.g., electronic sensor data transmitted by ocean buoys to illustrate ocean movement - NOAA, modeling and simulation of blast phenomena - DARPA, US Army
3. Real-time monitoring by systems that simultaneously provide imagery and electronic reports that can be transmitted via web-enabled methodologies to analysts elsewhere (e.g., container inspection or passenger inspection systems used by U.S. Customs Service)

• Status: Dec 4: Consensus as Advisory note
• Text from Subpart A Subcommittee
• Source: new

Advisory Notes from Subpart C: User Interface and Electronic Content

The following are recommended best practices.

1. Suppression of unneeded function

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

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

2. Writing guidelines

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

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

External References:

• Plain Language Tools, Office of the Federal Register

3. Interaction guidelines

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

External References

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

4. Parsing

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

External references:

• WCAG 2.0-4.1.1 Parsing (Level A)

5. User Preferences (non-visual)

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

Recommendations for additional advisory notes:

• Add an advisory note regarding the input from Robert B on 3-AA regarding a best practice for a method to navigate to the error should be provided. Thsi is also a reference to WCAG 2.0-3.3.3 Error suggestion (Level AA)

• Level A WCAG guidelines not included elsewhere:
  • 3.4.2-Page Titles
  • 2.4.3-Focus Order
  • 2.1.2 No Keyboard Trap
  • 2.4.1 Bypass Blocks

Advisory Notes from Subpart C: Authoring Tools

Some best practices for authoring tools to help authors create accessible content are:

1. Assistance with Checking for Accessibility Problems

Authoring tools with a user interface should either provide a mode which assists authors in checking for accessibility problems, or be compatible with evaluation tools that provide that function.

Advisory Notes from Subpart D: Information, Documentation and Support

Best practices for providing documentation to people with disabilities include:

1. Context-sensitive help

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

2. Text descriptions

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

3. User interface descriptions

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

Recommendations for additional advisory notes:

• Proposal for a best practice entry for compatibility of assistive technology with the product, so vendors can include information as to which AT they work with, installation and configuration information. Could be similar to Software Application Notes (SWANs) that printer manufacturers to include for information about some apps.

Advisory Notes from Subpart D:Support and E&IT related services

Best practices for providing support to people with disabilities include:

1. Remote assistance

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

Collected Material for Assistive Technology and Interoperability

These two notes were proposed, and discussed, but no agreement was reached as to how they would be used

Note on Assistive Technology and E&IT (New-2/26)

This note is proposed by the working group on AT-E&IT

This note addresses the question of when assistive technology (AT) is considered E&IT, and is therefore covered by Section 508.

Assistive technology may or may not meet the definition of E&IT. Assistive technology that provides an adaptive interface to E&IT, and that does not provide E&IT functions itself beyond special access functions, does not meet the definition of E&IT.

1. When assistive technology is E&IT, the product shall comply with the provisions of this part. When assistive technology is not E&IT, the requirements of this part do not apply (but see 3-New Assistive Technology). For example, a screen reader and an adaptive keyboard are interface adaptations and would not qualify as E&IT. A direct-connect TTY and a large button phone are both stand-alone products that provide E&IT functionality and would qualify as E&IT.

2. Nothing in this standard shall prevent an assistive technology manufacturer from developing a product designed to provide access for a single disability population.

3. Nothing in this standard shall prevent an agency from purchasing assistive technology as an accommodation for an individual with disabilities.

4. Nothing in this standard shall prevent an agency from requiring conformance to one or more standards in this part when assistive technology is not E&IT. For example, some AT can be expected to conform to appropriate technical standards and functional performance criteria applicable to the targeted disability population and generally applicable requirements, such as Information, Documentation and Support.

5. Assistive technology products that are E&IT, but are narrowly purposed for a discrete disability population, may not conform to all of the technical standards and functional performance criteria using the fundamental alteration exception. However, many can be expected to conform to appropriate technical standards and functional performance criteria applicable to the targeted disability population and generally applicable requirements, such as Information, Documentation and Support.

Proposed preamble text on AT (New-3/7)

This was proposed by Gregg V in email on Feb 25.

In this standard, some provisions require products to work with assistive technologies. In order for products and assistive technologies to work together it is (except for certain very well defined interconnections) necessary for both sides to work together. Sometimes assistive technology vendors do not have the capacity to work with every product vendor, even if the product vendor provides incentives or covers some or all of the cost. In these cases it may not be possible for a vendor to guarantee or even achieve full compatibility with those assistive technologies. It is recommended that procurement policies take this into account and make provision for product purchases while still keeping in mind the fact that products that will not work with assistive technologies in substantive ways will not be usable in substantive ways by employees with disabilities or members of the public.

As mentioned above, there are some very well defined interconnections where compatibility with a test tool has been proven to be sufficient to guarantee that products will work with assistive technologies. Where APIs or other standard interconnections exist that have been proven to be sufficient to guarantee compatibility with existing assistive technologies, then passing the test should be admissible as compatibility with those assistive technologies that the tool is certified for. The Assistive Technology Industry Association (ATIA) would be a good source to identify any tools that are developed for this purpose and proven to be effective.

Comments to Resolve:

• Peter K: Concern with tenses of phrases (e.g. "...keeping in mind the fact that products that DO not work with AT... will LIKELY not be usable..."); concerned about both the referenced to APIs, and I think it is inappropriate to reference specific trade associations in our report; concerned with references to "test tools" at this stage. All of the platform Accessibility Services technologies I know of have a set of tools to help developers know that they have done what they should. But I'm not aware of any of them that have explicit "pass/fail" criteria, and I wouldn't want to mislead the Access Board or any reader of this document into thinking we had those as of yet.
• Randy M: ATIA cannot provide automated test tools, so the entry in the second paragraph should be removed.

Annex

Narrow, Delineated Use

The TEITAC could not reach an agreement on whether this should be added as a new exception, though there was general agreement that it identifies an important issue. The group agreed to provide this information to the Access Board for its consideration.

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

Rationale: This exception is intended to address situations where conformance to the technical and performance standards can create access barriers by loading up a single product with multiple access features. For example, requiring all calculators to have speech output, large visual display, enlarged keys, and other access features built-in actually creates access barriers depending on the functional limitations of individuals with disabilities.

Despite long discussions and exploration of approaches, (such as identifying products as "personal-private", the concept of a "product line" approach) we have not reached consensus on a viable approach to addressing the problem.

In favor: Some committee members support creating an exception to address this problem

In opposition: This is a dangerous and unnecessary exception, which is likely to be abused. "Products with narrow delineated use" is not clearly defined.

• Status: Jan 7: Consensus as Advisory note
• Text from Subpart A Subcommittee and Closed Subcommittee
• Source: New

Proposed General Exception: 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.

Comments

• CSD/Trace: Do NOT accept new emergency and First Response Use (Rationale: this is same as comments listed in why we should not accept the new "Inherently Visual E&IT Assets. It falls in the same category – and is prone to abuse. For example, after 9-11 there were field units that people used to locate their children. This could be interpreted to mean that such units did not need to be accessible – leaving people with disabilities unable to post notices or search for their children. This should be covered by 'undue burden'. Where it is possible and for those disabilities it should apply. For those disabilities that do not make sense, it would not apply. Again the fundamental alteration language should take care of this.)

• Status: Feb 12 - Could not agree on this wording, will include in report to Access Board
• Text from Subpart A Subcommittee
• Source: New