Change Font/Format | PDF Version
Trace
Center Collation of
Access Board's 508 FINAL RULE and GUIDES
(Release 1.0 July 15, 2002)
Webmaster's Note: The most recent version of this document is available at http://trace.wisc.edu/docs/508-collation/.
This is a special compilation and collation of the 508 standards and Guides released by the Access Board. It contains only the material from the Access Board FINAL RULE and the Access Board’s GUIDES. 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 Guides released by the Access Board was then broken up and pasted under the provision 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 so that ALL text from the Final Rule and Guides is contained in this document.
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.
Subpart B -- Technical Standards
1194.21 Software applications and operating systems.
1194.22 Web-based intranet and internet information and applications.
1194.23 Telecommunications products.
1194.24 Video and multimedia products.
1194.25 Self contained, closed products.
1194.26 Desktop and portable computers.
Subpart C -- Functional Performance Criteria
1194.31 Functional performance criteria.
Subpart D -- Information, Documentation, and Support
1194.41 Information, documentation, and support.
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, (4) 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?
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?
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">
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">
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:
<APPLET CODE="MyCoolApplet.class" WIDTH="200", HEIGHT="100">
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!
<p>
<IMG src="pictureofme.jpg">
[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 provide a transcript of the speech which could be saved, reviewed, and searched.
Response. This provision uses language that is not substantively different than the WCAG 1.0 and was supported in the WAI comments to the proposed rule. There are new techniques for providing realtime captioning which are supported by new versions of programs like RealAudio. Providing captioning does not preclude posting a transcript of the speech for people to search or download. However, commenters preferred the realtime captioning over the delay in providing a transcript. No substantive changes have been made to this provision in the final rule.
[END OF PREAMBLE TEXT]
[BEGIN GUIDE TEXT]
What are considered equivalent alternatives?
Captioning for the audio portion and audio description of visual information
of multimedia presentations are considered equivalent alternatives. This provision
requires that when an audio portion of a multimedia production is captioned,
as required in provision (a), the captioning must be synchronized with the
audio. Synchronized captioning would be required so someone reading the captions
could also watch the speaker and associate relevant body language with the
speech.
If a website offers audio files with no video, do they
have to be captioned?
No, because it is not multimedia. However, since audio is a non-text element,
a text equivalent, such as a transcript, must be available. Similarly, a (silent)
web slide show presentation does not need to have an audio description accompanying
it, but does require text alternatives to be associated with the graphics.
If a Federal agency official delivers a live audio and
video webcast speech, does it need to be captioned?
Yes, this would qualify as a multimedia presentation and would require the
speech to be captioned.
Example:
National Endowment for the Humanities
www.neh.gov/media/scottcaptions.ram
National Center for Accessible Media (NCAM)
http://main.wgbh.org/wgbh/access/dvs/lion.ram
[END OF GUIDE TEXT]
(c) Web pages shall be designed so that all information conveyed with color is also available without color, for example from context or markup.
[BEGIN PREAMBLE TEXT]
Paragraph (c) prohibits the use of color as the single method for indicating important information on a web page. When colors are used as the sole method for identifying screen elements or controls, persons who are color blind as well as those people who are blind or have low vision may find the web page unusable. 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, must be combined with the use of color. (See §1194.23(c)(2) in the NPRM.)
Comment. The WAI expressed concern that as proposed, the provision did not capture the intent of the provision as addressed in the WCAG 1.0. The intent of such a requirement, according to WAI, was to have web page designers use methods other than color to indicate emphasis such as bold text.
Response. This provision incorporates the exact language recommended by the WAI in their comments to the proposed rule. This provision addresses not only the problem of using color to indicate emphasized text, but also the use of color to indicate an action. For example, a web page that directs a user to "press the green button to start" should also identify the green button in some other fashion than simply by color.
[END OF PREAMBLE TEXT]
[BEGIN GUIDE TEXT]
Why is this provision necessary?
When colors are used as the sole method for identifying screen elements or
controls, persons who are color blind as well as those people who are blind
or have low vision may find the web page unusable.
Does this mean that all pages
have to be displayed in black and white?
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, must be combined with the use of color.
This provision addresses not only the problem of using color to indicate emphasized
text, but also the use of color to indicate an action. For example, a web
page that directs a user to "press the green button to start" should
also identify the green button in some other fashion than simply by color.
Is there any way a page can
be quickly checked to ensure compliance with this provision?
There are two simple ways of testing a web page to determine if this requirement
is being met: by either viewing the page on a black and white monitor, or
by printing it out on a black and white printer. Both methods will quickly
show if the removal of color affects the usability of the page.
[END OF GUIDE TEXT]
(d) Documents shall be organized so they are readable without requiring an associated style sheet.
[BEGIN PREAMBLE TEXT]
Paragraph (d) provides that documents must be organized so they are readable without requiring browser support for style sheets. Style sheets are a relatively new technology that lets web site designers make consistent appearing web pages that can be easily updated. For instance, without style sheets, making headings appear in large font while not affecting the surrounding text requires separate tags hidden in the document to control font-size and boldface. Each heading would require a separate set of tags. Using style sheets, however, the web site designer can specify in a single tag that all headings in the document should be in large font and boldface. Because style sheets can be used to easily affect the entire appearance of a page, they are often used to enhance accessibility and this provision does not prohibit the use of style sheets. This provision requires that web pages using style sheets be able to be read accurately by browsers that do not support style sheets and by browsers that have disabled the support for style sheets. (See §1194.23(c)(4) in the NPRM.) This requirement is based on the fact that style sheets are a relatively new technology and many users with disabilities may either not have computer software that can properly render style sheets or because they may have set their own style sheet for all web pages that they view.
Comment. The WAI commented that while the provision was consistent with WCAG 1.0, the preamble inaccurately noted that this provision would prohibit the use of style sheets that interfere with user defined style sheets. The WAI noted that a browser running on a user's system determines whether or not style sheets associated with pages will be downloaded.
Response. The WAI correctly noted that this provision does not prohibit the use of style sheets that interfere with user-defined style sheets because the use of style sheets is controlled by a user's browser. This provision uses language that is not substantively different than WCAG 1.0 and was supported in the WAI comments to the proposed rule. No substantive changes have been made to this provision in the final rule.
[END OF PREAMBLE TEXT]
[BEGIN GUIDE TEXT]
What are the potential problems posed by style sheets?
Style sheets can enable users to define specific viewing preferences to accommodate
their disability. For instance, users with low vision may create their own
style sheet so that, regardless of what web pages they visit, all text is
displayed in an extra large font with white characters on a black background.
If designers set up their pages to override user-defined style sheets, people
with disabilities may not be able to use those pages. For good access, therefore,
it is critical that designers ensure that their web pages do not interfere
with user-defined style sheets.
In general, the "safest" and most useful form of style sheets are "external" style sheets, in which the style rules are set up in a separate file. An example of an external style sheet is:
Example of source code: <link rel=stylesheet type="text / css" href="section508.css>
[END OF GUIDE TEXT]
(e) Redundant text links shall be provided for each active region of a server-side image map.
[BEGIN PREAMBLE TEXT]
Paragraph (e) requires web page designers to include redundant text links for each active region of a server-side image map on their web pages. An "image map" is a picture (often a map) on a web page that provides different "links" to other web pages, depending on where a user clicks on the image. There are two basic types of image maps: "client-side image maps" and "server-side image maps." With client-side image maps, each "active region" in a picture can be assigned its own "link" (called a URL or "uniform resource locator") that specifies what web page to retrieve when a portion of the picture is selected. HTML allows each active region to have its own alternative text, just like a picture can have alternative text. See §1194.22(a). By contrast, clicking on a location of a server-side image map only specifies the coordinates within the image when the mouse was depressed - which link or URL is ultimately selected must be deciphered by the computer serving the web page. When a web page uses a server-side image map to present the user with a selection of options, browsers cannot indicate to the user the URL that will be followed when a region of the map is activated. Therefore, the redundant text link is necessary to provide access to the page for anyone not able to see or accurately click on the map. (See §1194.23(c)(6) in the NPRM.) No substantive changes have been made to this provision in the final rule.
[END OF PREAMBLE TEXT]
[BEGIN GUIDE TEXT]
How do "image maps" work?
An "image map" is a picture (often an actual map) on a web page
that provides different "links" to other web pages, depending on
where a user clicks on the image. There are two basic types of image maps:
"client-side image maps" and "server-side image maps."
With client-side image maps, each "active region" in a picture can
be assigned its own "link" (called a URL or "Uniform Resource
Locator") that specifies what web page to retrieve when a portion of
the picture is selected. HTML allows each active region to have its own alternative
text, just like a picture can have alternative text (see §1194.22(a)).
By contrast, clicking on a location of a server-side image map only specifies
the coordinates within the image when the mouse was depressed. The ultimate
selection of the link or URL must be deciphered by the computer serving the
web page.
Why is this provision necessary?
When a web page uses a server-side image map to present the user with
a selection of options, browsers cannot indicate to the user the URL that
will be followed when a region of the map is activated. Therefore, the redundant
text link is necessary to provide access to the page for anyone not able to
see or accurately click on the map.
[END OF GUIDE TEXT]
(f) Client-side image maps shall be provided instead of server-side image maps except where the regions cannot be defined with an available geometric shape.
[BEGIN PREAMBLE TEXT]
Paragraph (f) provides that client-side image maps shall be provided instead of server-side image maps except where the regions cannot be defined with an available geometric shape. As discussed above, there are two general categories of image maps: client-side image maps and server-side image maps. When a web browser retrieves a specific set of instructions from a client-side image map, it also receives all the information about what action will happen when a region of the map is pressed. For this reason, client-side image maps, even though graphical in nature, can display the links related to the map, in a text format which can be read with the use of assistive technology. (See §1194.23(c)(7) in the NPRM.)
Comment. The WAI suggested that the final rule include an exception for those regions of a map which cannot be defined with an available geometric shape.
Response. This provision incorporates the exact language recommended by the WAI in their comments to the proposed rule.
[END OF PREAMBLE TEXT]
[BEGIN GUIDE TEXT]
Why do client-side image maps provide better accessibility?
Unlike server-side image maps, the client-side image map allow an author
to assign text to each image map “hot spots.” This feature means
that someone using a screen reader can easily identify and activate regions
of the map. An explanation of how these image maps are constructed will help
clarify this issue.
Creating a basic client-side image map requires several steps:
- Identify an image for the map. First, an image must be used in a client-side image map. This image is identified using the <img> tag. To identify it as a map, use the "usemap" attribute.
- Use the <MAP> tag to "areas" within the map . The <MAP> tag is a container tag that includes various <AREA> tags that are used to identify specific portions of the image.
- Use <AREA> tags to identify map regions . To identify regions within a map, simply use <AREA> tags within the <MAP> container tags. Making this client-side image map accessible is considerably easier to describe: simply include the "ALT" attribute and area description inside each <AREA> tag. The following HTML demonstrates how to make a client-side image map:
<img src="navbar.gif" border="0" usemap="#Map">
<map name="Map">
<area shape="rect" coords="0,2,64,19" href="general.html"
alt="information about us" >
<area shape="rect" coords="65,2,166,20" href="jobs.html"
alt="job opportunities" >
<area shape="rect" coords="167,2,212,19" href="faq.html"
alt="Frequently Asked Questions" >
<area shape="rect" coords="214,2,318,21" href="location.html"
alt="How to find us" >
<area shape="rect" coords="319,2,399,23" href="contact.html"
alt="How to contact us" >
</map>
[END OF GUIDE TEXT]
(g) Row and column headers shall be identified for data tables.
[BEGIN PREAMBLE TEXT]
Paragraphs (g) and (h) permit the use of tables, but require that the tables be coded according to the rules for developing tables of the markup language used. When tables are coded inaccurately or table codes are used for non-tabular material, some assistive technology cannot accurately read the content. Many assistive technology applications can interpret the HTML codes for tables and will most likely be updated to read the table coding of new markup languages. (See §1194.23(c)(8-9) in the NPRM.) The Board will be developing technical assistance materials on how tables can comply with this section. In addition to these specific provisions, the technical assistance materials will address all of the provisions in this part.
Comment. Commenters were concerned by the preamble discussion in the NPRM which advised against the use of table tags for formatting of non-tabular material.
Response. The Board understands that there are currently few alternatives to the use of tables when trying to place items in predefined positions on web pages. These provisions do not prohibit the use of table codes to format non-tabular content. They require that when a table is created, appropriate coding should be used. Paragraph (g) incorporates the exact language recommended by the WAI in their comments to the proposed rule. Paragraph (h) uses language that is not substantively different than WCAG 1.0 and was supported in the WAI comments to the proposed rule. No substantive changes have been made to this provision in the final rule.
[END OF PREAMBLE TEXT]
(h) Markup shall be used to associate data cells and header cells for data tables that have two or more logical levels of row or column headers.
[BEGIN PREAMBLE TEXT]
(h) See (g)
[END OF PREAMBLE TEXT]
[BEGIN GUIDE TEXT]
Why are these two provisions necessary?
Paragraphs (g) and (h) permit the use of tables, but require that the tables
be coded according to the rules of the markup language being used for creating
tables. Large tables of data can be difficult to interpret if a person is using
a non-visual means of accessing the web. Users of screen readers can easily
get "lost" inside a table because it may be impossible to associate
a particular cell that a screen reader is reading with the corresponding column
headings and row names. For instance, assume that a salary table includes the
salaries for federal employees by grade and step. Each row in the table may
represent a grade scale and each column may represent a step. Thus, finding
the salary corresponding to a grade 9, step 5 may involve finding the cell in
the ninth row and the fifth column. For a salary chart of 15 grade scales and
10 steps, the table will have at least 150 cells. Without a method to associate
the headings with each cell, it is easy to imagine the difficulty a user of
assistive technology may encounter with the table.
Section 1194.22 (g) and (h) state that when information is displayed in a table
format, the information shall be laid out using appropriate table tags as opposed
to using a preformatted table in association with the "<pre>"
tag. Web authors are also required to use one of several methods to provide
an association between a header and its related information.
How can HTML tables be made readable with assistive technology?
Using the "Scope" Attribute in Tables – Using the "scope" attribute is one
of the most effective ways of making HTML compliant with these requirements.
It is also the simplest method to implement. The scope attribute also works
with some (but not all) assistive technology in tables that use "colspan"
or "rowspan" attributes in table header or data cells.
Using the Scope Attribute – The first row of each table should include column headings.
Typically, these column headings are inserted in <TH> tags, although <TD>
tags can also be used. These tags at the top of each column should include the
following attribute:
scope="col"
By doing this simple step, the text in that cell becomes associated with every
cell in that column. Unlike using other approaches (notably "id" and
"headers") there is no need to include special attributes in each
cell of the table. Similarly, the first column of every table should include
information identifying information about each row in the table. Each of the
cells in that first column are created by either <TH> or <TD> tags.
Include the following attribute in these cells:
scope="row"
By simply adding this attribute, the text in that cell becomes associated with
every cell in that row. While this technique dramatically improves the usability
of a web page, using the scope attribute does not appear to interfere in any
way with browsers that do not support the attribute.
Example of source code – the following simple table summarizes the work schedule of three
employees and demonstrates these principles.
<table>
<tr>
<th> </th>
<th scope="col" >Spring</th> <th scope="col"
>Summer</th> <th scope="col" >Autumn</th> <th
scope="col" >Winter</th> </tr>
<tr> <td scope="row" >Betty</td> <td>9-5</td>
<td>10-6</td> <td>8-4</td><td>7-3</td>
</tr>
<tr> <td scope="row" >Wilma</td> <td>10-6</td>
<td>10-6</td> <td>9-5</td> <td>9-5</td>
</tr>
<tr> <td scope="row" >Fred</td> <td>10-6</td>
<td>10-6</td> <td>10-6</td> <td>10-6</td>
</tr>
</table>
This table would be displayed as follows:
| Spring | Summer | Autumn | Winter | |
|---|---|---|---|---|
| Betty | 9-5 | 10-6 | 8-4 | 7-3 |
| Wilma | 10-6 | 10-6 | 9-5 | 9-5 |
| Fred | 10-6 | 10-6 | 10-6 | 10-6 |
The efficiency of using the scope attribute becomes more
apparent in much larger tables. For instance, if an agency used a table with
20 rows and 20 columns, there would be 400 data cells in the table. To make
this table comply with this provision without using the scope attribute would
require special coding in all 400 data cells, plus the 40 header and row cells.
By contrast, using the scope attribute would only require special
attributes in the 40 header and row cells.
Using the "ID" and "Headers" Attributes in Tables
Unlike using the "scope" attribute, using the "id" and
"headers" attributes requires that every data cell in a table include
special attributes for association. Although its usefulness for accessibility
may have been diminished as browsers provide support for the "scope"
attribute, the "id" and "headers" attributes are still very
useful and provide a practical means of providing access in smaller tables.
The following table is much more complicated than the previous example and demonstrates
the use of the "id" and "headers" attributes and then the
scope attribute. Both methods provide a means of complying with the requirements
for data tables in web pages. The table in this example includes the work schedules
for two employees. Each employee has a morning and afternoon work schedule that
varies depending on whether the employee is working in the winter or summer
months. The "summer" and "winter" columns each span two
columns labeled "morning" and "afternoon." Therefore, in
each cell identifying the work schedule, the user needs to be told the employee's
name (Fred or Wilma), the season (Summer or Winter), and the shift (morning
or afternoon).
<table>
<tr>
<th> </th>
<th colspan="2" id="winter" >Winter</th>
<th colspan="2" id="summer" >Summer</th>
</tr>
<tr>
<th> </th>
<th id="am1" >Morning</th>
<th id="pm1" >Afternoon</th>
<th id="am2" >Morning</th>
<th id="pm2" >Afternoon</th>
</tr>
<tr>
<td id="wilma" >Wilma</td>
<td headers="wilma am1 winter" >9-11</td>
<td headers="wilma pm1 winter" >12-6</td>
<td headers="wilma am2 summer" >7-11</td>
<td headers="wilma pm2 summer" >12-3</td>
</tr>
<tr>
<td id="fred" >Fred</td>
<td headers="fred am1 winter" >10-11</td>
<td headers="fred pm1 winter" >12-6</td>
<td headers="fred am2 summer" >9-11</td>
<td headers="fred pm2 summer" >12-5</td>
</tr>
</table>
This table would be displayed as follows:
| Winter | Summer | |||
|---|---|---|---|---|
| Morning | Afternoon | Morning | Afternoon | |
| Wilma | 9-11 | 12-6 | 7-11 | 12-3 |
| Fred | 10-11 | 12-6 | 9-11 | 12-5 |
Coding each cell of this table with "id" and "headers"
attributes is much more complicated than using the "scope" attribute
shown below:
<table>
<tr>
<th> </th>
<th colspan="2" scope="col" >Winter</th>
<th colspan="2" scope="col" >Summer</th>
</tr>
<tr>
<th> </th>
<th scope="col" >Morning</th>
<th scope="col" >Afternoon</th>
<th scope="col" >Morning</th>
<th scope="col" >Afternoon</th>
</tr>
<tr>
<td scope="row" >Wilma</td>
<td>9-11</td>
<td>12-6</td>
<td>7-11</td>
<td>12-3</td>
</tr>
<tr>
<td scope="row" >Fred</td>
<td>10-11</td>
<td>12-6</td>
<td>9-11</td>
<td>12-5</td>
</tr>
</table>
This table would be displayed as follows:
| Winter | Summer | |||
|---|---|---|---|---|
| Morning | Afternoon | Morning | Afternoon | |
| Wilma | 9-11 | 12-6 | 7-11 | 12-3 |
| Fred | 10-11 | 12-6 | 9-11 | 12-5 |
Is the summary attribute an option?
Although highly recommended by some webpage designers as a way of summarizing
the contents of a table, the "summary" attribute of the TABLE tag
is not sufficiently supported by major assistive technology manufacturers
to warrant recommendation. Therefore, web developers who are interested in
summarizing their tables should consider placing their descriptions either
adjacent to their tables or in the body of the table, using such tags as the
CAPTION tag. In no event should web developers use summarizing tables as an
alternative to making the contents of their tables compliant as described
above.
[END OF GUIDE TEXT]
(i) Frames shall be titled with text that facilitates frame identification and navigation.
[BEGIN PREAMBLE TEXT]
Paragraph (i) addresses the use of frames and requires that they be titled with text to identify the frame and assist in navigating the frames. "Frames" are a technique used by web designers to create different "portions" or "frames" of their screen that serve different functions. When a web site uses frames, often only a single frame will update with information while the other frames remain intact. Because using frames gives the user a consistent portion of the screen, they are often used for navigational toolbars for web sites. They are also often faster because only a portion of the screen is updated, instead of the entire screen. Frames can be an asset to users of screen readers and other assistive technology if the labels on the frames are explicit. Labels such as top, bottom, or left, provide few clues as to what is contained in the frame. However, labels such as "navigation bar" or "main content" are more meaningful and facilitate frame identification and navigation. (See §1194.23(c)(10) in the NPRM.) This provision uses language that is not substantively different than WCAG 1.0. No substantive changes have been made to this provision in the final rule.
[END OF PREAMBLE TEXT]
[BEGIN GUIDE TEXT]
Why is this provision necessary?
Frames provide a means of visually dividing the computer screen into distinct
areas that can be separately rewritten. Unfortunately, frames can also present
difficulties for users with disabilities when those frames are not easily
identifiable to assistive technology. For instance, a popular use of frames
is to create "navigational bars" in a fixed position on the screen
and have the content of the web site retrievable by activating one of those
navigational buttons. The new content is displayed another area of the screen.
Because the navigational bar doesn't change, it provides a stable "frame-of-reference"
for users and makes navigation much easier. However, users with disabilities
may become lost if the differences between the two frames are not clearly
established.
What is the best method for identifying frames?
The most obvious way to accomplish this requirement is to include text within
the body of each frame that clearly identifies the frame. For instance, in
the case of the navigation bar, a web developer should consider putting words
such as "Navigational Links" at the beginning of the contents of
the frame to let all users know that the frame depicts navigational links.
Providing titles like this at the top of the contents of each frame will satisfy
these requirements. An additional measure that should be considered by agencies
is to include meaningful text in the <frame> tag's "title"
attribute. Although not currently supported by major manufacturers of assistive
technology, the "title" attribute is part of the HTML 4.0 specification
and was intended to let web developers include a description of the frame
as a quote-enclosed string. Demonstrating the use of the "title"
attribute requires a basic understanding of how frames are constructed. When
frames are used in a web page, the first page that is loaded must include
a <frameset> tag that encloses the basic layout of the frames on the
page. Within the <frameset> tag, <frame> tags specify the name,
initial contents, and appearance of each separate frame. Thus, the following
example uses the "title" attribute to label one frame "Navigational
Links Frame" and the second frame "Contents Frame."
<frameset cols="30%, 60%">
<frame src="navlinks.html" name="navlinks" title="Navigational
Links Frame">
<frame src="geninfo.html" name="contents_page" title="Contents
Frame">
</frame>
While assistive technology does not yet widely support the "title" attribute, we recommend including this attribute in web pages using frames.
Example: ADA Technical Assistance Program - The use of frames with
“No Frames Link”
www.adata.org
[END OF GUIDE TEXT]
(j) Pages shall be designed to avoid causing the screen to flicker with a frequency greater than 2 Hz and lower than 55 Hz.
[BEGIN PREAMBLE TEXT]
Paragraph (j) sets limits on the blink or flicker rate of screen elements. This section is a result of the reorganization of the final rule and is similar to section 1194.21(k) discussed above. (See §1194.21(c) in the NPRM.) This provision is meant to be consistent with WCAG 1.0 Checkpoint 7.1 which provides that, "[u]ntil user agents allow users to control flickering, avoid causing the screen to flicker." This provision uses language which is more consistent with enforceable regulatory language.
[END OF PREAMBLE TEXT]
[BEGIN GUIDE TEXT]
Why is this provision necessary?
This provision is necessary because some individuals with photosensitive epilepsy
can have a seizure triggered by displays that flicker, flash, or blink, 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.
How can flashing or flickering elements be identified?
Flashing or flickering elements are usually added through technologies such
as animated gif's, Java applets, or third-party plug-ins or applications.
Java applets and third party plug-ins can be identified by the presence of
<APPLET> or <OBJECT> tags. Animated gif's are images that download
in a single file (like ordinary image files), but have content that changes
over short periods of time. Like other images, however, they are usually incorporated
through the use of the <IMG> tag.
[END OF GUIDE TEXT]
(k) A text-only page, with equivalent information or functionality, shall be provided to make a web site comply with the provisions of this part, when compliance cannot be accomplished in any other way. The content of the text-only page shall be updated whenever the primary page changes.
[BEGIN PREAMBLE TEXT]
Paragraph (k) requires that a text-only web page shall only be provided as a last resort method for bringing a web site into compliance with the other requirements in §1194.22. Text-only pages must contain equivalent information or functionality as the primary pages. Also, the text-only page shall be updated whenever the primary page changes. This provision is meant to be consistent with WCAG 1.0 Checkpoint 11.4 which provides that "[i]f, after best efforts, you cannot create an accessible page, provide a link to an alternative page that uses W3C technologies, is accessible, has equivalent information (or functionality), and is updated as often as the inaccessible (original) page."
[END OF PREAMBLE TEXT]
[BEGIN GUIDE TEXT]
What must a text-only page contain to comply with
this provision?
Text-only pages must contain equivalent information or functionality as the
primary pages. Also, the text-only page shall be updated whenever the primary
page changes.
Example: Disability.gov displays a text only page on home page
HTML source code: <div ID=”textonly”> <p><a HREF=”../textonly/default.asp”>Text
Only</a> </p></div>
Link: http://www.disability.gov/
[END OF GUIDE TEXT]
(l) When pages utilize scripting languages to display content, or to create interface elements, the information provided by the script shall be identified with functional text that can be read by assistive technology.
[BEGIN PREAMBLE TEXT]
Paragraph (l) requires that when web pages rely on special programming instructions called "scripts" to affect information displayed or to process user input, functional text shall be provided. It also requires that the text be readable by assistive technology such as screen reading software. Scripts are widely used by web sites as an efficient method to create faster or more secure web communications. A script is a programmatic set of instructions that is downloaded with a web page and permits the user's computer to share the processing of information with the web server. Without scripts, a user performs some action while viewing a web page, such as selecting a link or submitting a form, a message is sent back to the "web server", and a new web page is sent back to the user's computer. The more frequently an individual computer has to send and receive information from a web server, the greater chance there is for errors in the data, loss of speed, and possible violations of security. Also, when many users are simultaneously viewing the same web page, the demands on the web server may be huge. Scripts allow more work to be performed on the individual's computer instead of on the web server. And, the individual computer does not have to contact the web server as often. Scripts can perform very complex tasks such as those necessary to complete, verify, and submit a form and verify credit information. The advantage for the user is that many actions take place almost instantly, because processing takes place on the user's computer and because communication with the web server is often not necessary. This improves the apparent speed of a web page and makes it appear more dynamic. Currently, JavaScript, a standardized object-oriented programming language, is the most popular scripting language, although certain plug-ins (see below) support slightly different scripting languages. This provision requires web page authors to ensure that all the information placed on a screen by a script shall be available in a text form to assistive technology. (See §1194.23(c)(11) in the NPRM.)
Comment. The NPRM was more specific in its application, providing that pages must be usable when scripts, applets, or other programmatic objects are turned off or are not supported. The NPRM permitted the use of an alternative accessible page. Several commenters found the proposed provision too restrictive. They noted that, as proposed, it could severely discourage innovation both for web page developers and for designers of assistive technology. It was argued that if producers of assistive technology know that a web page would never require access to scripts, there would be no incentive to develop better access to these features. It was also pointed out that discussing scripts, applets, and plug-ins in the same provision was not appropriate, because plug-ins were actual programs that run on a user's machine and do not necessarily originate on the web page. Scripts, on the other hand, are downloaded to a user's system from the web page (or an associated file) and, unlike applets or plug-ins, operate completely inside the browser without any additional software. Therefore, as scripts directly affect the actual content of a web page, the web page designer has control over designing a script but does not have control over which plug-in a user may select to process web content.
Response. The final rule has two separate provisions for scripts (l), and applets and plug-ins (m). Web page authors have a responsibility to provide script information in a fashion that can be read by assistive technology. When authors do not put functional text with a script, a screen reader will often read the content of the script itself in a meaningless jumble of numbers and letters. Although this jumble is text, it cannot be interpreted or used. For this reason, the provision requires that functional text, that is text that when read conveys an accurate message as to what is being displayed by the script, be provided. For instance, if a web page uses a script only to fill the contents of an HTML form with basic default values, the web page will likely comply with this requirement, as the text inserted into the form by the script may be readable by a screen reader. By contrast, if a web page uses a script to create a graphic map of menu choices when the user moves the pointer over an icon, the web site designer may be required to incorporate "redundant text links" that match the menu choices because functional text for each menu choice cannot be rendered to the assistive technology. Determining whether a web page meets this requirement may require careful testing by web site designers, particularly as both assistive technology and the JavaScript standard continue to evolve.
[END OF PREAMBLE TEXT]
[BEGIN GUIDE TEXT]
What accessibility problems can scripts cause?
Web page authors have a responsibility to provide script information in a
fashion that can be read by assistive technology. When authors do not put
functional text with a script, a screen reader will often read the content
of the script itself in a meaningless jumble of numbers and letters. Although
this jumble is text, it cannot be interpreted or used.
How can web developers comply with this provision?
Web developers working with JavaScript frequently use so-called JavaScript URL's
as an easy way to invoke JavaScript functions. Typically, this technique is
used as part of <a> anchor links. For instance, the following link invokes
a JavaScript function called myFunction:
<a href="javascript:myFunction();">Start myFunction</a>
This technique does not cause accessibility problems for assistive technology. A more difficult problem occurs when developers use images inside of JavaScript URL's without providing meaningful information about the image or the effect of the anchor link. For instance, the following link alsoinvokes the JavaScript function myFunction, but requires the user to click on an image instead of the text "Start myFunction":
<a href="javascript:myFunction();"><img src="myFunction.gif"></a>
This type of link, as written, presents tremendous accessibility problems, but those problems can easily be remedied. The <img> tag, of course, supports the "alt" attribute that can also be used to describe the image and the effect of clicking on the link. Thus, the following revision remedies the accessibility problems created in the previous example:
<a href="javascript:myFunction();"><img src="myFunction.gif" alt="picture link for starting myFunction"></a>
Another technique advocated by some developers is to use the "title" attribute of the <a> tag. For instance, the following example includes a meaningful description in a "title" attribute:
<a title="this link starts myFunction" href="javascript:myFunction();"><img src="myFunction.gif"></a>
This tag is supported by some but not all assistive technologies. Therefore, while it is part of the HTML 4.0 specifications, authors should use the "alt" tag in the enclosed image.
Finally, the browser's status line (at the bottom of the screen) typically displays the URL of any links that the mouse is currently pointing towards. For instance, if clicking on an anchor link will send the user to http://www.usdoj.gov, that URL will be displayed in the status line if the user's mouse lingers on top of the anchor link. In the case of JavaScript URL's, the status line can become filled with meaningless snips of script. To prevent this effect, some web developers use special "event handlers" such as onmouseover and onmouseout to overwrite the contents of the status line with a custom message. For instance, the following link will replace the content in the status line with a custom message "Nice Choice".
<a href="javascript:myFcn();" onmouseover="status='Nice Choice'; return true;" onmouseout="status='';"><img src="pix.gif"></a>
This text rewritten into the status line is difficult or impossible to detect with a screen reader. Although rewriting the status line did not interfere with the accessibility or inaccessibility of the JavaScript URL, web developers should ensure that all important information conveyed in the status line also be provided through the "alt" attribute, as described above.
JavaScript uses so-called "event handlers" as a trigger for certain actions or functions to occur. For instance, a web developer may embed a JavaScript function in a web page that automatically checks the content of a form for completeness or accuracy. An event handler associated with a "submit" button can be used to trigger the function before the form is actually submitted to the server for processing. The advantage for the government agency is that it saves government resources by not requiring the government's server to do the initial checking. The advantage for the computer user is that feedback about errors is almost instantaneous because the user is told about the error before the information is even submitted over the Internet.
Web developers must exercise some caution when deciding which event handlers to use in their web pages, because different screen readers provide different degrees of support for different event handlers. The following table includes recommendations for using many of the more popular event handlers:
- onClick – The onClick event handler is triggered when the user clicks once on a particular item. It is commonly used on links and button elements and, used in connection with these elements, it works well with screen readers. If clicking on the element associated with the onClick event handler triggers a function or performs some other action, developers should ensure that the context makes that fact clear to all users. Do not use the onClick event handlers for form elements that include several options (e.g. select lists, radio buttons, checkboxes) unless absolutely necessary.
- onDblClick – The onDblClick event handler is set off when the user clicks twice rapidly on the same element. In addition to the accessibility problems it creates, it is very confusing to users and should be avoided.
- onMouseDown and onMouseUp – The onMouseDown and onMouseUp event handlers each handle the two halves of clicking a mouse while over an element – the process of (a) clicking down on the mouse button and (b) then releasing the mouse button. Like onDblClick, this tag should be used sparingly, if at all, by web developers because it is quite confusing. In most cases, developers should opt for the onClick event handler instead of onMouseDown.
- onMouseOver and onMouseOut – These two event handlers are very popular on many web sites. For instance, so-called rollover gif's, which swap images on a web page when the mouse passes over an image, typically use both of these event handlers. These event handlers neither can be accessed by the mouse nor interfere with accessibility – a screen reader simply bypasses them entirely. Accordingly, web designers who use these event handlers should be careful to duplicate the information (if any) provided by these event handlers through other means.
- onLoad and onUnload – Both of these event handlers are used frequently to perform certain functions when a web page has either completed loading or when it unloads. Because neither event handler is triggered by any user interaction with an element on the page, they do not present accessibility problems.
- onChange – This event handler is very commonly used for triggering JavaScript functions based on a selection from within a <select> tag. Surprisingly, it presents tremendous accessibility problems for many commonly used screen readers and should be avoided. Instead, web developers should use the onClick event handler (associated with a link or button that is adjacent to a <select> tag) to accomplish the same functions.
- onBlur and onFocus – These event handlers are not commonly used in web pages. While they don't necessarily present accessibility problems, their behavior is confusing enough to a web page visitor that they should be avoided.
[END OF GUIDE TEXT]
(m) When a web page requires that an applet, plug-in or other application be present on the client system to interpret page content, the page must provide a link to a plug-in or applet that complies with §1194.21(a) through (l).
[BEGIN PREAMBLE TEXT]
Paragraph (m) is, in part, a new provision developed in response to comments received on §1194.23(c)(11) of the NPRM and discussed in the preceding paragraph. While most web browsers can easily read HTML and display it to the user, several private companies have developed proprietary file formats for transmitting and displaying special content, such as multimedia or very precisely defined documents. Because these file formats are proprietary, they cannot ordinarily be displayed by web browsers. To make it possible for these files to be viewed by web browsers, add-on programs or "plug-ins" can be downloaded and installed on the user's computer that will make it possible for their web browsers to display or play the content of the files. This provision requires that web pages which provide content such as Real Audio or PDF files, also provide a link to a plug-in that will meet the software provisions. It is very common for a web page to provide links to needed plug-ins. For example, web pages containing Real Audio almost always have a link to a source for the necessary player. This provision places a responsibility on the web page author to know that a compliant application exists, before requiring a plug-in. (See §1194.21(c)(11) in the NPRM.)
[END OF PREAMBLE TEXT]
[BEGIN GUIDE TEXT]
Why is this provision necessary?
While most web browsers can easily read HTML and display it to the user, several
private companies have developed proprietary file formats for transmitting
and displaying special content, such as multimedia or very precisely defined
documents. Because these file formats are proprietary, web browsers cannot
ordinarily display them. To make it possible for these files to be viewed
by web browsers, add-on programs or "plug-ins" can be downloaded
and installed on the user's computer that will make it possible for their
web browsers to display or play the content of the files. This provision requires
that web pages that provide content such as Real Audio or PDF (Adobe Acrobat's
Portable Document Format) files also provide a link to a plug-in that will
meet the software provisions. It is very common for a web page to provide
links to needed plug-ins. For example, web pages containing Real Audio almost
always have a link to a source for the necessary player. This provision places
a responsibility on the web page author to know that a compliant application
exists, before requiring a plug-in.
How can plug-ins and applets be detected?
Plug-ins can usually be detected by examining a page's HTML for the presence
of an <OBJECT> tag. Some plug-in manufacturers, however, may require
the use of proprietary tags. Like plug-ins, applets can also be identified
by the presence of an <OBJECT> tag in the HTML source for a web page.
Also, an <APPLET> tag may also signal the inclusion of an applet in
a web page.
[END OF GUIDE TEXT]
(n) When electronic forms are designed to be completed on-line, 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 (n) requires that people with disabilities have access to interactive electronic forms. Electronic forms are a popular method used by many agencies to gather information or permit a person to apply for services, benefits, or employment. The 1998 Government Paperwork Elimination Act requires that Federal agencies make electronic versions of their forms available on-line when practicable and allows individuals and businesses to use electronic signatures to file these forms electronically. (See §1194.23(b)(10) in the NPRM.) At present, the interaction between form controls and screen readers can be unpredictable, depending upon the design of the page containing these controls. Some developers place control labels and controls in different table cells; others place control labels in various locations in various distances from the controls themselves, making the response from a screen reader less than accurate many times.
Comment. Adobe Systems expressed concern that completing some forms requires a script or plug-in and interpreted the proposed rule as prohibiting such items. They pointed out that there are other methods of completing a form that would not require scripts or plug-ins, but those methods require the constant transfer of information between the client and server computers. Adobe noted that that method can be extremely inefficient and can pose a security risk for the individual's personal data.
Response. This provision does not forbid the use of scripts or plug-ins and many of the existing products support these features. If a browser does not support these features, however, paragraphs (l) and (m) require that some other method of working with the web page must be provided. As assistive technologies advance, it is anticipated that the occasions when the use of scripts and plug-ins are not supported will diminish significantly. No substantive changes have been made to this provision in the final rule.
[END OF PREAMBLE TEXT]
[BEGIN GUIDE TEXT]
Why do electronic forms present difficulties to
screen readers?
Currently, the interaction between form controls and screen readers can be
unpredictable, depending upon the design of the page containing these controls.
HTML forms pose accessibility problems when web developers separate a form
element from its associated label or title. For instance, if an input box
is intended for receiving a user's last name, the web developer must be careful
that the words "last name" (or some similar text) appear near that
input box or are somehow associated with it. Although this may seem like an
obvious requirement, it is extremely easy to violate because the visual proximity
of a form element and its title offers no guarantee that a screen reader will
associate the two or that this association will be obvious to a user of assistive
technology.
The following form demonstrates these problems. Visually, this form is part of a table and each field is carefully placed in table cells adjacent to their corresponding labels (n.b. formatting forms with tables are by no means the only situation presenting the accessibility problems inherent in forms; tables merely illustrate the problem most clearly).
While the relationship between the titles "First Name" or "Last Name" and their respective input boxes may be obvious from visual inspection, the relationship is not obvious to a screen reader. Instead, a screen reader may simply announce "input box" when encountering each input box. The reason for these difficulties is revealed from inspecting the HTML source for this table. The following code is a simplified version of this table.
<FORM>
<TABLE>
<TR>
<TD><B>FIRST NAME: </B></TD>
<TD><INPUT TYPE="TEXT" NAME="FIRSTNAME"> </TD>
</TR>
<TR>
<TD><B>LAST NAME: </B></TD>
<TD><INPUT TYPE="TEXT" NAME="LASTNAME"> </TD>
</TR>
</TABLE>
<P>
<INPUT TYPE="SUBMIT" VALUE="SUBMIT">
</FORM>
The two pairs of form elements are indicated in bold above. The problem created by laying out form elements inside of this table is now clear – the form elements are separated from their labels by the formatting instructions for the table.
How can developers provide accessible HTML forms?
The first rule of thumb is to place labels adjacent to input fields, not in
separate cells of a table. For the web developer who does not wish to place
form elements immediately adjacent to their corresponding titles, the HTML
4.0 specification includes the <LABEL> tag that lets web developers
mark specific elements as "labels" and then associate a form element
with that label. There are generally two ways to use the label tag: explicit
labels and implicit labels.
“Explicit Labels" Work Well
Experience has shown that explicit labeling works extremely well with all
popular assistive technology and are recommended in all but the very simplest
of tables. We recommend that all agencies ensure that their web developers
are familiar with these important concepts. Using "explicit" labels
involves two distinct steps:
- Use the <LABEL> Tag and Associated "FOR" Attribute to Tag Labels. In other words, identify the exact words that you want to use as the label for the form element and enclose those words in a <LABEL> tag. Use the "FOR" attribute to uniquely identify that element.
- Use the "ID" Attribute in the Associated Form Element. Every form element supports the "ID" attribute. By setting this attribute to the identifier used in the "FOR" attribute of the associated <LABEL> tag, you "tie" that form element to its associated label. For instance, we have rewritten the HTML code for our simple form-inside-a-table to include explicit labels below. The new HTML code for the explicit labels is indicated in bold:
<FORM>
<TABLE>
<TR>
<TD><B><LABEL FOR="first"> FIRST NAME:</LABEL>
</B></TD>
<TD><INPUT TYPE="TEXT" NAME="FIRSTNAME" ID="first"
></TD>
</TR>
<TR>
<TD><B><LABEL FOR="last"> LAST NAME:</LABEL>
</B></TD>
<TD><INPUT TYPE="TEXT" NAME="LASTNAME" ID="last"
></TD>
</TR>
</TABLE>
<P>
<INPUT TYPE="SUBMIT" VALUE="SUBMIT">
</FORM>
In a nutshell, that's all there is to making HTML form elements accessible to assistive technology. Experience has shown that this technique works extremely well in much more complicated and convoluted forms and it should work well in all agency HTML forms.
Avoid Using "Implicit Labels"
In "implicit" labels, the form element and its associated label
are contained within an opening <LABEL> tag and a closing </LABEL>
tag. For instance, in the table above, an implicit label to associate the
words "First Name" with its associated input cell, we could use
an implicit label as follows:
<LABEL >
<TR>
<TD><B>FIRST NAME:</B></TD>
<TD><INPUT TYPE="TEXT" NAME="FIRSTNAME"></TD>
</TR>
</LABEL >
Experience has shown that implicit labeling should be avoided for two reasons. First, implicit labeling is not reliably supported by many screen readers and, in particular, does not work well if explicit labels are simultaneously used anywhere on the same web page. Often, the output can be wildly inaccurate and confusing. Second, if any text separates a label from its associated form element, an implicit label becomes impractical and confusing because the label itself is no longer easily identified with the form element.
[END OF GUIDE TEXT]
(o) A method shall be provided that permits users to skip repetitive navigation links.
[BEGIN PREAMBLE TEXT]
Paragraph (o) provides that a method be used to facilitate the easy tracking of page content that provides users of assistive technology the option to skip repetitive navigation links. (See §1194.23(c)(13) in the NPRM.) No substantive comments were received on this provision and no changes were made, other than editorial changes.
[END OF PREAMBLE TEXT]
[BEGIN GUIDE TEXT]
Why do navigational links present impediments
to screen readers and other types of assistive technologies?
This provision provides a method to facilitate the easy tracking of page content
that provides users of assistive technology the option to skip repetitive
navigation links. Web developers routinely place a host of routine navigational
links at a standard location – often across the top, bottom, or side
of a page. If a nondisabled user returns to a web page and knows that he or
she wants to view the contents of that particular page instead of selecting
a navigation link to go to another page, he or she may simply look past the
links and begin reading wherever the desired text is located. For those who
use screen readers or other types of assistive technologies, however, it can
be a tedious and time-consuming chore to wait for the assistive technology
to work through and announce each of the standard navigational links before
getting to the intended location. In order to alleviate this problem, the
section 508 rule requires that when repetitive navigational links are used,
there must be a mechanism for users to skip repetitive navigational links.
Example: USDA Target Center and DOL websites use the Skip Repetitive
Navigational Links.
http://www.usda.gov/oo/target.htm
(http://www.dol.gov/dol/odep/)
[END OF GUIDE TEXT]
(p) When a timed response is required, the user shall be alerted and given sufficient time to indicate more time is required.
[BEGIN PREAMBLE TEXT]
Paragraph (p) addresses the accessibility problems that can occur if a web page times-out while a user is completing a form. Web pages can be designed with scripts so that the web page disappears or "expires" if a response is not received within a specified amount of time. Sometimes, this technique is used for security reasons or to reduce the demands on the computer serving the web pages. A disability can have a direct impact on the speed with which a person can read, move around, or fill in a web form. For this reason, when a timed response is required, the user shall be alerted and given sufficient time to indicate that additional time is necessary. (See §1194.21(d) in the NPRM.)
Comment. The proposed rule prescribed specific settings for increasing the time-out limit based on a default setting. The Board sought comment on whether a system was commercially available that would allow a user to adjust the time-out. The Board also sought information on whether the proposed provision would compromise security. Commenters responded that security would be an issue if the time-out period was extended for too long and information with personal data was left exposed. Other commenters raised the point that specifying specific multiples of the default was unrealistic and arbitrary. The Multimedia Telecommunications Association (MMTA) stated that the default was not built-into a system. Rather, it was generally something that was set by an installer or a system administrator. They also noted that in order for a user to know that more time is needed, the user must be alerted that time is about to run out.
Response. The provision has been revised as a performance standard rather than a specific design standard by removing the reference to a specified length of time for users to respond. The Board agrees that it would be difficult for a user to know how much more time is needed even if the time-out could be adjusted. The final rule requires only that a user be notified if a process is about to time-out and be given an opportunity to answer a prompt asking whether additional time is needed.
[END OF PREAMBLE TEXT]
[BEGIN GUIDE TEXT]
Why do timed responses present problems to web
users with disabilities?
Web pages can be designed with scripts so that the web page disappears or
"expires" if a response is not received within a specified amount
of time. Sometimes, this technique is used for security reasons or to reduce
the demands on the computer serving the web pages. Someone's disability can
have a direct impact on the speed with which he or she can read, move around,
or fill in a web form. For instance, someone with extremely low vision may
be a slower-than-average reader. A page may "time out" before he
is able to finish reading it. Many forms, when they "time out" automatically,
also delete whatever data has been entered. The result is that someone with
a disability who is slow to enter data cannot complete the form. For this
reason, when a timed response is required, the user shall be alerted via a
prompt and given sufficient time to indicate whether additional time is needed.
Example: Thrift Savings Plan
www.tsp.gov
[END OF GUIDE TEXT]
Note to §1194.22: 1. The Board interprets paragraphs (a) through (k) of this section as consistent with the following priority 1 Checkpoints of the Web Content Accessibility Guidelines 1.0 (WCAG 1.0) (May 5, 1999) published by the Web Accessibility Initiative of the World Wide Web Consortium:
| Section 1194.22 Paragraph | WCAG 1.0 Checkpoint |
|---|---|
| (a) | 1.1 |
| (b) | 1.4 |
| (c) | 2.1 |
| (d) | 6.1 |
| (e) | 1.2 |
| (f) | 9.1 |
| (g) | 5.1 |
| (h) | 5.2 |
| (i) | 12.1 |
| (j) | 7.1 |
| (k) | 11.4 |
2. Paragraphs (l), (m), (n), (o), and (p) of this section are different from WCAG 1.0. Web pages that conform to WCAG 1.0, level A (i.e., all priority 1 checkpoints) must also meet paragraphs (l), (m), (n), (o), and (p) of this section to comply with this section. WCAG 1.0 is available at http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505.
§ 1194.23 Telecommunications products.
(a) Telecommunications products or systems which provide a function allowing voice communication and which do not themselves provide a TTY functionality shall provide a standard non-acoustic connection point for TTYs. Microphones shall be capable of being turned on and off toallow the user to intermix speech with TTY use.
[BEGIN PREAMBLE TEXT]
Paragraph (a) requires that telephone equipment shall provide a standard non-acoustic connection point for TTYs. A TTY is a device that includes a keyboard and display that is used to transmit and receive text over a telephone line using sound. Originally, TTY's used acoustic connections and the user placed the telephone handset on the TTY to transfer the sound signals between the TTY and the telephone. Handsets on many modern telephones do not fit well with many TTY acoustic couplers, allowing interference from outside noise. Individuals who use TTYs to communicate must have a non-acoustic way to connect TTYs to telephones in order to obtain clear TTY connections, such as through a direct RJ-11 connector, a 2.5 mm audio jack, or other direct connection. When a TTY is connected directly into the network, it must be possible for the acoustic pickup (microphone) to be turned off (automatically or manually) to avoid having background noise in a noisy environment mixed with the TTY signal. Since some TTY users make use of speech for outgoing communications, the microphone on/off capability must be automatic or easy to switch back and forth or a push-to-talk mode should be provided. In the Telecommunications Act Accessibility Guidelines (36 CFR Part 1193), the Board recognized that direct-connect TTYs are customer premises equipment (CPE) subject to section 255 of that Act. Since CPE is a subset of electronic and information technology, it is similarly covered by this rule. This provision was adopted from the Board's Telecommunications Act Accessibility Guidelines so that manufacturers of telecommunications and customer premises equipment covered by section 255 of the Telecommunications Act wishing to sell products to the Federal government would have a consistent set of requirements. (See §1194.23(d)(1) in the NPRM.)
Comment. The MMTA commented that providing a direct connection to an analog telephone may be as simple as providing an RJ-11 jack, but that digital phones pose additional problems. It noted that most multi-line business phones operating through a PBX are digital phones. However, it also stated that TTY connectivity can be accomplished by adding an analog line similar to what would be provided for a fax machine. The MMTA further suggested that TTY manufacturers should share the burden for compatibility. Another comment suggested that the Board require the provision of a shelf and outlet for a TTY.
Response. In some cases, the addition of an RJ-11 connector will be the easiest solution. In other cases, the addition of a "smart" adapter may be necessary, similar to the dataports available on many hotel phones. Some adapters and converters have circuitry which determines the nature of the line and plug-in equipment and makes the adjustment automatically while others are manual. There is merit, however, in viewing this provision from the standpoint of the capabilities of a system as opposed to the capabilities of a single desktop unit. There may be cases in which the connection is best made at the PBX level by installing analog phone lines where necessary. The final provision has been modified to allow for either option.
With respect to the suggestion that the standards require a shelf and outlet for a TTY, these standards apply to the electronic and information technology products themselves, not the furniture they occupy. Therefore, these standards do not address auxiliary features such as shelves and electrical outlets.
[END OF PREAMBLE TEXT]
[BEGIN GUIDE TEXT]
What is a TTY?
A TTY (Teletypewriter) is a data terminal that allows
a person with a communication disability to use the telephone. TTYs traditionally
have been stand-alone devices with a keyboard and an electronic display for
reading text. TTYs send and receive tones which are converted to text. TTYs
transmit and receive baudot code at a rate of 45.5 baud. Baudot refers to
the code made from bits of electronic information. Baudot is considered to
be an antiquated code. Baud refers to the speed at which data can be transmitted.
Some TTYs may transmit at a faster speed using proprietary protocols or ASCII.
ASCII (American Standard Code for Information Interchange) is a more conventional
code, commonly used by computers and other devices that transmit data.
It is possible to enable some computers to function as TTYs if appropriate communication software (and sometimes a different modem) is installed. Some TTYs can connect directly to the phone or phone line, thus reducing the possibility of noise interfering with the data. Depending on the type of phone, a TTY might connect via a standard RJ-11 phone jack or a 2.5 mm audio jack. A variety of TTY styles exist that include models without acoustic coupling ability and models without keyboards. People select and use TTYs differently depending on their communication preferences and the nature of their disabilities. Basic information on how to use a TTY can be obtained here.
What is VCO and HCO?
VCO is "voice carry over" and HCO is "hearing carry over".
These terms refer to strategies for using TTYs. VCO allows people who are
hard of hearing or oral deaf (deaf with intelligible speech) to use a TTY
without typing. They only use the TTY for reading during the inbound direction
of the call. They talk to their party by speaking into a microphone. Similarly,
HCO allows a person with a speech disability to hear a response from their
party directly. These options are often used in conjunction with a relay service.
What is a relay
service?
A telecommunications relay service (TRS) is essentially a telephone interpreting
service for people with communication disabilities. It enables a TTY user to
converse with a non-TTY user. Relay service operators are called Communication
Assistants (CAs) and serve as third parties to facilitate conversations - by
typing or speaking information as appropriate. Relay services are available
without charge 24 hours per day. These and other TRS provisions are mandated
under Title IV of the Americans with Disabilities Act. An FCC report
and order mandates 7-1-1 as a toll-free number to use in accessing a relay
service. The Federal Relay Service is one of
several relay services available throughout the country.
Why is a non-acoustic connection point needed
for TTYs?
Traditionally, people with communication disabilities used a TTY by placing
a telephone handset in an acoustic modem on top of the TTY. Some manufacturers
reduced the size of their TTY by removing the acoustic modem, thus requiring
the TTY to connect directly to a telephone or wall jack. Therefore, if a new
phone system has hardwired cords with no port for direct connection, then
a direct connect TTY cannot be used at that phone and the phone will be considered
non-conforming with this section 508 provision.
Why must phone
systems be capable of intermixing speech and TTY tones and why must users
be able to turn microphones on and off?
This provision supports VCO and HCO. People with communication disabilities
have reported instances in which they connected a TTY to a cellular phone,
which resulted in a deactivation of the telephone’s microphone. In those
cases, there was no way to talk into the phone (no way to turn the microphone
on). This is frustrating to people with a hearing disability and intelligible
speech who prefer to talk instead of type.
People who are deaf and use the TTY for both typing as well as reading would have less of a problem with a connection that disables the microphone. However, even they would be concerned if the phone was disabled to a point where it was unable to transmit tones for responding to interactive telephone response systems. TTY signals are not the same as "touch tone" sounds, and some TTYs may not readily make the necessary tones.
On the other extreme, some TTY-phone set-ups keep a microphone on throughout the entire conversation (never toggling it off). This can cause a problem if the microphone picks up extraneous noise during the data reception mode and results in errors.
Do TTYs work with digital phones?
At this time, TTYs do not work reliably with most digital cellular phones.
The industry is working toward a solution on this matter through an FCC
order which set a deadline of June 30, 2002 for wireless providers to be
able to transmit 911 calls made from TTYs.
With regard to landline phones,
most digital phones from offices or hotels will transmit TTY signals. If a TTY
is use in an acoustic mode, then it does not matter whether it is being used
with analog or digital phones. However, direct-connect TTYs should only be connected
to analog phones to prevent damage to the TTYs. TTYs use analog plugs. Users
may experience some confusion in determining whether a phone is analog or digital
because of variances in the jacks. Digital jacks are often larger than standard
RJ-11 analog plugs, but sometimes they are the same size. Finally, it is important
that digital systems enable TTY signals to come out of the system undistorted
if signals are compressed along the way.
[END OF GUIDE TEXT]
(b) Telecommunications products which include voice communication functionality shall support all commonly used cross-manufacturer non-proprietary standard TTY signal protocols.
[BEGIN PREAMBLE TEXT]
Paragraph (b) requires that products providing voice communication functionality be able to support use of all commonly used cross-manufacturer, non-proprietary, standard signals used by TTYs. Some products compress or alter the audio signal in such a manner that standard signals used by TTYs are not transmitted properly, preventing successful TTY communication. This provision is consistent with the Telecommunications Act Accessibility Guidelines. (See §1194.23(d)(2) in the NPRM.)
Comment. Comments from industry suggested that the Board should clarify the standard referred to as U.S. standard Baudot communications protocol. They noted that there are several standards in use in Europe. Some European products support more than one of these standards, but not the common U.S. standard. The comments said that such products would arguably comply with the provision but would not meet the intent of section 508.
Response. The proposed rule required that products must support all cross-manufacturer, non-proprietary protocols, not just one or two. Of course, that included the common U.S. Baudot protocol (ANSI/TIA/EIA 825). ASCII is also used, especially on dual mode TTYs, but it is less common. Compliance with international standard ITU-T Recommendation V.18 would meet this provision, but products complying with the ITU standard may not be commercially available. It is important that products and systems support the protocol used by most TTYs currently in use to avoid a disenfranchisement of the majority of persons who are deaf or hard of hearing. However, the intent of this provision is to require support of more than just Baudot or just ASCII. At present, only these two are commonly used in the U.S., but others may come into use later. While the Board does not want to disenfranchise users of current devices, neither does it want to exclude those who buy newer equipment, as long as such devices use protocols which are not proprietary and are supported by more than one manufacturer. Of course, like all the requirements of these standards, this provision is subject to commercial availability. Accordingly, the provision has been changed in the final rule by adding the phrase "commonly used."
[END OF PREAMBLE TEXT]
[BEGIN GUIDE TEXT]
How might telephone systems affect TTY signals?
Some systems compress or alter transmissions, including TTY audio signals,
in such a manner that the signals are not decoded properly. This provision is
consistent with language in the Telecommunications
Act Accessibility Guidelines.
What communication protocols are used by TTYs?
TTYs transmit in Baudot code at a rate of 45.5 baud. Products would need
to match this protocol to be considered "TTY compatible." A standard
was published for TTYs on June 23, 2000, which is available from the Telecommunications Industry Association.
Under 508, this is the protocol which must be retained as TTY signals pass through
phone systems.
Some TTYs also include the optional ability to connect at a rate of 300 baud ASCII, which enables them to communicate with some computers or other TTYs with the same protocol. These two codes (300 baud ASCII and 45.5 baud Baudot) are considered non-proprietary. Equipment that contains a v.18 chip will enable transmission in many protocols including these two. That chip is based on an international standard.
Some TTY manufacturers developed proprietary protocols that enable TTYs to communicate in Baudot at a higher rate. TTY users will see a benefit in using proprietary protocols only when communicating with other users who have products with the same protocol. The 508 standard does not require support for proprietary protocols.
[END OF GUIDE TEXT]
(c) Voice mail, auto-attendant, and interactive voice response telecommunications systems shall be usable by TTY users with their TTYs.
[BEGIN PREAMBLE TEXT]
Paragraph (c) provides that TTY users be able to utilize voice mail, auto-attendant, and interactive voice response telecommunications systems. Voice mail systems are available which allow TTY users to retrieve and leave TTY messages. This provision does not require that phone systems have voice to text conversion capabilities. It requires that TTY users can retrieve and leave TTY messages and utilize interactive systems. (See §1194.23(d)(3) in the NPRM.)
Comment. One commenter suggested that the Board encourage developers to build-in direct TTY decoding so that external TTYs are not required. For example, if an employee had voice mail with TTY functionality built-in, that employee would be able to read TTY messages through the computer system directly, without needing to attach an external TTY. The commenter noted that this would be beneficial to Federal agencies having telephone communication with members of the public who have speech or hearing disabilities. The agency could then have direct communication rather than being required to use an external TTY device or utilizing a relay service. Another said telecommunications systems should be required to have TTY decoding capability built-in, to the maximum extent possible. Another commenter pointed out that voice mail, voice response, and interactive systems depend on DTMF "touch tones" for operation and that many TTYs do not provide this function. Also, one commenter noted that automatic speech recognition (ASR) is not yet mature, but requested that a requirement for ASR be reviewed every two years to determine the feasibility of including such capabilities in products based on the rapid change of technology.
Response. This provision requires that voice mail, auto-attendant, and interactive voice response systems be usable with TTYs. It is desirable that computers have built-in TTY capability and there are currently systems which can add such functionality to computers. This provision is a performance requirement and the Board does not feel it would be useful to be more specific at this time. The current problems with voice mail and voice response systems are not necessarily susceptible to a single solution and there are several ways to comply, including voice recognition in some cases, depending on the system. Many voice mail systems could record a TTY message, just like a voice message, but the outgoing message needs to include a TTY prompt letting TTY users to know when to start keying. A requirement for a quick response to menu choices is the most frequently reported barrier for relay users. The ability to "opt out" of a menu and connect with an operator or transfer to a TTY system are also ways to make these services available and usable without highly sophisticated decoding technology.
[END OF PREAMBLE TEXT]
[BEGIN GUIDE TEXT]
What difficulties have TTY experienced with interactive
voice response systems (IVRSs)?
IVRSs include a
variety of systems such as voice mail, recordings that require selecting a
department you wish to connect to and job line announcements. Due to a hearing
disability, many TTY users cannot understand prompts indicating which phone
buttons to push when encountering IVRSs. Often when calling through relay
services, TTY users are not given enough time to respond and get timed-out
by the IVRS. Auditory information when typed to a TTY user via relay may not
include necessary spacing or punctuation to help a consumer understand sections
of what is being conveyed. TTY users have discovered that some voice mail
systems corrupt TTY data left in voice mail boxes.
What does this provision require?
This provision is a performance requirement. It does not require phone
systems to provide voice to text conversion capabilities. IVRS products have
been available for over a decade which provide TTY users all of the same functions
and information as non-TTY users, such as reading streaming text, leaving
messages, and managing personal voice mail. This software should not be confused
with other software on the market that is designed to allow computers to transmit
and receive TTY code for live communication.
[END OF GUIDE TEXT]
d) Voice mail, messaging, auto-attendant, and interactive voice response telecommunications systems that require a response from a user within a time interval, shall give an alert when the time interval is about to run out, and shall provide sufficient time for the user to indicate more time is required.
[BEGIN PREAMBLE TEXT]
Paragraph (d) addresses access problems that can arise when telecommunications systems require a response from a user within a certain time. Due to the nature of the equipment, users of TTYs may need additional time to read and respond to menus and messages. This provision is identical to section 1194.22(p) discussed above. (See §1194.21(d)(4) in the NPRM.)
Comment. The proposed rule prescribed specific settings
for increasing the time-out limit based on a default setting. Commenters raised
the point that specifying specific multiples of the default was unrealistic
and arbitrary. The MMTA stated that the default was not built-into a system.
Rather it was
generally something that was set by an installer
or a system administrator. It also noted that in order for users to know that
more time is needed, they must be alerted that time is about to run out.
Response. The provision has been changed to a performance standard rather than a specific design standard by removing the reference to a specified length of time for users to respond. The Board agrees that it would be difficult for a user to know how much more time is needed even if the time-out could be adjusted. The final rule requires only that a user be notified if a process is about to time-out and be given an opportunity to answer a prompt asking whether additional time is needed.
[END OF PREAMBLE TEXT]
[BEGIN GUIDE TEXT]
Why is an alert necessary?
This provision was included to serve the needs of people, such as those
with cognitive or dexterity disabilities, who may require additional time
to respond to the prompts of an interactive telephone response system in order
to avoid getting disconnected prematurely. The provision does not specify
what the alert could sound like or exactly how much additional time would
be sufficient, as those factors vary. This provision is identical to section
1194.22(p).
[END OF GUIDE TEXT]
(e) Where provided, caller identification and similar telecommunications functions shall also be available for users of TTYs, and for users who cannot see displays.
[BEGIN PREAMBLE TEXT]
Paragraph (e) requires that functions such as caller identification must be accessible for users of TTYs, and for users who cannot see displays. (See §1194.23(d)(5) in the NPRM.)
Comment. One commenter thought the reference to telecommunications relay services in the NPRM implied that caller identification information must somehow be transmitted directly to the end-user.
Response. Since the end-users in a telecommunications
relay service are not directly connected, passing along caller identification
information is not
commonly done, therefore, the reference
to relay services has been deleted to avoid confusion.
[END OF PREAMBLE TEXT]
[BEGIN GUIDE TEXT]
What types of challenges have people with disabilities
experienced with information displayed on phones?
Some phones have an LCD (liquid crystal display) window that shows Caller
ID or other functions of the phone. People with visual or other disabilities
may be unable to read the display. Talking Caller ID would be one means of
making that information available in an alternate format.
Receiving this information has been a problem in the past for TTY users who were forced to use an analog phone and line that bypassed the office digital system. This will no longer be a problem with new 508 compliant systems that will support TTY requirements.
[END OF GUIDE TEXT]
(f) For transmitted voice signals, telecommunications products shall provide a gain adjustable up to a minimum of 20 dB. For incremental volume control, at least one intermediate step of 12 dB of gain shall be provided.
[BEGIN PREAMBLE TEXT]
Paragraph (f) requires products to be equipped with volume control that provides an adjustable amplification up to a minimum of 20 dB of gain. If a volume adjustment is provided that allows a user to set the level anywhere from 0 to the upper requirement of 20 dB, there is no need to specify a lower limit. If a stepped volume control is provided, one of the intermediate levels must provide 12 dB of gain. The gain applies to the voice output. (See §1194.23(d)(6) in the NPRM.)
Comment. Several commenters supported the provision for a 20 dB gain, but some supported a 25 dB requirement, pointing out that many persons who are hard of hearing need more than 20 dB amplification. Others urged the Board to adopt the current Federal Communications Commission's (FCC) requirement for a minimum of 12 dB and a maximum of 18 dB. Some commenters said amplifying a poor quality signal would not be useful and that the amplification may itself introduce distortion.
Response. The proposed level of amplification was different from that required under the FCC regulations implementing the Hearing Aid Compatibility Act (47 CFR 68.317 (a)). The FCC requires volume control that provides, through the receiver in the handset or headset of the telephone, 12 dB of gain minimum and up to 18 dB of gain maximum, when measured in terms of Receive Objective Loudness Rating.
The Board's provision is consistent with the 1998 ANSI A117.1 document, "Accessible and Usable Buildings and Facilities." ANSI is the voluntary standard-setting body which issues accessibility standards used by the nation's model building codes. The Board has issued a separate NPRM to harmonize the existing ADAAG provision with the ANSI standard. The FCC originally selected its requirement to be consistent with the ADA Accessibility Guidelines now being proposed for amendment. This provision is consistent with the proposed ADA and Architectural Barriers Act Accessibility Guidelines and the Telecommunications Act Accessibility Guidelines. No changes were made to this provision in the final rule.
[END OF PREAMBLE TEXT]
[BEGIN GUIDE TEXT]
How are volume controls affected by this provision?
If a volume control (usually a calibrated wheel or slide) is provided
that allows a user to set the level anywhere from 0 to the upper requirement
of 20 dB, there is no need to specify an intermediate level. If a stepped
volume control is provided (usually through pressing a button repeatedly),
one of the intermediate levels must provide 12 dB of gain.
How is this provision related to ANSI standards
and ADA Accessibility Guidelines?
This provision is consistent with the 1998 American National Standards Institute (ANSI) A117.1 document,
"Accessible and Usable
Buildings and Facilities." ANSI is a voluntary standard-setting body which issues accessibility
standards that become incorporated into the nation's model building codes. This
standard is consistent with the Telecommunications Act Accessibility Guidelines
and proposed revisions to the ADA and Architectural Barriers
Act Accessibility Revised Guidelines.
[END OF GUIDE TEXT]
(g) If the telecommunications product allows a user to adjust the receive volume, a function shall be provided to automatically reset the volume to the default level after every use.
[BEGIN PREAMBLE TEXT]
Paragraph (g) requires that an automatic reset be installed on any telephone that allows the user to adjust the volume higher than the normal level. This is a safety feature to protect people from suffering damage to their hearing if they accidentally answer a telephone with the amplification turned too high. (See §1194.23(d)(7) in the NPRM.)
Comment. Most commenters supported the provision for an automatic reset. One commenter said the reset would be a problem for an individual user who would be required to constantly readjust his or her telephone to a usable level.
Response. The provision is adopted from the ADA Accessibility Guidelines, where it applies to public phones used by many people. The FCC's Part 68 rules require an automatic reset when the phone is hung up if the volume exceeds 18 dB gain. To provide the ability to override the reset function would require a waiver from the FCC since the standards require a 20 dB gain. No changes have been made to this section in the final rule.
[END OF PREAMBLE TEXT]
[BEGIN GUIDE TEXT]
Why is this provision necessary?
This is a safety feature to protect people from damaging their hearing,
which might occur if they answer a telephone with the amplification accidentally
turned too high.
How does it relate to other accessibility guidelines
and rules?
The provision is adopted from the ADA Accessibility Guidelines
(ADAAG), where it applies to public phones used by many people. The FCC's Part
68 rules requires an automatic reset when the phone is hung up if the volume
exceeds 18 dB gain. To provide the ability to override the reset function would
require a waiver from the FCC.
[END OF GUIDE TEXT]
(h) Where a telecommunications product delivers output by an audio transducer which is normally held up to the ear, a means for effective magnetic wireless coupling to hearing technologies shall be provided.
[BEGIN PREAMBLE TEXT]
Paragraph (h) requires telephones, or other products that provide auditory output by an audio transducer normally held up to the ear, to provide a means for effective wireless coupling to hearing aids. Many hearing aids incorporate "T-coils" that generate sounds based on magnetic signals received from earpieces that can generate the appropriate magnetic field. Generally, this provision means the earpiece generates sufficient magnetic field strength to induce an appropriate field in a hearing aid T-coil. The output in this case is the direct voice output of the transmission source, not the "machine language" such as tonal codes transmitted by TTYs. For example, a telephone must generate a magnetic output so that the hearing aid equipped with a T-coil can accurately receive the message. This provision is consistent with the Telecommunications Act Accessibility Guidelines. (See §1194.23(d)(8) 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 hearing aid compatibility (HAC)?
HAC commonly refers to magnetic leakage around a telephone receiver. Hearing
aid users desire a phone that emits such a magnetic field because it enables
them to listen through a phone handset held up to their ear without getting
an annoying squealing sound (acoustic feedback). They accomplish this by turning
off their hearing aid microphone and listening "inductively" (via
magnetism).
Who benefits from products with wireless magnetic
coupling?
Hearing aid users (and their representative associations) have been the
primary advocates for hearing aid compatibility and are the most common beneficiaries.
However, only hearing aids with a telecoil, also known as a t-coil or telephone
switch, can pick-up sound inductively. In addition, cochlear implant users,
who have an optional t-coil inserted in an ear-level speech processor, can
listen inductively.
What types of products can be made hearing aid
compatible?
In addition to HAC telephone handsets, HAC telephone headsets are now
available. Note that this provision does not require a product to fit comfortably,
nor does it address the problem of interference to hearing aids. (People with
over-the-ear hearing aids often find that headsets do not direct sound into
their hearing aid very well, even if the headset is HAC.)
How does this 508 provision relate to other public
policies?
This standard is consistent with language in the Telecommunications
Act Accessibility Guidelines.
[END OF GUIDE TEXT]
(i) Interference to hearing technologies (including hearing aids, cochlear implants, and assistive listening devices) shall be reduced to the lowest possible level that allows a user of hearing technologies to utilize the telecommunications product.
[BEGIN PREAMBLE TEXT]
Paragraph (i) requires that interference to hearing technologies be reduced to the lowest possible level that allows a user of hearing technologies to utilize a telecommunications product. Individuals who are hard of hearing use hearing aids and other assistive listening devices, but they cannot be used if products introduce noise into the listening aids because of electromagnetic interference. (See §1194.23(d)(9) in the NPRM.)
Comment. The American National Standards Institutes (ANSI) is developing methods of measurement and defining the limits for hearing aid compatibility and accessibility to wireless telecommunications. At the time of the proposed rule, the ANSI C63.19 ANSI/IEEE Standard for Hearing Aid Compatibility with Wireless Devices was not completed. The NPRM noted that the Board may ultimately incorporate the standard when it is completed. Several commenters recommended referencing the work of the ANSI committee.
Response. The ANSI committee has recently completed its work. No changes have been made to this provision in the final rule and the provision continues to be a performance standard rather than a specific design standard. However, compliance with the ANSI C63.19 ANSI/IEEE Standard for Hearing Aid Compatibility with Wireless Devices would meet this provision.
[END OF PREAMBLE TEXT]
[BEGIN GUIDE TEXT]
Why is this provision necessary?
This provision largely grew out of complaints about digital cellular phones
by hearing aid users. Some hearing aid users heard a humming sound coming
from the phone and this interfered with the ability to hear the conversation.
This problem existed for both hearing aid users with t-coils as well as those
without t-coils. See discussion of provision (h) (previous) for an explanation
of a t-coil.
Who and what does the provision apply to?
This provision was carefully worded so that it could apply to listening
technologies other than hearing aids, such as cochlear implants and assistive
listening systems. In addition, although digital cellular phones were identified
as one source of interference, there may be other electronic and information
technologies that cause interference.
How can interference be determined?
The ANSI/IEEE C63.19 Standard, available from the American
National Standards Institute, can be used to assess electromagnetic characteristics
of hearing aids and wireless phones for the purpose of determining compatibility.
The FCC, consumer groups and the telecommunications industry are now discussing
plans for educating the public about this cell phone/hearing aid compatibility
standard.
[END OF GUIDE TEXT]
(j) Products that transmit or conduct information or communication, shall pass through cross-manufacturer, non-proprietary, industry-standard codes, translation protocols, formats or other information necessary to provide the information or communication in a usable format. Technologies which use encoding, signal compression, format transformation, or similar techniques shall not remove information needed for access or shall restore it upon delivery.
[BEGIN PREAMBLE TEXT]
Paragraph (j) provides that all products that act as a transport or conduit for information or communication shall pass all codes, translation protocols, formats, or any other information necessary to provide information or communication in a usable format. In particular, signal compression technologies shall not remove information needed for access or shall restore it upon decompression. Some transmissions include codes or tags embedded in "unused" portions of the signal to provide accessibility. For example, closed captioning information is usually included in portions of a video signal not seen by users without decoders. This section prohibits products from stripping out such information or requires the information to be restored at the end point. (See §1194.25(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]
What types of products does this provision apply
to?
This provision applies to any technologies involved with the transmission
of information, such as televisions and DVD players. People who depend on
closed captioning discovered that sometimes they would miss captions if they
saw a show on cable as opposed to receiving the same show through other broadcast
modes. Closed captioned information is usually included in portions of a video
signal not seen by users without decoders or who have turned off or disabled
the captioning. This issue applies to retaining audio description information
as well. This provision prohibits products from stripping out such information
or requires the information to be restored at the end point. The provision
was written broadly enough to ensure that it will apply to evolving technologies.
[END OF GUIDE TEXT]
(k) Products which have mechanically operated controls or keys, shall comply with the following:
[BEGIN PREAMBLE TEXT]
Paragraph (k) addresses controls that require some physical force to activate. It is the application of force to these controls that distinguishes them from touch sensitive controls where the mere presence of a hand or finger is detected and reacted to by the product. (See §1194.23(a) in the NPRM.)
Comment. As proposed, this provision addressed mechanically operated controls, keyboard, and keypads. Commenters were concerned that the provisions were too general. Some commenters said that it was possible to interpret this section as applying to touchscreens, and that making touchscreen controls compliant with these provisions was not possible. Commenters also raised the question of whether the proposed standards would require every product to have a keyboard.
Response. This provision has been amended to clarify its application to mechanically operated controls. The provision only applies to products which have mechanically operated controls or keys and therefore does not require every product to have a keyboard. This provision was not intended to apply to touchscreens as touchscreens do not have mechanically operated controls.
[END OF PREAMBLE TEXT]
[BEGIN GUIDE TEXT]
What products are generally covered under this provision?
This provision only applies to products that have mechanically operated
controls or keys, such as standard telephone keypads and computer keyboards.
It is not intended to apply to touchscreens.
[END OF GUIDE TEXT]
(1) Controls and keys shall be tactilely discernible without activating the controls or keys.
[BEGIN PREAMBLE TEXT]
Paragraph (k)(1) provides that mechanically operated controls and keys shall be tactilely discernible without activating the controls or keys. Tactilely discernible means that individual keys can be located and distinguished from adjacent keys by touch. To comply with this provision, controls that must be touched to activate, must be distinguishable from each other. This can be accomplished by using various shapes, spacing, or tactile markings. Because touch is necessary to discern tactile features, this provision provides that the control should not be activated by mere contact. For example, the standard desktop computer keyboard would meet this provision because the tactile mark on the "j" and "f" keys permits a user to locate all other keys tactilely. The geographic spacing of the function, "numpad" and cursor keys make them easy to locate by touch. In addition, most keyboards require some pressure before they transmit a keystroke. Conversely, "capacitance" keyboards that react as soon as they are touched and have no raised marks or actual keys would not meet this provision. A "membrane" keypad with keys that must be pressed can be made tactilely discernible by separating keys with raised ridges so that individual keys can be distinguished by touch. (See §1194.23(a)(1) 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 meant by 'tactilely discernible'?
Individual keys must be identifiable and distinguishable from adjacent keys
by touch. Compliance with this provision can be accomplished by using various
shapes, spacing, or tactile markings. The normal desktop computer keyboard,
for example, would meet this provision because the tactile marks on the "j"
and "f" keys permit a user to locate all other keys tactilely. Many
phones also have a raised dot on the number 5 button, enabling them to orient
their fingers around the 12 keys. In addition, the physical spacing of the function,
"numpad" and cursor keys make them easy to locate by touch.
Because touch is necessary to discern tactile features, this provision requires keyboards to enable touch that does not automatically activate a function based on mere contact. Fortunately most keyboards require some pressure on individual keys in order to enable a keystroke.
However, "capacitance" keyboards would not meet this provision because they react as soon as they are touched and have no raised marks or actual keys. They may not react at all when touched by persons with prostheses. A "membrane" keypad with keys that must be pressed can be made tactilely discernible by separating keys with raised ridges so that individual keys can be distinguished by touch.
[END OF GUIDE TEXT]
(2) Controls and keys shall be operable with one hand and shall not require tight grasping, pinching, or twisting of the wrist. The force required to activate controls and keys shall be 5 lbs. (22.2 N) maximum.
[BEGIN PREAMBLE TEXT]
Paragraph (k)(2) provides that mechanically operated controls shall be accessible to persons with limited dexterity. Individuals with tremor, cerebral palsy, paralysis, arthritis, or artificial hands may have difficulty operating systems which require fine motor control, assume a steady hand, or require two hands or fingers to be used simultaneously for operation. Individuals with high spinal cord injuries, arthritis, and other conditions may have difficulty operating controls which require significant strength. The provision limits the force required to five pounds and is based on §4.27.4 of the ADA Accessibility Guidelines and is consistent with the Telecommunications Act Accessibility Guidelines. (See §1194.23(a)(3) in the NPRM.)
Comment. The ITIC was concerned about requiring that all controls be easily activated. They pointed out that on many pieces of equipment the on/off switch is purposely set so that it is hard to activate. This is done to prevent accidental shut-down of equipment such as with a network server. They felt it was unreasonable to require changing that type of control.
Response. The Board has addressed this issue by adding §1194.3(f) which exempts such controls from these standards. The on/off switch on a network server for example, would be operated only when maintenance of the equipment was required and would not be for normal operation. No changes have been made to this section in the final rule.
[END OF PREAMBLE TEXT]
[BEGIN GUIDE TEXT]
How will individuals with disabilities benefit from the
requirement enabling operability without tight grasping, pinching, twisting
or pressure?
Individuals with tremor, cerebral palsy, or other disabilities may have
difficulty operating systems which require fine motor control, a steady hand,
or two hands to be used simultaneously for operation. Individuals with high
spinal cord injuries, arthritis, and other conditions may have difficulty operating
controls which require significant strength. The standard limits the force required
to five pounds and is based on section 4.27.4 of the ADA Accessibility Guidelines,
codified as the ADA Standards
for Accessible Design as part of the Department of Justice’s regulation
implementing title III of the ADA at 28 C.F.R. pt. 36, Appendix A. This provision
is also consistent with the Telecommunications
Act Accessibility Guidelines.
[END OF GUIDE TEXT]
(3) If key repeat is supported, the delay before repeat shall be adjustable to at least 2 seconds. Key repeat rate shall be adjustable to 2 seconds per character.
[BEGIN PREAMBLE TEXT]
Paragraph (k)(3) establishes provisions for key repeat rate where an adjustable keyboard repeat rate is supported. It requires that the keyboard delay before repeat shall be adjustable to at least two seconds per character. (See §1194.23(a)(5) 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 does "key repeat" mean?
This provision addresses a challenge encountered by some people with fine
motor coordination difficulty. Sometimes they accidentally press a key several
times when intending to hit it only once. This could potentially result in the
same character displaying several times on the screen. Some systems do not support
key repeat. However, where key repeat is provided, this provision requires the
repeat to be adjustable. Specifically, the delay must be adjustable for a length
of time that is no greater than 2 seconds between repeats.
[END OF GUIDE TEXT]
(4) The status of all locking or toggle controls or keys shall be visually discernible, and discernible either through touch or sound.
[BEGIN PREAMBLE TEXT]
Paragraph (k)(4) provides that the status of toggle controls such as the "caps lock" or "scroll lock" keys be determined by both visual means and by touch or sound. For example, adding audio patterns such as ascending and descending pitch tones that indicate when a control is turned on or off would alleviate the problem of a person who is blind inadvertently pressing the locking or toggle controls. Also, buttons which remain depressed when activated or switches with distinct positions would meet this provision. (See §1194.23(a)(2) 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 meant by "status of controls" and why
do people need that information?
This provision requires the status of toggle controls, such as the "caps
lock" or "scroll lock" keys to be identifiable by either touch
or sound, in addition to visual means. For example, adding audio patterns, such
as ascending and descending pitch tones that indicate when a control is turned
on or off, would alleviate the problem of a person who is blind inadvertently
pressing the locking or toggle controls. Also, buttons which remain depressed
when activated and switched with distinct positions may meet this provision.
[END OF GUIDE TEXT]
§ 1194.24 Video and multimedia products.
(a) All analog television displays 13 inches and larger, and computer equipment that includes analog television receiver or display circuitry, shall be equipped with caption decoder circuitry which appropriately receives, decodes, and displays closed captions from broadcast, cable, videotape, and DVD signals. As soon as practicable, but not later than July 1, 2002, widescreen digital television (DTV) displays measuring at least 7.8 inches vertically, DTV sets with conventional displays measuring at least 13 inches vertically, and stand-alone DTV tuners, whether or not they are marketed with display screens, and computer equipment that includes DTV receiver or display circuitry, shall be equipped with caption decoder circuitry which appropriately receives, decodes, and displays closed captions from broadcast, cable, videotape, and DVD signals.
[BEGIN PREAMBLE TEXT]
Paragraph (a) requires that television displays 13 inches and larger, and computer equipment that includes television receiver or display circuitry be equipped with the capacity to decode and display captioning for audio material. (See §1194.23(e)(1) in the NPRM.)
Comment. Commenters supported this provision in general, but provided suggestions for clarification. They noted that the FCC defines "television receiver" as a device that can receive and display signals from broadcast, satellite, cable transmission, or other similar transmission sources. The commenters recommended that the provision should also address television monitors that are used with video cassette recorders (VCRs), digital video disks (DVDs), or direct video input, but do not include tuners. These non-receiver displays are commonly used throughout the government and in educational institutions and therefore, should have the capability to decode closed captions. According to commenters, the provision should reference analog television's "line-21, NTSC" or "EIA-608" caption data decoding capabilities. Many DVD presentations already include line-21 captions and commenters expressed frustration with their inability to see these captions on their desktop or laptop computers. Commenters noted that subtitles are not a substitute for captions, as captions convey more than just dialog. One commenter stated that the provision should apply to screens 10 inches or larger; while another said that digital television (DTV) will allow usable captions on smaller screens and the Board should reference the digital captioning standard EIA-708.
Response. This provision has been clarified to cover all television displays, not just those defined as a receiver under the FCC definition. The 13-inch display size was chosen because it is consistent with the Television Decoder Circuitry Act of 1990. The term "analog" added to this provision clarifies the application of the provision.
At the time of the issuance of the NPRM, the FCC was considering a rule on digital television, but had not completed its rulemaking. On July 21, 2000, the FCC issued an order on decoder circuitry standards for DTV. That standard will take effect on July 1, 2002. Devices covered under the FCC rules include DTV sets with integrated "widescreen" displays measuring at least 7.8 inches vertically, DTV sets with conventional displays measuring at least 13 inches vertically, and stand-alone DTV tuners, whether or not they are marketed with display screens. The provision in the final rule has been changed to reflect the FCC regulation.
[END OF PREAMBLE TEXT]
[BEGIN GUIDE TEXT]
What are captions?
Like subtitles, captions display spoken dialogue as
printed words on a television screen or computer monitor. Unlike subtitles,
captions are specifically designed for hard-of-hearing and deaf viewers to
enable their full participation when viewing video or multimedia productions.
Captions are carefully placed to identify speakers. They often include information
regarding on- and off-screen sound effects, such as music or laughter. Captions
also hold secondary benefits for people who are learning a foreign language,
learning how to read, or watching TV in a noisy area, as well as those who
understand best by processing visual information.

Captions come in two forms: open or closed captioning:
- Open captions are displayed automatically as part of the video, without having to be selected by the user.
- Closed captions normally do not appear as part of the video portion of a multimedia presentation unless the viewer has selected them to appear. The person viewing the presentation must be using technology that includes a closed caption decoder. The decoder will allow the otherwise-hidden data within the television signal to be displayed on the user’s TV screen or computer monitor. Many newer television models allow viewers to toggle captions on or off with ease.
What television display formats are required to include
caption decoder circuitry?
Analog and digital television displays, as well as stand-alone digital television
tuners and computer equipment that includes digital television receiver or display
circuitry, must include caption decoder circuitry. Section 508 does not require
small analog or digital television displays to include caption decoder circuitry.
Specifically, analog televisions with screens smaller than 13 inches diagonally
and DTVs with displays smaller than 7.8 inches vertically are exempted. The
Television
Decoder Circuitry Act of 1990 and the Telecommunications
Act of 1996 contain similar provisions.
[END OF GUIDE TEXT]
(b) Television tuners, including tuner cards for use in computers, shall be equipped with secondary audio program playback circuitry.
[BEGIN PREAMBLE TEXT]
Paragraph (b) requires that television tuners, including tuner cards for use in computers, have the ability to handle a secondary audio track used for audio description of visual material. The secondary audio channel is commonly used for audio description. An "audio description" is a verbal description of the visual content of a presentation. Audio descriptions are important for persons who are blind or who have low vision because they provide a description of the visual content of a presentation synchronized with verbal information. (See §1194.23(e)(2) 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 a secondary audio channel and why is special circuitry
required?
The most common method of broadcasting audio description is through the
Secondary Audio Program (SAP) feature of stereo televisions. Each television
channel has what is called a "secondary audio channel" associated
with it. The secondary audio channel may contain audio descriptions or foreign
language translations of dialogue. If used to deliver audio descriptions, SAP
can greatly enhance the multimedia experience for those who are blind or who
have low vision. When television tuners, including tuner cards for use in computers,
are equipped with SAP playback circuitry, people who are blind or who have low
vision may
access whatever audio description has been
associated with the presentation.
How do audio descriptions assist people with disabilities?
An "audio description" is an audible description of the visual
content of a presentation, synchronized with the existing soundtrack. Typically,
appropriate portions of the audio description are narrated during what would
otherwise be natural silences in the presentation.
What is a tuner card?
Tuner cards enable a computer to receive television broadcasts. This product
is an example of what the industry calls "convergence" and represents
a way in which the functions historically provided by TV, PC, cable and Internet
products are merging onto multi-function devices. Tuner cards can be internal
or external and can work with laptop or desktop computers.
[END OF GUIDE TEXT]
(c) All training and informational video and multimedia productions which support the agency's mission, regardless of format, that contain speech or other audio information necessary for the comprehension of the content, shall be open or closed captioned.
[BEGIN PREAMBLE TEXT]
Paragraph (c) requires the captioning of audio material in certain multimedia presentations. (See §1194.23(e)(3) in the NPRM.)
Comment. The NPRM limited the provision for captioning to productions that were procured or developed for repeated showings to audiences that may include people who are deaf or hard of hearing. Commenters were concerned that agencies would avoid this provision by saying that they did not anticipate having members of the audience who were deaf or hard of hearing. Commenters noted that in many instances providing an interpreter may not be a suitable alternative. They also pointed out that subtitles are not an effective substitute for captioning multimedia presentations because subtitles do not display the environmental sounds, descriptions of music, or additional text that conveys a richer content than mere translation of the spoken dialogue.
Response. As proposed, the provision was intended to require captioning whenever the audience might include a person who was deaf or hard of hearing. The final rule has been modified to require that all training and informational video and multimedia presentations that contain speech or other audio information necessary for the comprehension of the content and which supports an agency's mission, shall be open or closed captioned regardless of the anticipated audience. This provision would not require that a videotape recorded by a field investigator to document a safety violation be captioned or audio described, for example. On the other hand, if such a videotape were subsequently used as part of a training or informational presentation, it would have to be captioned and audio described. A video of a retirement celebration would not be in support of an agency's mission and would thus not be required to be captioned. Also, this provision applies only to video and multimedia presentations which contain speech or other audio information necessary for the comprehension of the content. A video that is not narrated would not be required to be captioned since it does not contain speech. The NPRM asked a question about the availability of software products that could be used to provide captioning or description to multimedia computer presentations. Information supplied by commenters suggests such products are readily available.
[END OF PREAMBLE TEXT]
(d) All training and informational video and multimedia productions which support the agency's mission, regardless of format, that contain visual information necessary for the comprehension of the content, shall be audio described.
[BEGIN PREAMBLE TEXT]
Paragraph (d) requires that certain multimedia presentations provide an audio description of visual material. (See §1194.23(e)(4) in the NPRM.)
Comment. The proposed rule limited the provision for audio description to productions that were procured or developed for repeated showings to audiences that may include people who are blind or who have low vision. Similar to (c) above, commenters were concerned that agencies may use the limitation to avoid providing the audio description.
Response. This provision has been modified to require audio description regardless of the anticipated audience. The final rule has been modified to require that all training and informational video and multimedia productions which support the agency's mission, regardless of format, that contain visual information necessary for the comprehension of the content, shall be audio described. A video or multimedia presentation that does not support an agency's mission would not be required to be audio described. Also, this provision applies only to videos or multimedia presentations which contain visual information necessary for the comprehension of the content. A "talking heads" video does not generally contain visual information necessary for the comprehension of the content and would therefore not be required to be audio described.
[END OF PREAMBLE TEXT]
[BEGIN GUIDE TEXT]
What is a multimedia production?
The term "multimedia productions" refers to productions that present
information in more than one sensory mode, e.g., both audibly and visually.
For instance, streaming video with a soundtrack is a multimedia production.
A show broadcast through a Federal military radio station is audio only and
therefore not covered by this captioning requirement. (However, the procurement
of electronic and information technology necessary to operate the radio station
would be covered under the 508 standard.)
What does it mean for a video or multimedia production
to "support the agency’s mission?"
Video and multimedia products that "support the agency’s mission"are
generally required to be captioned and audio-described. For instance, a training
film for the Social Security Administration regarding how agency personnel should
determine an applicant’s eligibility for benefits, is a training production
that supports the agency’s mission. A video of a retirement celebration,
on the other hand, would not be "in support of an agency's mission"
and is not covered by these provisions.
Raw videotaped footage recorded by a field investigator to document a safety violation could be considered a film "in support of an agency’s mission". However, it is not a "production" and therefore does not need to be captioned or audio described. On the other hand, if such footage were subsequently incorporated into agency training or an informational presentation, it would have to be captioned and audio described.
When are captioning and audio descriptions
required?
Captioning and audio descriptions are only required to be provided when
important to understand the audio or visual components of a video or multimedia
production. That is, even if a production "supports the agency’s
mission," only those audio portions that are necessary for the comprehension
of the production’s content need to be captioned.
Ex: A videotaped lecture would need to capture the lecturer’s words in captions if it is intended to be used for future training, but the captions need not also relate that students’ chairs were squeaking or that the door at the back of the room was closing loudly as people exited.
Similarly, only those visual portions that are necessary for the comprehension of the production’s content need to be audio described.
Ex: A videotaped lecture would need to include an audio description of graphics the lecturer draws on a chalkboard to illustrate a point, but would not need to include an audio description of the strictly verbal – or "talking heads" – portion of the lecture.
If I believe that no one with a hearing loss will see
the video, do I still have to caption it?
Yes, unless an exception applies (e.g., electronic and information technology
that is part of a national security system is not required to adhere to the
Access Board’s provisions), section 508 requires accessibility features
to be built into new multimedia products as called for in this technical provision.
Section 508 generally focuses on how the technology is designed, rather than
who may use it.
Agencies will likely find that captions will assist many nondisabled individuals as well, including those who otherwise have normal hearing but are "functionally hard of hearing" in rooms with poor acoustics due to echos or noisy ventilation, those who are learning English as a second language, and individuals with auditory processing disabilities. Finally, many people simply learn best if information is presented in more than one sensory mode, such as hearing while simultaneously reading the dialogue.
[END OF GUIDE TEXT]
(e) Display or presentation of alternate text presentation or audio descriptions shall be user-selectable unless permanent.
[BEGIN PREAMBLE TEXT]
Paragraph (e) provides that the captioning and audio description required in (c) and (d) above must be user selectable unless permanent. (See §1194.23(e)(5) in the NPRM.)
Comment. The National Center for Accessible Media (NCAM) at public television station WGBH indicated that unlike captioning, audio descriptions can only be hidden and then activated on request on broadcast or cablecast video. The videotape format VHS commonly used by consumers and many companies cannot encode audio description for later activation like closed captions. Videos in the VHS format must have their descriptions permanently recorded as part of the main audio program. As a result, the audio descriptions on VHS cannot be turned off. As a solution, NCAM suggested that it may be desirable to have a separate videotape available that was not described, along with a described version to allow a user to choose which version they wish to present. Unlike the VHS format, CD-ROMs, DVDs and other multimedia can support alternate audio channels for descriptions (or alternate languages). The means of choosing those alternate tracks varies by the medium, but usually involves selection from an on-screen menu. Those menus must be made audible or otherwise readily selectable so that people who are blind or visually impaired can independently select and gain access to those audio descriptions.
Response. While the displaying of captioning is user selectable, there may be instances where the audio description would be considered permanent. The provision provides that when permanent, the user selectability provision does not apply. No changes have been made to this section in the final rule.
[END OF PREAMBLE TEXT]
[BEGIN GUIDE TEXT]
Does this provision apply differently to audio description
than it does to captioning?
Given the current state and prevalence of analog technology, the "user-selectable"
language generally applies to closed captioning, which the viewer can turn on
or off. Audio description on VHS format videos is permanently encoded and is
always "on." If a user wanted to watch a video without listening to
the audio description, he or she would need to find a separate version of the
production that was not audio described. The same is true with open captioning.
CD-ROMs, DVDs, and other digital forms of multimedia can support alternate audio channels for audio description. Using SMIL (Synchronized Multimedia Integration Language) or other emerging technologies, captioning and audio description will likely be more easily integrated into digital multimedia presentations in the near future.
Another point bundled in this provision relates to difficulty users have reported with independently enabling audio description. The means of choosing alternate tracks for audio description varies by the medium, but usually involves selection from an on-screen menu. Therefore those menus must be made audible or otherwise readily selectable so that people with visual disabilities can independently gain access to audio descriptions.
[END OF GUIDE TEXT]
§ 1194.25 Self contained, closed products.
[BEGIN PREAMBLE TEXT]
Sections 1194.25 (a) through (j) apply to those products that generally have embedded software and are commonly designed in such a fashion that a user cannot easily attach or install assistive technology. This section is a result of the reorganization of the final rule. In some instances, a personal computer with a touch-screen will be enclosed in a display and used as an "information kiosk. Self contained, closed products include, but are not limited to, information kiosks and information transaction machines, copiers, printers, calculators, fax machines, and other similar types of products. A definition of self contained, closed products has also been added.
[END OF PREAMBLE TEXT]
(a) Self contained products shall be usable by people with disabilities without requiring an end-user to attach assistive technology to the product. Personal headsets for private listening are not assistive technology.
[BEGIN PREAMBLE TEXT]
Paragraph (a) provides that access features must be built-into a self contained, closed product rather than requiring users to attach an assistive device to the product. Personal headsets are not considered assistive technology and may be required to use the product. (See §1194.23(f)(1) in the NPRM.)
Comment. Though discussed in the preamble, the text of the proposed rule did not address the issue of personal headsets. The preamble noted that personal headsets were not considered assistive technology. The ITIC urged the Board to make this clear in the text of the rule.
Response. The Board has modified this provision by clarifying that personal headsets are not considered assistive technology. No other changes were made to this provision.
[END OF PREAMBLE TEXT]
[BEGIN GUIDE TEXT]

What
are self contained, closed products?
Self contained closed products generally
have embedded software and are commonly designed in such a fashion that a user
cannot easily attach or install assistive technology. For example, one could
attach a screen reader to a computer which meets the section 508 standards but
one would not be expected to attach a screen reader to a copier machine. A copier
machine is an example of a self-contained, closed product. Other examples include,
calculators, fax machines, information transaction machines, and information
kiosks. Unlike other provisions which allow a product to meet the standards
by being compatible with assistive technology, this provision requires self
contained, closed products to contain built-in accessibility. Although not built-in,
a headset is considered an allowable add-on, since it is not considered assistive
technology in this case. Headsets might be used for privacy, not accessibility
reasons.
[END OF GUIDE TEXT]
(b) When a timed response is required, the user shall be alerted and given sufficient time to indicate more time is required.
[BEGIN PREAMBLE TEXT]
Paragraph (b) addresses access problems
that can arise when self contained, closed products require a response from
a user within a certain time and is identical to §1194.22 (p) and §1194.23
(d) which are discussed in detail above. (See §1194.21(d) in the NPRM.)
The final rule requires only that a user be notified if a process is about
to time-out and be given an opportunity to answer a prompt asking whether
additional time is needed.
[END OF PREAMBLE TEXT]
[BEGIN GUIDE TEXT]
This provision addresses access problems that can arise when self contained, closed products require a response from a user within a certain time. For example, persons with dexterity related disabilities would find entering information such as a social security number within a specified time difficult or impossible. This provision requires that a user be notified if a process is about to time-out and be given an opportunity to [answer a prompt asking whether additional time is needed.
[END OF GUIDE TEXT]
(c) Where a product utilizes touchscreens or contact-sensitive controls, an input method shall be provided that complies with §1194.23 (k) (1) through (4).
[BEGIN PREAMBLE TEXT]
Paragraph (c) requires that when a product utilizes touchscreens or contact-sensitive controls, a method of operating the product be provided that complies with the provisions for controls in §1194.23 (k) (1) through (4). (See §1194.21(f) in the NPRM.)
Comment. The proposed rule required that touchscreens or touch-operated controls be operable without requiring body contact or close human body proximity. Commenters found the proposed provision to be confusing. One commenter noted that the proposed rule required all touchscreens to be operable by a remote control. Several commenters expressed concern that accessibility to touchscreens for individuals who are blind or who have low vision was not adequately addressed.
Response. Touchscreens and other controls that operate by sensing a person's touch pose access problems for a range of persons with disabilities. This provision does not prohibit the use of touchscreens and contact sensitive controls, but, as modified, the final rule requires a redundant set of controls that can be used by persons who have access problems with touchscreens.
[END OF PREAMBLE TEXT]
[BEGIN GUIDE TEXT]
What products are generally covered under this
provision?
This provision covers
products that use touch screens or other controls which operate through a
person’s touch. In some instances, a personal computer with a touch-screen
will be enclosed in a display and used as an "information kiosk".
Touchscreens and other controls that operate by sensing a person’s touch
pose access problems for a range of persons with disabilities. This provision
does not prohibit the use of touchscreens and contact sensitive controls,
but requires a redundant set of controls that can be used by persons who have
access problems with touchscreens.
Is the latching mechanism to release a toner cartridge
in a copier considered a control covered by section 508?
No. Changing a toner cartridge is considered maintenance, not normal daily
operations. These provisions apply to operable controls which are defined as
components of a product that require 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. These provisions
are intended to apply to products in their normal operation rather than when
a product may be used for maintenance, repair, or occasional monitoring. Operable
controls for tasks such as initial set-up and configuration, adding and replacing
parts, and repair and service tasks, are not covered by the standards.
Would printer control panels used for configuration, status,
diagnostic, or maintenance functions be required to be accessible?
If a panel of lights were used strictly for troubleshooting, they would
not be addressed by the standards. However, these controls are usually available
for all to use and may be temporarily set for the tasks of co-workers. Adjustments
may be needed for features in a copier such as contrast, reduction, double sided,
stapling, and sorting. Sometimes, people accidentally hit an exposed button
and the user needs to put the system back on-line. Therefore, these controls
are necessary for normal daily operation and are required to be accessible.
What is meant by "tactilely discernible"?
Individual keys must be identifiable and distinguishable
from adjacent keys by touch. A product can meet this provision by using various
shapes, spacing, or tactile markings. The normal desktop computer keyboard,
for example, would meet this provision because the tactile marks on the "j"
and "f" keys permit a user to locate all other keys tactilely. In
addition, the physical spacing of the function, "numpad" and cursor
keys make them easy to locate by touch. Because touch is necessary to discern
tactile features, this provision requires keyboards to enable touch that does
not automatically activate a function based on mere contact. Fortunately,
most keyboards require some pressure on individual keys in order to enable
a keystroke.
However, "capacitance" keyboards would not meet this provision because they react as soon as they are touched and have no raised marks or actual keys. They may not react at all when touched by persons with prostheses. A "membrane" keypad with keys that must be pressed can be made tactilely discernible by separating keys with raised ridges so that individual keys can be distinguished by touch.
What is meant by "status of controls"
and why do people need that information?
This provision requires that the status of toggle controls, such as the
"caps lock" or "scroll lock" keys be identifiable by either
touch or sound, in addition to visual means. For example, adding audio patterns,
such as ascending and descending pitch tones that indicate when a control
is turned on or off, would alleviate the problem of a person who is blind
inadvertently pressing the locking or toggle controls. Also, buttons which
remain depressed when activated and switched with distinct positions may meet
this provision.
What does "key repeat" mean?
This provision addresses a challenge encountered by some people with fine
motor coordination difficulty. Sometimes, they accidentally press a key several
times when intending to hit it only once. This could potentially result in the
same character displaying several times on the screen. Some systems do not support
key repeat. However, where key repeat is provided, this provision requires the
repeat to be adjustable. Specifically, the delay must be adjustable for a length
of time that is no greater than 2 seconds between repeats.
How will individuals with disabilities benefit
from the requirement enabling operability without tight grasping, pinching,
twisting, or pressure?
Individuals with tremor, cerebral palsy, or other disabilities may have difficulty
operating systems which require fine motor control, a steady hand, or two hands
to be used simultaneously for operation. Individuals with high spinal cord injuries,
arthritis, and other conditions may have difficulty operating controls which
require significant strength. This provision limits the force required to five
pounds and is based on section 4.27.4 of the ADA Accessibility Guidelines,
codified as the ADA Standards for Accessible Design as part of the Department
of Justice’s regulation implementing title III of the ADA at 28 C.F.R.
pt. 36, Appendix A. This provision is also consistent with the Telecommunications
Act Accessibility Guidelines.
[END OF GUIDE TEXT]
(d) When biometric forms of user identification or control are used, an alternative form of identification or activation, which does not require the user to possess particular biological characteristics, shall also be provided.
[BEGIN PREAMBLE TEXT]
Paragraph (d) addresses the use of biometric controls. Biometric controls refer to controls that are activated only if particular biological features (e.g., fingerprint, retina pattern, etc.) of the user matches specific criteria. Using retinal scans or fingerprint identification may become a common practice as a method of allowing an individual to gain access to personal data from an information transaction type of machine. (See §1194.21(e) in the NPRM.)
Comment. In the proposed rule, the Board sought comment on the best approach to accessibility issues raised by biometric forms of identification and controls. Commenters responded that asking a system to have multiple forms of biometric identification could be prohibitively expensive. Most commenters were in agreement that biometric controls provide the most security. However, they also agreed that when such a system needs to be accessed by a person with a disability and that disability prohibits the use of a specific biometric feature, a non-biometric alternative should be provided that does not compromise security.
Response. The provision does not require a specific alternative. That selection is left up to the agency, which may choose a less expensive form of identification. No changes were made to this provision in the final rule.
[END OF PREAMBLE TEXT]
[BEGIN GUIDE TEXT]
What are biometric forms of user identification or control?
Biometric controls refer to controls
that are activated only if a particular biol ogical feature (e.g., voiceprint)
of the user exists and matches specific criteria. Other examples include retinal
scans and fingerprint identification that may become a common practice for allowing
an individual to gain access to personal data from an information transaction
type of machine.
Biometric controls provide a high level of security. However, when a system needs to be accessed by a person with a disability and that disability prohibits the use of a specific biometric feature, a non-biometric alternative should be provided that does not compromise security.
[END OF GUIDE TEXT]
(e) When products provide auditory output, the audio signal shall be provided at a standard signal level through an industry standard connector that will allow for private listening. The product must provide the ability to interrupt, pause, and restart the audio at anytime.
[BEGIN PREAMBLE TEXT]
Paragraph (e) requires that when products use audio as a way to communicate information, the auditory signal will be available through an industry standard connector at a standard signal level. Individuals using personal headphones, amplifiers, audio couplers, and other audio processing devices need a place to plug these devices into the product in a standard fashion. This gives the user the ability to listen privately to the information. The product must also provide a method to pause, restart, and interrupt the flow of information. (See §1194.23(f)(2) and §1194.25(d) in the NPRM.) No substantive comments were received on this provision and no changes were made, other than editorial changes.
[END OF PREAMBLE TEXT]
[BEGIN GUIDE TEXT]
Does this provision apply to "beeps and tones"
or to voice signals only?
This provision applies only to voice output. For example, it could apply
to a device that is providing voice output for a person who is unable to see
a visual display.
What is meant by a standard connector?
People who regularly use information transaction kiosks may plan to carry
a portable headset (or other listening coupler) with them. Examples of common
plugs on headsets include those that fit 2.5 mm jacks (such as those in most
cellular phones) and 3.5 mm plugs (such as those in most portable stereos).
There have been problems in the past when manufacturers made proprietary plugs
that were flat with multiple pins and were compatible only their own products.
[END OF GUIDE TEXT]
(f) When products deliver voice output in a public area, incremental volume control shall be provided with output amplification up to a level of at least 65 dB. Where the ambient noise level of the environment is above 45 dB, a volume gain of at least 20 dB above the ambient level shall be user selectable. A function shall be provided to automatically reset the volume to the default level after every use.
[BEGIN PREAMBLE TEXT]
Paragraph (f) provides that when products deliver voice output, they shall provide incremental volume control with output amplification up to a level of at least 65 dB. Where the ambient noise level of the environment is above 45 dB, a volume gain of at least 20 dB above the ambient level shall be user selectable. According to the Occupational Safety and Health Administration, and the American Speech, Language, and Hearing Association, 65 dB is the volume level for normal speech. This provision requires that audio output from a kiosk type product shall have a minimum level of 65 dB. For people with reduced hearing, voice levels must be 20 dB above the surround sound level to be understandable. This means that as long as the noise level in the surrounding environment is below 45 dB, the 65 dB output level would be sufficient. If the product is in an environment with a high noise level, the user must be able to raise the volume to a setting of 20 dB higher than the ambient level. (See §1194.23(f)(3) in the NPRM.) A feature has been required to automatically reset the volume to the default level after every use. This is consistent with a similar provision addressing telecommunications products. No substantive comments were received and no other changes have been made to this section in the final rule.
[END OF PREAMBLE TEXT]
[BEGIN GUIDE TEXT]
How was the level of 65 dB determined?
According to the Occupational Safety and Health Administration,
and the American Speech, Language, and Hearing Association, 65 dB is the volume
level for normal speech. This provision requires that audio output from a
kiosk type product have a minimum level of 65 dB. A feature has been required
to automatically reset the volume to the default level after every use. This
is consistent with a similar provision addressing telecommunications products.
What are the needs of people with partial
hearing?
People who are hard of hearing, generally speaking, require voice levels
to be 20 dB above the ambient sound level to understand speech. This means that
as long as the noise level in the surrounding environment is below 45 dB, the
65 dB output level would be sufficient. If the product is in an environment
with a high noise level, the user must be able to raise the volume to a setting
of 20 dB higher than the ambient noise level. This would require the owner or
other appropriate responsible party to determine the volume of the background
noise at the location of the machine (specifically whether it is above 45 dB),
so the machine can be selected or calibrated for that specific environment.
To effectively meet this provision, consideration needs to be given to the fact
that ambient noise levels may vary in certain environments.
[END OF GUIDE TEXT]
(g) 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 (g) addresses the use of color prompting and is identical to section 1194.21(i) discussed above. (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?
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]
(h) When a product permits a user to adjust color and contrast settings, a range of color selections capable of producing a variety of contrast levels shall be provided.
[BEGIN PREAMBLE TEXT]
Paragraph (h) addresses color selection and contrast settings and is identical to section 1194.21(j) discussed above. (See §1194.23(b)(8) in the NPRM.)
[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
t
o 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]
(i) Products shall be designed to avoid causing the screen to flicker with a frequency greater than 2 Hz and lower than 55 Hz.
[BEGIN PREAMBLE TEXT]
Paragraph (i) addresses the use of flashing objects and is identical to section 1194.21(k) discussed above. (See §1194.21(c) in the NPRM.)
[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]
(j) Products which are freestanding, non-portable, and intended to be used in one location and which have operable controls shall comply with the following:
(1) The position of any operable control shall be determined with respect to a vertical plane, which is 48 inches in length, centered on the operable control, and at the maximum protrusion of the product within the 48 inch length (see Figure 1 of this part).
Figure one illustrates two bird's-eye views. In both views, the vertical plane is centered on the control area. In the first view, the vertical plane is set back from the control area by a protrusion on the device. In the second view, there are no protrusions on the device and the vertical plane is right up against the control area.
(2) Where any operable control is 10 inches or less behind the reference plane, the height shall be 54 inches maximum and 15 inches minimum above the floor.
(3) Where any operable control is more than 10 inches and not more than 24 inches behind the reference plane, the height shall be 46 inches maximum and 15 inches minimum above the floor.
(4) Operable controls shall not be more than 24 inches behind the reference plane (see Figure 2 of this part).
Figure two illustrates two front views. The first view illustrates a reach of no more than 10 inches deep with the control area between 15 and 54 inches. The second view illustrates a reach greater than 10 inches but not more than 24 inches deep with the control area between 15 and 46 inches.
[BEGIN PREAMBLE TEXT]
Paragraphs (j) (1) through (4) provide provisions for the physical characteristics of large office equipment including reach ranges and the general physical accessibility of controls and features. Examples of these products, include but are not limited to, copiers, information kiosks and floor standing printers. These provisions are based on the Americans with Disabilities Act Accessibility Guidelines (ADAAG 4.2 Space Allowance and Reach Ranges). Two figures are provided to help explain the application of these provisions. (See §1194.21(b)(1) through (4) in the NPRM.) No substantive comments were received on these provisions and no changes were made in the final rule.
[END OF PREAMBLE TEXT]
[BEGIN GUIDE TEXT]
What do these provisions require?
These provisions apply to the physical characteristics of large office equipment
including reach ranges and the general physical accessibility of controls and
features. Examples of these products, include but are not limited to copiers,
information kiosks, and free standing printers. These provisions are based on
the Americans with Disabilities
Act Accessibility Guidelines (ADAAG 4.2 Space Allowance and Reach Ranges).
If a document feeder was within the technical
specifications, but access to the platen glass was outside the reach range,
would a copier machine meet the provisions?
No. Users need to be able to access both ways of placing a piece of paper
on a copier for copying. There are some things (too small or too large) that
cannot be run through a paper feed.
If the trays for storing reams of paper are not
reachable, does the copier machine meet the provisions?
Copier paper tray access is not covered under the standards because replacing
paper is considered a maintenance function, not a normal daily operation.
Operable controls include, but are not limited to, mechanically operated controls,
input and output trays, card slots, keyboards, or keypads. The standards apply
to products in their normal operation rather than when a product may be used
for maintenance, repair, or occasional monitoring. Other tasks such as initial
set-up and configuration, adding and replacing parts, and repair and service
tasks are also not covered by the standards.
[END OF GUIDE TEXT]
§ 1194.26 Desktop and portable computers.
[BEGIN PREAMBLE TEXT]
This section is a result of the reorganization of the final rule. Paragraphs (a) through (d) contain provisions that apply to desktop and portable computers. The provisions in §1194.21 for software address the accessibility of programs and operating systems that run on a computer. In contrast, the provisions in this section address physical characteristics of computer systems including the design of controls and the use of connectors. This section was previously addressed in §1194.21 (General requirements), §1194.23 (Component specific requirements) and §1194.25 (Requirements for compatibility with assistive technology) in the NPRM.
[END OF PREAMBLE TEXT]
(a) All mechanically operated controls and keys shall comply with §1194.23 (k) (1) through (4).
[BEGIN PREAMBLE TEXT]
Paragraph (a) addresses keyboards and other mechanically operated controls. These provisions are addressed further in sections 1194.23 (k) (1) through (4) above. (See §1194.23(a) in the NPRM.)
[END OF PREAMBLE TEXT]
[BEGIN GUIDE TEXT]
What products are covered under this provision?
These provisions cover the keyboards, keypads, and other controls on desktop
and laptop computers that need to be activated during the normal operation
of the system. Examples of controls that are not located on a keyboard but
are still covered include but are not limited to, on/off switches, reset buttons,
unlocking controls for docking stations, and releases on items such as PCMCIA
card slots and drives.
What is meant by "tactilely discernible"?
Individual keys must be identifiable and distinguishable
from adjacent keys by touch. A product can meet this provision by using various
shapes, spacing, or tactile markings. The typical desktop computer keyboard,
for example, would meet this provision because the tactile marks on the "j"
and "f" keys permit a user to locate all other keys tactilely. In
addition, the physical spacing of the function, "numpad" and cursor
keys make them easy to locate by touch.
Because touch is necessary to discern tactile features, this provision requires keyboards to enable touch that does not automatically activate a function based on mere contact. Fortunately, most keyboards require some pressure on individual keys in order to enable a keystroke.
However, "capacitance" keyboards would not meet this provision because they react as soon as they are touched and have no raised marks or actual keys. They may not react at all when touched by persons with a hand prostheses. A "membrane" keypad with keys that must be pressed can be made tactilely discernible by separating keys with raised ridges so that individual keys can be distinguished by touch.
What is meant by "status of controls"
and why do people need that information?
This provision requires that the status of toggle controls, such as the
"caps lock" or "scroll lock" keys be identifiable by either
touch or sound, in addition to visual means. For example, adding audio patterns,
such as ascending and descending pitch tones that indicate when a control
is turned on or off, would alleviate the problem of a person who is blind
inadvertently pressing the locking or toggle controls. Also, buttons which
remain depressed when activated and switched with distinct positions will
meet this provision.
Would the reading of status and diagnostic indicators
(e.g., light emitting
diodes (LEDs)) on a desktop computer’s front
panel be required to be accessible?
Lights and buttons on control panels which are provided strictly for troubleshooting
are not addressed. However, indicators of normal operation are covered. For
example, the status of "power on" is accompanied by the sound of
a fan, and disk activation is accompanied by the sound of a disk spinning.
What does "key repeat" mean?
This provision addresses a challenge encountered by some people with fine
motor coordination difficulty. Sometimes, they accidentally press a key several
times when intending to hit it only once. This could potentially result in
the same character displaying several times on the screen.
Some systems do not support key repeat. However, where key repeat is provided, this provision requires the repeat to be adjustable. Specifically, the delay must be adjustable for a length of time that is up to 2 seconds between repeats.
How will individuals with disabilities benefit
from the requirement enabling operability without tight grasping, pinching,
twisting, or pressure?
Individuals with tremor, cerebral palsy, or other disabilities may have
difficulty operating systems which require fine motor control, a steady hand,
or two hands to be used simultaneously for operation. Some laptop computers,
for example, require two hands to simultaneously depress buttons on both sides
of the laptop to open it, while other laptops can open when a user moves a
single switch on the front.
Individuals with high spinal cord injuries, arthritis, and other conditions may have difficulty operating controls which require significant strength. This provision limits the force required to five pounds and is based on section 4.27.4 of the ADA Accessibility Guidelines, codified as the ADA Standards for Accessible Design as part of the Department of Justice’s regulation implementing title III of the ADA at 28 C.F.R. pt. 36, Appendix A. This provision is also consistent with the Telecommunications Act Accessibility Guidelines.
[END OF GUIDE TEXT]
(b) If a product utilizes touchscreens or touch-operated controls, an input method shall be provided that complies with §1194.23 (k) (1) through (4).
[BEGIN PREAMBLE TEXT]
Paragraph (b) provides that systems using touchscreen
technology must also provide controls that comply with sections 1194.23 (k)
(1) through (4) discussed above. (See
§1194.21(f)
in the NPRM.) Similar to §1194.25 (c), this provision was modified in
the final rule to require redundant controls.
[END OF PREAMBLE TEXT]
[BEGIN GUIDE TEXT]
What products are covered
under this provision?
This provision covers both desktop and portable computers that use touchscreens
or other controls which operate through a person’s touch. Touchscreens
and other controls that operate by sensing a person’s touch pose access
problems for a range of persons with disabilities. This provision does not
prohibit the use of touchscreens and contact sensitive controls, but requires
a redundant set of controls that can be used by persons who have access problems
with touchscreens.
[END OF GUIDE TEXT]
(c) When biometric forms of user identification or control are used, an alternative form of identification or activation, which does not require the user to possess particular biological characteristics, shall also be provided.
[BEGIN PREAMBLE TEXT]
Paragraph (c)
requires that when biometric forms of identification are used, an alternative
must also be available. This provision is identical to §1194.25 (d) discussed
above.
[END OF PREAMBLE TEXT]
[BEGIN GUIDE TEXT]
What are biometric forms of user identification
or control?
Biometric controls refer to controls that are activated only if a particular
biological feature (e.g., voiceprint) of the user exists and matches specific
criteria. Fortunately, many computer software manufacturers are aware that
voice recognition is a beneficial input or activation method intended to supplement,
not replace, other input controls such as standard keyboards.
[END OF GUIDE TEXT]
(d) Where provided, at least one of each type of expansion slots, ports and connectors shall comply with publicly available industry standards.
[BEGIN PREAMBLE TEXT]
Paragraph (d) requires that products have standard ports and connectors. This means that the connection points on a system must comply with a standard specification that is available to other manufacturers. This provision assures that the designers of assistive technology will have access to information concerning the design of system connections and thus be able to produce products that can utilize those connections. (See §1194.25(b) in the NPRM.)
Comment. In the proposed rule, this provision was addressed in §1194.25(b) under the requirements for compatibility with assistive technology. A commenter noted that this provision was more specific to computer products and not to all products.
Response.
As noted, this provision has been modified to apply to computer products.
[END OF PREAMBLE TEXT]
[BEGIN GUIDE TEXT]
What does this provision require?
This provision requires connection points on a computer system to comply
with an industry standard technical specification that is available to other
manufacturers. This assures that the developers of assistive technology will
have access to information concerning the design of system connections and
thus be able to produce products that can utilize those connections. Examples
of publicly available industry standards may include RS-232, Centronics, SCSI
interfaces, PCMCIA, or USB.
[END OF GUIDE TEXT]
Subpart C -- Functional Performance Criteria
§ 1194.31 Functional performance criteria.
[BEGIN PREAMBLE TEXT]
This section provides functional performance criteria for overall product evaluation and for technologies or components for which there is no specific requirement under other sections. These criteria are also intended to ensure that the individual accessible components work together to create an accessible product. This section requires that all product functions, including operation and information retrieval, be operable through at least one mode addressed in each of the following paragraphs.
Comment. The ITIC requested clarification as to how a manufacturer would determine the type and number of assistive technology devices for which support must be provided by a product.
Response. Manufacturers do not need to be aware of the universe of assistive technology products on the market. Each provision specifies the type of assistive technology that must be supported. For example, §1194.31(a) addresses those assistive technology devices which provide output to persons who cannot see the screen. Such devices may include screen readers, Braille displays and speech synthesizers. There are numerous resources available to manufacturers to assist them in identifying specific types of assistive technology which would be used to access their product.
[END OF PREAMBLE TEXT]
(a) At least one mode of operation and information retrieval that does not require user vision shall be provided, or support for assistive technology used by people who are blind or visually impaired shall be provided.
[BEGIN PREAMBLE TEXT]
Paragraph (a) provides that at least one mode of operation and information retrieval that does not require user vision shall be provided, or support for assistive technology used by people who are blind or visually impaired shall be provided. It is not expected that every software program will be self-voicing or have its own built-in screen reader. Software that complies with §1194.21 would also satisfy this provision. (See §1194.27(a) in the NPRM.) No substantive comments were received regarding this provision and no changes were made in the final rule.
[END OF PREAMBLE TEXT]
(b) At least one mode of operation and information retrieval that does not require visual acuity greater than 20/70 shall be provided in audio and enlarged print output working together or independently, or support for assistive technology used by people who are visually impaired shall be provided.
[BEGIN PREAMBLE TEXT]
Paragraph (b) provides that at least one mode of operation and information retrieval that does not require visual acuity greater than 20/70 (when corrected with glasses) must be provided in audio and enlarged print output that works together or independently. In the alternative, support for assistive technology used by people who are blind or who have low vision must be provided. Although visual acuity of 20/200 is considered "legally blind," there are actually millions of Americans with vision below the 20/200 threshold who can still see enough to operate and get output from technology, often with just a little additional boost in contrast or font size. This paragraph requires either the provision of screen enlargement and voice output or, that the product support assistive technology. (See §1194.27(b) in the NPRM.) No substantive comments were received regarding this provision and no changes were made in the final rule.
[END OF PREAMBLE TEXT]
(c) At least one mode of operation and information retrieval that does not require user hearing shall be provided, or support for assistive technology used by people who are deaf or hard of hearing shall be provided.
[BEGIN PREAMBLE TEXT]
Paragraph (c) provides that at least one mode of operation and information retrieval that does not require user hearing must be provided, or support for assistive technology used by people who are deaf or hard of hearing shall be provided. This provision is met when a product provides visual redundancy for any audible cues or audio output. If this redundancy cannot be built-into a product then the product shall support the use of assistive technology. (See §1194.27(c) in the NPRM.) No substantive comments were received regarding this provision and no changes were made in the final rule.
[END OF PREAMBLE TEXT]
(d) Where audio information is important for the use of a product, at least one mode of operation and information retrieval shall be provided in an enhanced auditory fashion, or support for assistive hearing devices shall be provided.
[BEGIN PREAMBLE TEXT]
Paragraph (d) requires that audio information important for the use of a product, must be provided in an enhanced auditory fashion by allowing for an increase in volume and/or altering the tonal quality or increasing the signal-to-noise ratio. For example, increasing the output would assist persons with limited hearing to receive information. Audio information that is important for the use of a product includes, but is not limited to, error tones, confirmation beeps and tones, and verbal instructions. (See §1194.27(d) in the NPRM.) No substantive comments were received regarding this provision. The final provision has been amended editorially to provide that support for assistive hearing devices may be provided in place of built-in enhanced audio features.
[END OF PREAMBLE TEXT]
(e) At least one mode of operation and information retrieval that does not require user speech shall be provided, or support for assistive technology used by people with disabilities shall be provided.
[BEGIN PREAMBLE TEXT]
Paragraph (e) provides that at least one mode of operation and information retrieval which does not require user speech must be provided, or support for assistive technology shall be provided. Most products do not require speech input. However, if speech input is required to operate a product, this paragraph requires that at least one alternative input mode also be provided. For example, an interactive telephone menu that requires the user to say or press "one" would meet this provision. (See §1194.27(e) in the NPRM.) No substantive comments were received regarding this provision and no changes were made in the final rule.
[END OF PREAMBLE TEXT]
(f) At least one mode of operation and information retrieval that does not require fine motor control or simultaneous actions and that is operable with limited reach and strength shall be provided.
[BEGIN PREAMBLE TEXT]
Paragraph (f) provides that at least one mode of operation and information retrieval that does not require fine motor control or simultaneous actions and which is operable with limited reach and strength must be provided. (See §1194.27(f) in the NPRM.) No substantive comments were received regarding this provision and no changes were made in the final rule.
[END OF PREAMBLE TEXT]
Subpart D -- Information, Documentation, and Support
§ 1194.41 Information, documentation, and support.
[BEGIN PREAMBLE TEXT]
In order for a product to be fully usable by persons with disabilities, the information about the product and product support services must also be usable by persons with disabilities. These issues are addressed in this section.
[END OF PREAMBLE TEXT]
(a) Product support documentation provided to end-users shall be made available in alternate formats upon request, at no additional charge.
[BEGIN PREAMBLE TEXT]
Paragraph (a) states that when an agency provides end-user documentation to users of technology, the agency must ensure that the documentation is available upon request in alternate formats. Alternate formats are defined in §1194.4, Definitions. Except as provided in paragraph (b) below, this provision does not require alternate formats of documentation that is not provided by the agency to other users of technology. (See §1194.31(a) in the NPRM.) No substantive comments were received regarding this provision and no changes other than editorial changes were made in the final rule.
[END OF PREAMBLE TEXT]
(b) End-users shall have access to a description of the accessibility and compatibility features of products in alternate formats or alternate methods upon request, at no additional charge.
[BEGIN PREAMBLE TEXT]
Paragraph (b) requires that agencies supply end-users with information about accessibility or compatibility features that are built-into a product, upon request. (See §1194.31(b) in the NPRM.) No substantive comments were received regarding this provision and, other than an editorial revision substituting "methods" for "modes", and general editorial changes, no other changes were made in the final rule.
[END OF PREAMBLE TEXT]
(c) Support services for products shall accommodate the communication needs of end-users with disabilities.
[BEGIN PREAMBLE TEXT]
Paragraph (c) provides that help desks and other support services serving an agency must be capable of accommodating the communications needs of persons with disabilities. For example, an agency help desk may need to communicate through a TTY. The help desk or support service must also be familiar with such features as keyboard access and other options important to people with disabilities. (See §1194.31(a) in the NPRM.) No substantive comments were received regarding this provision and no changes other than editorial changes were made in the final rule.
[END OF PREAMBLE TEXT]
Figures to Part 1194
Figure one illustrates two bird's-eye views. In both views, the vertical plane is centered on the control area. In the first view, the vertical plane is set back from the control area by a protrusion on the device. In the second view, there are no protrusions on the device and the vertical plane is right up against the control area.
Figure two illustrates two front views. The first view illustrates a reach of no more than 10 inches deep with the control area between 15 and 54 inches. The second view illustrates a reach greater than 10 inches but not more than 24 inches deep with the control area between 15 and 46 inches.
END NOTES
1. Section 508 does not apply to national security systems, as that term is defined in section 5142 of the Clinger-Cohen Act of 1996 (40 U.S.C. 1452).
2. The Access Board is an independent Federal agency established by section 502 of the Rehabilitation Act (29 U.S.C. 792) whose primary mission is to promote accessibility for individuals with disabilities. The Access Board consists of 25 members. Thirteen are appointed by the President from among the public, a majority of who are required to be individuals with disabilities. The other twelve are heads of the following Federal agencies or their designees whose positions are Executive Level IV or above: The departments of Health and Human Services, Education, Transportation, Housing and Urban Development, Labor, Interior, Defense, Justice, Veterans Affairs, and Commerce; the General Services Administration; and the United States Postal Service.
3. Whenever the Access Board revises its standards, the Federal Acquisition Regulatory Council is required to revise the FAR, and each appropriate Federal agency is required to revise its procurement policies and directives within six months to incorporate the revisions.
4. 48 CFR Chapter 1, part 2, §2.101 Definitions Information Technology (c).
PREAMBLE TO FINAL RULE – REMAINING TEXT
(Below is the remaining text from the Preamble of the final rule that did not relate to a specific provision and was therefore not excerpted and pasted above. It is included here so the Complete Final Rule is included.)
AGENCY: Architectural and Transportation Barriers Compliance Board.
ACTION: Final Rule.
SUMMARY: The Architectural and Transportation Barriers Compliance Board (Access Board) is issuing final accessibility standards for electronic and information technology covered by section 508 of the Rehabilitation Act Amendments of 1998. Section 508 requires the Access Board to publish standards setting forth a definition of electronic and information technology and the technical and functional performance criteria necessary for such technology to comply with section 508. Section 508 requires that when Federal agencies develop, procure, maintain, or use electronic and information technology, they shall ensure that the electronic and information technology allows Federal employees with disabilities to have access to and use of information and data that is comparable to the access to and use of information and data 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.
DATES: Effective date: February 20, 2001.
FOR FURTHER INFORMATION CONTACT: Doug Wakefield, Office of Technical and Information Services, Architectural and Transportation Barriers Compliance Board, 1331 F Street, NW., suite 1000, Washington, DC 20004-1111. Telephone number (202) 272-5434 extension 139 (voice); (202) 272-5449 (TTY). Electronic mail address: wakefield@access-board.gov.
SUPPLEMENTARY INFORMATION:
Availability of Copies and Electronic Access
Single copies of this publication may be obtained at no cost by calling the Access Board's automated publications order line (202) 272-5434, by pressing 2 on the telephone keypad, then 1, and requesting publication S-40 (Electronic and Information Technology Accessibility Standards Final Rule). Persons using a TTY should call (202) 272-5449. Please record a name, address, telephone number and request publication S-40. This document is available in alternate formats upon request. Persons who want a copy in an alternate format should specify the type of format (cassette tape, Braille, large print, or computer disk). This document is also available on the Board's Internet site (http://www.access-board.gov/sec508/508standards.htm).
Background
On August 7, 1998, the President signed into law the Workforce Investment Act of 1998, which includes the Rehabilitation Act Amendments of 1998. Section 508 of the Rehabilitation Act Amendments, as amended by the Workforce Investment Act of 1998, requires that when Federal agencies develop, procure, maintain, or use electronic and information technology, they shall ensure that the electronic and information technology allows Federal employees with disabilities to have access to and use of information and data that is comparable to the access to and use of information and data by Federal employees who are not individuals with disabilities, unless an undue burden would be imposed on the agency. (1) 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.
Section 508(a)(2)(A) requires the Architectural and Transportation Barriers Compliance Board (Access Board) (2) to publish standards setting forth a definition of electronic and information technology and the technical and functional performance criteria necessary for accessibility for such technology. If an agency determines that meeting the standards, when procuring electronic and information technology, imposes an undue burden, it must explain why meeting the standards creates an undue burden.
On March 31, 2000, the Access Board issued a notice of proposed rulemaking (NPRM) in the Federal Register (65 FR 17346) proposing standards for accessible electronic and information technology. The proposed standards were based on recommendations of the Electronic and Information Technology Access Advisory Committee (EITAAC). The EITAAC was convened by the Access Board in September 1998 to assist the Board in fulfilling its mandate under section 508. It was composed of 27 members including representatives of the electronic and information technology industry, organizations representing the access needs of individuals with disabilities, and other persons affected by accessibility standards for electronic and information technology. Representatives of Federal agencies, including the departments of Commerce, Defense, Education, Justice, Veterans Affairs, the Federal Communications Commission, and the General Services Administration, served as ex-officio members or observers of the EITAAC.
The public comment period for the proposed rule ended on May 30, 2000. Over 100 individuals and organizations submitted comments on the proposed standards. Comments were submitted by Federal agencies, representatives of the information technology industry, disability groups, and persons with disabilities. Approximately 35 percent of the comments came from Federal agencies. Fifteen percent came from individual companies and industry trade associations. Approximately 30 percent of the comments were from individuals with disabilities and organizations representing persons with disabilities. Eight states responded to the proposed rule and the remaining comments were from educational or research organizations.
The proposed standards covered various products, including computers, software, and electronic office equipment in the Federal sector. They provided technical criteria specific to various types of technologies and performance-based requirements, which focus on the functional capabilities of covered technologies. Specific criteria covered controls, keyboards, and keypads; software applications and operating systems (non-embedded); web-based information or applications; telecommunications functions; video or multi-media products; and information kiosks and transaction machines. Also covered was compatibility with adaptive equipment that people with disabilities commonly use for information and communication access.
General Issues
This section of the preamble addresses general issues raised by comments filed in response to the NPRM. Individual provisions of the rule are discussed in detail under the Section-by-Section Analysis below.
Effective Date for the Enforcement of Section 508
Section 508(a)(2)(A) required the Board to publish final standards for accessible electronic and information technology by February 7, 2000. Section 508(a)(3) provides that within six months after the Board publishes its standards, the Federal Acquisition Regulatory Council is required to revise the Federal Acquisition Regulation (FAR), and each Federal agency is required to revise the Federal procurement policies and directives under its control to incorporate the Board's standards. (3)
Because of the delay in publishing the standards, the proposed rule sought comment on making the standards effective six months after publication in the Federal Register to provide Federal agencies an opportunity to more fully understand the new standards and allow manufacturers of electronic and information technology time to ensure that their products comply with the standards before enforcement actions could be initiated. The NPRM noted that postponing the effective date of the Board's standards could not affect the right of individuals with disabilities to file complaints for electronic and information technology procured after August 7, 2000 since that right was established by the statute.
Comment. There was a general consensus that a delay in the effective date of the standards was warranted to provide a reasonable period of time for industry to bring their products into compliance with the Board's standards.
Response. On July 13, 2000, President Clinton signed into law the Military Construction Appropriations Act for Fiscal Year 2001 (Public Law 106-246) which included an amendment to section 508 of the Rehabilitation Act. Under the amendment, the effective date for the enforcement of section 508 was delayed to allow for additional time for compliance with the Board's final standards. As originally written, the enforcement provisions of section 508 would have taken effect on August 7, 2000. The amendment in Public Law 106-246 revises the enforcement date to 6 months from publication of the Board's final standards, consistent with the law's intent. As a result of the amendment, there is no need to delay the effective date of the standards. The effective date for the standards is largely an administrative provision and does not affect the date by which complaints may be filed under section 508. Complaints and lawsuits may be filed 6 months from the date of publication of these standards in the Federal Register.
Technical and Functional Performance Criteria
Section 508 (a)(2)(A)(ii) requires the Board to develop technical and functional performance criteria necessary to implement the requirements of section 508.
Comment. The Information Technology Association of America (ITAA) commented that the specificity of many of the proposed provisions go beyond what may be characterized as technical and functional performance criteria. ITAA commented that the statute intended that the standards be set forth in terms of technical and functional performance criteria as opposed to technical design requirements. Performance criteria are intended to give discretion in achieving the required end result. ITAA commented that product developers, who have a broad understanding of their own products, industry standards, and future trends need this discretion to meet the requirements of section 508 and that it is impossible to predict accurately future technological advances. Design requirements, they added, inhibit development and innovation. ITAA was concerned that many of the proposed provisions would impede technological advancements because they were too specific. On the other hand, ITAA supported proposed §1194.5, Equivalent Facilitation, because it would lessen the adverse impact of the specific requirements.
Response. According to administration policy, performance standards are generally to be preferred to engineering or design standards because performance standards provide the regulated parties the flexibility to achieve the regulatory objective in a more cost-effective way. The Board was given the responsibility to develop technical and functional performance criteria necessary to implement the requirements of section 508. Thus, the standards provide technical requirements as well as functional performance criteria. The standards reflect the need to be as descriptive as possible because procurement officials and others need to know when compliance with section 508 has been achieved and because the failure to meet the standards can result in an enforcement action. Several provisions, such as those regarding time-out features, have been revised in the final rule to be more performance oriented rather than specific design standards.
Section-by-Section Analysis
This section of the preamble summarizes each of the provisions of the final rule and the comments received in response to the proposed rule. Where the provision in the final rule differs from that of the proposed rule, an explanation of the modification is provided. The text of the final rule follows this section.
Subpart A -- General
Section 1194.1 Purpose
Section 1194.3 General Exceptions
Section 1194.4 Definitions
1194.5 Equivalent facilitation.
Subpart B -- Technical Standards (Formerly Subpart B -- Accessibility Standards in the NPRM).
Section 1194.21 Software Applications and Operating Systems
Section 1194.22 Web-based Intranet and Internet Information and Applications
Section 1194.23 Telecommunications Products
Section 1194.24 Video and Multimedia Products
Section 1194.25 Self Contained, Closed Products
Section 1194.26 Desktop and Portable Computers
Subpart C -- Functional Performance Criteria
Section 1194.31 Functional Performance Criteria
Subpart D -- Information, Documentation, and Support
Section 1194.41 Information, Documentation, and Support
Regulatory Process Matters
Executive Order 12866: Regulatory Planning and Review and Congressional Review Act
This final rule is an economically significant regulatory action under Executive Order 12866 and has been reviewed by the Office of Management and Budget (OMB). The final rule is also a major rule under the Congressional Review Act. The Board has prepared a regulatory assessment for the final rule which has been placed in the docket and is available for public inspection. The regulatory assessment is also available on the Board's Internet site (http://www.access-board.gov/sec508/assessment.htm). In the NPRM, the Board sought comment on the regulatory assessment which was prepared in conjunction with the proposed rule. The Board received four comments that specifically addressed concerns with that economic assessment. A summary of the comments received and the Board's responses can be found in Chapter Six of the Board's final regulatory assessment.
Section 508 covers the development, procurement, maintenance or use of electronic and information technology by Federal agencies. Exemptions are provided by statute for national security systems and for instances where compliance would impose an undue burden on an agency. The final rule improves the accessibility of electronic and information technology used by the Federal government and will affect Federal employees with disabilities, as well as members of the public with disabilities who seek to use Federal electronic and information technologies to access information. The final rule is based largely on the recommendations of the Electronic and Information Technology Access Advisory Committee.
The standards in the final rule will be incorporated into the Federal Acquisition Regulation (FAR). Failure of a Federal agency to comply with the standards may result in a complaint under the agency's existing complaint procedures under section 504 of the Rehabilitation Act or a civil action seeking to enforce compliance with the standards.
Estimated Baseline of Federal Spending for Electronic and Information Technology
According to OMB figures, Federal government expenditures for information technology products was $37.6 billion in fiscal year 1999. The defense agencies appear to have the highest information technology budgets, while civilian agency budgets are expected to increase rapidly. It was not possible however, to disaggregate this data such that it was useful for purposes of a regulatory assessment. Instead, the regulatory assessment uses annual sales data collected from the General Services Administration (GSA) as a proxy for the actual number of products in each applicable technology category. Using the GSA data, the regulatory assessment estimates that the Federal government spends approximately $12.4 billion annually on electronic and information technology products covered by the final rule. This estimate likely understates the actual spending by the Federal government because it is limited to the GSA data. Agencies are not required to make purchases through the GSA supply service, thus many items are purchased directly from suppliers. As a result, the government costs for software and compatible hardware products may actually be higher than estimates would indicate.
The regulatory assessment also examines historical budgetary obligations for information technology tracked by OMB until fiscal year 1998. Two scenarios were examined to develop an upper and lower bound to represent the proportion expected to be potentially affected by the final rule. During a five year period from fiscal year 1994 through fiscal year 1998, the average proportion of the total information technology obligations potentially covered by the final rule ranged between 25 percent and 50 percent. The $12.4 billion GSA estimate falls within this range, representing 33 percent of the total fiscal year 1999 information technology obligations of $37.6 billion. One limitation of these ranges is that they are based on gross classifications of information technology obligations and do not provide the level of disaggregation necessary to parallel the GSA data assessment. As a result, the two scenarios likely include expenditures on products and services that would not be effected by the final rule to a higher degree than the data obtained from GSA.
The degree to which the potential understatement of baseline spending leads to an understatement of the cost of the final rule is unclear. Some of the components of the estimated cost of the final rule rely heavily on the level of Federal spending while others are independent of this number.
Estimated Cost of the Final Rule
The regulatory assessment includes both direct and opportunity costs associated with the final rule. Major sources of cost include:
- Costs of modifying electronic and information technology to meet the substantive requirements of the standards;
- Training of staff, both Federal and manufacturers, to market, support, and use technologies modified in response to the standards; and
- Translation of documentation and instructions into alternate formats.
The direct costs that were quantified are shown in Table 1. The total quantified costs to society range from $177 million to $1,068 million annually. The Federal proportion of these costs is estimated to range between $85 million and $691 million. The ability of manufacturers, especially software manufacturers, to distribute these costs over the general consumer population will determine the actual proportion shared by the Federal government. Assuming that the addition of accessibility features add value to the products outside the Federal government, it is expected that the costs will be distributed across society thereby setting a lower bound cost to the Federal government of $85 million. If manufacturers do not distribute the costs across society, the upper bound of the Federal cost will increase to an estimated $1,068 million. These costs must be placed in appropriate context by comparing them with the total Federal expenditures for information technology. By comparison, the lower and upper bound of the incremental costs represent a range of 0.23 percent to 2.8 percent of the $37.6 billion spent by the Federal government on information technology in fiscal year 1999. Although the regulatory assessment does not analyze the timing of expenditures or reductions in costs over time, it is expected that the costs will decrease over time as a proportion of total electronic and information technology spending.
Table 1
| Electronic and information technology | Lower
bound cost estimates |
Upper
bound cost estimates |
|---|---|---|
| General Office Software | $110 |
$456 |
| Mission Specific Software | 10 |
52 |
| Compatible Hardware Products | ..... |
337 |
| Document Management Products | 56 |
222 |
| Microphotographic Products | 0.1 |
0.4 |
| Other Miscellaneous Products | 0.2 |
1 |
| Total Social Cost | 177 |
1,068 |
| Estimated Federal Proportion | 85 |
6911 |
1 As noted above, if manufacturers do not distribute the costs across society, the upper bound of the Federal cost will increase to an estimated $1,068 million.
Accessible alternatives are available to satisfy the requirements of the final rule for many types of electronic and information technologies, particularly computers and software products. Some electronic and information technology products will require modifications to meet the requirements of the final standards.
For many types of electronic and information technology, the final rule focuses on compatibility with existing and future assistive devices, such as screen readers. The final rule does not require that assistive technologies be provided universally. Provision of assistive technologies is still governed by the reasonable accommodation requirements contained in sections 501 and 504 of the Rehabilitation Act. Section 508 does not require that assistive devices be purchased, but it does require that covered electronic and information technology be capable of having such devices added at some later time as necessary.
Software products represent the largest part of the estimated costs. The regulatory assessment assumes that Federal software expenditures can be divided into two major subcategories: general office applications and mission-specific applications. Internet applications are assumed to be represented within each of these subcategories. General office applications include operating systems, wordprocessors, and spreadsheets, and are assumed to represent 80 percent of the total software category. The remaining 20 percent covers mission- specific or proprietary applications that have limited distribution outside the Federal government. Within each subcategory, the estimated costs of the final rule are distributed according to the level or degree of accessibility already being achieved in the private sector.
The general office application subcategory is broken into three groups based on discussions with several industry experts. The first 30 percent is expected to require very little modification to satisfy the final standards and therefore no incremental cost is associated with this group. The middle 40 percent is expected to require minor to medium alterations to satisfy the final rule. The cost of modifying a particular general office application in this category is estimated to be in the range of 0.4 percent to 1 percent based on discussions with several manufacturers. This assumption is based on the ratio of employees dedicated to accessibility issues. The methodology uses employee classification as a proxy for cost or expense of accessibility research and development, labor, and design that are all factored into the final product cost. The remaining 30 percent is expected to require significant modifications to meet the requirements of the final rule, which is estimated to cost in the range of 1 percent to 5 percent based on discussion with industry experts.
The regulatory assessment assumes that the remaining 20 percent of the software products purchased by the Federal government represent proprietary or mission-specific software with limited distribution outside the government. These products will require significant modification to satisfy the final rule. Based on discussions with industry experts, the cost increase associated with achieving the level of accessibility required by the final rule is estimated to range from 1 percent to 5 percent.
Estimated Benefits of the Final Rule
The benefits associated with the final rule results from increased access to electronic and information technology for Federal employees with disabilities and members of the public seeking Federal information provided using electronic and information technology. This increased access reduces barriers to employment in the Federal government for persons with disabilities, reduces the probability that Federal employees with disabilities will be underemployed, and increases the productivity of Federal work teams. The final standards may also have benefits for people outside the Federal workforce, both with and without disabilities, as a result of spillover of technology from the Federal government to the rest of society.
Two methods are presented in the regulatory assessment for evaluating the quantifiable benefits of the final rule. The first is a wage gap analysis that attempts to measure the difference in wages between the general Federal workforce and Federal workers with targeted and reportable disabilities. While this analysis is limited to white collar Federal workers due to data constraints, the potential change in productivity is measured by the difference between the weighted average salary for all white collar Federal employees and the average within the two disability classes. This assumes that an increase in accessibility will help diminish this wage gap by increasing worker productivity.
The alternative is a team based approach for measuring the productivity of Federal workers. This approach is based on the assumption that a Federal workers wage rate reflects their productivity and the scarcity of their skills in the labor market. However this may not apply to Federal wage rates, thus the average productivity of a Federal team is assumed to be equivalent to the average Federal wage rate. Based on this average rate, it is assumed that the final rule will produce an increase in productivity ranging between 5 percent and 10 percent.
Since no data have been identified to support the increase in productivity in the team based approach, the wage gap analysis is used to represent the benefits generated by the final rule shown in Table 2. Keeping in mind certain data limitations with this analysis, the benefits derived from the wage gap method do not account for benefits that may be accrued by the general public or other Federal workers due to spillover effects of increased accessibility resulting from the final standards.
Table 2
| Productivity increase |
Aggregate benefits range (millions) |
|---|---|
| Lower Bound |
..... |
Upper Bound |
$466 |
Not all government policies are based on maximizing economic efficiency. Some policies are based on furthering the rights of certain classes of individuals to achieve more equitable results, regardless of the effect on economic efficiency. Accessibility to electronic information and technology is an essential component of civil rights for persons with disabilities. The final rule will ensure that Federal employees with disabilities will have access to electronic and information technology used by the Federal government that is comparable to that of Federal employees without disabilities; and that members of the public with disabilities will have comparable access to information and services provided to members of the public without disabilities through the use of Federal electronic and information technology.
Based on Bureau of Census statistics from 1994, 20.6 percent or 54 million persons in the United States have some level of disability. By increasing the accessibility of electronic and information technology used by the Federal government, the final rule may also improve future employment opportunities in the Federal government for persons with disabilities currently employed by the Federal government, and for persons that are working in the private sector or are classified as not being active in the labor force. Increasing the accessibility of electronic and information technology increases the productivity and mobility of the disabled sector of the labor pool that, under existing conditions, may face barriers to their employment and advancement within the Federal workforce and in the private sector. The standards will allow other Federal workers who become temporarily disabled to maintain their productivity during their illness. In addition, accessible features of electronic and information technology may also enhance the productivity of Federal workers without disabilities and therefore be a benefit to the workforce in general.
Regulatory Flexibility Act
The Regulatory Flexibility Act (RFA) (5 U.S.C. 601 et seq.), as amended, generally requires Federal agencies to conduct a regulatory flexibility analysis describing the impact of the regulatory action on small entities. However, section 605(b) of the RFA, provides that a regulatory flexibility analysis is not required if the rule will not have a significant economic impact on a substantial number of small entities. This final rule imposes requirements only on the Federal Government and the Board certifies that it does not impose any requirements on small entities. As a result, a regulatory flexibility analysis is not required.
Executive Order 13132: Federalism
By its terms, this rule applies to the development, procurement, maintenance or use by Federal agencies of electronic and information technology. As such, the Board believes that it does not have federalism implications within the meaning of Executive Order 13132. In the proposed rule, the Board referred to the Department of Education's interpretation of the Assistive Technology Act (the "AT Act"), 29 U.S.C. 3001. The Board received approximately five responses from various State organizations regarding the relationship between the AT Act and Section 508 of the Rehabilitation Act. The Department of Education, the agency responsible for administering the AT Act, has advised the Board that it plans to work with States to address the relationship between the AT Act and section 508, and specifically how the Board's standards would apply to the States for purposes of the AT Act. As part of this process, the Department of Education will address issues raised in the five responses the Board received on the relationship between the AT Act and section 508 of the Rehabilitation Act.
Unfunded Mandates Reform Act
The Unfunded Mandates Reform Act does not apply to proposed or final rules that enforce constitutional rights of individuals or enforce any statutory rights that prohibit discrimination on the basis of race, color, sex, national origin, age, handicap, or disability. Since the final rule is issued under the authority of section 508, part of title V of the Rehabilitation Act of 1973 which establishes civil rights protections for individuals with disabilities, an assessment of the rule's effects on State, local, and tribal governments, and the private sector is not required by the Unfunded Mandates Reform Act.
List of Subjects in 36 CFR Part 1194
Civil rights, Communications equipment, Computer technology, Electronic products, Government employees, Government procurement, Individuals with disabilities, Reporting and recordkeeping requirements, Telecommunications.
This collation was prepared by the Trace Center with funding from the National Institute on Disability and Rehabilitation Research of the U.S. Department of Education, under Grants H133E980008 and H133E990006.