36 CFR Part 1194 - Proposed Information and Communication Technology (ICT) Standards and Guidelines NPRM - Preamble

Chapter 5: Software (Section-by-Section Analysis)

Chapter 5 contains proposed technical requirements for software, applications, platforms, and software tools. The requirements in this chapter, along with the scoping provisions in proposed E207 and C205, collectively form the “suite” of accessibility requirements for these types of ICT. This chapter is largely drawn from existing 508 Standards § 1194.21, but with updating to harmonize with WCAG 2.0.

501 General (Section-by-Section Analysis)

This is an introductory section.

501.1 Scope (Section-by-Section Analysis)

This section proposes that the technical requirements for software in this chapter be applied where either (a) required by 508 Chapter 2 or 255 Chapter 2, or (b) where otherwise referenced in any other chapters. There are two exceptions. Exception 1, as proposed, provides that Web applications conforming to all Level A and AA Success Criteria and all Conformance Requirements in WCAG 2.0 need not conform to proposed 502 (Interoperability with Assistive Technology) or 503 (Applications). This exception is provided because software that conforms to WCAG 2.0 AA is already accessible. The value of promoting a single harmonized standard outweighs any small benefit that might be achieved by conforming to overlapping, but separate, standards.

Exception 2 proposes that software that (1) is assistive technology and (2) supports the accessibility services of the platform for which it is designed need not conform with the provisions of this chapter. This exception is included because assistive technology frequently needs flexibility in order to perform well for end-users with disabilities. For example, a switch-activated on-screen keyboard might not have a mode that makes it usable by someone who is blind. This exception is also deliberately limited to software that follows platform specifications because it is important that assistive technology be compatible with other assistive technology.

502 Interoperability with Assistive Technology (Section-by-Section Analysis)

This is an introductory section.

502.1 General (Section-by-Section Analysis)

This section proposes that platforms, software tools provided by platform developers, and applications must conform to the requirements in the accompanying subsections related to documented accessibility features (502.2), accessibility services (502.3), and platform accessibility services (502.4). An exception is provided for platforms and applications that have closed functionality.

This section has implications for both platform developers and federal procurement officials. Agencies would have to ensure that all operating systems they purchase have an associated set of documented accessibility services. Software developers would have to provide accessibility services when creating platforms and their software tools.

502.2 Documented Accessibility Features (Section-by-Section Analysis)

This section addresses the compatibility of software and assistive technology. Specifically, under proposed 502.2, platform features that are defined in the platform documentation as accessibility features would be required to conform to requirements in accompanying subsections related to user control (502.2.1) and non-disruption (502.2.2) of accessibility features.

502.2.1 User Control of Accessibility Features (Section-by-Section Analysis)

This section proposes that platforms must provide user control over platform features when such features are defined in platform documentation as serving an accessibility purpose. This provision would be new to the 508 Standards and 255 Guidelines, though it draws on the prohibition in § 1194.21(b) of the existing 508 Standards against disrupting or disabling accessibility features. The Advisory Committee recommended that the Board include an express provision ensuring that persons with disabilities are able to activate and use features or settings—such as font size, or color—that preclude network or system-wide configurations from “locking down” needed accessibility features. See TEITAC Report, Part 6, Subpt. C, Rec. 2-C. This proposal was included in the 2010 and 2011 ANPRMs, and the only comments received related to minor editorial changes.

502.2.2 No Disruption of Accessibility Features (Section-by-Section Analysis)

This section proposes that, where accessibility features are defined in platform documentation, applications must not disrupt them. This provision mirrors existing 508 Standards § 1194.21(b). The Advisory Committee strongly recommended that the Board include this requirement in the proposed rule not only to ensure accessibility, but also to avoid platform developers from being responsible for incompatibilities that derived from undocumented platform services or hidden requirements of assistive technology. See TEITAC Report, Part 6, Subpt. C, Rec. 3-Q. This proposal was included in the 2010 and 2011 ANPRMs and received no adverse comments.

502.3 Accessibility Services (Section-by-Section Analysis)

This section proposes that platforms (such as operating systems) and software tools provided by the platform developer furnish a documented set of accessibility services—usually referred to as Application Programming Interfaces (APIs)—in order to enable applications running on the platform to interoperate with assistive technology. Additionally, applications that are themselves platforms would be required to expose underlying platform accessibility services or implement other document accessibility services.

This proposal does not have an analog in the existing 508 Standards because, at the time the standards were issued in 2000, mainstream operating systems had a well-established track record of providing APIs. Since then, some platforms, particularly those used by first generation mobile devices, stopped providing these requisite components of baseline accessibility. This proposed provision would not represent a significant change from widespread industry practice, since all major platforms have well-developed APIs that incorporate accessibility. Consequently, it is important to expressly require APIs. A documented set of accessibility services is important to end-users because, without them, developers are likely to provide inconsistent access to assistive technology, thereby leaving end-users with disabilities without access to needed features. Well-documented accessibility services are especially important for developers new to accessibility, and can serve to alert all developers to the importance of the accessibility features of platforms.

502.3.1 Object Information (Section-by-Section Analysis)

This section proposes that particular programming elements—namely object role, state, boundary, name, and description—must be programmatically determinable. Moreover, user-adjustable states would be required to be set programmatically, including through assistive technology. This proposal, along with proposed 502.3.3, corresponds to WCAG 2.0 Success Criteria 4.1.2 Name, Role, and Value. It is also consistent with existing 508 Standards § 1194.21(d), but more explicitly provides for the user to be able to change data values, not just read them. Making the specified states programmatically determinable is already a widespread industry practice and is a standard feature provided in software designed to be accessible. Nonetheless, it is important to address this issue in the proposed rule because, on occasion, users of assistive technology find that they can read data in fields, but cannot make changes.

502.3.2 Row, Column, and Headers (Section-by-Section Analysis)

This section proposes that, where a programming object is in a table, occupied rows and columns (i.e., those populated with data), as well as any headers associated with such rows or columns, must be programmatically determinable. This provision corresponds to §§ 1194.22(g) and 1194.22(h) of the existing 508 Standards. A similar requirement is set forth in WCAG 2.0 Success Criteria 1.3.1 Info and Relationships. See W3C, Understanding SC 1.3.1, Understanding WCAG 2.0 (Sept. 16, 2014), http://www.w3.org/TR/UNDERSTANDING-WCAG20/content-structure-separation-programmatic.html.

502.3.3 Values (Section-by-Section Analysis)

This section proposes that current values, as well as any set or range of allowable values associated with a programming object, must be programmatically determinable. This proposal would also require values that can be set by the user to be capable of being set programmatically, including through assistive technology. This proposal, along with proposed 502.3.1, corresponds to WCAG 2.0 Success Criteria 4.1.2 Name, Role, and Value. An express requirement for values to be set programmatically would be new to the 508 Standards. However, existing industry practice in response to existing standards (i.e., 508 Standards § 1194.21(d)) is to permit values to be set programmatically.

502.3.4 Label Relationships (Section-by-Section Analysis)

This section proposes that relationships between components must be programmatically exposed to assistive technology where a component labels, or is labeled by, another component. This provision corresponds to §§ 1194.21(l) and 1194.22(n) in the existing 508 Standards, though it is broader in scope since, unlike these current requirements, its coverage extends beyond forms. A similar requirement is set forth in WCAG 2.0 Success Criteria 1.3.1 Info and Relationships. See W3C, Understanding SC 1.3.1, Understanding WCAG 2.0 (Sept. 16, 2014), http://www.w3.org/TR/UNDERSTANDING-WCAG20/content-structure-separation-programmatic.html.

502.3.5 Hierarchical Relationships (Section-by-Section Analysis)

This section proposes that any hierarchical (parent-child) relationship between components be programmatically exposed to assistive technology. This is important for individuals who use assistive technology so they can understand the relationships or interdependencies between menu options, database entries, or other software elements that have parent-child relationships. For example, word processing and email software commonly use one or more sub-menus that cascade from a “main” menu item, which permit the user to perform desired actions such as saving a file in a specific format or altering font styles. Requiring components to expose (i.e., provide) hierarchical relationships to assistive technology ensures that an individual using a screen reader, for example, could understand these relationships and, thereby, perform the desired function or action. This provision corresponds to existing 508 Standards §§ 1194.21(l) and 1194.22(n). In addition, in response to existing 508 Standards § 1194.21(d), current industry practice is to ensure that any parent-child relationship that components have to other components is programmatically exposed to assistive technology. This requirement closely parallels Success Criterion 1.3.1 in WCAG 2.0, but has greater specificity because software is more structured than Web content.

502.3.6 Text (Section-by-Section Analysis)

This section proposes that the content of text objects, text attributes, and on-screen text boundaries be programmatically determinable. Additionally, text that can be set by the user would have to be capable of being set programmatically, including through assistive technology. This provision would be useful for a screen-reader user, for example, when filling in a field on a form. It would be quite frustrating to be able to navigate to a form field, and perhaps even read placeholder text in that field, but then not be able to enter text as needed. This provision corresponds to § 1194.21(f) in the existing 508 Standards.

502.3.7 Actions (Section-by-Section Analysis)

This section proposes that a list of all actions that can be executed on an object must be programmatically determinable. An example of an “object” is a drop-down menu of states and U.S. territories in an online form. Applications would also be required to allow assistive technology to programmatically execute available actions on objects. While this requirement is new to the 508 Standards, it represents widespread industry practice. It is also already a feature provided by software designed to be accessible. This proposed requirement is important because, on occasion, developers new to accessibility overlook this need.

502.3.8 Focus Cursor (Section-by-Section Analysis)

This section proposes that software be required to expose information and mechanisms necessary to programmatically track and modify keyboard focus, text insertion point, and selection attributes of user interface components. An example of “focus cursor” is a database, which, as the user hits the tab key, displays a visible box outlining the various fields. This provision corresponds to § 1194.21(c) in the existing 508 Standards.

502.3.9 Event Notification (Section-by-Section Analysis)

This section proposes that programmatic notification of events relevant to user interactions— including changes in a component’s state, value, name, description, or boundary—must be available to assistive technologies. This proposal complements existing 508 Standards § 1194.21(d), but more explicitly requires that changes to on-screen user interfaces be done in a way that such changes, otherwise known as events, are exposed to assistive technology. Such event notification is already a widespread industry practice, and, moreover, a feature provided by software designed to be accessible. This proposed requirement is important to address this issue in these proposed requirements because, on occasion, developers new to accessibility overlook this need.

502.4 Platform Accessibility Features (Section-by-Section Analysis)

This section addresses specifications for capabilities that users with disabilities have come to expect as core accessibility features when using today’s platforms and operating systems, such as allowing adjustment of delay before key acceptance and displaying provided captions. These features include: sticky keys; bounce keys; delay keys; show sounds; the ability to produce synthesized speech; and, the capability to display captions included in content. Specifically, this proposal would require platforms and platform software to conform to seven specific sections in ANSI/HFES 200.2, Human Factors Engineering of Software User Interfaces (incorporated by reference in 508 Chapter 1 and 255 Chapter 1). While this proposed requirement (and accompanying incorporation by reference of ANSI/HFES 200.2) is new to the 508 Standards and 255 Guidelines, it does not represent a material change from current industry practice. The seven enumerated features were first available as an add-on for the IBM DOS 3.3 operating system (which was publicly released in the mid-1980s), and have been incorporated into every release of the Microsoft Windows® operating system since then.

Question 33. The Board is requesting information from covered entities and other stakeholders on the potential costs or benefits from incorporation of ANSI/HFES 200.2, Human Factors Engineering of Software User Interfaces —Part 2: Accessibility (2008). Are there suggestions for other standards that would result in the same level of accessibility?

503 Applications (Section-by-Section Analysis)

This is an introductory section.

503.1 General (Section-by-Section Analysis)

This section addresses specifications for non-Web software—that is, programs with a user interface that are executed on a computing platform—related to certain user preferences, interfaces, and controls. The proposed requirements in this section are separate from, and in addition to, any required conformance to WCAG 2.0 success criteria that may be otherwise required under the proposed 508 Standards (under E207) or the 255 Guidelines (under C205).

503.2 User Preferences (Section-by-Section Analysis)

This section proposes that applications must permit user preferences to carry over from platform settings for text color, contrast, font type, font size, and focus cursor. This closely corresponds to § 1194.21(g) in the existing 508 Standards.

503.3 Alternative User Interfaces (Section-by-Section Analysis)

This section proposes to require that, when applications provide alternative user interfaces that function as assistive technology, such applications must use platform accessibility services (i.e., APIs). Examples of alternative user interfaces include on-screen keyboards for a single switch user, and screen reading software for a person who is blind. This proposed requirement would be new to the 508 Standards and 255 Guidelines. It is included in this proposed rule to address the accessibility gap that would occur should developers of novel interfaces not consider their products to be assistive technology and, consequently, conclude they may ignore the requirements for interoperability with assistive technology (proposed 502). By clarifying that alternative user interfaces functioning as assistive technology need to satisfy interoperability requirements, the section aims to forestall the rare, but problematic, situation where there is a question about whether a product should be treated as assistive technology or another type of software.

503.4 User Controls for Captions and Audio Description (Section-by-Section Analysis)

This proposed section addresses the accessibility of on-screen controls for captioning and audio description. Specifically, this provision would require software displaying video with synchronized audio to locate user controls for closed captions and audio description at the same menu level as common user controls (i.e., volume, program selection), as set forth in two accompanying subsections (proposed 503.4.1 and 503.4.2).

These proposed requirements for accessibility of software-based on-screen controls for captions and audio description serve as a complement to the near-identical requirements for hardware-related controls in Chapter 4. See discussion above in Section VI.C (Section-by-Section Analysis – section 413 User Controls for Captions and Audio Description). These proposed requirements would be new to the 508 Standards and 255 Guidelines. The Advisory Committee recommended inclusion of these provisions to ensure that persons with hearing- and vision-related disabilities can find—and use—captioning and audio description controls. See TEITAC Report, Rec. 4-C.

503.4.1 Caption Controls (Section-by-Section Analysis)

This proposed section would require that, where video-capable software provides on-screen volume adjustment controls, such ICT must also have a control for closed captioning at the same menu level as the volume adjustment controls.

503.4.2 Audio Description Controls (Section-by-Section Analysis)

This proposed section would require that, where video-capable software provides on-screen controls for program selection, such software must have user controls for audio description at the same menu level as the volume or program selection controls.

504 Authoring Tools (Section-by-Section Analysis)

This is an introductory section.

504.1 General (Section-by-Section Analysis)

This section proposes requirements for software used to create or edit electronic content— which is generally referred to as authoring tools—to ensure the accessibility of this content. Specifically, authoring tools would be required to conform to accessibility requirements related to content creation and editing (504.2), prompts (504.3), and templates (504.4) to the extent supported by the destination format. Authoring tools include applications that allow users to develop new Web pages, edit video, or create electronic documents. Authoring tools can also be used to create and publish content for use with telecommunications products or services. One example of a telecommunications equipment-based authoring tool is an interactive voice response system (IVR) that uses software capable of creating content used to populate menu choices.

These proposed requirements for authoring tools are new to the 508 Standards and 255 Guidelines. The Advisory Committee discussed authoring tools and offered recommendations on certain provisions, but did not achieve consensus on others. See TEITAC Report, Part 7, Subpt. C, Rec. 7. Industry is already trending toward providing mainstream document creation tools that facilitate accessible output. For example, two mainstream authoring tools that support accessible document creation and accessibility checking tools are Adobe Acrobat® XI Pro and Microsoft® Office software products. Any cost increases for this requirement should be quite modest for products that already support accessibility. It is not uncommon for developers of niche products to first learn about Section 508 because their product exports reports to PDF, and government customers are likely to encounter end-user complaints when such reports are inaccessible. In this way, while a particular authoring tool may be used only by a small number of people, its outputs—such as government reports—may be widely distributed to the public.

Benefits of accessible content created or edited with authoring tools conforming to proposed 504.1 would accrue to a wide range of disabilities, and the costs associated with making such tools capable of producing accessible output are likely to be minimal. Developers already understand how to make electronic documents accessible in commonly used formats (i.e., HTML, PDF, MS-Word), and it is typically much less expensive to “build in” accessibility when an authoring tool is first developed as opposed to remediating after a product has been developed.

504.2 Content Creation or Editing (Section-by-Section Analysis)

This section proposes to require authoring tools to include at least one mode of operation for creating or editing content that conforms to WCAG 2.0 Success Criteria for all features and formats supported by the authoring tool. Additionally, authoring tools must provide users with the option of overriding information required for accessibility to provide flexibility during the authoring process. A proposed exception would exempt authoring tools from compliance when authoring tools are used to directly edit plain text source code (e.g., Emacs and Windows Notepad). This exception is needed because plain text is fundamentally limited in its ability to encode accessibility features.

504.2.1 Preservation of Accessibility Information in Format Conversion (Section-by-Section Analysis)

This section proposes that authoring tools, when converting content or saving content in multiple formats, must preserve information required for accessibility to the extent supported by the destination format. This proposed requirement is similar to § 1194.23(j) in the existing 508 Standards. Because not all authoring tools support different file formats, this provision would only apply when such a tool provides a file conversion feature.

504.3 Prompts (Section-by-Section Analysis)

This proposed section would require authoring tools to proactively support the creation of accessible content by providing a mode of operation that prompts users—either during initial content creation or when content is saved—to create accessible content that conforms to all applicable Level A and AA Success Criteria in WCAG 2.0. This requirement is intended to ensure that users have access to accessibility features supported by their authoring tools.

504.4 Templates (Section-by-Section Analysis)

This proposed section would require that, where authoring tools provide templates, templates that facilitate the creation of accessible content conforming to all applicable WCAG 2.0 Level A and Level AA Success Criteria must be provided for a range of template uses. It is much easier to start with an accessible template as compared to adding accessibility features to otherwise finished content. Remediating accessibility problems after content development increases the cost and time necessary to produce accessible content.