EWG:Draft Sept 14

Editorial Working Group > September 14 Draft

This draft is released for review from September 17 - October 19 (5 weeks)

Related Pages

• Status Spreadsheet - an overview of the status of the work
• What's New in the Sept 14 Draft

Subpart A

Section 1194.1 Purpose

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

Version 1
The purpose of this part is to implement section 508 of the Rehabilitation Act of 1973, as amended (29 U.S.C. 794d). Section 508 requires that when Federal agencies develop, procure, maintain, or use electronic and information technology, Federal employees with disabilities have access to and use of information and data including communication that are as timely, accurate, complete, and efficient as compared to the access and use by Federal employees who are not individuals with disabilities, unless an undue burden would be imposed on the agency. Section 508 also requires that individuals with disabilities, who are members of the public seeking information or services from a Federal agency, have access to and use of information and data including communication that are as timely, accurate, complete, and efficient as compared to that provided to the public who are not individuals with disabilities, unless an undue burden would be imposed on the agency.

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

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

• Timely access means that individuals with disabilities have information and data available to them at the same time as individuals without disabilities, but that does not preclude captions that are slightly delayed or other reasonable differences in timing given individual situations.
• Accurate means that the information and data reflects the intended meaning especially when converted into another form or media.
• Complete means that all critical information and data is present when accessed by assistive technology or converted into another form or media.
• Efficient means that an individual with a disability exerts a reasonably similar or comparable amount of effort (given the capacity of current assistive technology) in using electronic and information technology as compared to an individual without a disability.

Access may be delivered via built-in access features or compatibility with assistive technology as described in the technical requirements specified in Subpart X. It should be noted that the determination of timely, accurate, complete, and efficient will not be a quantifiable measure.

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

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

• Status: Done
• Text from Subpart A Subcommittee
• Source: {508}1194.1
• Impact:
• External Reference:

Section 1194.2 Application

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

Current provision:

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

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

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

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

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

Version 1: Recommended New Introduction:

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

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

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

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

Version 3: Alternative for Paragraph (b)

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

Rationales:

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

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

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

• Rationale for Version 3: paragraph (b): Defer all procurement decision-making procedures to the Federal Acquisition Regulations (FAR) and/or other governing procurement policies. The Access Board and FAR will be simultaneously considering the 508 regulations. This presents an opportune time for GSA and the Access Board to consider how to ensure best provide guidance for agencies to implement 508 within the procurement process.

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

• Status: Done
• Text from Subpart A Subcommittee
• Source: {508}1194.2
• 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 which are critical to the direct fulfillment of military or intelligence missions. Systems which are critical to the direct fulfillment of military or intelligence missions do not include a system that is to be used for routine administrative and business applications (including payroll, finance, logistics, and personnel management applications).

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

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

1194.3 - NEW - Emergency, Field and First Response Use

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

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

• Impact:

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

• External Reference:

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

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

1194.3 - B- Incidental To A Contract

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

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

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

1194.3 - C - Employees Not Individuals With Disabilities

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

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

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

1194.3 - D - Access By Public

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

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

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

1194.3 - E - Fundamental Alteration

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

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

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

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

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

• Status: Done
• Text from Subpart A Subcommittee
• Source: {508}1194.3(e)

1194.3 - F - Service Areas

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

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

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

Version 2
Remove the provision entirely.

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

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

• Status: In progress: no consensus reached
• Text from Subpart A Subcommittee
• Source: {508}1194.3(f)

1194.3 - NEW - Narrow, Delineated Use

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

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

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

Section 1194.4 Definitions

The following definitions apply to this part:

Agency

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

Status: Done
Text from: Subpart A

Application Software

Discussion information can be found on http://teitac.org/wiki/Web_and_Software:_Definitions.

Status: In progress
Text coming from Web and Software Subcommittee.

Assistive Technology

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

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

Note: Abbreviated as "AT"

Status: Done
Text from: Subpart A

Authoring Tools

Any software used to create or modify content for publication.

Discussion of Work in Progress: 
* This is not intended to apply to text editors like Notepad. 
  Concern that this will be too broadly applied due to the definition of 
  "content". Subcommittee still working on these concerns.
* Proposal: change "used" to "intended"

Status: In Progress
Text from: Web and Software

Auto-updating

Object whose appearance is modeling one or more data values, such as a status monitor, or stock ticker, and which is updated autonomously by software.

Discussion of Work in Progress: 
* Concern that there is no consideration for frequency here. Auto-updating at 
  very slow frequencies like once per day is not a problem. Concern that this 
  is too broad and will cause ARIA content to fail even when there is no problem.

Status: In Progress
Text from: Web and Software

Captions

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

Status: Done
Text from: Audio/Visual

Closed Product Functionality

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

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

Status: Done
Text from: Self-Contained/Closed

Content

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

Status: In Progress
Text from: Web and Software

Content Format

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

Status: Done
Text from: Web/Software

Contrast Ratio

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

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

Notes:

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

Discussion of Work in Progress
* (Peter K): Why in the first note does it say ratio ranges from 1 to 21? 
             Why does it end at 21?
* (Gregg V): 21 is the highest value you can get, using the formula
* (Peter K): What about a definition of “luminance”
* (Jared S): For the definition of "luminance" see "relative luminance"
* Need to get agreement if the current text is acceptable

Status: Done
Text from: Web/Software

Decoration

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

Discussion of Work in Progress
* (Peter K) Should this perhaps be only visual sensory experience? Or audio too? 
* (Gregg V) The definition could apply to either - but we only use it for visual 
            in the standard.

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

Discussion of Work in Progress 
* (Peter K) It seems to me that by this definition, a copier is NOT E&IT, 
            as the IT is embedded. Is this the intention?
* (Aubrey W) The definition is clear that it does include copiers. Clarification is needed on what the third sentence means.
* (Gregg V) A copier is IT.  So is a printer.
* Need to get agreement if the current text is acceptable

Status: Done
Text from: Subpart A
Source: Clinger-Cohen

Free-Standing

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

Status: In Progress
Text coming from Hardware

General Flash and Red Flash Thresholds

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

1. There are more than three flashes within any one-second period; and
2. The flashing is below 50 Hz; and
3. The combined area of flashes occurring concurrently and contiguously occupies more than a total of .006 steradians (25% of any 10 degree visual field on the screen).

• For the general flash threshold, a flash is defined as a pair of opposing changes in relative luminance of 10% or more and the relative luminance of the darker image is below 0.80. An "opposing change" is an increase followed by a decrease, or a decrease followed by an increase.
• For the red flash threshold, a flash is defined as any transition to or from a saturated red.

• Note 1: Flashing that is less than 3 per second or greater than 50 hz automatically passes (see #1 and #2 above)
• Note 2: For general 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.

Discussion of Work in Progress
* (Jared S) Request to rename to "Flash Thresholds" for simplicity
* (Jared S) Request to remove reference to "images" as non-images can also flash
* (Jared S) Request to remove "red thresholds" or at least define "saturated red"
* (Jared S) Edit to item #3, add at the end "at a typical viewing distance" other wise it is not measurable
* Need to get agreement if the current text is acceptable

Status: Done
Text from: Web/Software

Information Technology

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

Status: Done
Text from: Subpart A

Informational Animation

An animation that conveys some information required for understanding content or functionality.

Status: Done
Text from: Web/Software

Interactive Elements

• Text coming from A/V Subcommittee

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

Large Scale Text

At least 18 point or 14 point bold

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

Status: Done
Text from: Web/Software

Menu

Set of selectable options.

Discussion of Work in Progress
* (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.

Status: Done
Text from: Telecommunications
Source: HFES 200

Operable Controls

Any physical control that affects the operation of the product. Operable controls include, but are not limited to, mechanically operated controls, input and output trays, card slots, keyboards, keypads, keys, or buttons, including touch-screens.

Rationale:

• The list of controls was added to make it clear that this applies to any controls, not just products with a "full keyboard."
• The question of whether the title should be "physically operable controls" was discussed, but determined not to be needed.

Status: Done
Text from: Hardware

Other Services To Cooperate With Assistive Technologies

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

Status: Done
Text from: Web and Software

Peak Non-crisis Network Traffic

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

Status: Done
Text from: Telecommunications

Platform Accessibility Services

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

Status: Done
Text from: Web/Software

Platform Software

Collection of software components that runs on an underlying software or hardware layer, such that the platform creates a virtual environment in which to run applications in a manner which isolates the applications from the underlying layer.

• Note 1: If there is a direct route from the application to the underlying layer then the software components in the middle are not considered to be 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 2: An application offering a compute service, such as a 3d rendering engine where a requesting application can directly access the underlying layer would also not be considered a "platform".
• 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.
• TBD: Notes about bootloader programs and closed systems?

Status: In Progress
Text from: Web/Software

Programatically Determinable

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

Status: Done
Text from: Web/Software

Real-time Text

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

Discussion of Work in Progress
* (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.

Status: Done
Text from: Telecommunications

Relative Luminance

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

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

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

Notes on the formulas

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

Status: Done
Text from: Web/Software

Synchronized Media

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

Status: Done
Text from: Web/Software

Telecommunications

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

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

Terminal

Device and/or software with which the end user directly interacts and that provide the user interface.

NOTE: For some systems, the software that provides the user interface may reside on more than one device such as a phone and a server.

Status: Done
Text from: Telecommunications

TTY

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

Status: Done
Text from: Telecommunications

Undue Burden

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

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

Video Description

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

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

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

Web Content

Content which is made available in the World Wide Web.

Alternate proposal: Remove as this is not used in any provisions.

Status: In Progress
Text from: Web and Software

World Wide Web

A very large set of hypertext-linked content files located on computers connected by the Internet.

Alternate proposal: Remove as this is not used in any provisions.

Status: In Progress
Text from: Web and Software

Section 1194.5 Equivalent Facilitation

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

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

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

Technical Provisions

1. Requirements for All Product and Services

1.1 Functional Performance Criteria

Version 1: If an E&IT product fails to meet one or more of the technical provisions above, meets it via equivalent facilitation, or if the technical provisions do not apply, the agency shall ensure that that the purpose of the technical provisions is met through the following functional performance criteria.

Version 2: After the technical requirements are applied, the following functional performance criteria must be applied to:
1) see if the technical provisions cover all aspects needed to provide access to the product,
2) check any equivalent facilitation, and
3) see if access can be provided in another way if any of the technical provisions are not met.

Discussion of Work in Progress: 
There is a lot of ongoing discussion about the Functional Performance Criteria
Notes from the General Interface SC are on the wiki cover 4 areas of discussion
http://teitac.org/wiki/Functional_Performance_Criteria
* Does meeting the FPC via AT require that AT exist or just AT API
* The term full access vs comparable access vs access vs use
* Testability
* When are the FPC applied.

• Status: In Progress
• Text from General
• Source: New
• Impact:
• External Reference:

1.1-A - Without Vision

Products must provide at least one mode that allows [access] without using vision. This access may be provided directly or through assistive technology.

• Status: In Progress
• Text from General
• Source: {508}1194.31(a), {255}1193.31
• Impact:
• External Reference:
• Testability: Expert evaluation
• Metadata
  • Disabilities: Blindness
  • User Activities: All
  • Product Characteristics: All
  • Product Types: All

1.1-B - With Limited Vision

Products must provide at least one mode that allows [access] visually without requiring visual acuity greater than 20/70. This access may be provided directly or through assistive technology.

• Status: In Progress
• Text from General
• Source: {508}1194.31(b), {255}1193.41(b)
• Impact:
• External Reference:
• Testability: Expert evaluation
• Metadata
  • Disabilities: Low vision
  • User Activities: All
  • Product Characteristics: All
  • Product Types: All

1.1-C - With Color Vision Deficits

Products must provide at least one mode that allows [access] for people with color vision deficits.

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

 Discussion of Work in Progress
* Proposed: Reword to ensure that this is a visual mode, and does not allow 
  provisions for   blindness to meet this provision.
* Proposed for removal, depending on how this section is handled overall.

• Status: In Progress
• Text from General
• Source: new
• Impact:
• External Reference:
• Testability: Expert evaluation
• Metadata
  • Disabilities: Color deficiency/Colorblindness
  • User Activities: All
  • Product Characteristics: All
  • Product Types: All

1.1-D - Without Hearing

Products must provide at least one mode that allows [access] without using hearing. This [access] may be provided directly or through assistive technology.

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

1.1-E - With Limited Hearing

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

Discussion of Work in Progress: 
* (Peter K) What is the definition of "enhanced audio"

• Status: In Progress
• Text from General
• Source: {508}1194.31(d), {255}1193.41(b)
• Impact:
• External Reference:
• Testability: Expert evaluation
• Metadata
  • Disabilities: Hard of hearing,
  • User Activities: All
  • Product Characteristics: All
  • Product Types: All

1.1-F - Without Speech

Products must provide at least one mode that allows [access] without using speech. This [access] may be provided directly or through assistive technology.

• Status: In Progress
• Text from General
• Source: {508}1194.31(e), {255}1193.41(h)
• Impact:
• External Reference:
• Testability: Expert evaluation
• Metadata
  • Disabilities: Speech
  • User Activities: All
  • Product Characteristics: All
  • Product Types: All

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

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

Discussion of Work in Progress: 
* (Peter K) Is "and does not require simultaneous actions" already covered in 2.1.C(2) Mechanical Controls. Can this be removed since is duplicate.

Discussion or Rationale: Adds AT option.

• Status: In Progress
• Text from General
• Source: {255}1193.41(e)
• Impact:
• External Reference:
• Testability: Expert evaluation
• Metadata
  • Disabilities: Dexterity, Mobility
  • User Activities: All
  • Product Characteristics: All
  • Product Types: All

1.1-H - With No Reach or Touch

Except for closed products, products must provide at least one mode that allows control through assistive technologies to allow [access] for people with no reach or ability to touch.

Rationale: This provision is proposed to address a concern that without a provision for individuals who are unable to reach and touch the product, a large group of people will be left out.

On the other side there is a concern that we don't have good techniques for built-in access to products that will address the range reach and touch disabilities. Voice, eye gaze, and head pointing might work, but might not work well enough in the field, or even meet the full range of disabilities being addressed with this provision.

A second concern is around closed products and the fact that if you can't attach AT then you have to rely on a built in solution. Some suggested that we should try to figure out how to create a safe way to have "closed products" be open to AT and thus solve the problem that way.

There is consensus on the issues, but we haven't yet figured out wording 
that we can reach consensus on or whether it is covered elsewhere.

• Status: In Progress
• Text from General
• Source: new
• Impact:
• External Reference:
• Testability: Expert evaluation
• Metadata
  • Disabilities: Dexterity, Mobility
  • User Activities: All
  • Product Characteristics: All
  • Product Types: All

1.1-I - With Cognitive, Language or Learning Limitations

Products must/shall? provide at least one mode that accommodates cognitive, language or learning impairments, directly or with assistive technology.

Discussion of Work in Progress: 
* This provision is here as a placeholder. 
* The general group identified several issues and questions in trying to move 
  this forward. The working group is looking for sufficient technical provisions 
  to support the inclusion of a FPC.
* From Web and SW Subcommittee: This requirement is extremely broad. 
  Three features recommended by Dr. Clayton Lewis to address the needs of 
  people with cognitive disabilities are:
  ** Word lookup
  ** Text Reading
  ** Spelling assistance
  The AT Interoperability provision supports assistive technology with the 
  necessary information to provide these functions.

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

1.2 General Technical Requirements

1.2-A - Accessibility Configuration

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

Rationale:

Discussion of Work in Progress
* Need rationale and impact for this provision.

• Status: Done
• Text from Telecommunications
• Source: new (was 5-A (first bullet) of Aug 17 draft)
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities: All
  • User Activities: All
  • Product Characteristics: All
  • Product Types: All

1.2-B - Closed Product Functionality

If any product functionality is closed, then individuals with disabilities must have access to that functionality without the use of any assistive technologies that must be attached or installed. A personal assistive listening device that connects to the standard audio connection required in the audio connection provision is not considered assistive technology.

Rationale:

Discussion of Work in Progress
* Need rationale and impact for this provision.

• Status: Done
• Text from Self Contained, Closed
• Source: {508}1194.25(a)
• Impact:
• External Reference:
• Testability: Expert evaluation
• Metadata
  • Disabilities: All
  • User Activities: All
  • Product Characteristics: All
  • Product Types: All

1.2-C - Flashing

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

• Flashing created by software is under the general flash and red flash threshold.

• Flashing created by hardware is either:
  • less than YYY candelas; or
  • less than 20 candelas/sq meter and contiguously occupies more than a total of .006 steradians (25% of any 10 degree visual field).

Rationale:

Discussion of Work in Progress
* The hardware portion of this provision is still under development.
* Need rationale and impact for this provision.

• Status: In Progress
• Text from Self Contained, Closed
• Source: {508}1194.21(k) 1194.22(j) 1194.25(i), and {255}1193.43(f)
• Impact:
• External Reference:
• Testability: Inspection
• Metadata
  • Disabilities: All
  • User Activities: All
  • Product Characteristics: All
  • Product Types: All

1.2-D - Biometric ID

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

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

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

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

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

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

Discussion of Work in Progress
* The hardware portion of this provision is still under development.
* Need impact for this provision.

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

1.2-E - Pass Through

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

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

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

Rationale:

Discussion of Work in Progress
* (Peter K) Virtually every computing device “transmits or conducts information 
   or communication”, so this would apply to things like disk drive firmware and 
   a huge host of other things that have no user input impact. It is nonsensical.
* (Gregg V) It says that these things should not strip disability access information 
   in the process.  For most things it would be no issue.   In places where it  
   does apply it would be important. 
* (Gregg V) I think the last "usable" is supposed to be Accessible.
* (David B/Gregg) Need note that this applies to captions
* Need rationale and impact for this provision.

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

1.2-F - Audio information

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

Rationale:

Discussion of Work in Progress
* Need rationale and impact for this provision.

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

1.2-G - Visual Information

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

Rationale:

Discussion of Work in Progress
* Need rationale and impact for this provision.

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

1.2-H - Color

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

Rationale:

Discussion of Work in Progress: 
* This will be harmonized with the color provision in Section 3, 
  where it is included to ensure that web/software developers see it.
* Need rationale and impact for this provision.

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

1.2-I - Text size

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

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

Rationale:

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

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

2. Hardware Aspects of Products

2.1 All Products with Hardware

2.1-A - Contrast Ratio for Display

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

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

Rationale This applies to both active displays (backlit displays such as an LCD) and passive displays.

Discussion of Work in Progress
* Does this apply to cell phones? Yes. It should apply to all products.   
  (Gregg V) Phones should have no problem.  Isn't a phone made that I know 
   of that can't meet this.  Only old passive LCDs would have a problem.  
   Phones displays are much better than this.   
   (X is going to be either 3 or 5 – either way phones are much better)

• Status: In Progress - completing values for X:1
• Text from Hardware
• Source: {508} 1194.26(b); {508} 1194.25(c)
• Impact:
• External Reference:
• Testability: Formal test method
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

2.1-B - Contrast Ratio for Legends and Instructions

If the legend or instructions on the device are the only means of conveying information, then the contrast ratio shall be X:1 and the relative luminance difference must be at least 15% of XXX.

Notes:

• XXX is a placeholder for the final scale on which the 15% is based.
• If other means of conveying the information in the label or instructions exists (e.g. uniquely tactilely discernible though shape and/or location), then this contrast ratio requirement does not apply.
• This requirement excludes system 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.'

Discussion of Work in Progress 
* There is some conflict between guidance provided in non-accessibility 
  ISO standards such as ISO 9241.4

• Status: In Progress - completing values for XXX
• Text from Hardware
• Source: {508} 1194.26(b); {508} 1194.25(c)
• Impact:
• External Reference:
• Testability: Formal test method
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

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

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

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

2.1-D - Touch Operated Controls

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

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

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

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

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

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

Discussion of Work in Progress
* Keyboard controls that provide equivalent functionality are equivalent
* Touch screens can't always provide a 1:1 match of soft and mechanical controls.
* Need to finalize some language that addresses the intent of “redundancy” 
  of controls beyond just requiring another set of mechanical controls.  
* Need to add an ability to de-activate the touch screen to prevent accidental
  activation
* Is remote control an acceptable alternative

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

2.1-E - Connector or Connection Language

If users can access and the user interface of a product through a non-standard user connection, they must also be able to control that functionality through a standard user connection using standard protocols for that type of input or output. If an adapter is required to convert a non-standard user connection on an E&IT device into a standard user connection, it shall be the responsibility of the E&IT vendor to offer such adapter.

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

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

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

2.1-F - Installed or Free-Standing Products

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

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

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

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

2.2 If the Product has Speech Output or Throughput

2.2-A - Magnetic Coupling

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

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

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

2.2-B - Interference with Hearing Device

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

Recommended Advisory Note (for US): Include information about existing standards: TIA Standard for Cordless Phones and the ANSI standard for cellular and PCS frequency bands and for hearing aid immunity. Standards do not exist for other frequency bands and for any VoIP at this time.

Discussion or Rationale: 
* SC is working on the wording of this and will report back
* Need exact title/number of existing standards for reference

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

2.2-C - Audio Connection

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

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

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

Alternate wording for clarity

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

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

Discussion on Work in Progress:  
* Need to be more specific about "standard signal level"
* Need to check against the definitions for public-shared and 
  personal-private to be sure they work for this provision (or 
  define the distinction here).

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

2.2-D - Volume

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

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

Discussion of work in progress: 
* Final level for THD still to be determined. 
* Question about where are volumes set? Is that where you measure from? 

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

2.2-E - Volume (Gain)

For incoming voice signals:

1. Analog line-powered telecommunications products, wireline, and all cordless telephones (wireline or VoIP) must comply with FCC regulation §68.317 for volume control
2. All cellular phones - TBD
3. All other telecommunications products or systems that provide a function allowing voice communication must provide a gain adjustable from the normal unamplified level to at least 20 dB above the normal unamplified level as measured in accordance with the provisions of the FCC regulation §68.317 for volume control. The volume at the normal unamplified level setting must also meet the requirement in FCC regulation 68.317.

Discussion of Work in Progress:
* Language for cellular phones pending outcome of ATIS Study Group 11 work
* Further research needed for 20 dB requirement
* Review telecoms/communications to be sure requirement is inclusive
* Need to determine if the word "telecommunications" should be removed

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

2.2-F - Volume Reset

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

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

3. User Interface and Electronic Content Provisions

There are updates to provisions in this section

These provisions apply to all electronic user interfaces and 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.

Discussion of Work in Progress: 
* Need to add an example

• Status: Done. Update posted on Sept 24, 2007
• Text from Web and Software
• Source: {508}1194.22(c) and 1194.25(h) (was 6.1.A in July 18 draft)
• Impact:
• External Reference: Harmonized with WCAG 2.0 and ISO 9241.171
• Testability: Expert evaluation
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

3-B - Contrast

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

Discussion of Work in Progress: 
* (Peter K) Needs to be more general
* (Peter K) Since have this should remove 3P User Preferences, and 3Q Color Adjustment
* Need to get agreement if the current text is acceptable

• Status: Done
• Text from Web and Software
• Source: {508}1194.21(j) (was 3.2.A and 6.1.B in July 18 draft)
• Impact:
• External Reference: Harmonized with WCAG 2.0 and ISO 9241.171
• Testability: Formal test method
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

3-C - Size, shape, location

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

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

Discussion or Rationale: This applies to instructional text in the interface or other onscreen information.

• Status: Done
• Text from Web and Software
• Source: new
• Impact:
• External Reference: Harmonized with WCAG 2.0
• Testability: Inspection
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

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

Discussion or Rationale:

• Status: Done, Updated: Sept 26, 2007
• Text from Web and Software
• Source: {508}1194.21(g) (was 3.2-C in July 18 draft)
• Impact:
• External Reference:
• Testability: If platform settings, inspection; if no platform settings, formal test method
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

3-E - Color Adjustment

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

Discussion or Rationale:

• Status: Done
• Text from Web and Software
• Source: new
• Impact:
• External Reference:
• Testability: Formal test method
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

3-F - Non-text Objects

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

• Controls-Input: If non-text objects is a control or accepts user input, then it must have a name that describes its purpose. (See also User Interface Components provisions)
• Media: If non-text objects is synchronized multimedia, live audio-only or live video-only content, then text alternatives at least identify non-text objects: All non-text objects must have a text alternative that presents equivalent information, except for the situations listed below.
• Media: If a non-text object is synchronized multimedia, live audio-only or live video-only content, then text alternatives at least identify the non-text object with a descriptive text label. (For synchronized multimedia, see also Audio and/or Video provisions)
• 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)
• Test:' If a non-text object is a test or exercise that must be presented in non-text format, then text alternatives at least identify the non-text object with a descriptive text label. (For multimedia, see also Audio and/or Video provisions)
• Sensory: If a non-text object is primarily intended to create a specific sensory experience, then text alternatives at least identify the non-text object with a descriptive text label. (For multimedia, see also Audio and/or Video provisions)
• CAPTCHA: If the purpose of a non-text object is to confirm that content is being accessed by a person rather than a computer then text alternatives that identify and describe the purpose of the non-text object must be provided and alternative forms in different modalities must be provided to accommodate different disabilities.
• Decoration, Formatting, Invisible Objects: If a non-text object is pure decoration, or used only for visual formatting, or if it is not presented to users, then it is implemented such that it can be ignored by assistive technology.

• Status: Done, Updated: Sept 26, 2007
• Text from Web and Software
• Source: {508}1194.22(a) (was 6.1.E in July 18 draft)
• Impact:
• External Reference: Harmonized with WCAG 2.0
• Testability: Expert evaluation
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

3-G - Human Language

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

• Status: Done
• Text from Web and Software
• Source: new
• Impact:
• External Reference: Harmonized with WCAG 2.0
• Testability: Inspection
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

3-H - Language of Parts

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

• Status: Done
• Text from Web and Software
• Source: new
• Impact:
• External Reference: Harmonized with WCAG 2.0
• Testability: Inspection
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

3-I - Pausing

Moving, blinking, scrolling, or auto-updating information must allow pausing by the user unless it is part of an activity where timing or movement is essential. Content that is pure decoration must at least allow stopping by the user.

Discussion of Work in Progress
* Need to add a note about decoration.
* Should also allow hiding of decorative content.

• Status: In Progress
• Text from Web and Software
• Source: new (was 6.1.M in July 18 draft)
• Impact:
• External Reference: Harmonized with WCAG 2.0
• Testability: Inspection
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

3-J - Flashing

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

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

Rationale: This provision is a subset of 1.2.B - Flashing and is included in this section for completeness of this group of provisions.

Discussion of Work in Progress: 
* (Peter K) Is subset of 1.2C - Flashing, so this entry should be removed
* (Jared S) Agrees with removing provision if Hardware Subcommittee agrees
* Need to get agreement if the current text is acceptable

• Status: Done
• Text from Web and Software
• Source: {508}1194.21(k) 1194.22(j) 1194.25(i), and {255}1193.43(f) (was 6.1.D in July 18 draft)
• Impact:
• External Reference: Harmonized with WCAG 2.0
• Testability: Inspection
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

3-K - Consistent Identification

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

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

• Status: Done
• Text from Web and Software
• Source: New (was 6.1.L in July 18 draft)
• Impact:
• External Reference: Harmonized with WCAG 2.0
• Testability: Inspection
• Metadata
  • Disabilities: Cognitive language/learning
  • User Activities:
  • Product Characteristics:
  • Product Types:

3-L - Audio Turnoff

When any audio plays automatically for more than 3 seconds, there must be a mechanism to pause or stop the audio, or a mechanism to control audio volume which can be set independently of the system volume.

Discussion or Rationale: 
* (Peter K) We should clarify the situation for web pages: better if 
   the web browser had this responsibility, so web pages that played sound 
   didn't have to explicitly include a 'turn sound off' button when the 
   browser can do this function more universally (less burned on programmers 
   to do this once in the browser). Perhaps this could be done in an advisory note...?
* (Jim A) The browser (user agent) can only turn off sound that it knows 
   about, such as the <bgsound> element. If the author uses <embed> or <object> 
   to contain FLASH or media player sounds or some JavaScript to play the sound 
   the hosting user agent has no "knowledge" or control of what occurs 
   in these elements.
* (Jared S) This provision should be an advisory note

• Status: Done
• Text from Web and Software
• Source: {508}1194.25(e) - Second sentence (was 4.C in July 18 draft)
• Impact:
• External Reference: Harmonized with ISO 9241.71, HFES 200, WCAG 2.0
• Testability:
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

3-M - Reading Sequence

When the sequence in which information is presented affects its meaning, a correct reading sequence can be programmatically determined and sequential navigation of interactive components is consistent with that sequence.

editorial suggestion: When the sequence in which information is presented affects its meaning, a correct reading sequence must be programmatically determinable. The sequential navigation of interactive components must be consistent with that reading sequence.

Discussion of Work in Progress: 
* (Peter K) The phrase "correct reading order" is not clear. In 8.1.C the phrase "logical linear" is used which is clearer.
* Need to get agreement if the current text is acceptable

• Status: In Progress
• Text from Web and Software
• Source: new (was 6.1.N in July 18 draft)
• Impact:
• External Reference: Harmonized with WCAG 2.0. Similar to recommendation in ISO 9241.71
• Testability: Inspection
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

3-N - Link Purpose

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

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: Done
• Text from Subcommittee
• Source: New (was 6.1.H in July 18 draft)
• Impact:
• External Reference: Harmonized with WCAG 2.0
• Testability: Expert evaluation
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

3-O - Information and Relationships

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

1. row and column headers are identified for data tables
2. markup is used to associate data cells and header cells for data tables that have two or more logical levels of row or column headers.
3. markup is used to identify section headings
4. markup is used to identify form element labels

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

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

Discussion of Work in Progress
* (Peter K) This provision pretty clearly assumes it is 
            talking about a document, but it doesn't mention it explicitly 
            (and there, an XML/HTML document). In (2), (3), and (4) it directs 
            the explicit use of “markup” to do things (all of which are covered in 3-V). 
            This provision should either be removed as redundant, or scoped to 
            explicitly apply to (web) documents.
* (Jared S) Should remove "markup"
* (Jared S) Disagrees with removing this provision
* Need to get agreement if the current text is acceptable

• Status: Done
• Text from Web and Software
• Source: New (was 6.1.I in July 18 draft)
• Impact:
• External Reference: Harmonized with WCAG 2.0
• Testability: Inspection
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

3-P - User Interface Components

For all user interface components, including form elements and those generated by scripts

• the name and role must be programmatically determined
• states, properties, and values that can be set by the user must be programmatically determined and can be programmatically set, and
• notification of changes to these items is available to user agents, including assistive technologies.

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

editorial suggestion, version 1: For all user interface objects, including form elements and those generated by scripts

• the name and role must be programmatically determined
• states, properties, and values that can be set by the user must be programmatically determined and can be programmatically set, and
• notification of changes to these items is available to user agents, including assistive technologies.

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

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

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

Discussion of Work in Progress: 
* (Peter K) Same comments as 3O - Information and Relationship. Recommend remove this provision.
* (Jared S) Disagree with removing

• Status: Done, Updated: Sept 26, 2007
• Text from Web and Software
• Source: New (was 6.1.K in July 18 draft)
• Impact:
• External Reference: Harmonized with WCAG 2.0
• Testability: Inspection
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

3-Q - Disruption of Access Features

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

Discussion or Rationale:

• Status: Done
• Text from Web and Software
• Source: {508}1194.21(b) (was 3.1.A in July 18 draft)
• Impact:
• External Reference:
• Testability: Expert evaluation
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

3-R - Timing

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

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

editorial suggestion: Change "software or content" to "user interface or content". The plenary has reviewed this and decided to keep the current phrase "product or content".

Discussion or Rationale: The recommended change is harmonized with both the ISO 9241.71 Software Accessibility standard and WCAG 2.0.

Discussion of Work in Progress
* In Adjust, issue with "before encountering" - this issue is resolved.
* In Essential Exception, still discussing the suggestion to 
  add something about data integrity. - this issue is resolved.
* "Sufficient time" is not objectively testable, except through human
  performance (summative) testing. There are other acceptable 
  strategies for addressing the needs of users who need more time. - This needs
  to be moved to rationale section.

• Status: Done
• Text from Web and Software
• Source: New (incorporates {508}1194.22(p), {508}1194.23(d), {508}1194.25(b) (was 3.1.B, 3.1.D and 6.K in the July 18 draft)
• Impact:
• External Reference: Harmonized with WCAG 2.0 and ISO 9241.71
• Testability: Inspection
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

3-S - Keyboard Operation

Version 1: All functionality of the product operable through the user interface must be operable through a keyboard interface without requiring specific timings for individual keystrokes. The only exception is where the underlying function requires input that depends on the path of the user's movement and not just the endpoints.

• Note: This 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: This does not forbid and should not discourage providing mouse input or other input methods, such as gestures, in addition to keyboard operation.

editorial suggestion for first paragraph in version 1: All functionality operable through the user interface must be operable through a keyboard interface without requiring specific timings for individual keystrokes. The only exception is where the underlying function requires input that depends on the path of the user's movement and not just the endpoints.

Discussion of Work in Progress 
* (Peter K) This is no longer scoped to products with a keyboard? 
   Should it be?
* Question of if a note should be added regarding how this would apply to on-screen keyboards
* Discussion continuing on web and software wiki Web_and_Software:_September_12#Keyboard_Operation

• Status: Done, Updated: Sept 26, 2007
• Text from Web and Software
• Source: {508}1194.21(a) (was 3.3.A in July 18 draft)
• Impact:
• External Reference: Harmonized with WCAG 2.0 and ISO 9241.71
• Testability: Inspection
• Metadata
  • Disabilities: Blindness, Physical
  • User Activities: All
  • Product Characteristics: Uses Keyboard (Physical - touch typeable)
  • Product Types: Web Content; Telephone only device; IVR (Voicemail, Autoattendant, Audiotext); Software (installed or through browser); Copiers; AudioVisual equipment (Video Monitor, TV, Projector); KIOSKS; Network Interface to devices; Desktop Computer Systems

3-T - Focus Indicator

Software must support at least one mode that provides a highly visual indication of which user interface object currently has the keyboard focus.

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

editorial suggestion for first paragraph: User interfaces must support at least one mode that provides a highly visual indication of which user interface object currently has the keyboard focus.

Discussion of Work in Progress 
* The note providing a testable sufficient technique for determining "highly visual" is not final.  
  Focus cursors are provided by user agents for some technologies (HTML, PDF, etc.) but 
  are needed for other technologies (JavaScript, Flash, etc.)

• Status: Done, Updated Sept 26, 2007
• Text from Web and Software
• Source: {508}1194.21(c) (was 6.1.J in July 18 draft)
• Impact:
• External Reference: Harmonized with ISO 9241.71
• Testability: Inspection
• Metadata
  • Disabilities: Blind, Physical
  • User Activities: All
  • Product Characteristics: Involves Web Content or Applications
  • Product Types: Web Content; Software (installed or through browser); Network Interface to devices; Desktop Computer Systems; Portable Computer Systems

3-U - AT Interoperability

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

• provide assistive technology with object information including but not limited to:
  • role, state(s), boundary, name, and description
  • the row and column an object is in, and the headers for the row and column for that object if it is in a table that has row or column headers.
  • current value and any minimum or maximum values, if the object represents one of a range of values
  • relationship this object has as a label for another object, or being labeled by another object
  • parent or containing element, and any children objects
  • text contents, text attributes, and the boundary of text rendered to the screen
• provide assistive technology with a list of actions that can be executed on an object and allow assistive technology to programmatically execute any of those actions;
• allow assistive technology to track and modify focus, text insertion point, and selection attributes of user interface objects;
• provide assistive technology with notification of events relevant to user interactions, including but not limited to changes in the object's state(s), value, name, description, or boundary
• Note: This provision applies to forms in the software.

editorial suggestion for the first paragraph: On platforms that support AT interoperability, user interface objects 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:

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.

Discussion of Work in Progress
* (from Sept plenary) question raised if this should also list other 
   accessibility issues such as sound.
* Note that there is an outstanding issue as to whether or not this provision 
  is met by software that uses an accessibility API but does not actually work 
  with AT. This issue is related to the issues around the functional 
  performance criteria.

• Status: Done, Updated: Sept 26, 2007
• Text from Web and Software
• Source: {508}1194.21(d) (was 3.4-A in July 18 draft)
• Impact:
• External Reference: Harmonized with ISO 9241.171
• Testability: Expert evaluation
• Metadata
  • Disabilities: Blindness
  • User Activities: All
  • Product Characteristics: Has OS that supports installed AT and user can install
  • Product Types: Telephone only device; Software (installed or through browser); Network Interface to devices; Desktop Computer Systems; Portable Computer Systems

3-V - Both platform and Application

Software that is both a 'platform', and an 'application' running on another platform must:

1. 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.
2. define, expose, and translate accessibility service information between applications running within its platform and the underlying platform - so that those applications can meet the AT Interoperability provision.
3. provide mechanisms for:
   • moving the keyboard focus into and out of an application, and
   • addressing central conflicts between keyboard mnemonics in the application and the host platform.

Rationale:

• Status: In Progress
• Text from Web and Software
• Source: New (was 3.1.C in July 18 draft)
• Impact:
• External Reference: ISO 9241.71 and UUAG
• Testability: Unsure how to address this provision
• Metadata
  • Disabilities: All
  • User Activities: All
  • Product Characteristics: All
  • Product Types: Software (installed or through browser); Network Interface to devices; Desktop Computer Systems; Portable Computer Systems

3-W - Accessibility Services

Platform software shall provide access to a set of services that enable applications running on the platform to interact with other assistive technology sufficient to enable compliance with the "AT interoperability" and "User Interface Components" provisions.

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

3-X - Advisory Notes

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

1. Suppression of unneeded function

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

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

2. Writing guidelines

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

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

3. Interaction guidelines

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

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

Discussion or Rationale:

Discussion of Work in Progress: 
* (Jared S) Recommend that we add additional advisory notes to 3-X, where
            appropriate, to further address some of the WCAG 2.0 provisions that
            have been excluded. Primarily:
            - Parsing (Level A)
            - Descriptive Page Titles (Level A)
            - Focus Order (Level A)
            - Error identification (Level A)
            - Error suggestion (Level AA)
            - Descriptive headings and labels (Level AA)
            These are the Level AA or below items not currently in the draft that
            should at least receive honorable mention in advisory notes. If this
            is agreeable, I can work on pulling out the relevant text and
            structuring it - we'll probably need a "Web only" section in 3-X.

• Status: Done
• Text from Web and Software
• Source: new
• Impact:
• External Reference:
• Testability: Many of these are testable
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

4. Additional Provisions for Audio-Visual Players or Displays

4-A - Caption Playback

(There are several edits proposed for this provision. Edits and alternate versions are listed section by section within this provision. Throughout, the word "equipment" has been replaced with "products")

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

1. Products of this type:

• Analog television displays that measure 13 inches or more diagonally
• Computer products that includes analog television receiver or display circuitry

Use this standard:

• CEA 608

To provide these functions:

• Receive, decode and display signals from
  • broadcast
  • cable
  • satellite
  • videotape
  • optical disc
  • other recorded media

2. Products of this type:

• Wide-screen (16:9) digital television (DTV) displays measuring at least 7.8 inches vertically
• DTV sets with conventional (4:3) displays measuring at least 13 inches diagonally
• Stand-alone DTV tuners, whether or not they are marketed with display screens
• Computer equipment that includes DTV receiver or display circuitry

Use this standard:

• CEA 708

To provide these functions:

• Receive, decode and display signals from:
  • broadcast
  • cable
  • satellite
  • videotape
  • optical disc
  • other recorded media
  • IPTV

OR

• Decode data, when available, and pass a decoded ("open-captioned") video signal to the DTV display or monitor

3. Products of this type:

• Other digital video source devices including personal video display devices

Use this standard:

• CEA 708 or functional equivalent (see end-note for definition of functional equivalent)

To provide these functions:

• Pass caption data, when available, to the caption decoding circuitry of DTV displays

OR

• Decode caption data, when available, and pass a decoded ("open-captioned") video signal to the DTV display or monitor. For personal video display devices, decoding of caption data will be subject to the "readily achievable" standard; if decoding of caption data is not "readily achievable," open-captioned video must be supplied for use on that device.

Proposed additional section Version 1:
4. Products of this type:

• Software audio or video players on computers, personal video display devices or other devices which play digital audio or video

Use any standard or method

To provide these functions:

• Display caption data, when available.
• Players must allow users to turn the caption display on and off at will, and the technology for doing so must be freely available to all users.

Material for inclusion in the additional notes document:

TEITAC definition of "Functional Equivalent" to CEA 708

Equivalent text display functionalities must:

• Support caption placement control by caption authors for any position within the TV safe area.

• Support standard, large, and small caption sizes and must allow the caption author to choose a size and allow the viewer to choose an alternative size.

• Support eight font variations. Caption authors may specify one of these eight font styles to be used to write caption text. Equivalents must include the ability for users to choose among the eight fonts. The equivalent must display the font chosen by the caption author unless the user chooses a different font.

• Support the eight font styles defined as follows: default (undefined), monospaced with serifs (similar to Courier), proportionally spaced with serifs (similar to Times New Roman), monospaced without serifs (similar to Helvetica Monospaced), proportionally spaced without serifs (similar to Arial and Swiss), casual font type (similar to Dom and Impress), cursive font type (similar to Coronet and Marigold), and small capitals (similar to Engravers Gothic).

• Support author and user choice of eight character foreground and eight character background colors: white, black, red, green, blue, yellow, magenta and cyan).

• Support author and user selection of character and background opacity options: SOLID, TRANSLUCENT, TRANSPARENT [FLASH option deleted]

• Support options for altering the appearance of caption character edges.

• Support the authoring and selection of the six caption services, but information from only one service need be displayed at a given time.

• Include an option that permits a user to choose a setting that will display captions as intended by the caption provider (a default). Equivalents must also include an option that allows a viewer's chosen settings to remain until the viewer chooses to alter these settings, including during periods when the video source device is powered off.

• Support interoperability and conversion between other common caption formats such as CEA 608, CEA 708, or Timed Text (e.g. DFXP).

Discussion of Work in Progress: 
* (Peter K) Do not understand what the phrase "Support options for altering the appearance of caption character edges" means.
* (Peter K) What are the 6 services referred to in the statement "Support the authoring and selection of the six caption services..."

• Status: In Progress, Proposed update posted October 9, 2007
• Text from A/V
• Source: new
• Impact:
• External Reference: CEA 608, CEA 708
• Testability: Inspection
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

4-B - Supplemental Audio Playback

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

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

Discussion or Rationale Edited for clarity

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

5. Additional Provisions for Real-time Voice Conversation Functionality

5-A - Relay Services Accessibility

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

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

5-B - Real-Time Text Reliability and Interoperability

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

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

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

Discussion of Work in Progress: 
* (Peter K) First sentence is a duplicate of %C that says you must have/support RTT. Recommend removing from this provision

• Status: In Progress
• Text from Telecommunications
• Source: {508]1194.23(b), {255}1193.51(e), this is a combination of 5.B and 5.C in the July 18 draft
• Impact:
• External Reference:
• Testability: Inspection and formal test methods
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

5-C - Voice Terminal Hardware and Software

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

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

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

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

Discussion of Work in Progress: 
* (Peter K) Needs to be reworded. Says do A. If don't have A, then do B. Should change to You must do either A or B or both.

• Status: In Progress
• Text from Telecommunications
• Source: {508}1194.23(a), {255}1193.51(d), this is a combination of 5.D and 5.E in the July 18 draft
• Impact:
• External Reference:
• Testability: Inspection
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

5-D - IVR, Auto-Attendant and Messaging

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

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

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

Rationale:

Discussion of Work in Progress: 
* Telecommunications will provide an advisory note about Baudot and TTY.
* (Peter K) Not clear on the statement "All functions that are accessible to voice users 
            must also be directly accessible to users of real-time text." How to do on a voice prompt menu.
* Need rationale information

• Status: In Progress
• Text from Telecommunications
• Source: {508}1194.23(c), was 5.F in July 18 draft
• Impact:
• External Reference:
• Testability: Inspection (#1,3,4) and Formal test method (#2)
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

5-E - Caller and Status Information

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

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

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

Discussion of Work in Progress: 
* (Peter K) This says that products with visual interfaces that display status 
          info must make the info available for TTYs among others. How do I make 
          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.

• Status: Done
• Text from Telecommunications
• Source: {508}1194.23(e), was 5.G in July 18 draft
• Impact:
• External Reference:
• Testability: Inspection
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

5-F - Video Support

Telecommunications products or systems which have the capacity to transmit video, text, and voice communications must support internet protocol text and voice communications in X format, and they must have sufficient transmission bandwidth capacity to support video communication such as video relay and point to point video communications.

Discussion or Rationale: "X format" remains undefined; comments were received regarding whether this should be applied to 255 in addition to 508.

• Status: In Progress, Proposed update posted October 17, 2007
• Text from Telecommunications
• Source: new, was 5.H in July 18 draft
• Impact:
• External Reference:
• Testability: Formal test methods and inspection; will depend on how "X format" is defined."
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

6. Audio and/or Video Content

6-A - Synchronized Alternatives

Equivalent alternatives for any multimedia presentation must be synchronized with the presentation.

Discussion: Web/Software subcommittee states needs to harmonize with AV input

Discussion of Work in Progress: 
* (Peter K) Should remove provision, contradicts 6.B(1) and 6.C(1). Agreed to by Gregg V and Andrew K.

• Status: Done, Updated: Oct 18, 2007
• Text from Web and Software
• Source: {508}1194.22(c) (was 3.2.A in July 18 draft)
• Impact:
• External Reference:
• Testability: Inspection
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

6-B - Captions and Transcripts

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

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

Discussion of Work in Progress: 
* (Peter K) Note 2 and 3 use the term "concurrent audio" should that be "concurrent spoken audio"

• Status: Done
• Text from A/V
• Source: {508}1194.24(c) (was 6.2.B in July 18 draft)
• Impact:
• External Reference:
• Testability: Inspection
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

6-C - Video Description

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

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

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

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

Version 2: Change #2 and #3:

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

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

Discussion of Work in Progress: 
* Provision is too broad, new version of text offered to correct this.

• Status: Done
• Text from A/V
• Source: {508}1194.24(d) (was 6.2.C in July 18 draft)
• Impact:
• External Reference:
• Testability: Inspection; possibly expert evaluation regarding "informational content"
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

6-D - Open or Closed Captions/Descriptions

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

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

6-E - Interactive Elements

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

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

7. Information, Documentation and Support

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

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

7.1 Product Documentation and Help

7.1-A - Accessible Documentation and Features

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

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

Advisory Note: There is an overlap between general features and features that support accessiblity. Guidance on how to choose what features to document includes:

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

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

7.1-B - Keyboard Shortcuts

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

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

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

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

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

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

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

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

Rationale for Version 3: Clarification

Discussion of Work in Progress
* Still looking for a way to express this provision that will meet the needs 
  of all users (for example allowing for inclusion in either contextual help 
  or consolidated documentation. 
* Still looking for a way to address applications that run on multiple 
  platforms which can result in different shortcuts for the same action.

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

7.1-X - Advisory Notes

Best practices for providing documentation to people with disabilities include:

1. Context-sensitive help

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

2. Text descriptions

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

3. User interface descriptions

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

Discussion of Work in Progress: 
* 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. No conclusion was reached.

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

7.2 Support and E&IT related services

7.2-A - Support Services

Agencies that provide help desk and technical support services must accommodate the communication needs of users with disabilities. These support services must be able to offer information on the basic use of assistive technology, as well as complete and accurate information on how to install and configure assistive technology for optimum performance.

Discussion or Rationale: Reworded to be more specific regarding the type of support.

Question about if it's the accessibility configuration of the product, or the configuration of the AT with the product.

Concerns regarding the phrase "complete and accurate information on how to install and configure assistive technology for optimum performance." Vendors should be giving support information about their own product, not the AT.

Recommendation to make these best practices since it's not possible for vendors to test all of their products with all the possible AT and know how it should all be configured.

We were reminded that this provision applies to the agency and not the product manufactures. It was mostly agreed that this clarification should be added to the provision. Agencies can contract for these services, but are generally the ones doing the first line support.

More research is needed on how section 508 differs from section 255 with regards to this.

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

7.2-X - Advisory Notes

Best practices for providing support to people with disabilities include:

1. Remote assistance

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

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

8. Content Format and Authoring Tools

8.1 If a Content Format

Discussion of Work in Progress: 
* The subcommittee is working on a discussion regarding when compliance is required. 

8.1-A - Non-text Objects

A content format that supports non-text objects must provide an encoding mechanism to associate non-text objects with textual descriptions that a user-agent can display.

Discussion or Rationale

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

8.1-B - Multimedia (Format)

A content format that supports synchronized media must provide an encoding mechanism to include synchronized text of verbal content, and audio descriptions of critical nonverbal activity displayable by a user-agent.

Rationale

Discussion of Work in Progress: 
* Proposal to remove this provision to be worked out
* (Allen H) Need to work with A/V subcommittee to harmonize 

• Status: In Progress
• Text from Web and Software
• Source: new
• Impact:
• External Reference:
• Testability: Inspection
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

8.1-C - Reading Order

A content format that supports 2 dimensional display of information must provide an encoding mechanism to identify the logical linear reading order of the content displayable by a user-agent.

Discussion or Rationale

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

8.1-D - Table Headers

A content format that supports row and column headers in data tables must provide an encoding mechanism to identify row and column headers for data tables displayable by a user-agent.

Discussion or Rationale

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

8.1-E - Complex Table Headers

A content format that supports data tables that have two or more logical levels of row or column headers must provide an encoding mechanism to associate row and column headers with data cells, displayable by a user-agent.

Discussion or Rationale

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

8.1-F - Interactive Elements

A content format that supports interactive elements must provide an encoding mechanism to identify name, operation, and state, of any interactive elements displayable by a user-agent.

Discussion or Rationale

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

8.1-G - Links

A content format that supports links must provide an encoding mechanism to identify link text displayable by a user-agent.

Discussion or Rationale

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

8.1-H - Embedded Comments

A content format that supports embedded comments must provide an encoding mechanism to identify embedded comments and associate those comment locations within the document.

Discussion or Rationale

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

8.1-I - Images of Text

A content format that supports scanned images of text must provide an encoding mechanism to identify text of scanned images of text, displayable by a user-agent. Note, this means allowing for inclusion of the text of a scanned image of text.

Discussion or Rationale

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

8.1-J - Dynamic Information

A content format that supports dynamic presentations, graphs, or other extracted information, must provide an encoding mechanism to include data used for any dynamic presentations, graphs, or other extracted information displayable by a user-agent.

Discussion or Rationale

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

8.1-K - Support for multiple languages

Content formats which support multiple languages must provide a programmatically determinable mechanism to identify both the primary language, and the language of any sections that are in another language from the primary language.

Rationale: Support Section 3 provisions for language.

Discussion of Work in Progress: 
* Still working on wording

• Status: In Progress
• Text from Web and Software
• Source: New
• Impact:
• External Reference:
• Testability: Inspection
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

8.2 Additional requirements for Authoring Tools

8.2-A - Accessible Output

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

Discussion or Rationale:

• Status: Done
• Text from Web and Software
• Source: new
• Impact:
• External Reference: ATAG, ISO 9241.71
• Testability: Inspection
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

8.2-B - Preserve Accessibility Information

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

Discussion or Rationale: Need to write up a rationale that includes an explanation of why "unless the user explicitly indicates otherwise" is necessary, so that the phrase is not lost during later work

• Status: Done
• Text from Web and Software
• Source: new
• Impact:
• External Reference: ATAG, ISO 9241.71
• Testability: Inspection; possibly some expert evaluation
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

8.2-C - Prompts

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

Discussion or Rationale: There are concerns to still be worked out on this.

• Status: In Progress
• Text from Web and Software
• Source: new
• Impact:
• External Reference: ATAG, ISO 9241.71
• Testability: Inspection
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

8.2-D - Evaluation Support

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

Discussion of Work in Progress 
* Further discuss and write up a rationale explaining what is meant 
  by "compatible with..."
* (Sept 3 plenary) need to add more information about repair or remediation.

• Status: In Progress
• Text from Web and Software
• Source: new
• Impact:
• External Reference: 'ATAG, ISO 9241.71'
• Testability: Inspection
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

8.2-E - Accessible Templates

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

• Status: Done
• Text from Web and Software
• Source: new
• Impact:
• External Reference: ATAG, ISO 9241.71
• Testability: Expert evaluation
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types: