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

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?