The policy of achieving Section 508 compliance through the use of alternative interfaces is a complex issue. In general, alternative interfaces provide a secondary, accessible means of accessing an application outside of the primary interface. Alternative interfaces can take a variety of forms. Common alternative interfaces include: text only interfaces, command line interfaces, the creation of an accessibility “mode” for users or some combination of these approaches.
Certain situations arise where the provision of an alternative interface that is Section 508 compliant is the best strategy for a product. These instances tend to be the exception, however, and most applications are required to make their main interface accessible to achieve compliance. Thus, in most cases, the provision of an alternative interface will not allow an application to achieve compliance with the Section 508 requirements.
Section 508 Overview
The purpose of Section 508 as defined in § 1194.1 is that:
“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.”
An undue burden can only be determined by the agency procuring a piece of technology and cannot be claimed by the vendor providing the relevant IT system. The undue burden is determined in the scope of all of the agency resources rather than those of a specific procurement and in general will not apply to the vast majority of procurements.
The Section 508 standards are divided into three parts: technical standards, functional performance criteria, and information, documentation, and support standards. The technical standards define criteria for the development of software applications and operating systems, web-based information or applications, telecommunications products, video or multi-media products, self contained, closed products, and desktop or notebook computers. The functional performance criteria define standards for the overall use of the application across six different specific disability types. The requirements for information, documentation, and support require access to user guides, installation guides for end-user installable devices, and customer support and technical support communications.
For most enterprise class web-enabled applications the following portions of the Section 508 standards will be applicable:
- Subpart B — Technical Standards
- 1194.21 Software Applications and Operating Systems
- 1194.22 Web-based Intranet and Internet Information and Applications
- Subpart C — Functional Performance Criteria
- 1194.31 Functional Performance Criteria
- Subpart D — Information, Documentation, and Support
- 1194.41 Information, Documentation, and Support
Section 508 and Alternative Interfaces
Alternative interfaces sit at the intersection of the requirements of § 1194.21 and § 1194.22, but are generally interpreted with respect to the requirements for “text-only pages.” While console interfaces are clearly not text-only web pages, the technique of providing alternative interfaces is considered a general technique which is governed by the requirements for text-only pages. The requirements for text-only pages are found in § 1194.22 paragraph (k) which states:
(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.
Thus, alternative interfaces can be provided, but only when compliance cannot be accomplished in any other way. This requires that a vendor exhaust all other possible options for providing the given functionality in the primary interface before providing an alternative interface. This presents a burden on development, to research and demonstrate why the primary interface cannot be made accessible, and on documentation, to clarify the level of effort that has gone into exhausting all options to make the primary interface accessible. If, however, an organization has met these two requirements, then an alternative interface can be developed.
Alternative Interface Considerations
The general challenge with the provision of a separate alternative interface is that the compliance strategy is fundamentally based on a “separate but equal” approach to accessibility. This approach states that when organizations have two different interfaces that these interfaces are both equal in terms of what users can accomplish. While this approach is allowed under Section 508, it generally faces two significant challenges in practical implication.
First, it specifically requires users to identify themselves as individuals with disabilities and utilize a “special” application relevant to members of the disabled community rather than a “regular” application. Disability advocacy groups find this approach troubling at best and, as part of the authoring of the Section 508 requirements, allowed it only as a last resort.
Second, the maintenance of two, independent interfaces poses large logistical and project management costs. This results in a situation where the feature parity of the two interfaces lapses over time – with the specialized alternative interface generally not containing functionality present in the primary interface. This gradual slippage causes the alternative interface to fall out of compliance and thus the entire application to no longer be compliant.
Disability Specificity Considerations
Provision of separate “accessible mode” and “standard mode” interfaces is often developed with a focus on a specific type of disability. Most notably, alternative interfaces are developed to support the use of an application by individuals who are fully blind that utilize screen readers. While support for screen readers is a focus of Section 508, the standards also require that applications work with five other classes of assistive technology and disability types. Within this additional set of requirements, two key types of assistive technology, screen magnifiers and voice recognition software, are widely used and should be considered compliance requirements. Furthermore, users often utilize a mix of assistive technology to interact with computers. For example, low vision users are likely to use a screen magnification system in conjunction with a screen reader. In a similar use case, users with mobility disabilities are likely to use a screen reader, such as JAWS, with a voice recognition program and a software bridge, such as JSAY, which provides communication between programs and of the screen reader with voice commands.
Often, when an accessible mode is provided, it only supports a single set of these assistive technologies rather than multiple types of assistive technologies. For example, users who have low vision often use a screen reader in conjunction with screen magnification software. For such users to properly interact with an application, the application must work properly both within the screen reader and within a piece of screen magnification software. Often, when applications provide an accessible mode, it is provided with the assumption that the user is blind. This occurs in an interface that may function within a screen reader, but visually does not provide a meaningful user experience. For users who utilize a combination of assistive technologies, this may result in a user experience that is inaccessible in spite of the interfaces effective function in assistive technology.
Valid Alternative Interfaces
Once it has been demonstrated that making the primary interface accessible is not feasible, then development effort can be put into building an alternative interface. In general, the alternative interface has to be able to demonstrate a level of utility on par with that of the primary interface. Holistically, this means that a given user of the system needs to be able to gain the same level of benefit from the use of the alternative interface that comes from using the primary interface. At a feature level, it means that all of the features that are available in the primary interface need to be available in the secondary interface with a relatively similar level of ease.