Trace Center Collation of
Access Board's 508 FINAL RULE and GUIDES

(Release 1.1 June 9, 2004)

Webmaster's Note: A previous version of this collation, Release 1.0 July 15, 2002 is also available.

This is a special compilation and collation of the Section 508 Standards and Guides released by the Access Board. It contains only the material from the Final Rule, the Access Board's Guide to the Section 508 Standards, and the Accessible Telecommunications Product Design Technical Assistance document (released by the Access Board on December 18, 2003). However it is re-arranged to put all the information relating to each provision of the Final Rule together. The document was compiled as follows.

This compilation started with the Standards in the Final rule (Part 1194).
The discussion from the PREAMBLE of the FINAL RULE for each provision was then clipped from the preamble and put under each provision. For screen reader users, each provision of the preamble is also marked with text where it begins and ends. (This markup appears in a smaller font that can be seen around each preamble clipping and is surrounded by square brackets).
The text from the GUIDE TO THE SECTION 508 STANDARDS released by the Access Board was then broken up and pasted under the provision that the pieces applied to.
The text from the Accessible Telecommunications Product Design Technical Assistance document was also broken up and included with the provison that the pieces applied to.
Any text from the Preamble that did not relate to a specific provision of the Standard was pasted at the end of this document in Appendix A so that ALL text from the Final Rule and Guides is contained in this document. Similarly, any of the text from the Telecommunications Product Design Guide has been included in Appendix B.

The result is a document which puts all of the current Access Board material for each provision together under the provisions.

This document was prepared to facilitate reading and understanding of the rule by Trace Staff. It is released in case it would be useful to others as well.

We believe this compilation to be error free. However, if you notice an error please send a note to info@trace.wisc.edu.

Thank You

Electronic and Information Technology Accessibility Standards

ARCHITECTURAL AND TRANSPORTATION BARRIERS COMPLIANCE BOARD

[Published in the Federal Register on December 21, 2000]

36 CFR Part 1194
[Docket No. 2000-01]
RIN 3014-AA25

Thurman M. Davis, Sr.,

Chair, Architectural and Transportation Barriers Compliance Board.

For the reasons set forth in the preamble, the Board adds part 1194 to Chapter XI of title 36 of the Code of Federal Regulations to read as follows:

PART 1194 -- ELECTRONIC AND INFORMATION TECHNOLOGY ACCESSIBILITY STANDARDS

Subpart A -- General

Sec.

1194.1 Purpose.
1194.2 Application.
1194.3 General exceptions.
1194.4 Definitions.
1194.5 Equivalent facilitation.

Figures to Part 1194

Authority: 29 U.S.C. 794d.

Subpart A -- General

§ 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). Section 508 requires that when Federal agencies develop, procure, maintain, or use electronic and information technology, Federal employees with disabilities have access to and use of information and data that is comparable 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 that is comparable to that provided to the public who are not individuals with disabilities, unless an undue burden would be imposed on the agency.

[BEGIN PREAMBLE TEXT]

This section describes the purpose of the standards which is to implement section 508 of the Rehabilitation Act of 1973, as amended by the Workforce Investment Act of 1998. No substantive comments were received and no changes have been made to this section in the final rule.

[END PREAMBLE TEXT]

§ 1194.2 Application.

[BEGIN PREAMBLE TEXT]

This section specifies what electronic and information technology is covered by the standards. Electronic and information technology covered by section 508 must comply with each of the relevant sections of this part. For example, a computer and its software programs would be required to comply with §1194.26, Desktop and portable computers, §1194.21, Software applications and operating systems, and the functional performance criteria in §1194.31. Paragraph (a) states the general statutory requirement for electronic and information technology that must comply with the standards unless doing so would result in an undue burden. The term "undue burden" is defined at §1194.4 (Definitions) and is discussed in the preamble under that section.

[END OF PREAMBLE TEXT]

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

[BEGIN PREAMBLE TEXT]

Paragraph (a)(1) states the statutory obligation of a Federal agency to make information and data available by an alternative means when complying with the standards would result in an undue burden. For example, a Federal agency wishes to purchase a computer program that generates maps denoting regional demographics. If the agency determines that it would constitute an undue burden to purchase an accessible version of such a program, the agency would be required to make the information provided by the program available in an alternative means to users with disabilities. In addition, the requirements to make reasonable accommodations for the needs of an employee with a disability under section 501 and to provide overall program accessibility under section 504 of the Rehabilitation Act also apply.

Comment. The National Federation of the Blind (NFB) suggested that additional language be added that would require agencies to provide information by an alternative means at the same time the information and data are made available to others.

Response. This paragraph restates the general statutory requirement to provide an alternative means of providing an individual the use of the information and data. Providing individuals with information and data by an alternative means necessarily requires flexibility and will generally be dealt with on a case-by-case approach. Although, the Board agrees that information provided by an alternative means should be provided at generally the same time as the information is made available to others, the provision provides the needed flexibility to ensure that agencies can make case-by-case decisions. No substantive changes were made in the final rule.

[END OF PREAMBLE TEXT]

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

[BEGIN PREAMBLE TEXT]

Paragraph (a)(2) sets forth the statutory requirement for an agency to document any claim of undue burden in a procurement. Such documentation must explain in detail which provision or provisions of this rule impose an undue burden and the extent of such a burden. The agency should discuss each of the factors considered in its undue burden analysis.

Comment. The General Services Administration was concerned that this provision was too limiting because it only referred to products which are procured by the Federal Government and did not include products which are developed, maintained, or used. The American Council of the Blind (ACB) recommended that the requirement for documentation apply when agencies claim the lack of commercially available accessible equipment or software. The NFB commented that there should be a requirement for agencies to explain the specific alternate means to be used to provide information or data. Without such a requirement, they argued, persons with disabilities must be knowledgeable enough to inquire about an alternate means after first discovering that the product used for the information and data is not accessible. Although agencies would be expected to know in advance when products will not be accessible, persons with disabilities will not have this information until encountering the problem.

Response. Paragraph (a)(2) addresses the documentation of undue burden. By statute, the requirement to document an undue burden applies only to procurements. This rule does not prescribe the needed documentation of a finding of an undue burden but merely restates the statutory requirement that a finding be documented. The FAR is expected to address the needed documentation. No substantive changes have been made in the final rule.

[END OF PREAMBLE TEXT]

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

[BEGIN PREAMBLE TEXT]

Paragraph (b) states that procurement of products complying with this part is subject to commercial availability. The concept of commercial availability is based on existing provisions in the FAR (see 48 CFR 2.101, Definitions of Words and Terms: Commercial item).

The proposed rule provided that the standards applied to products which were available in the commercial marketplace; would be available in time to meet an agency's delivery requirements through advances in technology or performance; or were developed in response to a Government solicitation. As noted in the preamble, this language was derived from the definition for "commercial item" in the FAR cited above. The preamble to the proposed rule stated that the determination of commercial availability is to be applied on a provision by provision basis.

Comment. A number of commenters sought further clarification of this provision. Several commenters from the information technology industry and some Federal agencies were concerned that the concept of what is commercially available was more appropriately within the jurisdiction of the Federal Acquisition Regulatory Council. The American Foundation for the Blind (AFB) and the ACB wanted agencies to document their determination that a product was not commercially available similar to what is required under undue burden. The ITAA commented that commercial availability should not be applied on a provision by provision basis.

Response. The Board agrees that the FAR is the appropriate venue for addressing commercial availability. The Board believes that the concept of commercial availability is captured in the FAR definition of "commercial item".

With respect to documentation, Federal agencies may choose to document a determination that a product is not available in the commercial marketplace in anticipation of a subsequent inquiry. However, such documentation is not required by section 508.

Similar to an undue burden analysis, agencies cannot claim that 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. The final rule has been modified to clarify this application.

[END OF PREAMBLE TEXT]

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

[BEGIN PREAMBLE TEXT]

Paragraph (c) applies this rule to electronic and information technology developed, procured, maintained, or used by an agency directly or used by a contractor pursuant to a contract with an agency.

Comment. The ITAA commented that this provision conflicts with section 508. For example, they commented that if a contract required a vendor to purchase and maintain a specific computer system for the purpose of gathering and relaying certain data to an agency, the standards would apply to such a computer system even if the system would be used only by vendor employees. In addition, ITAA commented that this is not a technical and functional performance criterion, and should be addressed by the FAR.

Response. Consistent with section 5002(3)(C) of the Clinger-Cohen Act of 1996 (40 U.S.C. 1452) and as further discussed in section 1194.3(b) below, products used by a contractor which are incidental to a contract are not covered by this rule. For example, a Federal agency enters into a contract to have a web site developed for the agency. The contractor uses its own office system to develop the web site. The web site is required to comply with this rule since the web site is the purpose of the contract, however, the contractor's office system does not have to comply with these standards, since the equipment used to produce the web site is incidental to the contract. See section 1194.3(b) below. No changes were made to this provision in the final rule.

[END OF PREAMBLE TEXT]

§ 1194.3 General exceptions.

[BEGIN PREAMBLE TEXT]

this section provides general exceptions from the standards

[END OF PREAMBLE TEXT]

(a) 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).

[BEGIN PREAMBLE TEXT]

Paragraph (a) provides an exception for telecommunications or information systems 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. This exception is statutory under section 508 and is consistent with a similar exception in section 5142 of the Clinger-Cohen Act of 1996. This exception does not apply to a system that is to be used for routine administrative and business applications (including payroll, finance, logistics, and personnel management applications). For example, software used for payroll, word processing software used for production of routine documents, ordinary telephones, copiers, fax machines, and web applications must still comply with the standards even if they are developed, procured, maintained, or used by an agency engaged in intelligence or military activities. The Board understands that the Department of Defense interprets this to mean that a computer designed to provide early missile launch detection would not be subject to these standards, nor would administrative or business systems that must be architecturally tightly coupled with a mission critical, national security system, to ensure interoperability and mission accomplishment. No substantive comments were received and no changes have been made to this section in the final rule.

[END OF PREAMBLE TEXT]

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

[BEGIN PREAMBLE TEXT]

Paragraph (b) provides an exception for electronic and information technology that is acquired by a contractor incidental to a Federal contract. That is, the products a contractor develops, procures, maintains, or uses which are not specified as part of a contract with a Federal agency are not required to comply with this part. For example, a consulting firm that enters into a contract with a Federal agency to produce a report is not required to procure accessible computers and word processing software to produce the report regardless of whether those products were used exclusively for the government contract or used on both government and non-government related activities since the purpose of the contract was to procure a report. Similarly, if a firm is contracted to develop a web site for a Federal agency, the web site created must be fully compliant with this part, but the firm's own web site would not be covered. No substantive comments were received and no changes have been made to this section in the final rule.

[END OF PREAMBLE TEXT]

(c) 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.

[BEGIN PREAMBLE TEXT]

Paragraph (c) clarifies that, except as required to comply with these standards, 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. Specific accessibility related software means software which has the sole function of increasing accessibility for persons with disabilities to other software programs (e.g., screen magnification software). The purpose of section 508 and these standards is to build as much accessibility as is reasonably possible into general products developed, procured, maintained, or used by agencies. It is not expected that every computer will be equipped with a refreshable Braille display, or that every software program will have a built-in screen reader. Such assistive technology may be required as part of a reasonable accommodation for an employee with a disability or to provide program accessibility. To the extent that such technology is necessary, products covered by this part must not interfere with the operation of the assistive technology. No substantive comments were received and no changes have been made to this section in the final rule.

[END OF PREAMBLE TEXT]

(d) 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.

[BEGIN PREAMBLE TEXT]

Paragraph (d) specifies that when agencies provide access to information or data to the public through electronic and information technology, agencies are not required to make equipment 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 equipment 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. For example, if an agency provides an information kiosk in a Post Office, a means to access the kiosk information for a person with a disability need not be provided in any location other than at the kiosk itself.

Comment. The ACB commented that where a location is not accessible, an agency must provide the information in a location that is accessible to people with disabilities.

Response. This paragraph restates the general statutory requirement that when agencies provide access to information or data to the public through electronic and information technology, the agencies are not required to make equipment 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 equipment 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. The accessibility of the location would be addressed under section 504 of the Rehabilitation Act or other Federal laws. No substantive changes were made in the final rule.

[END OF PREAMBLE TEXT]

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

[BEGIN PREAMBLE TEXT]

Paragraph (e) states that compliance with this part does not require a fundamental alteration in the nature of a product or service or its components.

Comment. The AFB commented that fundamental alteration is not an appropriate factor to include in this rule since the statute provides undue burden as the proper protection and allowing a fundamental alteration exemption weakens the intent of the statute and its high expectations of government. If the concept of fundamental alteration is maintained, AFB recommended that it be part of an explanation of undue burden. The Department of Commerce agreed that the inclusion of a fundamental alteration exception would negate the purpose of section 508. The Trace Research and Development Center said that the term should be defined.

The Information Technology Industry Council (ITIC) commented that the Board should expand the concept of fundamental alteration by stating that an agency should not be required to fundamentally alter the nature of a program or service that the agency offers.

Response. Fundamental alteration is an appropriate exception for inclusion in the standards. It means a change in the fundamental characteristic or purpose of the product or service, not merely a cosmetic or aesthetic change. For example, an agency intends to procure pocket-sized pagers for field agents for a law enforcement agency. Adding a large display to a small pager may fundamentally alter the device by significantly changing its size to such an extent that it no longer meets the purpose for which it was intended, that is to provide a communication device which fits in a shirt or jacket pocket. For some of these agents, portability of electronic equipment is a paramount concern. Generally, adding access should not change the basic purpose or characteristics of a product in a fundamental way.

Comment. The ITAA commented that telecommunications equipment switches, servers, and other similar "back office" equipment which are used for equipment maintenance and administration functions should be exempt from the standards. For example, in the case of telecommunications equipment, technicians might need to configure service databases, remove equipment panels to replace components, or run tests to verify functionality. ITAA commented that section 508 should not apply to these types of products since applying requirements to such products would have serious design and cost ramifications.

Response. The Board agrees and has provided an exception that 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. This exception is consistent with a similar exception in the Board's guidelines under the Americans with Disabilities Act (ADA) (§4.1.1 (5)(b) 36 CFR part 1191) and the Architectural Barriers Act (§4.1.2 (5) exception, Uniform Federal Accessibility Standards Appendix A to 41 CFR part 101-19.6).

[END OF PREAMBLE TEXT]

(f) 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.

§ 1194.4 Definitions.

The following definitions apply to this part:

[BEGIN PREAMBLE TEXT]

Accessible. The term accessible was defined in the proposed rule in terms of compliance with the standards in this part, as is common with other accessibility standards. As proposed, if a product complies with the standards in this part, it is "accessible"; if it does not comply, it is not accessible.

Comment. The Trace Research and Development Center (Trace Center) and the General Services Administration commented that the proposed definition of accessible would mean that products can be declared "accessible" if they are merely compatible with assistive technology and that the definition of accessible was being used as a measure of compliance. The Trace Center commented that the problem with this approach is that a product could have few or no accessibility features because it was an undue burden and still be considered accessible.

Response. Although the term accessible was used sparingly in the proposed rule, the Board agrees that the definition may be problematic. The term as used in the proposed rule was in fact addressing products which comply with the standards. Products covered by this part are required to comply with all applicable provisions of this part. Accordingly, the definition has been eliminated in the final rule and the term accessible is not used in the text of the final rule. A product is compliant with the requirements of section 508 of the Rehabilitation Act of 1973 (as amended by the Workforce Investment Act of 1998) by meeting all the applicable provisions of part 1194.

[END OF PREAMBLE TEXT]

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

[BEGIN PREAMBLE TEXT]

Agency. The term agency includes any Federal department or agency, including the United States Postal Service. No substantive comments were received regarding this definition and no changes have been made in the final rule.

[END OF PREAMBLE TEXT]

Alternate formats. Alternate formats usable by people with disabilities may include, but are not limited to, Braille, ASCII text, large print, recorded audio, and electronic formats that comply with this part.

[BEGIN PREAMBLE TEXT]

Alternate formats. Certain product information is required to be made available in alternate formats to be usable by individuals with various disabilities. Consistent with the Board's Telecommunications Act Accessibility Guidelines (36 CFR part 1193), the proposed rule defined alternate formats as those formats which are usable by people with disabilities. The proposed definition noted that the formats may include Braille, ASCII text, large print, recorded audio, and accessible internet programming or coding languages, among others. ASCII refers to the American Standard Code for Information Interchange, which is an American National Standards Institute (ANSI) standard defining how computers read and write commonly used letters, numbers, punctuation marks, and other codes.

Comment. One commenter was concerned that the term "accessible internet programming or coding languages" used in the description of acceptable alternate formats was somewhat ambiguous and recommended using the term "accessible internet formats".

Response. The Board agrees that the term "accessible internet programming or coding languages" may be vague. In addition, as noted above, the final rule will not include the term "accessible". The definition for alternate formats has been modified to refer to "electronic formats which comply with this part". This change will permit, for instance, alternate formats to include a computer file (either on the internet or saved on a computer disk) that can be viewed by a browser and which complies with the standards for web pages. No other changes have been made to the definition in the final rule.

[END OF PREAMBLE TEXT]

Alternate methods. Different means of providing information, including product documentation, to people with disabilities. Alternate methods may include, but are not limited to, voice, fax, relay service, TTY, Internet posting, captioning, text-to-speech synthesis, and audio description.

[BEGIN PREAMBLE TEXT]

Alternate methods. The proposed rule used the term "alternate modes" which was defined as different means of providing information to users of products, including product documentation, such as voice, fax, relay service, TTY, internet posting, captioning, text-to-speech synthesis, and audio description.

Comment. One commenter suggested that "alternate methods" would be a better term to describe the different means of providing information. The commenter was concerned that the term alternate modes would be confused with alternate modes of operation of the product itself which does not necessarily refer to how the information is provided.

Response. The Board agrees that the term alternate methods is a more descriptive and less confusing term than the term alternate modes. Other than the change in terminology from alternate modes to alternate methods, no other changes have been made to the definition in the final rule.

[END OF PREAMBLE TEXT]

Assistive technology. 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.

[BEGIN PREAMBLE TEXT]

Assistive technology. Assistive technology is defined as 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. The definition was derived from the definition of assistive technology in the Assistive Technology Act of 1998 (29 U.S.C. 3002). The preamble to the proposed rule noted that assistive technology may include screen readers which allow persons who cannot see a visual display to either hear screen content or read the content in Braille, specialized one-handed keyboards which allow an individual to operate a computer with only one hand, and specialized audio amplifiers that allow persons with limited hearing to receive an enhanced audio signal. No substantive comments were received regarding this definition and no changes have been made in the final rule.

[END OF PREAMBLE TEXT]

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 the principal function of which is not the acquisition, storage, manipulation, management, movement, control, display, switching, interchange, transmission, or reception of data or information. For example, HVAC (heating, ventilation, and air conditioning) equipment such as thermostats or temperature control devices, and medical equipment where information technology is integral to its operation, are not information technology.

[BEGIN PREAMBLE TEXT]

Electronic and information technology. This is the statutory term for the products covered by the standards in this part. The statute explicitly required the Board to define this term, and required the definition to be consistent with the definition of information technology in the Clinger-Cohen Act of 1996. The Board's proposed definition of information technology was identical to that in the Clinger-Cohen Act. Electronic and information technology was defined in the proposed rule to include information technology, as well as any equipment or interconnected system or subsystem of equipment, that is used in the creation, conversion, or duplication of data or information.

Information technology includes computers, ancillary equipment, software, firmware and similar procedures, services (including support services), and related resources. Electronic and information technology includes information technology products like those listed above as well as telecommunications products (such as telephones), information kiosks and transaction machines, World Wide Web sites, multimedia, and office equipment such as copiers, and fax machines.

Consistent with the FAR,⁽⁴⁾ the Board proposed that electronic and information technology not include any equipment that contains embedded information technology that is used as an integral part of the product, but the principal function of which is not the acquisition, storage, manipulation, management, movement, control, display, switching, interchange, transmission, or reception of data or information. For example, HVAC (heating, ventilation, and air conditioning) equipment such as thermostats or temperature control devices, and medical equipment where information technology is integral to its operation, are not information technology.

Comment. Several commenters recommended that the exception for HVAC control devices and medical equipment be revised in the final rule. The commenters were concerned that the exception was too broad in that it exempted equipment such as medical diagnostic equipment that they felt should be covered by the rule. In addition, the National Association of the Deaf (NAD) requested that public address systems, alarm systems, and two-way communications systems such as intercoms be expressly included as electronic and information technology.

Response. The exemption is consistent with existing definitions for information technology in the FAR. Public address systems, alarm systems, and two-way communications systems are already addressed by the Americans with Disabilities Act Accessibility Guidelines and will be addressed in more detail in the Board's guidelines under the Architectural Barriers Act which apply to Federal facilities. No changes have been made to the definition in the final rule.

[END OF PREAMBLE TEXT]

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.

[BEGIN PREAMBLE TEXT]

Information technology. The definition of information technology is identical to that in the Clinger-Cohen Act, that is, 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. Information technology includes computers, ancillary equipment, software, firmware and similar procedures, services (including support services), and related resources. No substantive comments were received regarding this definition and no changes have been made in the final rule.

[END OF PREAMBLE TEXT]

Operable controls. A component of a product that requires physical contact for normal operation. Operable controls include, but are not limited to, mechanically operated controls, input and output trays, card slots, keyboards, or keypads.

[BEGIN PREAMBLE TEXT]

Operable controls. The proposed rule defined operable controls as those components of a product that require physical contact for normal operation of the device. Examples of operable controls were provided, including on/off switches, buttons, dials and knobs, mice, keypads and other input devices, copier paper trays (both for inserting paper to be copied and retrieving finished copies), coin and card slots, card readers, and similar components. The proposed rule also clarified that operable controls do not include voice-operated controls.

Comment. One commenter was concerned that the term paper trays was confusing and interpreted it to mean the large trays on a copier which are loaded with reams of paper for copying. The commenter suggested that the term input and output trays be used instead.

Response. The Board agrees that input and output trays are more descriptive. The final rule reflects this change which is intended to apply to products in their normal operation rather than when the product may be used for maintenance, repair, or occasional monitoring. For example, a user should be able to add paper to a desktop laser printer. No other changes have been made to this definition.

[END OF PREAMBLE TEXT]

Product. Electronic and information technology.

[BEGIN PREAMBLE TEXT]

Product. The term product is used in the rule as a shorthand for electronic and information technology. No substantive comments were received regarding this definition and no changes have been made in the final rule.

[END OF PREAMBLE TEXT]

Self Contained, Closed Products. Products that generally have embedded software and are commonly designed in such a fashion that a user cannot easily attach or install assistive technology. These products include, but are not limited to, information kiosks and information transaction machines, copiers, printers, calculators, fax machines, and other similar types of products.

[BEGIN PREAMBLE TEXT]

Self contained, closed products. This term was not used in the proposed rule and is provided in the final rule as a result of the reorganization of the standards. Self contained, closed products, are those that generally have embedded software and are commonly designed in such a fashion that a user cannot easily attach or install assistive technology. These products include, but are not limited to, information kiosks and information transaction machines, copiers, printers, calculators, fax machines, and other similar types of products.

[END OF PREAMBLE TEXT]

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

[BEGIN PREAMBLE TEXT]

Telecommunications. The definition for telecommunications is consistent with the definition in the Board's Telecommunications Act Accessibility Guidelines and the definition of telecommunications in the Telecommunications Act. No substantive comments were received regarding this definition and no changes have been made in the final rule.

[END OF PREAMBLE TEXT]

TTY. An abbreviation for teletypewriter. Machinery or equipment that employs interactive text based communications through the transmission of coded signals across the telephone network. TTYs may include, for example, devices known as TDDs (telecommunication display devices or telecommunication devices for deaf persons) or computers with special modems. TTYs are also called text telephones.

[BEGIN PREAMBLE TEXT]

TTY. TTYs are machinery or equipment that employ interactive text based communications through the transmission of coded signals across the telephone network.

Comment. The Trace Center recommended adding the word "baudot" to the definition of TTY to clarify that the term is not meant to be broader than baudot TTYs. The NAD and other consumer groups, however, supported the Board's definition and encouraged the Board to use the same definition consistently.

Response. The definition for the term TTY is consistent with the definition of TTY in the Board's ADA Accessibility Guidelines and Telecommunications Act Accessibility Guidelines. No changes have been made to the definition in the final rule.

[END OF PREAMBLE TEXT]

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

[BEGIN PREAMBLE TEXT]

Undue burden. The final rule defines the term undue burden as "significant difficulty or expense." In determining what is a significant difficulty or expense, each agency must consider the resources available to the program or component for which the product is being developed, maintained, used or procured. The proposed rule defined undue burden as an action that would result in significant difficulty or expense considering all agency resources available to the agency or component. The Board sought comment in the NPRM on two additional factors (identified as factor (2) and factor (3) in the preamble) for agencies to consider in assessing a determination of an undue burden. Factor (2) addressed the compatibility of an accessible product with the agency's or component's infrastructure, including security, and the difficulty of integrating the accessible product. Factor (3) concerned the functionality needed from the product and the technical difficulty involved in making the product accessible.

Comment. The ITAA, ITIC and the Oracle Corporation opposed the inclusion of a definition for undue burden in the final rule. Both the ITAA and the ITIC commented that defining undue burden was beyond the Board's authority. Oracle suggested that the concept of undue burden under section 508 was beyond the Board's expertise in that it was a procurement matter. The commenters were also concerned that the Board's definition was too narrow. Alternatively, if the Board was to adopt a definition for undue burden, the ITAA favored adoption of the factors associated with undue burden and undue hardship in the ADA and section 504 of the Rehabilitation Act. In particular, the ITAA recommended adoption of the "nature and cost" of the accommodation as a factor for consideration. ITIC favored adoption of the employment factors in title I of the ADA if the Board were to include a definition of undue burden. Both the ITAA and the ITIC also favored the adoption of factors (2) and (3) identified in the NPRM if undue burden was to be addressed in the final rule.

The remainder and majority of the commenters did not address the issue of whether the Board should adopt a definition of undue burden, but rather how to define it. At least two Federal agencies and 10 organizations representing persons with disabilities opposed the inclusion of factors (2) and (3) suggested in the NPRM. The Department of Commerce and a majority of advocacy organizations representing people with disabilities opposed factors (2) and (3) on the grounds that the factors would create a loophole for agencies to avoid compliance with section 508. The Department of Veterans Affairs opposed factor (3) as it considered that factor to be more about job assignment than undue burden. Several commenters including Sun Microsystems and Adobe Systems favored adopting factors (2) and (3) in the definition of undue burden. The Social Security Administration (SSA) and the Department of Health and Human Services, Administration for Children and Families, sought guidance as to the amount of increased cost of a product that would not constitute undue burden regardless of an agency's overall budget. Citing the example of a product that would cost 25 percent more to comply with the standards, the SSA questioned whether that would be undue or would 10 percent or 50 percent be considered undue. The General Services Administration recommended basing the financial resources available to an agency on a program basis.

Response. The term undue burden is based on caselaw interpreting section 504 of the Rehabilitation Act (Southeastern Community College v. Davis, 442 U.S. 397 (1979)), and has been included in agency regulations issued under section 504 since the Davis case. See, e.g., 28 CFR 39.150. The term undue burden is also used in Title III of the ADA, 42 U.S.C. 12182 (b)(2)(A)(iii). The legislative history of the ADA states that the term undue burden is derived from section 504 and the regulations thereunder, and is analogous to the term "undue hardship" in Title I of the ADA, which Congress defined as "an action requiring significant difficulty or expense." 42 U.S.C. 12111(10)(A). See, H. Rept. 101-485, pt. 2, at 106. In the NPRM, the Board proposed adoption of "significant difficulty or expense" as the definition for undue burden. No changes were made to that aspect of the definition in the final rule.

Title I of the ADA lists factors to be considered in determining whether a particular action would result in an undue hardship. 42 U.S.C. 12111(10)(B)(i)-(iv). However, since title I of the ADA addresses employment and the individual accommodation of employees, not all of the factors are directly applicable to section 508 except for the financial resources of the covered facility or entity which is necessary to a determination of "significant difficulty or expense." Unlike title I, section 508 requires that agencies must procure accessible electronic and information technology regardless of whether they have employees with disabilities. Requiring agencies to purchase accessible products at the outset eliminates the need for expensive retrofitting of an existing product when requested by an employee or member of the public as a reasonable accommodation at a later time.

In determining whether a particular action is an undue burden under section 508, the proposed rule provided that the resources "available" to an "agency or component" for which the product is being developed, procured, maintained, or used is an appropriate factor to consider. The language was derived from the section 504 federally conducted regulations. Those regulations limited the consideration of resources to those resources available to a "program". The preamble to the proposed rule noted that an agency's entire budget may not be available for purposes of complying with section 508. Many parts of agency budgets are authorized for specific purposes and are thus not available to other programs or components within the agency. The definition of undue burden has been clarified in the final rule to more clearly reflect this limitation. The provision now states that "agency resources available to a program or component" are to be considered in determining whether an action is an undue burden. Because available financial resources vary greatly from one agency to another, what constitutes an undue burden for a smaller agency may not be an undue burden for another, larger agency having more resources to commit to a particular procurement. Each procurement would necessarily be determined on a case-by-case basis. Because a determination of whether an action would constitute an undue burden is made on a case-by-case basis, it would be inappropriate for the Board to assess a set percentage for the increased cost of a product that would be considered an undue burden in every case.

The Board has not included factors (2) and (3) in the text of the final rule. While the Board acknowledges that these may be appropriate factors for consideration by an agency in determining whether an action is an undue burden, factors (2) and (3) were not based on established caselaw or existing regulations under section 504. Further, the Board recognizes that undue burden is determined on a case-by-case basis and that factors (2) and (3) may not apply in every determination. Agencies are not required to consider these factors and may consider other appropriate factors in their undue burden analyses.

Comment. Adobe Systems questioned whether a product which does not meet a provision based on a finding of undue burden, has to comply with the remaining provisions.

Response. The undue burden analysis is applied on a provision by provision basis. A separate undue burden analysis must be conducted and, in the case of procurements, be documented for each applicable provision.

[END OF PREAMBLE TEXT]

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

[BEGIN PREAMBLE TEXT]

This section allows the use of designs or technologies as alternatives to those prescribed in this part provided that they result in substantially equivalent or greater access to and use of a product for people with disabilities. This provision is not a "waiver" or "variance" from the requirement to provide accessibility, but a recognition that future technologies may be developed, or existing technologies could be used in a particular way, that could provide the same functional access in ways not envisioned by these standards. In evaluating whether a technology results in "substantially equivalent or greater access," it is the functional outcome, not the form, which is important. For example, an information kiosk which is not accessible to a person who is blind might be made accessible by having a telephone handset that connects to a computer that responds to touch-tone commands and delivers the same information audibly. In addition, voice recognition and activation are progressing rapidly so that voice input soon may become a reasonable substitute for some or all keyboard input functions. For example, already some telephones can be dialed by voice. In effect, compliance with the performance criteria of §1194.31 is the test for equivalent facilitation.

Comment. Commenters supported the Board in its recognition that accessibility may sometimes be attained through products that do not strictly comply with design standards. Several commenters supported this concept because they believed that it will result in the development of better access solutions for individuals with disabilities.

Response. No changes have been made to this provision in the final rule.

[END OF PREAMBLE TEXT]

Subpart B -- Technical Standards

[BEGIN PREAMBLE TEXT]

Comment. Subpart B of the proposed rule contained four sections: §1194.21 (General Requirements); §1194.23 (Component Specific Standards); §1194.25 Standards for Compatibility; and §1194.27 (Functional Performance Criteria). The Board sought comment in the proposed rule on the organization of Subpart B in general and §1194.21 (General Requirements), §1194.23 (Component Specific Requirements) and §1194.25 (Requirements for Compatibility) in particular. A number of commenters found the application of the proposed rule to be confusing due to the manner in which the rule was organized. Commenters questioned whether a specific product need only comply with the provisions under a specific heading in §1194.23 (Component Specific Requirements) or whether they must also look to the provisions in §1194.21 (General Requirements), as well as §1194.25 (Compatibility). Commenters further questioned whether multiple provisions within a specific section would apply. For example, making electronic forms accessible was addressed under §1194.23(b) (Non-embedded software applications and operating systems). Provisions for web sites were addressed separately in §1194.23(c) (Web-based information or applications). Since electronic forms are becoming very popular on web sites, the commenters questioned whether the provisions for electronic forms under the software section should also be applied to web sites even though the section on web sites did not specifically address electronic forms. Another commenter pointed out that some provisions under §1194.21 (General Requirements) actually addressed specific components such as touch screens, which were addressed under General Requirements in the proposed rule. Finally, other commenters noted that several provisions under §1194.23 (Component Specific Requirements) were really compatibility concerns, such as §1194.23(b) (Non-embedded software).

Response. A product must comply with the provisions under each applicable section in Subpart B. For example, a telecommunications product that has computer, software and operating systems, a keyboard, and web browser will have to comply with each of the relevant sections in Subpart B. The Board has reorganized Subpart B in the final rule as follows:

The title of Subpart B has been changed from "Accessibility Standards" to "Technical Standards".

Subpart B has been reorganized so that each section addresses specific products. For example, §1194.21 addresses software applications, §1194.22 addresses web-based intranet and internet information and applications, and so on. Each technical provision that applies to a product is located under that product heading. As a result, there is some redundancy in this section. However, the Board believes that this format will help clarify the application of the standards for each type of product. For example, the provision prohibiting the use of color alone to indicate an action applies not only to web page design, but also to software design and certain operating systems. In the final rule, it is addressed in §1194.21(i) (Software applications and operating systems), §1194.22(c) (Web-based intranet and internet information and applications), as well as §1194.25(g) (Self contained, closed products).

The provisions contained in §1194.21 (General Requirements), §1194.23 (Component Specific Requirements) and §1194.25 (Requirements for Compatibility with Assistive Technology) of the proposed rule have been moved to the new subpart B (Technical Standards) in the final rule.

Also, the provisions in the proposed rule under §1194.27 (Functional Performance Criteria) have been redesignated as Subpart C (Functional Performance Criteria) in the final rule. Subpart C provides functional performance criteria for overall product evaluation and for technologies or components for which there is no specific provision in subpart B. The substance of each of the provisions in the final rule are discussed below.

[END OF PREAMBLE TEXT]

§ 1194.21 Software applications and operating systems.

[BEGIN PREAMBLE TEXT]

Paragraphs (a) through (l) address provisions for software applications and operating systems. Electronic and information technology products operate by following programming instructions referred to as software. Software refers to a set of logical steps (or programming instructions) that control the actions or operations of most forms of electronic and information technology products. For instance, when a pager receives a radio signal, the software embedded inside the pager determines whether the signal is a "page" and how it should display the information it receives. The circuitry inside the pager, including the display unit, merely follows the instructions encoded in the software. Software can be divided into two broad categories: software that is embedded in a chip mounted in a product and non-embedded software that is loaded onto a storage device such as a hard disk and can be erased, replaced, or updated. For instance, a word processing program that is installed onto a computer's hard drive and which may be easily erased, replaced, or updated is typically "non-embedded" software. By contrast, the set of instructions installed on a chip inside a pager and which cannot be erased, replaced, or updated is typically embedded software. The proposed rule included provisions for non-embedded software. However, as pointed out by commenters, as technology changes, the distinction between embedded software and non-embedded software is increasingly becoming less clear. These provisions apply to all software products.

[END OF PREAMBLE TEXT]

(a) When software is designed to run on a system that has a keyboard, product functions shall be executable from a keyboard where the function itself or the result of performing a function can be discerned textually.

[BEGIN PREAMBLE TEXT]

Paragraph (a) requires that when software is designed to run on a system that has a keyboard, the software shall provide a way to control features which are identifiable by text, from the keyboard. For example, if a computer program included a "print" command or a "save" command (both can be readily discerned textually), the program must provide a means of invoking these commands from the keyboard. For people who cannot accurately control a mouse, having access to the software's controls through keyboard alternatives is essential. For example, rather than pointing to a particular selection on the screen, a user may move through the choices in a dialogue box by pressing the tab key. (See §1194.23(a)(4) and §1194.23(b)(1) in the NPRM.)

Comment. The NPRM required that products must provide logical navigation among interface elements through the use of keystrokes. Commenters questioned the meaning of "logical" and whether the provisions, as proposed, were requiring that each system have a keyboard. Commenters were concerned that requiring that all features of every software program be accessible from a keyboard was not feasible because some programs that allow an individual to draw lines and create designs using a mouse could not be replicated with keystrokes.

Response. This provision applies to products which are intended to be run on a system with a keyboard. It does not require that a keyboard be added. The term "logical navigation" has been deleted. Only those actions which can be discerned textually are required to be executable from a keyboard. For example, most of the menu functions in common drawing programs that allow a user to open, save, size, rotate, and perform other actions on a graphic image can all be performed from the keyboard. However, providing keyboard alternatives for creating an image by selecting a paintbrush, picking a color, and actually drawing a design would be extremely difficult. Such detailed procedures require the fine level of control afforded by a pointing device (e.g., a mouse) and thus cannot be discerned textually without a lengthy description. Accordingly, in the final rule, keyboard alternatives are required when the function (e.g., rotate figure) or the result of performing a function (e.g., save file confirmation) can be represented with words.

[END OF PREAMBLE TEXT]

[BEGIN GUIDE TEXT]

Why is keyboard access to software required? Software drop-down menu that includes alternate keyboard commands
When keyboard access to a programs' controls and features is provided, a person who cannot use a mouse or other pointing device will still be able to run the product. For example, a person with a disability that affects dexterity may find it impossible to move or hold a pointing device with enough accuracy to activate desired features. A person who cannot see the screen, therefore relying on assistive technology, may have no problems moving the pointer but will be unable to determine what is being pointed to.

Does this provision prohibit the use of "mouse-only" functions in any software?
All actions that can be identified or labeled with text are required to be executable from a keyboard. For example, most of the menu functions even in common drawing programs that allow a user to open, save, size, rotate, and perform other actions on a graphic image can all be performed from the keyboard. However, providing keyboard alternatives for creating an image by selecting a "drawing tool", picking a color, and actually drawing a design would be extremely difficult. Such procedures require the precise level of control afforded by a pointing device (e.g., a mouse) and cannot be given text labels because there is no way to predict what action the user plans to perform. Therefore, when a programmer is determining which functions need keyboard access, the best rule of thumb is to add keyboard shortcuts to any feature where the function can be identified with a text label.

Many applications utilize toolbars with buttons. Do these buttons all need keyboard access?
Not necessarily. Most toolbars give a visual shortcut to functions that also exist in the menu structure of a program. If the feature activated by a control on a toolbar is a duplicate of a menu function that already has a keyboard shortcut then the toolbar control does not need its own keyboard access. However, if the control on the toolbar is unique and cannot be accessed in any other way, the control will be required to have a keyboard shortcut. Although not in the toolbar, a scroll feature which is not available in a menu bar must have keyboard alternatives. Typically, the use of the page up, and page down keys will provide keyboard access to scroll bars.

[END OF GUIDE TEXT]

(b) Applications shall not disrupt or disable activated features of other products that are identified as accessibility features, where those features are developed and documented according to industry standards. Applications also shall not disrupt or disable activated features of any operating system that are identified as accessibility features where the application programming interface for those accessibility features has been documented by the manufacturer of the operating system and is available to the product developer.

[BEGIN PREAMBLE TEXT]

Paragraph (b) prohibits applications from disrupting or disabling activated features of other products that are identified as accessibility features, where those features are developed and documented according to industry standards. Applications also shall not disrupt or disable activated features of any operating system that are identified as accessibility features where the application programming interface for those accessibility features has been documented by the manufacturer of the operating system and is available to the product developer. The application programming interface refers to a standard way for programs to communicate with each other, including the operating system, and with input and output devices. For instance, the application programming interface affects how programs have to display information on a monitor or receive keyboard input via the operating system.

Many commercially available software applications and operating systems have features built-into the program that are labeled as access features. These features can typically be turned on or off by a user. Examples of these features may include, reversing the color scheme (to assist people with low vision), showing a visual prompt when an error tone is sounded (to assist persons who are deaf or hard of hearing), or providing "sticky keys" that allow a user to press key combinations (such as control-C) sequentially rather than simultaneously (to assist persons with dexterity disabilities). This provision prohibits software programs from disabling these features when selected. (See §1194.23(b)(2) in the NPRM.)

Comment. The proposed rule only specified that software not interfere with features that affect the usability for persons with disabilities. Commenters from industry noted that the provision in the NPRM did not provide any method of identifying what features are considered access features and further stated that this provision was not achievable. These commenters pointed out that it was impossible for a software producer to be aware of all of the features in all software packages that could be considered an access feature by persons with disabilities. Sun Microsystems recommended that this provision address access features that have been developed using standard programming techniques and that have been documented by the manufacturer.

Response. This provision has been modified in the final rule to reference access features which have been developed and documented according to industry standards. No other changes have been made in the final rule.

[END OF PREAMBLE TEXT]

[BEGIN GUIDE TEXT]

What is the application programming interface?
The application programming interface, (API) refers to a standard way for programs to communicate with each other, including the operating system, and with input and output devices. For instance, the application programming interface affects how programs display information on a monitor or receive keyboard input via the operating system.

What are accessibility features?
Many commercially available software applications and operating systems have features built into the program that are labeled as accessibility features. These features can typically be turned on or off by a user. Examples of these features include: reversing the color scheme (to assist people with low vision), showing a visual prompt when an error tone is sounded (to assist persons who are deaf or hard of hearing), or providing "sticky keys" that allow a user to press key combinations (such as control-C) sequentially rather than simultaneously (to assist persons with dexterity disabilities). This requirement prohibits software programs from disabling these features when they have been activated prior to running the application.

[END OF GUIDE TEXT]

(c) A well-defined on-screen indication of the current focus shall be provided that moves among interactive interface elements as the input focus changes. The focus shall be programmatically exposed so that assistive technology can track focus and focus changes.

[BEGIN PREAMBLE TEXT]

Paragraph (c) requires that software applications place on the screen a visual indication of where some action may occur if a mouse click or keystroke takes place. This point on a screen indicating where an action will take place is commonly referred to as the "focus". This provision also requires that the focus be readable by other software programs such as screen readers used by computer users who are blind. (See §1194.23(b)(3) in the NPRM.) No substantive comments were received and no changes have been made to this section in the final rule.

[END OF PREAMBLE TEXT]

[BEGIN GUIDE TEXT]

What is the importance of the focus for assistive technology?
The position on a screen where an action will take place is referred to as the "focus". For example, when a menu item in a program is highlighted - meaning that if the user clicks the mouse or presses the enter key - the feature will activate and that item has the focus. Providing a visual indication of the focus allows someone who is viewing the screen to accurately access the programs' features. When a computer is being operated by a person who is also running a screen enlargement program or a speech or Braille output system, the assistive technology must discern the focus point. This provision requires that the position of the programs' focus be made available through its code to assistive technology. When, for example, a screen enlargement program magnifies a section of the screen, it must be able to follow the focus as the focus changes. If the magnified area does not move with the focus, the user may easily move down through a list of choices with the arrow keys but the magnified area remains stationary and very shortly the user has no idea what items will be activated if an action is taken.

[END OF GUIDE TEXT]

(d) Sufficient information about a user interface element including the identity, operation and state of the element shall be available to assistive technology. When an image represents a program element, the information conveyed by the image must also be available in text.

[BEGIN PREAMBLE TEXT]

Paragraph (d) requires that software programs, through the use of program code, make information about the program's controls readable by assistive technology. Simply stated, this paragraph requires that information that can be delivered to or received from the user must be made available to assistive technology, such as screen reading software. Examples of controls would include button checkboxes, menus, and toolbars. For assistive technology to operate efficiently, it must have access to the information about a program's controls to be able to inform the user of the existence, location, and status of all controls. If an image is used to represent a program function, the information conveyed by the image must also be available in text. (See §1194.23(b)(4) and §1194.23(b)(5) in the NPRM.) No substantive comments were received and no changes have been made to this section, other than editorial changes.

[END OF PREAMBLE TEXT]

[BEGIN GUIDE TEXT]

What is considered a "user interface element"?
Examples of user interface elements include button checkboxes, menus, toolbars, scroll bars, and any other feature of a program that is intended to allow the user to perform some action.

What does this provision require to be done with these elements?
This provision requires that text must be associated with each element. The text must identify the element and its current state or condition. For example, a button that shows a hand for getting more help must have the word "help" associated with the button. If a checkbox is present, a text label must indicate what is being checked, and whether the checkbox is checked or unchecked. There are many ways to accomplish this depending on the program language being used.

[END OF GUIDE TEXT]

(e) When bitmap images are used to identify controls, status indicators, or other programmatic elements, the meaning assigned to those images shall be consistent throughout an application's performance.

[BEGIN PREAMBLE TEXT]

Paragraph (e) requires that when bitmap images are used by a program to identify programmatic features, such as controls, the meaning of that image shall not change during the operation of a program. "Bitmap images" refer to a type of computer image commonly used in "icons" (e.g., a small picture of a printer to activate the print command). Most screen reading programs allow users to assign text names to bitmap images. If the bitmap image changes meaning during a program's execution, the assigned identifier is no longer valid and is confusing to the user. (See §1194.23(b)(6) in the NPRM.)

Comment. As proposed, this provision did not identify which images had to remain consistent during the application. The AFB commented that the provision should be modified to indicate the type of image that needs to hold a consistent meaning during the running of an application. AFB noted that this provision should apply only to those bitmaps that represent a program function, and not to all images.

Response. The final rule applies the provision to those images which are used to identify controls, status indicators, or other programmatic elements. No other changes have been made to this section in the final rule.

[END OF PREAMBLE TEXT]

[BEGIN GUIDE TEXT]

What forms of bitmap images are affected by this provision?
This provision applies to those images which are used to indicate an action. An image used strictly for decoration is not covered by this provision.

Why is the provision important for accessibility?
Most screen reading programs allow users to assign text names to bitmap images. If the bitmap image changes meaning during a program's execution, the assigned identifier is no longer valid and is confusing to the user.

[END OF GUIDE TEXT]

(f) Textual information shall be provided through operating system functions for displaying text. The minimum information that shall be made available is text content, text input caret location, and text attributes.

[BEGIN PREAMBLE TEXT]

Paragraph (f) provides that software programs use the functions provided by an operating system when displaying text. The operating system is the "core" computer software that controls basic functions, such as receiving information from the keyboard, displaying information on the computer screen, and storing data on the hard disk. Other software programs use the standard protocols dictated by the operating system for displaying their own information or processing the output of other computer programs. When programs are written using unique schemes for writing text on the screen or use graphics, other programs such as software for assistive technology may not be able to interpret the information. This provision does not prohibit or limit an application programmer from developing unique display techniques. It requires that when a unique method is used, the text be consistently written throughout the operating system. (See §1194.23(b)(7) in the NPRM.)

Comment. The proposed rule did not specify that software programs must use the functions provided by an operating system when displaying text. The NPRM required that the text would be provided through an application programming interface that supported interaction with assistive technology or that it would use system text writing tools. Commenters raised several concerns regarding this provision. Some commenters were concerned that without a recognized interface standard, there was no assurance that assistive technology would be able to access the text provided by an application. Software producers felt that the provision should not unduly restrict how programs create or display text. Baum Electronics and GW Micro pointed out that the only way to ensure that both assistive technology and applications are using a common interface, was to use the text displaying functions of the operating system.

Response. The Board agrees that using operating system functions is one approach that would be available to all programmers. The final rule has been modified to require that textual information be provided through the operating system functions so that it will be compatible with assistive technology. This provision does not restrict programmers from developing unique methods of displaying text on a screen. It requires that when those methods are used, the software also sends the information through the operating systems functions for displaying text.

[END OF PREAMBLE TEXT]

[BEGIN GUIDE TEXT]

Can an application programmer develop unique display techniques for writing text on the screen or using graphics?
The operating system is the "core" computer software that controls basic functions, such as receiving information from the keyboard, displaying information on the computer screen, and storing data on the hard disk. Other software programs use the standard protocols dictated by the operating system for displaying their own information or processing the output of other computer programs. When programs are written using unique schemes for writing text on the screen or use graphics, other programs such as software for assistive technology may not be able to interpret the information. This provision does not prohibit or limit an application programmer from developing unique display techniques. It requires that when a unique method is used, the text should also be written to the screen through the operating system.

[END OF GUIDE TEXT]

(g) Applications shall not override user selected contrast and color selections and other individual display attributes.

[BEGIN PREAMBLE TEXT]

Paragraph (g) prohibits applications from overriding user selected contrast and color selections and other individual display attributes. As described above, the operating system provides the basic functions for receiving, displaying, transmitting, or receiving information in a computer or similar product. Thus, the operating system would appear the logical choice for "system-wide" settings that would be respected by all computer programs on a computer. Many modern operating systems incorporate the ability to make settings system-wide as an accessibility feature. This permits, for instance, users to display all text in very large characters. Often, persons with disabilities prefer to select color, contrast, keyboard repeat rate, and keyboard sensitivity settings provided by an operating system. When an application disables these system-wide settings, accessibility is reduced. This provision allows the user to select personalized settings which cannot be disabled by software programs. (See §1194.23(b)(9) in the NPRM.) No substantive comments were received and no changes have been made to this section in the final rule.

[END OF PREAMBLE TEXT]

[BEGIN GUIDE TEXT]

How does this requirement improve accessibility for people with disabilities?
Often, persons with disabilities can increase their efficiency with a system by selecting colors, contrast, keyboard repeat rate, and keyboard sensitivity settings provided by an operating system. When an application disables these system-wide settings, accessibility is reduced. This provision is aimed at allowing users to select personalized settings which cannot be disabled by software programs.

Does this provision mean that programs may not use any custom settings?
This provision allows programs to have unlimited options for customizing the display of the programs' content. However, there must be a section in the software that tells the program not to use its own setting, but to use whatever settings are already in place before the program starts. A simple menu selection, for example under a view, or options menu, might be a checkbox that lets the user check "use system display setting."

[END OF GUIDE TEXT]

(h) When animation is displayed, the information shall be displayable in at least one non-animated presentation mode at the option of the user.

[BEGIN PREAMBLE TEXT]

Paragraph (h) addresses animated text or objects. The use of animation on a screen can pose serious access problems for users of screen readers or other assistive technology applications. When important elements such as push-buttons or relevant text are animated, the user of assistive technology cannot access the application. This provision requires that in addition to the animation, an application provide the elements in a non-animated form. (See §1194.23(b)(11)in the NPRM.) No substantive comments were received and no changes have been made to this section in the final rule.

[END OF PREAMBLE TEXT]

[BEGIN GUIDE TEXT]

How can screen animation affect accessibility for people with disabilities?
The use of animation on a screen can pose serious access problems for users of screen readers or other assistive technology applications. When important elements such as push-buttons or relevant text are animated, the user of assistive technology cannot access the application reliably. This provision requires that in addition to the animation, an application shall provide an option to turn off animation.

[END OF GUIDE TEXT]

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

[BEGIN PREAMBLE TEXT]

Paragraph (i) prohibits the use of color as the single method for indicating important information. For instance, a computer program that requires a user to distinguish between otherwise identical red and blue squares for different functions (e.g., printing a document versus saving a file) would not comply with this provision. Relying on color as the only method for identifying screen elements or controls poses problems, not only for people with limited or no vision, but also for those people who are color blind. This provision does not prohibit the use of color to enhance identification of important features. It does, however, require that some other method of identification, such as text labels, be combined with the use of color. (See §1194.21(a) in the NPRM.) No substantive comments were received and no changes have been made to this section in the final rule.

[END OF PREAMBLE TEXT]

[BEGIN GUIDE TEXT]

How can color coding create accessibility difficulties? Program window with a green button labled "start" with text above: "Press Green button to Start." There is text above an adjacent red button labeled "cancel" that states "Press Red button to Cancel."
A software program that requires a user to distinguish between otherwise identical red and blue squares for different functions (e.g., printing a document versus saving a file) would pose problems for anyone who was color blind and would generally be very difficult to run with assistive technology. Screen reading software can announce color changes. However, this is an "on/off" feature. This means that if a user had to identify a specific color, they would have to have all colors announce which would greatly reduce the usability of the software for that person.

Does the provision prohibit the use of colors?
No. This provision does not prohibit the use of color to enhance identification of important features. It does, however, require that some other method of identification, such as text labels, be combined with the use of color.

[END OF GUIDE TEXT]

(j) When a product permits a user to adjust color and contrast settings, a variety of color selections capable of producing a range of contrast levels shall be provided.

[BEGIN PREAMBLE TEXT]

Paragraph (j) requires software applications to provide users with a variety of color settings that can be used to set a range of contrast levels. (See §1194.23(b)(8) in the NPRM.)

Comment. The NPRM specified a minimum number of color settings. Some commenters were concerned that the proposed provision was too specific, while others felt it was too general because it failed to measure how different levels of contrast would be produced. Several commenters suggested requiring "a wide variety" of color settings as recommended by the EITAAC. One commenter noted that, as proposed, the provision forbids a monochrome display. Commenters also stated that some systems do not provide users with color selection capabilities.

Response. The provision in the final rule is limited to those circumstances where the system allows a user to select colors. This provision requires more than just providing color choices. The available choices must also allow for different levels of contrast. Many people experience a high degree of sensitivity to bright displays. People with this condition cannot focus on a bright screen for long because they will soon be unable to distinguish individual letters. An overly bright background causes a visual "white-out". To alleviate this problem, the user must be able to select a softer background and appropriate foreground colors. The provision has been revised as a performance standard rather than a specific design standard by removing the requirement for 8 foreground and 8 background color selections.

[END OF PREAMBLE TEXT]

[BEGIN GUIDE TEXT]

Do all products have to provide color selections?
No. This provision is applied to those products that already allow a user to adjust screen colors.

What is the desired outcome of this requirement?
This provision requires more than just providing color choices. The available choices must also allow for different levels of contrast. Many people experience a high degree of sensitivity to bright displays. People with this condition cannot focus on a bright screen for long because they will soon be unable to distinguish individual letters. An overly bright background causes a visual "white-out". To alleviate this problem, the user must be able to select a softer background and appropriate foreground colors. On the other hand, many people with low vision can work most efficiently when the screen is set with very sharp contrast settings. Because there is such a variance in individual needs it is necessary for a program to have a variety of color and contrast settings.

[END OF GUIDE TEXT]

(k) Software shall not use flashing or blinking text, objects, or other elements having a flash or blink frequency greater than 2 Hz and lower than 55 Hz.

[BEGIN PREAMBLE TEXT]

Paragraph (k) limits the flashing or blinking rate of screen items. (See §1194.21(c) in the NPRM.)

Comment. The Trace Center expressed concern that research supported a limit of 3 Hz, not 2 Hz as described in the NPRM. Trace suggested that the flash or blink rate avoid any flickering between (but not including) 3 Hz and 55 Hz, which is the power frequency for Europe.

Response. This provision is necessary because some individuals with photosensitive epilepsy can have a seizure triggered by displays which flicker or flash, particularly if the flash has a high intensity and is within certain frequency ranges. The 2 Hz limit was chosen to be consistent with proposed revisions to the ADA Accessibility Guidelines which, in turn, are being harmonized with the International Code Council (ICC)/ANSI A117 standard, "Accessible and Usable Buildings and Facilities", ICC/ANSI A117.1-1998 which references a 2 Hz limit. The Board agrees that an upper limit is needed, since all electrically powered equipment, even an incandescent light bulb, has a "flicker" due to the alternating current line voltage frequency (60 Hz in the U.S., 55 Hz in Europe). There does not appear to be any significant incidence of photosensitive seizures being induced by the line voltage frequency of ordinary lights. Therefore, the provision has been changed to prohibit flash or blink frequencies between 2 Hz and 55 Hz.

[END OF PREAMBLE TEXT]

[BEGIN GUIDE TEXT]

Why are flashing or blinking displays limited by this provision?
This requirement is necessary because some individuals with photosensitive epilepsy can have a seizure triggered by displays that flicker or flash, particularly if the flash has a high intensity and is within certain frequency ranges. The 2 Hz limit was chosen to be consistent with proposed revisions to the ADA Accessibility Guidelines which, in turn, are being harmonized with the International Code Council (ICC)/ANSI A117 standard, "Accessible and Usable Buildings and Facilities", ICC/ANSI A117.1-1998 which references a 2 Hz limit. An upper limit was identified at 55 Hz.

[END OF GUIDE TEXT]

(l) When electronic forms are used, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues.

[BEGIN PREAMBLE TEXT]

Paragraph (l) requires that people with disabilities have access to electronic forms. This section is a result of the reorganization of the final rule and is identical to section 1194.22(n) discussed below. (See §1194.23(b)(10) in the NPRM.)

[END OF PREAMBLE TEXT]

[BEGIN GUIDE TEXT]

Why are electronic forms so difficult for some people with disabilities to access?
At present, the interaction between form controls and screen readers can be unpredictable, depending upon the design of the page containing these controls.

How can forms in a software application meet this provision?
If keyboard alternatives are provided for navigating through a form, and all elements of the form are labeled with text located in close proximity to the field that is to be completed, the form will most likely meet this provision. Attention must be paid to the placement of field labels. On a webpage, a label can have a direct association with a particular field that is indicated in the HTML code. Assistive technology can interpret the HTML and correctly announce the appropriate label. There is no similar method for forms in software programs. Therefore, the label must be in a logical position relative to the input areas. For example, placing labels to the immediate left of where the user is to enter information is by far the most logical position for the label.

[END OF GUIDE TEXT]

§ 1194.22 Web-based intranet and internet information and applications.

[BEGIN PREAMBLE TEXT]

In the proposed rule, the Board indicated that the EITAAC had recommended that the Board's rule directly reference priority one and two checkpoints of the World Wide Web Consortiums' (W3C) Web Accessibility Initiative's (WAI) Web Content Accessibility Guidelines 1.0 (WCAG 1.0). Rather than reference the WCAG 1.0, the proposed rule and this final rule include provisions which are based generally on priority one checkpoints of the WCAG 1.0, as well as other agency documents on web accessibility and additional recommendations of the EITAAC.

Comment. A number of comments were received from the WAI and others expressing concern that the Board was creating an alternative set of standards that would confuse developers as to which standards should be followed. WAI was further concerned that some of the provisions and preamble language in the NPRM were inaccurate. On the other hand, a number of commenters, including the ACB and several members of the EITAAC, supported the manner in which web access issues were addressed in the proposed rule.

Response. The final rule does not reference the WCAG 1.0. However, the first nine provisions in §1194.22, paragraphs (a) through (i), incorporate the exact language recommended by the WAI in its comments to the proposed rule or contain language that is not substantively different than the WCAG 1.0 and was supported in its comments.

Paragraphs (j) and (k) are meant to be consistent with similar provisions in the WCAG 1.0, however, the final rule uses language which is more consistent with enforceable regulatory language. Paragraphs (l), (m), (n), (o), and (p) are different than any comparable provision in the WCAG 1.0 and generally require a higher level of access or prescribe a more specific requirement.

The Board did not adopt or modify four of the WCAG 1.0 priority one checkpoints. These include WCAG 1.0 Checkpoint 4.1 which provides that web pages shall "[c]learly identify changes in the natural language of a document's text and any text equivalents (e.g., captions)."; WCAG 1.0 Checkpoint 14.1 which provides that web pages shall "[u]se the clearest and simplest language appropriate for a site's content."; WCAG 1.0 Checkpoint 1.3 which provides that "[u]ntil user agents can automatically read aloud the text equivalent of a visual track, provide an auditory description of the important information of the visual track of a multimedia presentation."; and WCAG 1.0 Checkpoint 6.2 which provides that web pages shall "[e]nsure that equivalents for dynamic content are updated when the dynamic content changes."

Section 1194.23(c)(3) of the proposed rule required that web pages alert a user when there is a change in the natural language of a page. The "natural language" referred to the spoken language (e.g., English or French) of the web page content. The WAI pointed out that the preamble to the NPRM misinterpreted this provision. The preamble suggested that a statement such as "the following paragraph is in French" would meet the provision. WAI responded by noting that this was not the intent of the provision. The WCAG 1.0 recommend that web page authors embed a code or markup language in a document when the language changes so that speech synthesizers and Braille displays could adjust output accordingly.

The Trace Center advised that only two assistive technology programs could interpret such coding or markup language, Homepage Reader from IBM and PwWebspeak from Isound. These programs contain the browser, screen reading functions, and the speech synthesizer in a single highly integrated program. However, the majority of persons who are blind use a mainstream browser such as Internet Explorer or Netscape Navigator in conjunction with a screen reader. There are also several speech synthesizers in use today, but the majority of those used in the United States do not have the capability of switching to the processing of foreign language phonemes. As a result, the proposed provision that web pages alert a user when there is a change in the natural language of a page has been deleted in the final rule.

The Board also did not adopt WCAG 1.0 Checkpoint 14.1 which provides that web pages shall "[u]se the clearest and simplest language appropriate for a site's content." While a worthwhile guideline, this provision was not included because it is difficult to enforce since a requirement to use the simplest language can be very subjective.

The Board did not adopt WCAG 1.0 Checkpoint 1.3 which provides that "[u]ntil user agents can automatically read aloud the text equivalent of a visual track, provide an auditory description of the important information of the visual track of a multimedia presentation." Although the NPRM did not propose addressing this issue in the web section, there was a similar provision in the multi-media section of the NPRM.

The Board did not adopt WCAG 1.0 Checkpoint 6.2 which provide that web pages shall "[e]nsure that equivalents for dynamic content are updated when the dynamic content changes." The NPRM had a provision that stated "web pages shall update equivalents for dynamic content whenever the dynamic content changes." The WAI stated in its comments that there was no difference in meaning between the NPRM and WCAG 1.0 Checkpoint 6.2. The NPRM provision has been deleted in the final rule as the meaning of the provision is unclear.

A web site required to be accessible by section 508, would be in complete compliance if it met paragraphs (a) through (p) of these standards. It could also comply if it fully met the WCAG 1.0, priority one checkpoints and paragraphs (l), (m), (n), (o), and (p) of these standards. A Federal web site that was in compliance with these standards and that wished to meet all of the WCAG 1.0, priority one checkpoints would also have to address the WAI provision regarding using the clearest and simplest language appropriate for a site's content (WCAG 1.0 Checkpoint 14.1), the provision regarding alerting a user when there is a change in the natural language of the page (WCAG 1.0 Checkpoint 4.1), the provision regarding audio descriptions (WCAG 1.0 Checkpoint 1.3), and the provision that web pages shall "ensure that equivalents for dynamic content are updated when the dynamic content changes (WCAG 1.0 Checkpoint 6.2).

The Board has as one of its goals to take a leadership role in the development of codes and standards for accessibility. We do this by working with model code organizations and voluntary consensus standards groups that develop and periodically revise codes and standards affecting accessibility. The Board acknowledges that the WAI has been at the forefront in developing international standards for web accessibility and looks forward to working with them in the future on this vitally important area. However, the WCAG 1.0 were not developed within the regulatory enforcement framework. At the time of publication of this rule, the WAI was developing the Web Content Accessibility Guidelines 2.0. The Board plans to work closely with the WAI in the future on aspects regarding verifiability and achievability of the Web Content Accessibility Guidelines 2.0.

[END OF PREAMBLE TEXT]

(a) A text equivalent for every non-text element shall be provided (e.g., via "alt", "longdesc", or in element content).

[BEGIN PREAMBLE TEXT]

Paragraph (a) requires that a text equivalent for every non-text element shall be provided. As the Internet has developed, the use of photographs, images, and other multimedia has increased greatly. Most web pages are created using HTML, or "HyperText Markup Language." A "page" in HTML is actually a computer file that includes the actual text of the web page and a series of "tags" that control layout, display images (which are actually separate computer files), and essentially provide all content other than text. The tags are merely signals to the browser that tell it how to display information and many tags allow web designers to include a textual description of the non-textual content arranged by the tag. The provision is necessary because assistive technology cannot describe pictures, but can convey the text information to the user. Currently, most web page authoring programs already provide a method for web designers to associate words with an image and associating text with non-textual content is easy for anyone familiar with HTML. This provision requires that when an image indicates a navigational action such as "move to the next screen" or "go back to the top of the page," the image must be accompanied by actual text that states the purpose of the image, in other words, what the image is telling you to do. This provision also requires that when an image is used to represent page content, the image must have a text description accompanying it that explains the meaning of the image. Associating text with these images makes it possible, for someone who cannot see the screen to understand the content and navigate a web page. (See §1194.23(c)(1) in the NPRM.)

Comment. In the NPRM, §1194.23(c)(1) required text to be associated with all non-textual elements, and prescribed the use of specific techniques, such as "alt" and "longdesc," to accomplish that requirement. WAI commented that, while the use of specific techniques was provided in WCAG 1.0 as examples of methods to use, the proposed rule was limiting the manner in which text could be associated with non-textual elements to two techniques. The result was that other approaches to providing text tags in web languages other than HTML were prohibited.

Other commenters pointed out that many images on a web page do not need text tags. They noted that some images are used to create formatting features such as spacers or borders and that requiring text identification of these images adds nothing to the comprehension of a page. These images were, in their view, textually irrelevant. One commenter suggested that this provision should address "every non-text element" because such features as buttons, checkboxes, or audio output were covered by other provisions in the proposed rule.

Response. This provision incorporates the exact language recommended by the WAI in their comments to the proposed rule. Non-text element does not mean all visible elements. The types of non-text elements requiring identification is limited to those images that provide information required for comprehension of content or to facilitate navigation. Web page authors often utilize transparent graphics for spacing. Adding text to identify these elements would produce unnecessary clutter for users of screen readers.

The Board also interprets this provision to require that when audio presentations are available on a web page, because audio is a non-textual element, text in the form of captioning must accompany the audio, to allow people who are deaf or hard of hearing to comprehend the content. (See §1194.23(c)(1) in the NPRM.)

[END OF PREAMBLE TEXT]

[BEGIN GUIDE TEXT]

What is meant by a text equivalent?
A text equivalent means adding words to represent the purpose of a non-text element. This provision requires that when an image indicates a navigational action such as "move to the next screen" or "go back to the top of the page," the image must be accompanied by actual text that states the purpose of the image. This provision also requires that when an image is used to represent page content, the image must have a text description accompanying it that explains the meaning of the image.

HTML Source Code: <img src="art/logo-green.gif" alt="Access Board Logo">

http://www.access-board.gov/

Access Board Logo - The Access Board, a federal agency committed to accessible design

How much information actually needs to be in the text equivalent?
The text information associated with a non-text element should, when possible, communicate the same information as its associated element. For example, when an image indicates an action, the action must be described in the text. The types of non-text elements requiring actual text descriptions are limited to those elements that provide information required for comprehension of content or those used to facilitate navigation. Web page authors often utilize transparent graphics for spacing. Adding a text description to these elements will produce unnecessary clutter for users of screen readers. For such graphics, an empty ALT attribute is useful.

Example of source code: <IMG src="transparent.gif" alt="">

What is meant by the term, non-text element?
A non-text element is an image, graphic, audio clip, or other feature that conveys meaning through a picture or sound. Examples include buttons, check boxes, pictures and embedded or streaming audio or video.

HTML Source Code: <img src="art/logo-green.gif" alt="Access Board Logo">

http://www.access-board.gov/

How should audio presentations be treated?
This provision requires that when audio presentations are available on a multimedia web page, the audio portion must be captioned. Audio is a non-textual element, so a text equivalent of the audio must be provided if the audio is part of a multimedia presentation, Multimedia includes both audio and video. If the presentation is audio only, a text transcript would meet this requirement.

What are ways of assigning text to elements?
There are several ways of providing textual information so that it can be recognized by assistive technology devices. For instance, the <IMG> tag can accept an "alt" attribute that will enable a web designer to include text that describes the picture directly in the <IMG> tag.

HTML source code: <img src="image/ab_logo1.gif" alt="The Architectural and Transportation Barriers Compliance Board emblem-Go to Access Board website"
Link: http://www.section508.gov/

Similarly, the <APPLET> tag for Java applets also accepts an "alt" attribute, but it only works for browsers that provide support for Java. Often, users with slower internet connections will turn support for Java applets off. A better alternative for providing textual descriptions is to simply include the alternative text between opening and closing <APPLET> or <OBJECT> tags. For instance, if a web designer wanted to include an applet called MyCoolApplet in a web page, and also include a description that the applet shows a stock ticker displaying the current price of various stocks, the designer would use the following HTML coding for example:

This applet displays current stock prices for many popular stocks.

</APPLET>

Finally, yet another way of providing a textual description is to include it in the page in the surrounding context:

Below is a picture of me during my great vacation!

[END OF GUIDE TEXT]

(b) Equivalent alternatives for any multimedia presentation shall be synchronized with the presentation.

[BEGIN PREAMBLE TEXT]

Paragraph (b) provides that equivalent alternatives for any multimedia presentation shall be synchronized with the presentation. This would require, for example, that if an audio portion of a multi-media production was captioned as required in paragraph (a), the captioning must be synchronized with the audio. (See §1194.23(c)(12) and (e)(3) in the NPRM.)

Comment. Comments from organizations representing persons who are deaf or hard of hearing strongly supported this provision. One commenter from the technology industry raised a concern that this provision would require all live speeches broadcast on the Internet by a Federal agency to be captioned. The commenter noted that an alternative might be to pro

Trace Center Collation of Access Board's 508 FINAL RULE and GUIDES

Electronic and Information Technology Accessibility Standards

PART 1194 -- ELECTRONIC AND INFORMATION TECHNOLOGY ACCESSIBILITY STANDARDS

Subpart A -- General

Subpart B -- Technical Standards

Subpart C -- Functional Performance Criteria

Subpart D -- Information, Documentation, and Support

Figures to Part 1194

Subpart A -- General

§ 1194.1 Purpose.

§ 1194.2 Application.

§ 1194.3 General exceptions.

§ 1194.4 Definitions.

§ 1194.5 Equivalent facilitation.

Subpart B -- Technical Standards

§ 1194.21 Software applications and operating systems.

§ 1194.22 Web-based intranet and internet information and applications.

Trace Center Collation of
Access Board's 508 FINAL RULE and GUIDES