EWG:Draft Nov 27

Editorial Working Group > November 27 Draft

This draft is based on discussions at the November 2007 plenary meetings, and was edited during telephone meetings during November, December and the beginning of January.

It has now been superceded by a new version, created for work during the January 7-9 plenary

Related Pages

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

Subpart A

Section 1194.1 Purpose

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

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

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

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

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.

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

Section 1194.2 Application

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

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

Version 4: From Karen P-S

1. Mark entire current draft as applicable to 508

2. Add section for 255

Section 255
Where readily achievable, telecommunications and interconnected VoIP equipment and customer premises equipment must comply with the requirements of (fill in subpart) of this part. Where it is not readily achievable to comply with (fill in subpart'), telecommunications and interconnected VoIP equipment and customer premises equipment must comply with the requirements of (fill in subpart), if readily achievable.

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

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

(b) In development such a process, manufacturers must consider the following factors, as the manufacturer deems appropriate:
(1) Where market research is undertaken, including individuals with disabilities in target populations of such research;
(2) Where product design, testing, pilot demonstrations, and product trials are conducted, including individuals with disabilities in such activities;
(3) Working cooperatively with appropriate disability-related organizations; and
(4) Making reasonable efforts to validate any unproven access solutions through testing with individuals with disabilities or with appropriate disability-related organizations that have established expertise with individuals with disabilities.

Text from: Telecommunications §1193.21 (first paragraph) and Telecommunications §1193.23 (second section). Changes to original text in italics.
Note: there are 3 references to subparts that must be filled in above. The first refers to accessibility provisions and the latter subpart refers to compatibility provisions.

Version 5, addition from Gregg V.

• Prohibited reduction of accessibility, usability and compatibility

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

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

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 from on November plenary: Could not reach consensus
• Text from Subpart A Subcommittee
• Source: {508}1194.2
• Impact:
• External Reference:

Section 1194.3 General Exceptions

1194.3 - A - Intelligence Or Security Systems (Consensed)

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

• Status from on November plenary: Done, have consensus, Dec 4 conference call
• Text from Subpart A Subcommittee
• Source: {508}1194.3(a), no change

1194.3 - NEW - Emergency, Field and First Response Use (Discussed Jan 2, No Quorum, No Final Decision)

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

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

• Impact:

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

• External Reference:

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

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

Notes from Jan 2 conference call
Recommending to not include this exception in the final report.

• Status from on November plenary: Discussed Jan 2, No Quorum, No Final Decision
• Text from Subpart A Subcommittee
• Source: New

1194.3 - B- Incidental To A Contract (Consensed)

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

• Status from on November plenary: Done, have consensus, Dec 4 conference call
• Text from Subpart A Subcommittee
• Source: {508}1194.3(b), no change

1194.3 - C - Employees Not Individuals With Disabilities (Consensed)

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 from on November plenary: Done, have consensus, Dec 4 conference call
• Text from Subpart A Subcommittee
• Source: {508}1194.3(c), no change

1194.3 - D - Access By Public (Consensed)

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

• Status from on November plenary: Done, have consensus, Dec 4 conference call
• Text from Subpart A Subcommittee
• Source: {508}1194.3(d), no change

1194.3 - E - Fundamental Alteration (Discussed Dec 18, No Consensus)

Version 1
Add a second sentence that includes the issues identified as needing clarification for 508.
For E&IT subject to Section 508, fundamental alteration includes altering specified product requirements or business need and technical infeasibility.

Version 2 (Current Provision)
Keep the current wording with minor edits (must for shall) in sentence one.
This part must 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. The only change is in the word "shall" is replaced with "must".

Comments by Karen PS to be consistent with the telecommunications guidelines
Version 2 (Current Provision)
This section as it was originally written can apply to both Section 508 and 255 and it would be a lot simpler to leave as is.

Comments from CSD/Trace Center
No change to language. (Version 2) Also version 2 can be applicable to both section 255 and 508 while version 1 specifies E&IT, which is only section 508.

Comments from Dec 18 conference call
Karen PS: In section 255 there is an introductory paragraph in the preamble on this. Why not keep the entry one sentence and add information to the preamble.
Peter K: The August 17 draft had different language, using "or the agency" instead of "given the agency". Should we go back to that text?
Gregg V: "business need" is not a defined term. Prefers version 1 use the phrase: "This exception would include instances where it is technically impossible to meet a provision without a fundamental alteration to..."

Language proposed by Karen PS, working from TItle II of ADA, 255 and 508 (from email of 3 Jan)
1194.3-E- Undue Burden For E&IT covered by Section 508, this part shall not be construed to require an undue burden in the nature of a product or its components.

(1) Undue burden means significant difficulty or expense. In determining whether an action would result in an undue burden, an agency must consider all agency resources available to the program or component for which the product is being developed, procured, maintained, or used.
(2) Technical infeasibility, if it is substantiated by empirical evidence or documentation, is one factor in determining whether an action would constitute an undue burden.

1194.3-New - Fundamental Alteration (applicable to both Section 255 and 508)
This part must not be construed to require a fundamental alteration in the nature of a product or its components. A fundamental alteration occurs when the accessibility feature would substantially reduce the functionality of the product, materially render some features inoperable, or substantially impede or deter use of the product.

For E&IT subject to Section 508, in order to claim fundamental alteration, an agency must prove that the development, procurement, maintenance or use of the product in question would substantially or materially interfere with the purpose and function for which the product is being developed, procured, maintained or used. The burden of proof as to whether a product would result in a fundamental alteration rests with the manufacturer or agency asserting this claim.

• Status from on November plenary: Discussed on Dec 18 conference call, no consensus reached
• Text from Subpart A Subcommittee
• Source: {508}1194.3(e)

1194.3 - F - Service Areas (Consensus - will send multiple versions)

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 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 the controls or interfaces of such products where they could be executed externally or remotely.

Version 2
Remove the provision entirely.

Version 3, from Peter K and Brad H
Products whose design limits physical access, and which are only accessed for maintenance, repair, or occasional monitoring are not required to comply with this part. This part does apply to the controls or interfaces of such products where they could be executed externally or remotely.

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.

Comments from Dec 18 conference call
Jim T: If use version 1, how would documentation be impacted?
Peter K: Wording became more complex in Sept 3 draft, may want to go back to older version?
Resolved the question of if this was just a reach and touch issue, but is really something that impacts all disabilities
Rex L: Main thrust of Section 508 originally was to get as many people using E&IT by dividing it into two groups, things used by most users vs. things for special use.

Comments from Jan 7 plenary meeting
Agreement reached to send the multiple versions to the Access Board.

• Status from on November plenary: Discussed on Dec 18 conference call, no consensus reached
• Text from Subpart A Subcommittee
• Source: {508}1194.3(f)

1194.3 - NEW - Narrow, Delineated Use (Consensus - no full agreement)

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 (for example: 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.

Comments from CSD/Trace Center
Not accept. (Rationale: Not needed and dangerous. Likely to be abused.)

Comments from Dec 18 conference call
Gregg V: "products with narrow delineated use" is not clearly defined.
Discussion of this exception was handled by both the Subpart A and Closed Products subcommittee. Recommendation that a task force with people from both subcommittees work on rewording of the exception.
Request made to just pass all the information as is to the Access Board.

Comments from Jan 7 plenary meeting
Could not reach agreement, so will send relevant info on this to the Access Board. EWG to determine where in the report it will reside.

• Status from on November plenary: Done, Jan 7 plenary, can not agree, so will provide to Access Board
• Text from Subpart A Subcommittee
• Source: New

1194.3 - NEW – Inherently Visual E&IT Assets (Consensed)

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

i. Weather simulation imagery that presents a moving visualizations of weather systems (required by National Weather Service)

ii. Modeling and simulation results of physical phenomena that provides information (e.g., electronic sensor data transmitted by ocean buoys to illustrate ocean movement - NOAA, modeling and simulation of blast phenomena - DARPA, US Army

iii. Real-time monitoring by systems that simultaneously provide imagery and electronic reports that can be transmitted via web-enabled methodologies to analysts elsewhere (e.g., container inspection or passenger inspection systems used by U.S. Customs Service)

b. We recommend an exception be created to allow these applications to fall in a recognized are of the standard, rather than requiring stretching the application of some other provision.

Comments from Dec 18 conference call
Exception will be removed. Text will be added as an advisory note to the Fundamental Alteration exception.

• Status from on November plenary: Done, have consensus, Dec 4 conference call
• Text from ITAA
• Source: New

Section 1194.4 Definitions

Agency (Consensed)

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

Status from on November plenary: Done, have consensus, Dec 18 conference call
Text from: Subpart A

Application Software (Consensed)

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

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

Status from on November plenary: Done, have consensus, Dec 18 conference call
Text from: Web and Software Subcommittee.

Assistive Technology (Consensed)

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

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

Note: Abbreviated as "AT"

Status from on November plenary: Done, have consensus, Dec 18 conference call
Text from: Subpart A

Authoring Tools (Discussed Jan 2, No Quorum, No Final Decision)

Any software intended to create or modify content for publication. This definition covers authoring tools which are able to create or modify content in a format such that the format supports compliance with the user interface and content provisions.

Notes from Jan 2 conference call
Recommend EWG work to merge the definition and note information. Above definition is an attempt at this from the meeting. Version with additional work below:

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

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

Status from on November plenary: Discussed Jan 2, No Quorum, No Final Decision
Text from: Web and Software

CAPTCHA (Consensed)

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

Note 1: CAPTCHA tests often involve asking the user to type in text that is presented in an obscured image or audio file.
Note 2: A Turing test is any system of tests designed to differentiate a human from a computer. It is named after famed computer scientist Alan Turing. The term was coined by researchers at Carnegie Mellon University.

Status from on November plenary: Done, have consensus, Nov 27 conference call, confirmed Dec 18 conference call
Text from: Web and Software

Captions (Consensed)

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 from on November plenary: Done, have consensus, Dec 18 conference call
Text from: Audio/Visual

Closed Product Functionality (Consensed)

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 from on November plenary: Done, have consensus, Dec 18 conference call
Text from: Self-Contained/Closed

Content (Discussed Jan 2, No Quorum, No Final Decision)

Information and sensory experience to be communicated to the user by means of software, including but not limited to: text, images, sounds, videos, controls and animations, as well as the encoding that defines the structure, presentation, and interactions associated with those elements. For example: word processing files, presentation files, spreadsheet files, text files, portable document files, web based content, etc.

Notes from Jan 2 conference call
Recommend approve definition as modified in the meeting.

Status from on November plenary: Discussed Jan 2, No Quorum, No Final Decision
Text from: Web and Software

Content Format (Discussed Jan 2, No Quorum, No Final Decision)

An encoding mechanism for storing information.

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

Notes from Jan 2 conference call
Recommend approve definition as is.

Status from on November plenary: Discussed Jan 2, No Quorum, No Final Decision
Text from: Web/Software

Contrast Ratio (Discussed Jan 2, No Quorum, No Final Decision)

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

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

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

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

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

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

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

Notes from Jan 2 conference call
Recommend approve definition as is.

Status from on November plenary: Discussed Jan 2, No Quorum, No Final Decision
Text from: Web/Software

Customer Premises Equipment (Consensed)

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

Status from on November plenary: Done, have consensus, Dec 18 conference call
Text from: Telecommunications §1193.3
Source: Telecommunications Act of 1996; FCC Order No. 07-110

Decoration (Discussed Jan 2, No Quorum, No Final Decision)

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.

Notes from Jan 2 conference call
Recommend approve definition as is.

Status from on November plenary: Discussed Jan 2, No Quorum, No Final Decision

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

Comments to be resolved:

• (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
• (CSD/Trace Center) Change "not the principal function" to "not a principal function". And add to end "E&IT that is combined with non-E&IT is covered but the coverage does not extend to the non-E&IT" There are too many compound products that are clearly IT with something added. A computer mounted on the door of a refrigerator should count as a computer – but the refrigerator should not be included.
  • Add "Note: A computer mounted on the door of a refrigerator should count as a computer – but the refrigerator should not be included."

Status from on November plenary: Not discussed
Text from: Subpart A
Source: Clinger-Cohen

Enhanced Audio (Discussed Jan 2, No Quorum, No Final Decision)

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

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

Notes from Jan 2 conference call
Since the provision that uses this is not resolved, not able to consider this definition consensed.

Status from on November plenary: Was "Done, have consensus, Dec 18 conference call" but was raised again in the Jan 2 call, so no longer done.
Text from: General

First Responder (Discussed Jan 2, No Quorum, No Final Decision)

No definition has been provided

• Request definition be added to support new exception.

Notes from Jan 2 conference call
Recommend remove this definition since are recommending to remove the exception.

Status from on November plenary: Discussed Jan 2, No Quorum, No Final Decision
Text from: Subpart A

Free-Standing

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

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

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

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

Functional Equivalent to TV Closed Captions (Discussed Jan 2, No Quorum, No Final Decision)

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

Revision proposed by GV and Larry Goldberg
User-controllable features equivalent to CEA 708 display of caption text that comply with 3.B (Contrast), 3.E (Color Adjustment), and 1.2.J (Text size).

Rationale: The "via AT" aspect moved into the definition probably during the discussion where we trying to make the "functional equivalence" work for TV as well as mobile devices and software media players. But I think it no longer has meaning once the other provisions were refined.

Notes from Jan 2 conference call
Unable to reach any agreement. Recommend definition be discussed at next meeting.

Revision proposed for discussion (Andrew K ++)
Synchronized text displayed on-screen that reflects the audio of a program.

Note: Functionality to provide user-choices for background and foreground color adjustment or contrast, and text size for captions may also be provided, as allowed by the product.

Status from on November plenary: Discussed Jan 2, No Quorum, No Final Decision
Text from Audio/Visual

General Flash and Red Flash Thresholds (Discussed Jan 2, No Quorum, No Final Decision)

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

1. There are more than 3 General Flashes and/or more than 3 Red Flashes within any one-second period; and
2. The flashing is below 50 Hz; and
3. The combined area of flashes occurring concurrently occupies more than a total of 0.006 steradians within any 10 degree visual field on the screen (25% of any 10 degree visual field on the screen) at typical viewing distance, and where:

• a. For software and content: A General Flash is defined as a pair of opposing changes in relative luminance of 10% or more of the maximum relative luminance where the relative luminance of the darker image is below 0.80; and where "a pair of opposing changes" is an increase followed by a decrease, or a decrease followed by an increase, and

• b. For hardware: A General Flash is defined as a pair of opposing changes in luminance of 20 candellas/m2 and where “a pair of opposing changes” is an increase followed by a decrease, or a decrease followed by an increase, and

• c. A Red Flash is defined as any pair of opposing transitions involving a saturated red.

Exception: Flashing that is a fine balanced alternating such as white noise or an alternating checkerboard-like pattern with "squares" smaller than 0.1 degree on a side does not violate the thresholds.

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

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

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

Note 4: For general software, or Web content: Tools are available that will carry out analysis from video screen capture.

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

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

Note 7: To fail, the threshold change in luminance (or relative luminance) must be true for all points within the .006 steradians. (It is not the average value.)

Notes from Jan 2 conference call
Recommend approving definition as is.

After Jan 2 call - Additions for hardware added. Shown in italics to make it easier to read this once, without comparing two very technical versions.

• Status from on November plenary: Discussed Jan 2, No Quorum, No Final Decision

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.

Comment from GV - not used except in phrase "electronic and information technology" which has its own definition. So Information Technology should be dropped from Definitions since it isn't used in any provisions.

Status from on November plenary: Not discussed
Text from: Subpart A

Interactive Elements

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

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

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

Interconnected Voice over Internet Protocol (VoIP) Product (Consensed)

A product that is used to provide interconnected VoIP service

Status from on November plenary: Done, have consensus, Dec 18 conference call
Text from: FCC regulations 47 C.F.R. §9.3

Interconnected Voice over Internet Protocol (VoIP) Service (Consensed)

A service that:

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

Status from on November plenary: Done, have consensus, Dec 18 conference call
Text from: FCC regulations 47 C.F.R. §9.3

Keyboard (Consensed)

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

Status from on November plenary: Done, have consensus, Dec 18 conference call
Text from: Web and Software

Keyboard Interface (Consensed)

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

Status from on November plenary: Done, have consensus, Dec 18 conference call
Text from: Web and Software

Large Scale Text (Consensed)

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 from on November plenary: Done, have consensus, Dec 18 conference call
Text from: Web/Software

Manufacturer

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

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

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

Menu

Set of selectable options.

Comments to be resolved:

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

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

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

Non-text Object (Consensed)

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

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

Status from on November plenary: Done, have consensus, Dec 18 conference call
Text from: Web/Software

Other Services To Cooperate With Assistive Technologies (Consensed)

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

Status from on November plenary: Done, have consensus, Dec 18 conference call
Text from: Web and Software

Peak Non-crisis Network Traffic (Consensed)

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

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

Status from on November plenary: Done, have consensus, Dec 18 conference call
Text from: Telecommunications

Peripheral Devices

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

• Requested this definition be added to support Section 255.

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

Platform Accessibility Services (Consensed)

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

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

Status from on November plenary: Done, have consensus, Dec 18 conference call
Text from: Web/Software

Platform Software (Consensed)

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

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

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

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

Status from on November plenary: Done, have consensus, Dec 18 conference call
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.

Comments to be resolved:

• The term used in the provisions is "programatically determinable"
• EWG note: actually "determined" is used twice, "determinable" is used once in 3-P - User Interface Components.
• GV: This definition is currently ambiguous and will lead to endless discussion as to whether it means users can use AT to access software or not. Suggest a note be added to make it clear what the Committee’s intention is. There are two positions that I know of for the note. If there are more they should be added before discussion. But they should be clearly worded and un-ambiguous as to the meaning. Up to now we have gotten agreement by wording things so that everyone was interpreting it differently. Which is not agreement since the final language can't be such that it is not unambiguous or else many of our provisions are untestable. We need to add either note 1 or note 2 depending on the consensus of the group.
  • Version 1 of the note: Programmatically determinable means that information about the product's user interface can be determined by existing assistive technologies (that is, AT generally available to users).
  • Version 2 of the note: Note: Programmatically determinable means that it can be determined through a software interface. It does not require that this interface be in use by any assistive technology (AT) generally available to users. An API that exposes information is sufficient in itself to meet this provision even if AT does not currently work with it.

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

Readily Achievable (Consensed)

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

Status from on November plenary: Done, have consensus, Dec 18 conference call
Text from: Telecommunications §1193.3 (no change)
Source: Telecommunications Act of 1996

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.

Comments to be resolved:

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

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

Relative Luminance

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 1. The "^" character is the exponentiation operator. (Formula taken from [sRGB] and [IEC-4WD]).
2. Almost all systems used today to view Web content assume sRGB encoding. Unless it is known that another color space will be used to process and display the content, authors should evaluate using sRGB colorspace.
3. For dithered colors, use average values of the colors used (average R, average G, and average B).
4. Tools are available that automatically do the calculations when testing contrast and flash.
5. A MathML version of the relative luminance definition is available.

Comment Phrase "If using other color spaces, see Understanding Success Criterion 1.4.3." removed from Note 2, as this is a WCAG reference.

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

Specialized Customer Premises Equipment (Consensed)

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

Status from on November plenary: Done, have consensus, Dec 18 conference call
Text from: Telecommunications §1193.3; FCC Order No. 07-110

Synchronized Media (Consensed)

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

Status from on November plenary: Done, have consensus, Dec 18 conference call
Text from: A/V

Telecommunications (Consensed)

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 from on November plenary: Done, have consensus, Dec 18 conference call
Text from: Telecommunications
Source: Telecommunications Act of 1996

Telecommunications Equipment (Consensed)

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

Status from on November plenary: Done, have consensus, Dec 18 conference call
Text from: Telecommunications §1193.3 (no change)
Source: Telecommunications Act of 1996

Telecommunications Service (Consensed)

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

Status from on November plenary: Done, have consensus, Dec 18 conference call
Text from: Telecommunications §1193.3 (no change)
Source: Telecommunications Act of 1996

Terminal (Discussed Jan 2, No Quorum, No Final Decision)

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.

Notes from Jan 2 conference call
Recommend approve definition as is.

Status from on November plenary: Discussed Jan 2, No Quorum, No Final Decision
Text from: Telecommunications

TTY (Consensed)

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 from on November plenary: Done, have consensus, Dec 18 conference call
Text from: Telecommunications

Unavailable Items (Consensed)

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

Status from on November plenary: Done, have consensus, Dec 18 conference call
Text from: Web and Software, listed in provision 3-D User Preferences

Undue Burden (Consensed)

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

Status from on November plenary: Done, have consensus, Dec 18 conference call
Text from: Subpart A (no change)

Usable (Consensed)

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

Status from on November plenary: Done, have consensus, Dec 18 conference call
Source: Telecommunications §1193.3 (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 from on November plenary: Not discussed
Text from: Audio-Video
External Reference: Guidelines (draft) from the Described and Captioned Media Program (U.S. Department of Education)

Section 1194.5 Equivalent Facilitation

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

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

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

Subpart B

Comments to be resolved:

Comments from ITAA
The current recommendation document proposes a complete re-work of the current Accessibility Standards format and layout. At present, we have six years of contracted efforts which have recorded operative regulatory guidance under the current format. The proposed organization of technical and performance requirements will result in a massive bottleneck of applicable Standards under the old format, and applicable Standards under a new organizational format. Any recommended input to the Access Board should also proposed how any new technical and performance criteria will be mapped to the previous requirement.

We feel the FAR is not the place for such technical and performance requirements transition since the FAR only addresses the procurement process itself.

1. Requirements for All Product and Services

1.1 Functional Performance Criteria

Version 1, based on draft created by ATIA/ITI Joint Recommendation

The purpose of the Functional Performance Criteria is to provide guidance to help Federal departments or agencies determine whether products being used, developed, procured or maintained meet the functional needs of individuals with disabilities. The Functional Performance Criteria can also be used to help departments and agencies identify and report product functions that may not meet the Functional Performance Criteria and evaluate the importance of the lack of access to those functions relative to the intended use of the product.

Version 2 from the General Subcommittee
The functional performance criteria have three roles:
1. If any of the technical provisions are not met, the Functional Performance Criteria must be used to see if access is provided in another way (i.e. through equivalent facilitation).
2. If the technical provisions are met, the Functional Performance Criteria must be used to see if the technical provisions cover all aspects needed to provide access to the product. (i.e overall evaluation)
3. The Functional Performance Criteria can be used to help identify and report functions (of a partially conforming product) that would not meet the Functional Performance Criteria (and would therefore not work with employees and/or public users with disabilities) so that agency can evaluate the importance of lack of access to those functions to the intended use of the product.

• Status from on November plenary: Could not reach consensus

1.1-A - Without Vision

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

Comments to be resolved:

Comments from CSD/Trace Center
Change 1.1A to "without requiring user vision" [to address ITAA comment]

• Status from on November plenary: Not discussed
• Text from General
• Source: {508}1194.31(a), {255}1193.41
• Impact:
• External Reference:
• Testability: Expert evaluation
• Metadata
  • Disabilities: Blindness
  • User Activities: All
  • Product Characteristics: All
  • Product Types: All

1.1-B - With Limited Vision

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

Comments to be resolved:

Comments from CSD/Trace Center
Change 1.1B to "without requiring visual acuity better than 20/70 and without relying on audio output."
Rationale: If audio is not eliminated as a solution – then 1.1B is always satisfied by 1.1A. 20/70 is used instead of the 20/200 to harmonize 508 and 255.

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

1.1-C - With Color Vision Deficits

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

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

Comments to be resolved:

Comments from Sun
This language is not testable, and in fact doesn't map well to existing technical standards (see the text in 3-A – Color, which states things much more clearly, and also 3-B - Contrast). So long as the Functional Performance Criteria aren't considered testable, this language isn't a large problem; but still this is already much better stated in 3-A and 3-B, and it would be better to eliminate this provision.

• Status from on November plenary: Not discussed
• Text from General
• Source: {255}1193.41(c)
• Impact:
• External Reference:
• Testability: Expert evaluation
• Metadata
  • Disabilities: Color deficiency/Colorblindness
  • User Activities: All
  • Product Characteristics: All
  • Product Types: All

1.1-D - Without Hearing

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

Comments to be resolved:

Comments from CSD/Trace Center
Change 1.1D to "without requiring user hearing" [to address ITAA comment]

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

1.1-E - With Limited Hearing

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

Comments to be resolved:

Additional text from the telecommunications guidelines proposed by Karen Peltz Strauss
This subpart requires the provision of auditory feedback that is important for use of the product through at least one mode in enhanced auditory fashion such as increased amplification, increased signal-to-noise ratio or a combination.

Comment from ITI/Sun
The text refers to “enhanced audio” without defining it. We should not make such a reference without providing a definition.

Comments from ITAA
Proposed new wording for consistency. “Products must provide a mode that allows access with enhance audio, if audio information is required for access. This access may be provided directly or through assistive technology."

Comments from CSD/Trace Center
Add note to 1.1E to "Audio can be enhanced by providing increased volume or removal of background music or sounds." [to address ITAA, ITI and Sun comment]

Comment from Sun
Propose the definition of "Enhanced Audio": Audio which has been enhanced through amplification and/or through a variety of audio filters to make it easier for people with hearing impairments to understand.

• Status from on November plenary: Not discussed
• Text from General
• Source: {508}1194.31(d), {255}1193.41(b), and {255}1193.43(e)
• Impact:
• External Reference:
• Testability: Expert evaluation
• Metadata
  • Disabilities: Hard of hearing,
  • User Activities: All
  • Product Characteristics: All
  • Product Types: All

1.1-NEW - With Low Vision and Limited or No Hearing

New provision proposed by Karen PS, October 24, 2007
Products must provide at least one mode that permits operation by users with visual acuity between 20/70 and 20/200, without relying on audio output

Text from: Telecommunications §1193.41 (b) (no change)

• Status from on November plenary: Not discussed

1.1-F - Without Speech

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

Comments to be resolved:

Comments from CSD/Trace Center
Change 1.1F to "…without requiring user speech" [to address ITAA comment]

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

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

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

Comments to be resolved:

Addition from telecommunications guidelines proposed by Karen PS
Products must provide at least one mode that allows access for people with limited reach and strength, that does not require user fine motor control, and that does not require simultaneous actions.

Rationale: This draft adds the phrase "that does not require fine motor control" as well as reflecting the general recommendation to remove the phrase about AT.

Source: §1193.41(e)

Comment from ITI
This text is completely redundant with the technical provision 2.1-D (2). This duplication is unnecessary and adds to the burden of meeting 508 with no benefit. This should be removed.

Comments from ITAA
Reword for consistency. “Allows access without requiring more than limited reach and strength, and without requiring simultaneous actions.”

Comment from Japan/Hajime
Previous functional performance criteria include the following:

"At least one mode of operation and information retrieval that does not require fine motor control or simultaneous actions and that is operable with limited reach and strength must be provided."

In section 1.1-G (With Limited Reach, Strength, or Manipulation), we could only find the functional performance criteria relating to the clause " does not require simultaneous actions" and could not find anything relating to the clause "does not require fine motor control." Do we miss it in the new draft?

Comments from CSD/Trace Center
Change 1.1-G. to "…Products must provide at least one mode that allows access for people with limited reach and strength, and that does not require user fine motor control or simultaneous actions. [to address Japan and Karen P-S comment. Also somewhat ITI]

• Status from on November plenary: Not discussed
• Text from General
• Source: {508}1194.31(f); {255}1193.41(e), (f)
• Impact:
• External Reference:
• Testability: Expert evaluation
• Metadata
  • Disabilities: Dexterity, Mobility
  • User Activities: All
  • Product Characteristics: All
  • Product Types: All

1.1-H - Without Physical Contact

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

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

Explanatory Notes
1. Use of cameras to monitor user movement to control input would meet this provision.
2. Allowing users to control the product using their own communication or control via a universal wireless connection would also meet this provision.

• a. ANSI/INCITS URC standard would be one
• b. Wireless USB would be another solution

3. A connection is allowed since it may be necessary. Individuals could have a companion or bystander connect them and still allow them privacy in completing the transaction. Methods not requiring any contact or assistance of course are preferred.

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

Version 2, proposed by Paul S:
Products with a visual interface must provide at least one mode that allows the product to be accessible for people with disabilities with only minimal physical contact with the product such as power-on, initialization of a call, change of a mode of operation, or initial connection and setup of a special interface device. This access may be provided directly or through assistive technology.

Rationale and Notes
1. It is well known that a large population of people with physical disabilities cannot reach out to touch a product or cannot reach out long enough to actually operate a product physically.
2. While it is preferable that no contact at all be required, some physical contact may be needed to turn power on, initialize a telephone call or change mode of operation. In some cases it may be required for the user to be assisted by a companion or bystander with these operations.
3. Assistive Technology examples:

• The use of a standard network interface (e.g. USB, Ethernet, IEEE 1394, Wi-Fi, Bluetooth, etc.) that allows users to control the product using software via a wired or wireless network connection would meet this provision.
• The use of the infra-red (“IR”) port used for remote controls in consumer electronics products would meet this provision.

4. Direct Access examples:

• Voice dialing is an example of direct access. Access to voice dialing may require physical contact with the product to initiate the call or change mode of operation to enable voice dialing.

Comments to be resolved:

Comments from ITI
Products not meeting the no-touch through AT portion of the provision can claim the exception for "closed products". There is an inescapable logical loop rendering this proposed provision completely ineffective. The proposed provision should be removed because, in addition to the logical loop problem, no-touch access through AT is already served by the limited mobility functional standard (1.1-G) as well as many of the technical standards.

Comment from Paul Schomburg
I think this provision as drafted is confusing, incomplete and requires more in-depth discussion. My primary concern is that the existence of a network interface by itself does not provide access to “all the features of the product” and thus by itself cannot assure accessibility. With regard to the specific solutions sited by Greg Vanderheiden, I don’t know of any commercial off-the-shelf product that is compatible with the ANSI/INCITS URC standard and thus doubt it is a practical solution at this time. I also don’t believe that the “use of cameras to monitor user movement to control input would meet this provision” since such a method of control is not a product feature a manufacturer could incorporate into the product itself.

Rather than apply this to all E&IT products, these requirements should only be applied to products with a visual interface that could be accessed from across a network. I would need further explanations or examples for how E&IT products without a visual interface could comply to be comfortable with applying this to all E&IT products. To be proactive here are some suggestions for a new version, but there may be other parties that also need to weigh in with their views:

Comments from CSD/Trace Center
If there is concern here – then perhaps an 'at risk' note could be used to say that it would be removed if certain things were not true by the time the rules were promulgated.

• Status from on November plenary: Not discussed
• Text from General
• Source: new
• Impact:
• External Reference:
• Testability: Expert evaluation
• Metadata
  • Disabilities: Dexterity, Mobility
  • User Activities: All
  • Product Characteristics: All
  • Product Types: All

1.1-I - With Cognitive, Language or Learning Limitations

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

Comments to be resolved:

Update proposed by Karen PS
Products must provide at least one mode that accommodates cognitive, language, memory or learning impairments, directly or with assistive technology.

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

Comment from ITI
While ITI appreciates the sincere interest and desire of many to address cognitive disabilities within Section 508, we believe that doing so would present a number of serious challenges for manufacturers and government agencies, including:

• A lack of technical provisions relevant to cognitive disorders
• A lack of differentiation of various types of cognitive disorders, and
• A lack of clear distinction of when the needs for those with cognitive disorders are met.

If we are still struggling with even understanding what this should be at this time, then we likely don't have enough time to finish it. Accordingly, we recommend removal of this provision.

Comment from Sun
We included our comments in the ITI report for this provision, but feel strongly that this item needs resolution. If we are still struggling with even understanding what this should be at this time, then we likely don't have enough time to finish it. The current provision text is written as a general goal, and Sun supports including "should" language for this provision at this point, if it is stated in the context of a goal for the technical provisions.

Comments from ITAA

• This requirement is overly broad. Anyone can claim conformance.
• This theoretical mode of operation is not testable as described, even by "Expert Evaluation". There are no thresholds described, e.g., grade level reading.
• What are the criteria for satisfying this mode.
• Until there are thresholds defined, we prefer this provision not be included.

Other Comments

• 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 AT with the necessary information to provide these functions.

Comments from CSD/Trace Center
Use language proposed by Karen PS from 255

• Status from on November plenary: Not discussed
• 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

Subpart C

Technical Provisions

It was agreed in the November plenary that the Functional Performance Criteria would be moved out of the technical provisions section. It is yet to be determined if they should be before or after subpart C which is the technical provisions.

EWG note: We did not renumber all provisions to reflect the removal of section 1.1. This will be done in the next version.

Comments to be resolved:

Proposed introduction to distinguish between Section 255 and Section 508 by Karen PS
For the purposes of Section 255, each manufacturer of a product that is used to provide telecommunications or interconnected VoIP service must ensure that such products are designed, developed and fabricated to incorporate the access features described in the functional performance and technical criteria contained in this part, if readily achievable. Whenever it is not readily achievable to incorporate such access features directly into the products, the manufacturer must ensure that the products are compatible with existing peripheral devices or specialized customer premises equipment commonly used by individuals with disabilities to achieve access, if readily achievable.

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

Source: FCC Regulations 47 C.F.R. §§6.5; 7.5

Comments from CSD/Trace Center
Adopt Karen P-S additions for 255 and 508 addition. This includes removing the "directly or via AT sentence" and moving that to the intro saying that either method is appropriate but that there are differences in how they are applied for the two regulations.

1.2 General Technical Requirements

1.2-A - Closed Functionality (Consensed)

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

• 2.1-E - Connector or Connection Language
• 3-F - All Non-Text Objects
• 3-G - Human Language
• 3-H - Language of Parts
• 3-N - Link Purpose
• 3-O - Information and Relationships
• 3-P - User Interface Components
• 3-U - AT Interoperability
• 3-W - Accessibility Services

Rationale:

• Status from on November plenary: Done, have consensus
• Text from Self Contained, Closed
• Source: {508}1194.25(a) (was 1.2-C in Oct 26 draft)
• Impact:
• External Reference:
• Testability: Expert evaluation
• Metadata
  • Disabilities: All
  • User Activities: All
  • Product Characteristics: All
  • Product Types: All

1.2-B - Biometric ID (Consensed)

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

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

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

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

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

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

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

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

• Status from on November plenary: Done, have consensus
• Text from: General
• Source: {508}1194.25(d), {508}1194.26(c) (was 1.2-D in Oct 26 draft)
• Impact:
• External Reference:
• Testability: Inspection
• Metadata
  • Disabilities: All (that could be caused by loss body part or function)
  • User Activities: All
  • Product Characteristics: All
  • Product Types: All

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

Notes from November plenary:
Consensus reached on paragraphs 2 and 3.

No consensus on paragraph 1.

Rationale:

• Status from on November plenary: Could not reach consensus
• Text from Telecommunications
• Source: {508}1194.23(j), {255}1193.37 (was 1.2-E in Oct 26 draft)
• Impact:
• External Reference:
• Testability: Inspection
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

1.2-D - Audio information

Products must provide a mode in which audio is not used as the only means of conveying information, indicating an action, or prompting a response. Section 255 and Section 508 treat AT solutions differently, so review section XX of this document before implementing a solution.

Notes from November plenary meeting:
Need to resolve the issue of removing "either directly or via assitive technology"

Proposal to move this and 1.2-G Visual Information to the FPC section and then deal with "directly or via AT" there.

Proposal to add "for the purpose of 508 can be done directly or via AT, for the purpose of 255, must be done directly."

Request to have the Access Board legal staff review this.

Do not have agreement on the second sentence.

There were three versions of this provision created at the November plenary. See the November plenary page for all versions.

• Status from on November plenary: Could not reach consensus
• Text from Self-Contained/Closed
• Source: {255}1194.43(d) (was 1.2-F in Oct 26 draft)
• 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-E - Visual Information

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

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

• Status from on November plenary: Could not reach consensus
• Text from Self-Contained/Closed
• Source: {255}1194.43(a) (was 1.2-G in Oct 26 draft)
• 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-F - Color (Consensed)

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

Note: This provision is harmonized with 3.A

Rationale:

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

1.2-G - 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."

Notes from November plenary:
Subgroup to work on text.

• Status from on November plenary: Could not reach consensus
• Text from Self-Contained/Closed
• Source: {255}1193.43(b) (was 1.2-I in Oct 26 draft)
• 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 - Reflectance Contrast for Legends and Passive Displays (Consensed)

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

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

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

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

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

Rationale:

• Status from on November plenary: Done, have consensus, Dec 4 conference call (was 2.1-B in Oct 26 draft)
• Text from Hardware
• Source: {508}1194.21(j) & .25(h)
• Impact:
• External Reference:
• Testability: Formal test method
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

2.1-B - Flashing

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

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

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

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

Version 2 (new proposed language to address comments, 4 Jan)
Products must not flash more than 3 times in any one second period, unless:

• Flashing created by software or content meets provision 3-J Flashing
• For flashing created by hardware, the flashing element along with reflected flash from adjoining surfaces of the product is be below the general flash and red flash thresholds.

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

Comments to be resolved:

Comments from Gregg V

• We are still working on the Hardware flash definitions for
  • screen flicker (not content)
  • indicators and visual alerts
• Impact should say: "Negative cost - The change saves money (e.g. special circuitry not needed to control frequency of status LEDs) and provides additional flexibility to industry for non-critical stimuli."
• Possible advisory note: "NOTE: Screen flicker of 60hz is safe for most (85%) but refresh frequencies of 75hz or greater are recommended where possible."

Comments from ITAA
a. If it is possible that a computer with a small, dim monitor pass, and a computer with a large, bright monitor fail, which product does not comply? The computer, the software, the content, or the monitor?

b. "Under the general flash and red flash threshold" means “less than some thresholds expressed elsewhere?” Reference?

Replies to ITAA from Gregg V
a. There currently is no provision dealing with monitors. Only the provisions for software and Web have been completed. The Display Provision is still being worked on by a subcommittee of hardware subcommittee (consisting of Rob N, Tom A and Gregg V).

REGARDING THE 'SOFTWARE/CONTENT/MONITOR question: Any of the three could fail. The Monitor; if it flickers itself with no content being displayed (the monitor is not responsible for what is displayed on it). The software or content could fail if they generate images that flash in a way that violates either flash threshold. For content it is a function of the content not the brightness of the display - so failures by software or content are independent of the display.

b. "General Flash and Red Flash Threshold" are defined in the Definition section. (Suggestion: all defined terms should be marked when they are used, or linked to the definition, so they can be easily identified.)

Notes from Jan 2 conference call
This provision was on the agenda, but was not discussed since there is a group of people still working on it. (Update now posted as Version 2 above)

• Status from on November plenary: Not discussed (was 2.1-C in Oct 26 draft)
• Text from (General transfer to Hardware and Web/Software)
• Source: {508}1194.21(k) 1194.22(j) 1194.25(i), and {255}1193.43(f)
• Impact:
• External Reference:
• Testability: Inspection
• Metadata
  • Disabilities: All
  • User Activities: All
  • Product Characteristics: All
  • Product Types: All

2.1-C - Mechanical Controls (Consensed)

All mechanically operated controls and keys:

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

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

• Status from on November plenary: Done, have consensus, Dec 4 conference call (was 2.1-D in Oct 26 draft)
• 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 (Discussed Dec 4, No Consensus)

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. At least one functionally equivalent alternative means of operation must not require vision. Likewise, at least one functionally equivalent alternative means of operation must not require fine motor control.

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

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

Notes from Dec 4 plenary call:

• Request to remove note could not be agreed on.
• Question regarding if could add AT to meet this. This is being reviewed with Randy M.

• Status from on November plenary: Discussed on Dec 4 plenary call, no consensus reached (was 2.1-E in Oct 26 draft)
• 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 - Standard User Interface Connection (Consensed)

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

• Status from on November plenary: Done, have consensus, Dec 4 conference call (was 2.1-F in Oct 26 draft)
• 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 (Consensed)

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

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 from on November plenary: Done, have consensus, Dec 4 conference call (was 2.1-G in Oct 26 draft)
• Text from Hardware
• Source: {508} 1194.25(j), {255}1193.41(f)
• 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

Comments to be resolved:

Comment from Phil J
An editorial comment - that the text in the 2.2 provisions A through F do not match the title - 'audio output' vs 'speech output'. Because of the mismatch, one can think it applies to all audio output, but apparently the title is correct and its the provisions A through F that need editing to make it clearer. All the 2.2 provisions A through F say "audio output", except 2.2-E uses "incoming voice signals", and 2.2-D explicitly uses both: "Product Characteristics: Sound output – speech, Sound output (other than speech)" So the text needs to be tightened up in the next editorial pass to avoid the confusion.

Comments from CSD/Trace Center
For all of the provisions in this section ensure that provisions refer specifically to speech rather than "auditory output beyond simple tonal feedback or signaling,". Specifically

• 2.2A - "Products that deliver [speech] output with an audio transducer that is normally held up to the ear …"
• 2.2B - "Products that deliver [speech] output with an audio transducer that is normally held up to the ear.
• 2.2C - "When products that provide speech output or throughput, ….
• 2.2D - "When products that provide speech output,
• 2.2E - OK as is
• 2.2F - OK as is.

2.2-A - Magnetic Coupling (Consensed)

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 of such hearing technology to effectively utilize the product. This does not apply to headphone, headset, or other accessories that plug into a jack on the product.

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

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

Rationale:

• Status from on November plenary: Done, have consensus, Dec 4 conference call
• Text from Hardware and Telecommunications
• Source: {508}1194.23(h), {255}1193.43(i)
• Impact:
• External Reference: ANSI C63.19 (2007), TIA-1083
• Testability: Formal test method
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

2.2-B - Interference with Hearing Device (Discussed Dec 4, No Consensus)

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

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

Notes from Dec 4 plenary call:

• Could not agree if the phrase “the lowest possible level that allows" should be replaced with "a level low enough to allow".

• Status from on November plenary: Discussed on Dec 4 plenary call, no consensus reached
• Text from Hardware and Telecommunications
• Source: {508}1194.23(i), {255}1193.43(h)
• Impact: minimal
• External Reference: (Need exact title/number of existing standards for reference)
• Testability: Formal test method
• Metadata
  • Disabilities: Hearing, Hard of Hearing
  • User Activities:
  • Product Characteristics:
  • Product Types:

2.2-C - Audio Connection (Discussed Jan 2, No Quorum, No Final Decision)

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

1. Conforming Handset: Auditory output is available via audio transducer that is designed to be held up to the ear that meets 2.2-A (Magnetic Coupling), 2.2-B (Interference with Hearing Device), and 2.2-E (Volume - gain) and product does not require simultaneous use of keyboard; or
2. Phone Jack: A standard 2.5mm or 3.5mm audio jack for headphones/headsets is provided or
3. Any Connection with Adapter avail: Product is a not designed to be located in a public location and an adapter from the product's audio output format to a 2.5mm or 3.5mm phone jack is commonly available or available from the manufacturer.
4. Public Display only: Product is designed for public audio or audio-video display only and there is a standard audio output on the product-system (which can be but does not need to be accessible to the public).

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

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

Rationale submitted with this version

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

How it would apply

• Public phones would use (a - Conforming Handset)
• Office phones would likely use (c – Any Connection with Adapter Avail) but could use (b – Phone Jack)
• Computers with build in speech conversation could use (b – Phone Jack) which most have already or (c – Any Connection with Adapter Avail) including Bluetooth.
• Kiosks without keyboards could use (a - Conforming Handset) or (b – Phone Jack) or both.
• Kiosks WITH keyboards would have to use (b – Phone Jack) or, of course, both (a - Conforming Handset) and (b – Phone Jack)
• Television sets would use (c – Any Connection with Adapter Avail) or (d - Public Display Only)
• Public address systems and Custom Designed public Video Displays would use (d – Public Display Only) which only requires an audio connection they will already have.

Comments to be resolved:

Comments from "Work In Progress" List
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).

Comments from ITAA
a. This provision needs to clarify if a headphone jack is required for cell (and other) phones.

b. This provision needs to clarify if a headphone jack is required even if no "information" is provided by audio output (muzak).

Comments from CSD/Trace Center

1. Use new version from Gregg V (in UPDATES) with edits to address other's issues.
2. Make revision above to limit to devices that output speech to address "Musak" issue identified by ITAA:
3. RE ITAA question: Cell phones should be required to include headphone jack directly or via adapter but current language (crafted to remove requirement for public pay phones) also removed existing requirement for headphone jack from cell phones. To address this
   • Add the following to the front of the first bullet: "Product is designed for public use and"
4. To address Karen PS concern about need for private listening
   • Add the following to the end of the Second bullet: "that allows for private listening"
   • Add the following to the end of the Second bullet: "and that allows for private listening"

Notes from Jan 2 conference call - Latest version from Gregg V
When products provide information via auditory output beyond simple tonal feedback or signaling, one of the following must be true:

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

2. Phone Jack: A standard 2.5mm or 3.5mm audio jack for headphones/headsets is provided or

3. Hardwire Adapter: Product is not designed to be located in a public location and a hardwire adapter from the product's audio output format to a 2.5mm or 3.5mm phone jack is commonly available or available from the manufacturer.

4. Wireless Adapter: A wireless adapter is commonly available or available from the manufacturer that provides a standard 2.5mm or 3.5mm audio jack and has similar size and battery life performance to the product and the user has the ability to pair without assistance.

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

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

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

Rationale

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

How it would apply

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

• Status from on November plenary: Discussed Jan 2, No Quorum, No Final Decision
• Text from Hardware
• Source: {508} 1194.25(e); {255}1193.51(b), {255}1193.43(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 (Discussed Jan 7,No Consensus)

Version 1
All products with speech output must meet the following provisions regarding volume:

1. For products use in public places where the background noise level is not controlled to less than 50 dBA SPL RMS, the maximum volume level must be at least 80 dB SPL RMS measured at a typical listening position.
2. For products not for use in public places or where the background noise level of the public place is controlled to less than 50 dBA SPL RMS, the maximum volume of the product must be at least 65 dB SPL RMS.
3. All products must have less than 12 dB symmetrical clipping at all volume levels including maximum volume level.
4. Volume on audio jacks must be adjustable.

Note 1: It is recommended that volume levels be adjustable by users where products are used by single individuals.

Note 2: Signal contouring and AGC are not considered to be clipping.

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

Version 2, proposed by Gregg V
All products with speech output must meet the following provisions regarding volume:

1. Adjustable to a maximum volume level must be at least 80 dB SPL RMS measured at a typical listening position.
2. All products must have less than 12 dB symmetrical clipping at all volume levels including maximum volume level.
3. Volume on audio jacks must be adjustable.

The notes would be the same.

Version 3, proposed by Paul M and Diane G
All products with speech output must meet the following provisions regarding volume as measured using a 2K Hz reference signal:

1) Products to be used by the public must be capable of a volume level of at least 80 dB SPL RMS measured at a typical listener position.

2) All products must have less than 12 dB symmetrical clipping at all volume levels including maximum volume level.

3) Volume output on audio jacks must be adjustable.

Notes from Jan 2 conference call
Provision text updated to reflect discussions. Recommend approval.

Notes from Jan 7 conference call
Added version 2
Discussions are going to continue on this provision.

• Status from on November plenary: Discussed Jan 2, No Quorum, No Final Decision
• 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) (Concensed)

For incoming voice signals:

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

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

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

Note 1: The provision of volume control gain is not particularly related to whether the voice communication is carried by an analog signal, digital encoding, packet technology (e.g., VoIP), etc. It does, however, depend on the power available to the amplifier providing the gain function. This distinction has been taken into account in specifying the volume control gain requirements. For example the requirements for a battery-powered cordless telephone applies whether the product uses analog, digital or VoIP technology.

Note 2: FCC regulation §68.317 requires both analog and digital telephones to provide between 12 and 18 dB of gain at the maximum volume control setting relative to their volume at the normal unamplified level. The gain is allowed to exceed 18 dB if it is automatically reset to the nominal level when the telephone goes back on hook. [The FCC also has a procedure described in Memorandum Opinion and Order DA 01-578 for waiving the automatic reset requirement for telephones specifically designed for use by hard of hearing persons, provided adequate warnings are placed on the telephone.] In addition, the volume at the normal unamplified level has to meet requirements specified in industry standards ANSI/EIA-470-A-1987 (for analog telephones) and ANSI/EIA/TIA-571-1991 (for digital telephones).

Note 3: FCC regulation §68.317 makes reference to older industry standards in specifying how to measure the receive acoustic loudness and determine compliance with requirements for both gain and loudness at the normal unamplified level. Clause 15.2 of TIA TSB-31-C, Telecommunications – Telephone Terminal Equipment – Rationale and Measurement Guidelines for U.S. Network Protection, provides guidance on how to apply these requirements to test methods specified in current standards, including measurement procedures for analog, digital, and VoIP telephones.

Note 4: Other products or systems that provide a voice communication function, including products and systems that do not have an audio transducer that is normally held to the ear, such as speakerphones, should provide at least 15 dB of volume control range above the normal unamplified listening level. In these cases of speakerphones, it is desirable for the volume control to provide at least 15 dB of gain above the normal unamplified level, but there is no agreed upon specification as to what constitutes the normal unamplified level.

Note 5: Volume (gain) on cellular and PCS handsets is currently the focus of review and study in Working Group 11 of the ATIS Incubator program which is expected to be available no later than June 2008. It is recommended that no recommendation be made at this time by the TEITAC, but rather, the recommendations from the study can be given to the Access Board.

Notes from Jan 7 conference call
EWG to resolve the phrase "normally held to the ear". This phrase is also used in other provisions.

• Status from on November plenary: Done, have consensus, Jan 7 plenary meeting
• Text from Telecommunications
• Source: {508}1194.23(f), {255}1193.43(e)
• 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 (Consensed)

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

Rationale:

• Status from on November plenary: Done, have consensus, Dec 4 conference call
• Text from Telecommunications
• Source: {508}1194.23(g)
• Impact:
• External Reference:
• Testability: Inspection
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

3. User Interface and Electronic Content Provisions

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

Comments to be resolved:

Comment from ITI
The provisions of this section are not appropriate for hardware user interfaces. Most were contained in the original Section 508 technical standards under 1194.21 (Software and Operating Systems), 1194.22 (Web-based Intranet and Internet Information and Applications) or in the Web Content Accessibility Guidelines (WCAG) 2.0. These requirements were designed for web and software, not hardware displays. These provisions are especially of concern for handheld E&IT and closed products that by definition are unable to meet the AT compatibility provisions.

3-A - Color (Consensed)

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

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

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

• Status from on November plenary: Done, have consensus, Nov 27 conference call
• Text from Web and Software
• Source: {508}1194.21 (i), 1194.22(c) and 1194.25(h), {255}1193.41(c)
• Impact:
  • Minimal
  • Currently the Section 508 software provision on color is equivalent to this one so no impact for software. 255 also has an equivalent provision so there is no impact to telecom products. The Web provision allows for the color to be programmatically determinable so there is a slight impact there.
  • Beneficial for people who are color blind which is a large portion of the population.
• External Reference: Harmonized with WCAG 2.0 and ISO 9241-171
• Testability: Expert evaluation
• Metadata
  • Disabilities: Color deficiency/Colorblindness
  • User Activities: All
  • Product Characteristics: Uses Color (on buttons, labels, displays, indicators, anywhere etc.)
  • Product Types: Software (installed or through browser); Network Interface to devices; Desktop Computer Systems; Portable Computer Systems

3-B - Contrast (Consensed)

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

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

Note: There is disagreement about the impact. GV suggests that with tools available, this should not be considered Significant

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

3-C - Size, shape, location (Consensed)

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

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

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

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

• Status from on November plenary: Done, have consensus, Nov 27 conference call
• Text from Web and Software
• Source: new
• Impact:
  • Minimal
  • No current requirement in Section 508.
• External Reference: Harmonized with WCAG 2.0
• Testability: Inspection
• Metadata
  • Disabilities: All
  • User Activities: All
  • Product Characteristics: All
  • Product Types: Software (installed or through browser); Network Interface to devices; Desktop Computer Systems; Portable Computer Systems

3-D - User Preferences (Consensed)

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

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

Note: Application software that is is also a platform would need to expose the underlying platform's color, contrast, and other individual display settings to applications running within its platform, so that these applications can meet the User Preferences provision.

Rationale: In the current 508 provision, the phrases "shall not override" and "other display attributes" are vague and raise testability issues. The reworded provision clarifies that the application should utilize a definitive list of display settings. The reworded provision also requires a minimum contrast for scenarios where the platform does not provide color and contrast settings. This is needed so that users requiring good contrast will be provided with at least a 5:1 contrast ratio in the software user interface. The contrast requirements are harmonized with WCAG 2.0 and with 3-B Contrast.

• Status: Consensus reached 11 Dec
• Text from Web and Software
• Source: {508}1194.21(g)
• Impact: Minimal for desktop platforms. Significant for websites and other types of platforms such as mobile devices.
• External Reference:
• Testability: If platform settings, inspection; if no platform settings, formal test method
• Metadata
  • Disabilities: All
  • User Activities: All
  • Product Characteristics: All
  • Product Types: Software (installed or through browser); Network Interface to devices; Desktop Computer Systems; Portable Computer Systems

3-E - Color Adjustment (Consensed)

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

Rationale: Current provision is weak and unfailable. If an application doesn't permit the user to adjust color and contrast settings, it passes. If it does permit the user to adjust them, the requirement to provide "a variety of color selections capable of producing a range of contrast levels" is so subjective that they all pass.

Editorial adjustment to be approved
The opening phrase: "When a product permits a user to..." is changed as above

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

3-F - Non-text Objects (Consensed)

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

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

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

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

• Status from on November plenary: Done, have consensus, Nov 27 conference call
• Text from Web and Software
• Source: {508}1194.22(a)
• Impact:
  • Minimal
  • Section 508 already has the requirement for text alternatives. This provision provides more guidance on appropriate text alternatives and allows some things that were not allowed before so may even save some money.
• External Reference: Harmonized with WCAG 2.0
• Testability: Expert evaluation
• Metadata
  • Disabilities: All
  • User Activities: All
  • Product Characteristics: All
  • Product Types: Software (installed or through browser); Network Interface to devices; Desktop Computer Systems; Portable Computer Systems

3-G - Human Language (Consensed)

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

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

Rationale: Harmonization with WCAG 2.0.

• Status from on November plenary: Done, have consensus, Nov 27 conference call
• Text from Web and Software
• Source: new
• Impact:
  • Minimal for HTML Web pages. Could be significant for other document types.
  • No current requirement in Section 508 but adding the language identifier at the document level is a small amount of effort.
• External Reference: Harmonized with WCAG 2.0
• Testability: Inspection
• Metadata
  • Disabilities: All
  • User Activities: All
  • Product Characteristics: All
  • Product Types: Software (installed or through browser); Network Interface to devices; Desktop Computer Systems; Portable Computer Systems

3-H - Language of Parts (Consensed)

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

Rationale: Harmonization with WCAG 2.0.

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

3-I - Pausing

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

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

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

Rationale: Harmonization with WCAG 2.0.

Comments to be resolved:

Comments from ITAA
a. Auto updating is not well understood by lay audience

b. Providing pause is major impact to some web developers. Constituents want to know how acute is the problem? Confusion? Seizures? [This question begs the larger question of which provisions are more important than others – vendors insist on being able to make reasonable tradeoffs between them]

Comments from CSD/Trace Center

1. Web content can be paused and restarted by 'clicking' on the content – without needing to add any controls.
2. This provision is for people with attention disorders – and also, in some cases, for those using screen readers or magnifiers that refocus on changing content.

• Status from on November plenary: Not discussed
• Text from Web and Software
• Source: {508}1194.21(h)
• Impact:
  • Significant
  • User agents provide support for this on some Web technologies. But for other Web technologies and for software, the application developer must provide this support.
• External Reference: Harmonized with WCAG 2.0
• Testability: Inspection
• Metadata
  • Disabilities: All
  • User Activities: All
  • Product Characteristics: All
  • Product Types: Software (installed or through browser); Network Interface to devices; Desktop Computer Systems; Portable Computer Systems

3-J - Flashing (Consensed)

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

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

• Status from on November plenary: Done, have consensus, Nov 27 conference call
• Text from Web and Software
• Source: {508}1194.21(k) 1194.22(j) 1194.25(i), and {255}1193.43(f)
• Impact:
  • None
  • Currently 508 doesn't allow any flashing at all within the range of 2 to 55 Hz. This provision is less strict as it only applies to flashing that occupies a large area of the user's field of vision.
• External Reference: Harmonized with WCAG 2.0
• Testability: Inspection
• Metadata
  • Disabilities: Flash sensitive
  • User Activities: All
  • Product Characteristics: All
  • Product Types: Software (installed or through browser); Network Interface to devices; Desktop Computer Systems; Portable Computer Systems

3-K - Consistent Identification

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

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

Comments to be resolved:

Comments from ITAA
a. We propose to make this a best-practice, not a provision, as it makes the page more usable, it doesn’t proscribe access.

b. The "must" imperative as opposed to "should" is very difficult to accomplish in a eGovernment or eBusiness portal federation context. What might be consistent within the boundaries of a specific portal providing a specific business capability will/may not be consistent for all companion capabilities that coexist in the environment. What a user sees on a page may come from very diverse vendors, and these may vary from one access to another. Consistency of identification across this domain may well be impossible.

Comments from CSD/Trace Center
What is 'usability problem' for those with higher cognitive abilities may be a barrier to those with cognitive disabilities.

• Status from on November plenary: Not discussed
• Text from Web and Software
• Source: {508}1194.21(e)
• Impact:
  • Significant
  • Requires manual assessment and correction. Cost to remediate existing applications could be very high. Subjectivity of the testing could also increase expense.
• External Reference: Harmonized with WCAG 2.0
• Testability: Inspection
• Metadata
  • Disabilities: All
  • User Activities: All
  • Product Characteristics: All
  • Product Types: Software (installed or through browser); Network Interface to devices; Desktop Computer Systems; Portable Computer Systems

3-L - Audio Turnoff

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

Rationale: Harmonization with WCAG 2.0.

Version 2, text proposed by Sun
When any audio plays on a web site 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. Use of a web browser with the ability to turn off audio is sufficient to meet this provision.

Additional text proposed by Karen PS for compatibility with 255
Availability of audio cutoff – when a product delivers audio output through an external speaker, provide an industry standard for headphones or personal listening devices (e.g., phone-like handset or earcup which cuts off the speaker(s) when used.

Text from: Telecommunications §1193.43 (g)

Rationale for additional text: The section 255 telecommunications guidelines contained the following different section, which does not appear to be covered anywhere in these guidelines

Comments to be resolved:

Comment from ITI
This should be an advisory note and not a standard, and should include a clarification of the situation for web pages. There are many ways to enable Audio Turnoff, e.g., at the system level, at the browser, plug-in audio controls, etc. Requiring the content provider to supply this capability seems to be the least effective and efficient.

Comment from Sun
We included our comments in the ITI report for this provision, but feel strongly that this item needs resolution. This should be an advisory note and not a standard. Should clarify the situation for web pages. There are many ways to enable Audio Turnoff (at the system level, at the browser, plug-in audio controls, etc.) and requiring the content provider to supply this capability seems to be the least effective/efficient.

Comments from (Japan/Haijime Yamada)
The description of "three seconds" in 3-L is quotation of WCAG 2.0 (guideline 1.4.2). When the standard of the web content apply to other products such as Closed Product, does not the problems come out?

Comments from "Work In Progress" List
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.

This provision should be an advisory note

Comments from CSD/Trace Center

1. RE ITI and SUN comment about system level turn off. Turning off the sound at the system level turns off the screen reader sound as well. There needs to be a means to turn off the content sound without turning off the screen reader output or the screen reader cannot be used. This should not be advisory as it can preclude use of the screen reader. The word 'mechanism' is used to allow the content to rely on mechanisms in the browser etc if it is a fair assumption that such a mechanism exists. (mostly it does not today – except for an experimental browser from IBM).
2. RE Japan question: The problem would continue to exist in closed products where the sounds would interfere with built in self voicing.

• Status from on November plenary: Not discussed
• Text from Web and Software
• Source: {508}1194.25(e) - Second sentence
• Impact:
  • Minimal
  • No current Section 508 requirement but may not be a common occurrence.
• External Reference: Harmonized with ISO 9241-171, HFES 200, WCAG 2.0
• Testability:
• Metadata
  • Disabilities: All
  • User Activities: All
  • Product Characteristics: All
  • Product Types: Software (installed or through browser); Network Interface to devices; Desktop Computer Systems; Portable Computer Systems

3-M - Reading Sequence

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

Note 1: In order to achieve this provision, objects in data operated on by the software which can be presented in 2 dimensions, would need to be associated with sufficient information to identify a logical one dimensional presentation of the same objects, that the software can obtain as readily as it can obtain the 2 dimensional objects themselves.

Note 2: For products with closed functionality the visual and (linear) audible presentation should match navigation

Rationale: Harmonization with WCAG 2.0.

Comments to be resolved:

Comments from "Work In Progress" List
The phrase "correct reading order" is not clear. In 8.1.C of the Sept 14 draft, the phrase "logical linear" was used which is clearer. Note: this topic is to be discussed at the plenary not the subcommittee level

Current WCAG 2.0 text:

1.3.2 Meaningful Sequence: When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined. (Level A)

How to Meet 1.3.2

Understanding 1.3.2

2.4.3 Focus Order (Relationships): If a Web page can be navigated sequentially, focusable components receive focus in an order that follows information and relationships conveyed through presentation. (Level A)

How to Meet 2.4.3

Understanding 2.4.3

2.4.11 Focus Order (Visual): If a Web page can be navigated sequentially and the focus order affects operability, focusable components receive focus in an order that is consistent with the visual layout order of the web page. (Level AAA)

How to Meet 2.4.11

Understanding 2.4.11

• Status from on November plenary: Not discussed
• Text from Web/Software and Closed Products
• Source: New
• Impact:
  • Minimal for software. Significant for Web pages and other types of electronic content.
  • Need tools to linearize content. Manual checking required.
• External Reference: Harmonized with WCAG 2.0. Similar to recommendation in ISO 9241-171
• Testability: Inspection
• Metadata
  • Disabilities: All
  • User Activities: All
  • Product Characteristics: All
  • Product Types: Software (installed or through browser); Network Interface to devices; Desktop Computer Systems; Portable Computer Systems

3-N - Link Purpose

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

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

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

Comments to be resolved:

Comments from ITAA
Define “Purpose.” There may be a different purpose for different users – how do we change the name to reflect the purpose.

Current WCAG 2.0 text:
2.4.4 Link Purpose (In Context): The purpose of each link can be determined from the [link text] alone, or from the link text together with its programmatically determined link context, except where the purpose of the link would be ambiguous to users in general. (Level A)

How to Meet 2.4.4

Understanding 2.4.4

2.4.9 Link Purpose (Link Only): A mechanism is available to allow the purpose of each link to be identified from link text alone. (Level AAA)

How to Meet 2.4.9

Understanding 2.4.9

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

3-O - Information and Relationships

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

1. row and column headers are identified for data tables

• a. Note: In order to achieve this provision, table objects in data operated on by the software would need to be associated with sufficient information to identify any row and column headers for the table, that the software can obtain as readily as it can obtain the table itself.
  

2. markup is used to associate data cells and header cells for data tables that have two or more logical levels of row or column headers.

• a. Note: In order to achieve this provision, cells in table objects with multiple logical levels of headers in data operated on by the software would need to be associated with sufficient information to identify any row and column headers for the table cell, that the software can obtain as readily as it can obtain the table cell itself
  

3. markup is used to identify section headings
4. markup is used to identify form element labels

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

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

Comments to be resolved:

Comments from "Work In Progress" List
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.

Should remove "markup"

Disagree with removing this provision

Need to get agreement if the current text is acceptable, There is also EWG input.

This topic was discussed at the General Subcommittee meeting on Oct 15. Please see the meeting notes for more information.

Comment from ITI
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.

Comments from ITAA
Propose rewording for clarity: Information and relationships that are conveyed through presentation, or that can be programatically determined, or that are available in text, and notification of changes to this information and these relationships must be available to user agents, including assistive technologies. For example: 1. row and column headers that are identified for data tables
2. markup that 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 that is used to identify section headings
4. markup that is used to identify form element labels

WCAG 2.0 Text
1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. (Level A)

How to Meet 1.3.1

Understanding 1.3.1

• Status from on November plenary: Not discussed
• Text from Web and Software
• Source: {508}1194.22(g), (h), (i), & (n), .21(l)
• Impact:
  • Significant
  • Currently Section 508 only requires markup for tables. This provision requires that apparent section headings, lists, etc. be coded as such. Also extends to all types of electronic documents, not just Web pages. Significant positive impact to end users and agencies. IT-AT interoperability will be improved and less customization should be required.
• External Reference: Harmonized with WCAG 2.0
• Testability: Inspection
• Metadata
  • Disabilities: All
  • User Activities: All
  • Product Characteristics: All
  • Product Types: Software (installed or through browser); Network Interface to devices; Desktop Computer Systems; Portable Computer Systems

3-P - User Interface Components

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

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

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

Comments to be resolved:

Comments from "Work In Progress" List
Same comments as 3O - Information and Relationship. Recommend remove this provision.

Disagree with removing

This topic was discussed at the General Subcommittee meeting on Oct 15. Please see the meeting notes for more information.

Comment from ITI
This is really about (web) documents; everything in it is covered by 3-U. We should either remove it as redundant, or scope to it web documents. Please specifically note the final text of 3-U: "Note: This provision applies to forms in the software."

Comments from ITAA
a. Change all “programmatically determined” to “programmatic determinable” per the definitions in Subpart A

b. In the third sentence, start it with “any”

• Status from on November plenary: Not discussed
• Text from Web and Software
• Source: {508}1194.21(l) & .22(n)
• Impact:
  • Significant
  • Rich Internet Applications will have to implement the ARIA standards. Significant positive impact to end users and agencies. IT-AT interoperability will be improved and less customization should be required.
• External Reference: Harmonized with WCAG 2.0
• Testability: Inspection
• Metadata
  • Disabilities: All
  • User Activities: All
  • Product Characteristics: All
  • Product Types: Software (installed or through browser); Network Interface to devices; Desktop Computer Systems; Portable Computer Systems

3-Q - Disruption of Access Features

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

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

Comments to be resolved:

Comments from "Work In Progress" List
This doesn't read to me like "applications must not disrupt assistive technology". Is there a way to get that concept back in even if through additional notes?

Comments from ITAA
a. I'm pretty sure that developers will not "define an accessibility usage" if it means they can get around this provision.

b. The provision needs to clarify the meaning of "platform developer documentation?" Manuals for application developers, manuals for platform developers, or written by the platform vendor organization?

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

3-R - Timing

For each time limit that is set by the product or content, at least one of the following must happen:
1. Turn off: the user is allowed to turn off the time limit before encountering it; or
2. Adjust: the user is allowed to adjust the time limit before encountering it over a wide range that is at least ten times the length of the default setting; or
3. Extend: the user is warned before time expires and given at least 20 seconds to extend the time limit with a simple action (for example, "hit any key"), and the user is allowed to extend the time limit at least ten times; or
4. 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
5. Essential Exception: the time limit is part of an activity where timing is essential and time limits can not be extended further without invalidating the activity.

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

Comments to be resolved:

Comments from "Work In Progress" List
An additional bullet should be added stating that time limits that minimally impact the user's experience, information, or session state are allowable. This will cover time out features like screen locks, web session locks were a user may return to the session state after logging in again, etc.

Comment from ITI
An additional bullet should be added stating that time limits that minimally impact the user's experience, information, or session state are allowable. This will cover time out features like screen locks, web session locks were a user may return to the session state after logging in again, etc.

Comments from ITAA
a. As with the biometric discussion, this item is a prime example of frequent requirement conflicts. The security imperatives (Federal Information Security Management Act (FISMA) imparted in NIST Special Publication 800-53A Guide for Assessing the Security Controls in Federal Information Systems as well as DoD and other Federal Agency implementations require sessions to be killed after x-minutes of inactivity. The security imperative is a far better example of an "essential" timing requirement than those presently identified.

b. Delete "Real-time Exception" – a real-time exception is just a special case of an essential exception and doesn’t need a special category.

Comments from CSD/Trace Center
Should not add new bullet (re ITI). Current language covers that to the extent it should be covered. New bullet language opens up a major loophole and breaks harmonization with WCAG.

Proposed text from Sun
Proposed text for new bullet: Inconsequential Impact Exception: the impact of the user failing to react within the time limit is inconsequential – no data, state, or opportunity is lost.

• Status from on November plenary: Not discussed
• Text from Web and Software
• Source: New (incorporates {508}1194.22(p), {508}1194.23(d), {508}1194.25(b), {255}1193.41(g)
• Impact:
  • None for Web sites. Minimal for software.
  • Currently 508 only allows one strategy for dealing with timeouts on Web sites. Any current 508 compliant Web site will continue to comply with this provision. New requirement for software. Large positive impact to end users.
• External Reference: Harmonized with WCAG 2.0 and ISO 9241-171
• Testability: Inspection
• Metadata
  • Disabilities: All
  • User Activities: All
  • Product Characteristics: All
  • Product Types: Software (installed or through browser); Network Interface to devices; Desktop Computer Systems; Portable Computer Systems

3-S - Keyboard Operation (Consensed)

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

Note 1: This does not forbid and should not discourage providing mouse input or other input methods, such as gestures, in addition to keyboard operation.
Note 2: The exception relates to the underlying function, not the input technique. For example, if using handwriting to enter text, the input technique (handwriting) requires path dependent input but the underlying function (text input) does not.
Note 3: Keyboard interface can be either a hardware keyboard interface, a wireless interface or a software keyboard interface where AT can generate keystrokes that would be seen by software.
Note 4: For platform software, this includes the ability to move the keyboard focus into and out of applications.

Rationale: In the current 508 wording, the phrase "textually discernible" is confusing and often misinterpreted to mean the provision only applies to text documents when it should be applied more broadly. The new wording is harmonized with WCAG 2.0.

• Status from on November plenary: Done, have consensus, Nov 27 conference call
• Text from Web and Software
• Source: {508}1194.21(a)
• Impact:
  • None for software. Minimal for Web pages.
  • Functionally equivalent to the current Section 508 software keyboard requirement. New requirement for Web pages. In many cases, keyboard operation of Web pages is provided by the user agent. Rich Internet Applications must ensure keyboard operation though.
• External Reference: Harmonized with WCAG 2.0 and ISO 9241-171
• Testability: Inspection
• Metadata
  • Disabilities: Blindness, Physical
  • User Activities: All
  • Product Characteristics: Uses Keyboard (Physical - touch typeable)
  • Product Types: Web Content; Telephone only device; IVR (Voicemail, Autoattendant, Audiotext); Software (installed or through browser); Copiers; AudioVisual equipment (Video Monitor, TV, Projector); KIOSKS; Network Interface to devices; Desktop Computer Systems

3-T - Focus Indicator

Version 1 from subcommittee:

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

Note 1: The presence of a highly visible text insertion point can be considered a visual indication of keyboard focus for a text area.

Note 2: A focus cursor that is visually locatable by people (familiar with what the focus cursor would look like) who have 20/20 vision at 3.5 times the typical viewing distance without moving the cursor is sufficient.

Note 3: Since computer software would be displayed on unknown screen sizes: for computer software a focus cursor that is visually locatable by people (familiar with the cursor) who have 20/20 vision at 2.5 meters when software is displayed on a 38 cm (15 inch) diagonal screen at 1024 x 768 pixels resolution, without moving the cursor is sufficient.

Note 4: Since computer software would be displayed on unknown screen sizes: for computer software a focus cursor that is visually locatable by people (familiar with the cursor) who have 20/20 vision at 2.5 meters when software is displayed on a 38 cm (15 inch) diagonal screen at 1024 x 768 pixels resolution, without moving the cursor is sufficient.

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

Note 1: If the object is a text entry field, a visual indication of the text insertion point is sufficient as a focus cursor.

Note 2: A focus cursor that is visually locatable by people with unimpaired vision at 2.5 meters when software is displayed on a 38 cm (15 inch) diagonal screen at 1024 x 768 pixels resolution, without moving the cursor is sufficient.

Rationale: In the current 508 provision, the term "well-defined" is not testable. The new wording clarifies that a high degree of visibility is required and provides notes that clarify how a high degree of visibility can be achieved.

Comments to be resolved:

Comments from "Work In Progress" List
Either add one more note to version 1 stating: "This provision is restricted to the visibility of the focus. Focus must also be programmatically exposed for assistive technology usage--see 3-U." OR use version 2.

Comment from ITI
This provision would be very difficult to test and therefore should be dropped.

Comments from CSD/Trace Center
High visibility of focus indicator is a very important provision – and invisible or barely visible indicators are a major barrier to low vision, and physical disabilities. (Also cognitive).

• Status from on November plenary: Not discussed
• Text from Web and Software
• Source: {508}1194.21(c)
• Impact:
  • Significant
  • "Well-defined" focus cursor is currently required by 508. New provision provides testable measurement for "highly visual". Significant work for some desktop platforms, applications, and for Web 2.0 style applications.
• External Reference: Harmonized with ISO 9241-171
• Testability: Inspection
• Metadata
  • Disabilities: Low Vision, Physical
  • User Activities: All
  • Product Characteristics: Involves Web Content or Applications
  • Product Types: Web Content; Software (installed or through browser); Network Interface to devices; Desktop Computer Systems; Portable Computer Systems

3-U - AT Interoperability

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

1. provide assistive technology with object information including but not limited to:

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

2. 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;
3. allow assistive technology to track and modify focus, text insertion point, and selection attributes of user interface components;
4. provide assistive technology with notification of events relevant to user interactions, including but not limited to changes in the component's state(s), value, name, description, or boundary

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

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

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

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

Comments to be resolved:

Comments from "Work In Progress" List
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.

This topic was discussed at the General Subcommittee meeting on Oct 15. Please see the meeting notes for more information.

Comment from TIA
The provisions of these sections have not been adequately vetted for Telecommunications hardware user interfaces and application. These requirements were designed for web and software in an IT computing environment, not telecommunications hardware displays, and are platform specific. These provisions are of special concern for handheld Telecom devices many of which are unable to meet the AT interoperability provisions and have a different perspective for platform and application interaction.

Note: The TIA comment also applied to provision 3.V "Both platform and application" in the Sept 14 draft.

Comments from ITAA
a. There is no definition of “user interface objects”.

b. This wording would require that any product that can meet the provisions for accessibility without AT must STILL use the services on the platform. What we think was meant was if you use AT to meet specific provisions, you must interface to the AT thought the specified services. Also there is confusion as to whether "such services" means both platform services and/or "other" services.

c. 5th bullet – The provision should clarify if the names of elements and objects are wanted? Are elements objects?
EWG note: not clear on which bullet this applies to since this calls for the "5th bullet" where the next item calls for the "5th sub-bullet". Maybe these two comments applie to 1e, but it is not clear.

d. Precede text of 1-e (5th sub-bullet of 1st bullet) with “name of”

e. This requirement imposes no constraint on currency for the AT tool itself. Should an application have to demonstrate interoperability with pre-Microsoft Active Accessibility (MSAA) or Java Foundation Classes (JFC or Swing) implemented the Java Accessibility API as represented in an earlier Java Runtime Environment (JRE) that are now obsolete or deprecated. The MSAA and Java APIs respectively are examples of "platform software" in this instance, but MSAA on Windows 95 is not the same as MSAA on Vista Ultimate. The JAVA Accessibility API is not the same on JRE 1.3 and 1.5.

This can of worms sometimes leads to an interpretation that support is required for very early versions of emacsspeak with a Lynx browser, or no longer supported tools like IBM's Home Page Reader, Vocal Point's VoiceBrowser, and others.

There needs to be some constraining text that addresses obsolescence for practicality sake. Should the next iteration of Section 508 lay unaltered for a period equivalent to the present circumstance (nearly 10 years - multiple web generations), the same issues will be manifested where the best practice or best approach is compromised by the constraining text of the standard. Even in the browser, the accessibility features available in HTML 3.2 when Section 508 was introduced are greatly expanded in current markup language releases

Comments from CSD/Trace Center

1. Very important provision
2. Products that have built in access can be closed and skip this.
3. Phones are increasingly including operating systems and can thus support this instead of operating as closed products.
4. This provision does not specify an API that can be built to. It only provides requirements for an API.
5. This provision needs to clearly state that "AT interoperability" means that products that pass this provision will really interoperate with AT. (also applies to 3-V by inheritance).

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

3-V - Accessibility Services

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

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

Comments to be resolved:

Comments from ITAA
a. Change "sufficient" to "sufficiently"

b. There is no discussion of translation of the plausible future state of mediation services to achieve accessibility. First generation examples include Adobe PDF Conversion by Email Attachment and Adobe PDF Conversion by Simple Form. Emerging examples include Service Oriented Architecture (SOA) mediation and metadata discovery services that would provide alternative rendering of XML content based on the user (or their user agent needs). These types of services are already performed routinely in situations where a PDA (as identified by the agent string) is delivered information in a 9 line display while a full size browser receives the whole page. XML is the same, XSL handles the transform.

Comments from ITAA regarding provision 3-V "Both Platform and Application (included here since 3-V "Accessibility Services" has replaced the prior provision

Clarify ambiguity of “running within its platform”, perhaps replace with “using this software as a platform”

• Status from on November plenary: Not discussed
• Text from Web and Software
• Source: New
• Impact:
  • None for current desktop operating system platforms. Significant for applications that are also platforms and for non-desktop platforms.
  • All desktop operating system platforms meet the requirement. Not all applications that are also platforms and non-desktop platforms meet the requirement.
• External Reference: Harmonized with 9241-171
• Testability:
• Metadata
  • Disabilities: All
  • User Activities: All
  • Product Characteristics: All
  • Product Types: Software (installed or through browser); Network Interface to devices; Desktop Computer Systems; Portable Computer Systems

3-W - Multiple Ways (New provision)

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

Rationale: Harmonization with WCAG 2.0

EWG comment: This does not follow the format of telling what must be done. Need to clarify the goal of this provision.

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

3-X - Labels or Instructions (New provision)

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

Rationale: Harmonization with WCAG 2.0

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

3-Y - On Focus (New provision)

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

Rationale: Harmonization with WCAG 2.0

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

3-Z - On Input (New provision)

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

Rationale: Harmonization with WCAG 2.0

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

3-AA - Error Identification (New provision)

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

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

Rationale:

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

3-BB - Labels Descriptive (New provision)

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

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

Rationale:

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

3-XX - Advisory Notes for Access Board

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

1. Suppression of unneeded function

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

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

2. Writing guidelines

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

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

3. Interaction guidelines

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

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

4. Parsing

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

5. User Preferences (non-visual)

User interfaces which provide a mode of interaction other than visual (such as vocal, aural, gustatory, olfactory, tactile) that can affect human sensory functions, should either provide settings that allow the user to stop and control those functions or a mode that utilizes the platform user settings for control of those functions.

Rationale:

Comments to be resolved:

Comments from "Work In Progress" List

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:

• Descriptive Page Titles (Level A)
• Focus Order (Level A) (EWG question: is this covered by 3-M Reading Sequence?)
• Error suggestion (Level AA) (EWG question: is this covered by 3-AA Error Identification?)

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.

Comment from ITI
Advisory notes should not be included within the standard, but rather, posted on the Access Board web site either in the FAQ page or perhaps a section that provides additional guidance to federal agencies.

• Status from on November plenary: Not discussed
• Text from Web and Software
• Source: new
• Impact:
• External Reference:
• Testability: Many of these are testable
• Metadata
  • Disabilities: All
  • User Activities: All
  • Product Characteristics: All
  • Product Types: Software (installed or through browser); Network Interface to devices; Desktop Computer Systems; Portable Computer Systems

4. Additional Provisions for Audio-Visual Players or Displays

4-A - Caption Processing (Consensed, still open actions)

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

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

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

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

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

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

Notes from plenary November meeting:

There is concern with the title using the word playback. "Processing" may be used instead. Is an open item to resolve (make sure it's the right word to use).

Larry to complete an explanatory note regarding computer equipment including TV tuners.

• Status from on November plenary: Done, have consensus
• Text from A/V
• Source: {508}1194.24(a)
• Impact:
• External Reference: CEA 608, CEA 708
• Testability: Inspection
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

4-B - Supplemental Audio Playback (Process) (Consensed, still open actions)

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

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

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

Notes from November plenary:

Need to change "playback" to "process" if this is the agreed upon term.

CEA: concern regarding phrase "ancillary audio program playback circuitry". Want to point to ATSC A53 VI standard which refers to the full program plus description mix.

• Status from on November plenary: Done, have consensus
• Text from A/V
• Source: {508}1194.24(b)
• Impact:
• External Reference:
• Testability: Inspection
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

4-C - Access to Caption and Video Controls (Consensed)

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

For example:

For captioning:

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

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

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

Rationale:

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

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

Note from November plenary:

Concern raised regarding laptops, to which the answer is that a keyboard equivalent would be acceptable.

• Status from on November plenary: Done, have consensus
• Text from A/V
• Source: new
• Impact:
• External Reference:
• Testability: Inspection
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

5. Audio and/or Video Content

Was section 6 in Oct 26 draft.

5-A - Captions and Transcripts (Consensed)

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

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

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

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

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

Notes from November plenary:

States looking for exemption language so that it's clear what is covered otherwise all states will create their own rule.

• Status from on November plenary: Done, have consensus
• Text from A/V
• Source: {508}1194.24(c) (was 6-A in Oct 26 draft)
• Impact:
• External Reference:
• Testability: Inspection
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

5-B - Video Description (Consensed)

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

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

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

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

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

• Status from on November plenary: Done, have consensus
• Text from A/V
• Source: {508}1194.24(d) (was 6-B in Oct 26 draft)
• Impact:
• External Reference:
• Testability: Inspection; possibly expert evaluation regarding "informational content"
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

5-C - Interactive Elements

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

Notes from November plenary:

• Avoid using the word "accessible" since we haven't defined it. Need to look at how other provisions did this.
• Add explanatory notes for examples
• Do not have consensus on this provision.

• Status from on November plenary: Could not reach consensus
• Text from A/V
• Source: {508}1194.24(d) & .22(b) (was 6-D in Oct 26 draft)
• Impact:
• External Reference:
• Testability: Inspection; possibly expert evaluation regarding "interactive elements" and "content"
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

6. Additional Provisions for Real-time Voice Conversation Functionality

Was section 5 in Oct 26 draft.

6-A - Real-Time Text Reliability and Interoperability (Consensed)

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

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

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

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

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

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

• Status from on November plenary: Done, have consensus
• Text from Telecommunications
• Source: {508]1194.23(b), {255}1193.51(e) (was 5-B in Oct 26 draft)
• Impact:
• External Reference:
• Testability: Inspection and formal test methods
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

6-B - Voice Terminal Hardware and Software (Consensed, still have items to resolve)

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

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

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

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

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

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

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

Notes from November plenary:
Need to be sure 255 is addressed for #3.

Need to determine the right word to use "system" vs. "protocol" in Note 2.

Need to resolve Bluetooth question.

Rationale:

• Status from on November plenary: Done, have consensus
• Text from Telecommunications
• Source: {508}1194.23(a), {255}1193.51(d) (was 5-C in Oct 26 draft)
• Impact:
• External Reference:
• Testability: Inspection
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

6-C - IVR, Auto-Attendant and Messaging (Consensed)

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

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

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

Rationale:

• Status from on November plenary: Done, have consensus
• Text from Telecommunications
• Source: {508}1194.23(c) (was 5-D in Oct 26 draft)
• Impact:
• External Reference:
• Testability: Inspection (#1,3,4) and Formal test method (#2)
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

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

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

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

Rationale:

Comments to be resolved:

Comment from "Work In Progress" List
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.

Comment from ITI
This says that products with visual interfaces that display status info must make the info available for TTYs among others. We don't know how to do this for many classes of products (e.g. making Skype's connection information available to a TTY). This provision is making assumptions about the device that don't match the text of the provision.

Comments from IBM

• Agree with "Work in Progress" comment about TTYs.
• #3 of this requirement is covered by 1.2-G Visual information for closed products and by 3-U AT interoperability for products that are compatible with AT.
• The last sentence actually refers to the "software and content" provisions.
• The #2 raises testability concerns.
• In summary, #3 is covered by other provisions and should be removed. #2 is untestable and should be removed. And the requirement for providing information to TTY users should be clarified.

• Status from on November plenary: Not discussed
• Text from Telecommunications
• Source: {508}1194.23(e) (was 5-E in Oct 26 draft)
• Impact:
• External Reference:
• Testability: Inspection
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

6-E - Video Support (Consensed)

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

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

Note 1: Twenty frames per second or better is recommended to facilitate lip reading and fingerspelling in the video communications provided under this section.
Note 2: Explanatory information concerning sign language and lip-reading real-time conversation using low bit rate video communication can be found in ITU-T H-Series Supplement 1. http://www.itu.int/rec/T-REC-H.Sup1/en.
Note 3: Non-auditory alerting for incoming video communications can be achieved via flashes, vibrations and sound; the preferred method will depend on the needs of the individual using the product.

Rationale:

• Status from on November plenary: Done, have consensus
• Text from Telecommunications
• Source: new (was 5-F in Oct 26 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:

7. Additional Provisions for Authoring Tools

Was section 8 in Oct 26 draft.

7-A - Accessible Output

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

Version 2, proposed by ITI (additional text in italics):
For each accessible content format supported, when available, authoring tools must allow the author to produce content, including content derived from programmatic sources, which meets applicable Section 508 provisions.

Rationale:

Comments to be resolved:

Comment from ITI:
The committee should also provide a definition for “accessible content format.”

Comments from ITAA
Provision must clarify meaning of “content derived from programmatic sources”.

• Status from on November plenary: Not discussed
• Text from Web and Software
• Source: new (was 8-A in Oct 26 draft)
• Impact:
• External Reference: ATAG, ISO 9241.71
• Testability: Inspection
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

7-B - Preserve Accessibility Information (Consensed)

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

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

• Status from on November plenary: Done, have consensus, Dec 4 conference call
• Text from Web and Software
• Source: new (was 8-B in Oct 26 draft)
• Impact:
• External Reference: ATAG, ISO 9241.71
• Testability: Inspection; possibly some expert evaluation
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

7-C - Prompts (Discussed Dec 4, 11, No Consensus)

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

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

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

Notes from Dec 4 and 11 plenary call:

• Request to add "or be compatible with additional tools that provide this function."
• Request to add "used in conjunction with"
• Request to make this a function that an administrator could turn on so that the tools be used.
• Or, "Authoring tools alone, or with a third-party tool"...
• Include the word "bundled" or "embedded" or "included" to make it clear it has to be integrated for everyone.

• Status from on November plenary: Discussed on Dec 4,11 plenary call, no consensus reached
• Text from Web and Software
• Source: new (was 8-C in Oct 26 draft)
• Impact:
• External Reference: ATAG, ISO 9241.71
• Testability: Inspection
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

7-D - Accessible Templates

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

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

Comment to be resolved:

Comment from ITI:
Templates are often supplied as a convenience and are not necessarily supported by the original product. This provision could be interpreted as meaning one of each type of template would need to be made accessible. For some products, this would be a very burdensome task and we feel that resources would be better spent building more accessible authoring tools. Accordingly, ITI recommends that this provision be removed.

• Status from on November plenary: Not discussed
• Text from Web and Software
• Source: new (was 8-D in Oct 26 draft)
• Impact:
• External Reference: ATAG, ISO 9241.71
• Testability: Expert evaluation
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

7-X - Advisory Notes

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

Comments to be resolved:

Comments from "Work In Progress" List
Further discuss and write up a rationale explaining what is meant by "compatible with..."

From Sept 3 plenary: need to add more information about repair or remediation

Rationale:

• Status from on November plenary: Not discussed
• Text from Web and Software
• Source: new (was 8-X in Oct 26 draft)
• Impact:
• External Reference: 'ATAG, ISO 9241.71'
• Testability: Inspection
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

Subpart D

EWG Note: Numbering was restarted at 1 to make this clear this is not part of the technical provisions.

1. Information, Documentation and Support

There is a proposal to merge 1.1 and 1.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.

1.1 Product Documentation and Help

1.1-A - Accessible Documentation and Features (Discussed Dec 11, No Consensus)

Version 1, from Oct 26 draft: 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 documentation 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.

Version 2, proposed by Karen PS to be consistent with the telecommunications guidelines §1193.33
Documentation for users on the installation, configuration, or use of the product including the description, installation, and use of accessibility, usability, and compatibility features, must conform to the relevant accessibility provisions in 1194 Subparts B and C. This documentation includes, but is not limited to, reports, system documentation, user help, installation guides for end-user installable devices covered by Section 255, and user training or technical support materials. Features included in the product specifically to meet accessibility requirements must be documented. The documentation must be available in alternate formats or modes upon request and, for the purposes of Section 255, at no additional charge.

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:
1. Anything that changes user preferences, keyboard commands, special accessibility features that the product supports (i.e., captioning), and features that allow users to adjust the product to their needs.
2. Any features that are used to meet this standard or to enhance accessibility

Version 3, added Jan 4, 2008, proposed by Rex L to add what was ITAA had proposed in "1.1- NEW - Accessible Documentation" provision", this modifies version 2
Documentation for users concerning the installation, configuration, or use of the product including the description, installation, and use of accessibility, usability, and compatibility features, and documentation that is other than documentation for users, must conform to the relevant accessibility provisions in 1194 Subparts B and C. This documentation includes, but is not limited to, reports, system documentation, user help, program or project progress reports, QA or QC plans, program management plans, white papers, analyses, installation guides for end-user installable devices covered by Section 255, 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 or modes upon request and, for the purposes of Section 255, at no additional charge.

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

Advisory Note: There is an overlap between general features and features that support accessiblity. Guidance on how to choose what features to document includes:
1. Anything that changes user preferences, keyboard commands, special accessibility features that the product supports (i.e., captioning), and features that allow users to adjust the product to their needs.
2. Any features that are used to meet this standard or to enhance accessibility

Comments to resolve
1. Word "usabilty" used in Version 2 and 3

• Status from on November plenary: Discussed on Dec 11 conference call, no consensus reached
• Text from Documentation and Technical Support
• Source: {508}1194.41(a), {508}194.41(b), {255}1193.33(a)(1)and {255}1193.33(a)(2) (was 7.1-A in Oct 26 draft)
• 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

1.1- NEW - Accessible Documentation

New provision proposed by ITAA
ITAA supports the inclusion of an additional category of documentation requirements under Standards 1194.41 that clarifies accessibility requirements for all documentation other than user documentation, and defines the accessibility requirement for such EIT deliverables. These documentation products include: program progress reports, qa/qc plans, program management plans, white papers, analyses, etc. Various agencies such as the VA, EPA, have stated that all documentation submitted under their funding will be accessible - is this the operative statutory requirement?

• Status from on November plenary: Discussion delayed until Jan 2 conference call

1.1-B - Keyboard Shortcuts (discussed Dec 11, No Consensus)

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

Comments to be resolved:

Comments from "Work In Progress" List
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.

Comment from ITI
ITI supports Version 2.

Comments from ITAA
a. ITAA endorses version 3.
b. In list item 3, add "equivalent" before "keyboard commands"

Comments from Japan/Haijime Yamada
Suggest changing the expressiong "operating system" in 7.1 B version 3 to "platform software" since the later is defined in the Definitions.

• Status from on November plenary: Discussed on Dec 11 conference call, no consensus reached
• Text from Documentation and Technical Support
• Source: New (was 7.1-B in Oct 26 draft)
• Impact: +
• External Reference:
• Testability: Inspection
• Metadata
  • Disabilities: All
  • User Activities: Training/learning
  • Product Characteristics: User documentation (any type – electronic or print)
  • Product Types: All

1.1-X - Advisory Notes for Access Board (Consensed)

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.

Comments to be resolved:

Comments from "Work In Progress" List
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 reac

• Status from on November plenary: Done, have consensus, Dec 11 conference call
• Text from Documentation and Technical Support
• Source: New (was 7.1-X in Oct 26 draft)
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities: All
  • User Activities: Training/learning
  • Product Characteristics: User documentation (any type – electronic or print)
  • Product Types: All

1.2 Support and E&IT related services

Was section 7.2 in Oct 26 draft

1.2-A - Support Services (Discussed Dec 11, No Consensus)

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

Version 2: Help desk and technical support services must offer information on the accessibility features of the product. These support services must accommodate the communication needs of users with disabilities.

Version 3, proposed by Karen PS to be consistent with the telecommunications guidelines §1193.33
Help desk, technical support, and customer support services provided by call centers and in-person service centers, must accommodate the communication needs of users with disabilities, where these services are otherwise provided by agencies or manufacturers. For the purposes of Section 255, such services must be made available at no additional charge. 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:

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

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

Comments to be resolved:

Comments from "Work In Progress" List
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.

Comments from ITAA
For the situation where the agency has the vendor provide support vendors cannot "comply" with this without the AT knowledge

Comments from NASCIO:
Agency requirements do not belong in "technical requirements" to be applied to EIT products/services. This includes 1.2-A, 1.2-C, 5-A, 5-F (1) & (3), and 7.2-A. These might all be adopted as agency policies (perhaps with much more specificity applicable to implementation in that agency), but not as EIT technical standards.

Comments from 11 Dec:
Separate 255 and 508 versions

• Status from on November plenary: Discussed on Dec 11 conference call, no consensus reached
• Text from Documentation and Technical Support
• Source: {508}1194.41(c) and {255}1193.33(a)(3) (was 7.2-A in Oct 26 draft)
• Impact:
• External Reference:
• Testability: Expert evaluation
• Metadata
  • Disabilities: All
  • User Activities: Training/learning
  • Product Characteristics: All
  • Product Types: All

1.2-B - Manufacturer Contact (Consensed)

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

• Status from on November plenary: Done, have consensus, Dec 18 conference call
• Text from: Telecommunications
• Source:
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities: All
  • User Activities: Training/learning
  • Product Characteristics: All
  • Product Types: All

1.2-C - Training (Consensed)

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

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

• Status from on November plenary: Done, have consensus, Dec 18 conference call
• Text from: Telecommunications
• Source:
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities: All
  • User Activities: Training/learning
  • Product Characteristics: All
  • Product Types: All

1.2-X - Advisory Notes for Access Board (Consensed)

Best practices for providing support to people with disabilities include:

1. Remote assistance

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

• Status from on November plenary: Done, have consensus, Dec 18 conference call
• Text from Documentation and Technical Support
• Source: New (was 7.1-X in Oct 26 draft)
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities: All
  • User Activities: Training/learning
  • Product Characteristics: All
  • Product Types: All

2. NEW SECTION Implementation, Operation and Maintenance

2-A - Relay Services Accessibility (Consensed)

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

Rationale:

• Status from on November plenary: Done, have consensus
• Text from Telecommunications
• Source: new (was 5-A in Oct 26 draft)
• Impact:
• External Reference:
• Testability: #2 is testable by inspection
• Metadata
  • Disabilities:
  • User Activities:
  • Product Characteristics:
  • Product Types:

2-B - Video Support (Consensed)

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

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

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

Rationale:

• Status from on November plenary: Done, have consensus
• Text from Telecommunications
• Source: new (was 5-F in Oct 26 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:

2-C - Accessibility Configuration

Products procured must be capable of being configured to be accessible to and usable by people with disabilities while simultaneously meeting the product's function. The accessibility features should not disable any product functions.

Note proposed from the telecom Task Force:
Note: This provision is not intended to prevent a product feature that would allow the user to tie product functions together(e.g. turning one on would turn another off) so long as turning on an accessibility feature did not turn off other product functions by default.

Notes from November plenary:
Recommend make a note of server settings vs. client systems

• Status from on November plenary: Could not reach consensus
• Text from Telecommunications
• Source: new (was 1.2-A in Oct 26 draft)
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities: All
  • User Activities: All
  • Product Characteristics: All
  • Product Types: All

2-D - Accessible Content

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

Rationale:

Notes from November plenary:
Reword "accessible to people with disabilities" consistent with other provisions that require compliance with "applicable parts of 508"

The wording is too broad. "Output ... that is distributed or archived" is everything. Also encompasses system reports. Would be very expensive to make all of these reports accessible. One suggestion is to require agencies to develop policies around what content must be accessible.

• Status from on November plenary: Could not reach consensus
• Text from Web/Software
• Source: new (was 1.2-b in Oct 26 draft)
• Impact:
• External Reference:
• Testability:
• Metadata
  • Disabilities: All
  • User Activities: All
  • Product Characteristics: All
  • Product Types: All