Last week I gave an overview of the US Access Board’s (“The Board”) latest proposal to update the Information and Communication Technology (ICT) Standards and Guidelines related to Section 508 (“The Refresh”). This week I’ll share some of the proposed updates in The Refresh. Please note this is not a complete list, but those that I think are of note for a broad audience or relevant to common scenarios that we come across.
Structure of Standards and Guidelines
This proposal follows the prior advanced notices by restructuring Section 508 around feature capabilities of products and services rather than types of products or services. Modern technology often combines different functionality into one product or service. For example, a mobile phone contains hardware, telecommunications services, software, web content, and multimedia all in one product. Restructuring the standards and guidelines will allow those determining compliance to evaluate the product or service based on the features that it has rather than what type of product or service it is. This should reduce confusion about applicable requirements and remove repetitive standards and guidelines that were previously placed in each section to address the same issues across product types.
Harmonization and References to International Voluntary Consensus Standards
Voluntary consensus standards are not international laws, but instead are guidelines or standards that organizations such as governments can adopt as standards in their respective legislation process. There are two important aspects of harmonization of voluntary consensus standards. One is to align the standards so that organizations wishing to sell into governments both domestic and internationally can use one global set of standards to determine conformance. Secondly, assistive technology that relies on interoperability features can reliably know what to expect from software, web sites and other services. The Refresh harmonizes with international standards such as the European Union’s EN 301-549 standard for public procurement of ICT although this particular standard is not incorporated directly in the Refresh. The Refresh does, however, include by reference incorporation of other international standards such as the Web Content Accessibility Guidelines (WCAG) 2.0 and PDF/UA-1.
WCAG 2.0 Level A and AA will broadly represent the accessibility requirements for web content, software (including mobile apps), and document accessibility. That is, Section 508 will not list out specific web standards — WCAG 2.0 Level A and AA will be the web requirements. For software, WCAG 2.0 Level A and AA will also apply with additional standards specified. For documents, the Access Board says that either WCAG 2.0 or PDF/UA (for PDFs) can be used to determine compliance of a document. For hardware, WCAG does not apply and thus additional standards are referenced and new standards are specified by the Refresh.
WCAG guidelines are incorporated into the Refresh in the scoping and applicable chapters of the standards and guidelines. This reference by incorporation has several benefits but also may cause confusion. One benefit is that the standards do not have to be repeated multiple places, and the referenced standard does not need to be listed at all in the Refresh, reducing the size of the document. One point of confusion is that readers who jump directly to a Chapter such as Chapter 5 may not realize that the WCAG guidelines are applicable to this chapter. Another point of confusion is that readers will need to locate the appropriate guidelines on their own and may incorrectly locate old or new versions of the guidelines and not the version of the guidelines that were incorporated by reference.
Many people have concerns that The Board is referencing specific versions of standards and they are afraid that the version will become obsolete and the updates will not be required by the Section 508 standard. The Access Board has explained that they must reference specific versions and cannot require a non-versioned standard because they cannot delegate their standards-making authority to other organizations. For example, if the WCAG 2 standard is adopted by reference into Section 508 and then WCAG 2.0 is updated by the Web Accessibility Initiative (WAI) at the World Wide Web Consortium (W3C). The Access Board would have no legal say over the changes and any changes would then become binding requirements for the US Federal Government. That is why specific versions must be included.
On a related note, while to my knowledge the WAI is not planning to update or revise the current WCAG 2 guidelines in the near term — there is much discussion of extension models to allow modules or extensions to be added to the base WCAG 2.0 guidelines. These extensions could address new situations such as mobile guidelines or guidelines to support access by people with cognitive disabilities. In theory, The Board could decide to incorporate these extensions of modules in future rulemaking. This extension model could, in theory, make that update process more timely.
The WCAG Conformance Requirements are also rolled into the Refresh by reference into Section 508. This nuance may not be obvious to the average reader. The WCAG Conformance Requirements cover 5 additional aspects of accessibility including conformance level, full pages, complete processes, only accessibility supported ways of using technology and non-interference. These conformance requirements are important because they, among other things, allow alternative versions of content to be used to meet the standards, and set forth an objective way to determine whether techniques meet the WCAG success criteria by ensuring they can be used by assistive technology in a given environment.
The proposal also makes a change in the terminology from Electronic and Information Technology (E&IT) to Information and Communications Technology (ICT). The term ICT encompasses E&IT as well as other communication technology such as voice over IP (VOIP), telecommunication products, and customer premises equipment (CPE) used for telecommunications. The term is a more modern term that also takes into account modern communication methods and fits better with the harmonized Section 508 and Section 255 standards. This terminology change does not practically alter the applicability of the standards and guidelines to what was previously covered.
Electronic Content (e.g. Document) Accessibility
The proposed refresh specifically calls out covered electronic content (e.g. documents). While electronic content posted to the web previously had to be accessible it was not clear in the current standards if other documents were covered (e.g. non-public facing documents). The proposed rule specifies that public facing content, as well as eight other categories of non-public facing content that communicate agency official business, will have to be accessible. These categories include forms, templates and training materials, as well as questionnaires and surveys. In addition, coverage extends to emergency notifications as well as initial and final decisions adjudicating an administrative claim or proceeding, internal or external program or policy announcements, notices of benefits, program eligibility, employment opportunity or personnel action, and any formal acknowledgements or receipts. Unfortunately this does not cover draft content. Access to draft content by an employee with a disability would likely be covered under Section 504 of the Rehabilitation Act as an accommodation.
Role of the Functional Performance Criteria
Functional performance criteria are outcome based standards that define whether something can be accessed by a person with disability. For example, The Board has clarified in the proposed rule that the Functional Performance Criteria only apply in situations where a technology standard/guideline does not exist to address the situation, or as an equivalent manner to meet the standards when a technique standard cannot be met. In the current section 508 the purpose of the functional performance objectives was nebulous and thus some agencies considered that both functional and technical standards had to be met.
This change could, in theory, allow ICT that meets the technical requirements but is not usable by people with disabilities. On the other hand, it allows vendors to know that when they create products that meet the technical specification, there will not be a separate evaluation against functional criteria that are not as clear as technical standards.
The functional performance criteria have been updated and some additional ones added (e.g. color perception and limited reach and strength). Criteria for access by people with cognitive disabilities that was indicated during the advanced notice of proposed rulemaking phase did not make it into the proposed rule. Section 508 still covers access by people with cognitive disabilities via relevant technical standards; however, there are no functional performance criteria. In addition, there are other functional performance criteria that may also likely need to be considered in the future (e.g. depth perception).
The low vision functional performance criterion was updated to read:
302.2 With Limited Vision. Where a visual mode of operation is provided, ICT shall provide at least one mode of operation that magnifies, one mode that reduces the field of vision required, and one mode that allows user control of contrast.
This update raises additional questions though — what criteria do you use to determine the field of vision required for user control? That is, does this criterion require that form labels and fields appear in the 20 degree field of vision based on a standard monitor size and resolution from a standard viewing angle? To what extent is user control over contrast met — providing one contrast option? The criterion doesn’t even specify that it has to be a high contrast option. For example, light gray on gray, medium gray on gray and dark gray on gray found in a common Microsoft Office product are all different levels of contrast, although for most people with low vision they are unreadable.
Similarly, the updated functional performance criterion for people who are hard of hearing states:
302.5 With Limited Hearing. Where an auditory mode of operation is provided, ICT shall provide at least one mode of operation that improves clarity, one mode that reduces background noise, and one mode that allows user control of volume.
It’s not clear what steps are needed to increase clarity and reduce background noise — that is, the reduction of background noise of the system itself such as in a multimedia production or background noise from the environment. Clarity would presumably mean high definition audio but it could also mean TTS options for audio cues, etc. Having more information regarding testing steps and example situations and solutions would assist people complying with this criterion.
Real-time Text Support
The proposed rule would require that whenever two-way voice communication is provided, real-time text (RTT) functionality be provided to allow for comparable access for people who are deaf or hard of hearing. Real-time text is text which is transmitted on a character-by-character basis as the characters are typed, rather than as a single block of text once transmission is complete. Instant messaging and SMS (often called text messages) are examples of text based communication that sends the message after the message is completed rather than character by character. During the public hearing several people from industry commented on this requirement. They indicated that while they supported the idea of making this a requirement, it may not be achievable in all situations, and they pointed out that there are implementation challenges such as interoperability between different systems that must be considered in order to implement this requirement. The EN 301-549 EU standard has also identified additional specific requirements regarding real-time text that should also be considered to make sure this feature is accessible (e.g., speed of the real-time text, indication of the direction, and ability to switch between modes of operation). This provision would apply to the communication providers, the government, and would cover products that use voice over internet protocol systems like VOIP phones, Microsoft Skype for Business (Formerly Lync), Skype, Google Hangouts, Apple FaceTime, etc.
Currently ICT is required to be interoperable or compatible with documented features of assistive technology and accessibility features. The interoperability requirements are being updated to be clearer about how technology, including operating systems, software toolkits and platforms (including browsers), must work together with assistive technology such as screen readers, screen magnifiers and speech recognition to increase or maintain access by people with disabilities.
The proposed rule indicates that some software that operates within a sandboxed environment within the platform, such as plug-ins like Java and Flash and media players, are exempt from some of the user preferences for accessibility. However, it is not clear which standards will be required for these types of software to be accessible to people with disabilities. Specifically, platform settings to adjust color, fonts, etc. are not covered, yet there does not appear to be a fallback requirement as there is in the current Section 508 to provide a variety of color and contrast settings to assist users who require high contrast. This is an area where we need clarity from the Board.
Additional interoperability requirements surround the use of applications programming interfaces (API). APIs are agreed upon methods of communication between software such as a platform or app and an assistive technology. The proposed rule has increased the requirements, not only requiring that an API be used to expose information to assistive technology, but that it also allow assistive technology to control the user interface through the API. That is, AT may be required to programmatically set and change values and add event hooks to watch for changes in the application. This is very good news for users of assistive technology however it raises some questions that need to be answered. For example, what constitutes an API? Is the Document Object Model (DOM) of a webpage considered an API? What if certain features such as setting and controlling an app are not supported in current accessibility APIs? Would keyboard interface support permit the same benefit to users with disabilities?
The Board is seeking public comments on the rule as well as a preliminary assessment of its estimated costs and benefits. Comments are due by May 28, 2015.
Comments can be submitted or viewed through the www.regulations.gov website. The proposed rule includes instructions on submitting comments.
For further information, visit the Board’s website.
In my next post I’ll discuss some of the areas needing further clarification from The Board, including:
- PDF/UA-1 Requirements
- VPATs and Conformance Documents
- Third Party Content and Social Media
- Authoring Tools
- Hardware Standards
- Back Office Exemptions