5 Implementation Recommendations

5.1   Serving Multiple Audiences
5.2   Testability
5.3   Assistive Technology and Sections 255 and 508
5.4   Accessibility for People with Cognitive Disabilities
5.5   Usability of the Standard and Guidelines
5.6   Recommendations for Research

5.1   Serving Multiple Audiences

The Sections 255 and 508 materials have many audiences, with different needs:

  • Procurement staff
  • ICT managers
  • Regulators and regulatory staff
  • Federal employees with disabilities
  • Designers, engineers, and developers, including document creators
  • Disability advocates
  • Consumers with disabilities

The provisions and related information should serve both those with a deep knowledge of ICT accessibility, and those new to it.
The Committee worked with a goal to make clear and testable provisions. This has resulted in there being more provisions and more details in the individual provisions.

The Committee is also aware of the tools made available by the General Services Agency (GSA) such as the BuyAccessible wizard (and corresponding Buy Accessible Product and Services Directory), which can help agency procurement officers determine what requirements to include in a request for proposals (RFP) or other contract.  Tools such as these have proved valuable when working with other accessibility standards, such as WCAG 2.0 and its Quick Reference tool.9

The Committee is required to deliver its recommendations in a report consisting of a complete set of provisions in a document suitable for publication in the Federal Register.  However, we also discussed several alternatives to a report that could take the provisions out of a “flat” document form, and put them into an electronic tool that could be manipulated to deliver the kinds of information that different audiences require, in the most suitable format. This work is beyond the scope of the Committee, but we hope and expect tools to be developed that will help all audiences make effective use of the provisions to procure, develop or deploy products and services that meet the new regulations.  One value of tools such as these is that they help people identify the provisions that are relevant to their current work, focus on their accessibility tasks and improve their management.  To help with this future work, the report includes some limited (non-normative) additional information for the provisions:

  • The source provision in both Section 508 and Section 255
  • Identification of any external references, such as other standards
  • Identification of any harmonization with other standards
  • The disabilities the provision addresses10

It should be noted that the thorough process of discussion, iterative modification, and final consensus used by the committee on the wording of each provision was not utilized in the formulation of the metadata. The metadata was by and large submitted by individuals and, although subject to review and comment by committee members, was not discussed in committee or brought forward for consensus.

5.2   Testability

One criticism of the current Section 255 Guidelines and Section 508 Standard (and other accessibility standards efforts) is that the provisions are too broad or vague resulting in conflicting interpretations, and therefore not practical to test. We heard repeatedly that some manufacturers can not easily determine whether their product meets the requirements and that it is difficult for purchasers to compare the claims of similar products. The Committee was also informed that for certain types of products, the cost of the proposed test procedures could exceed the product's development costs.  This is because reliable multi-scenario tests are labor-intensive and not easily automated.

We are persuaded by these claims, but also recognize the necessity of keeping the provision general enough to allow alternative solutions to the underlying functional problem. As we considered each provision, we tried to find a balance between generality and precision that is:

  • Precise and unambiguous enough to easily determine if a product meets the requirements of the provision.
  • Open enough, avoiding overly prescriptive language, so that the provision does not stifle innovation.

The Committee did not create any specific test methods for the provisions in the recommendations. While there was discussion on what type of test might be needed for each provision, no consensus was reached. Including this section in the report was also a concern as this is not a formal recommendation for test methods, but a statement of how a test might be developed.
We used the terminology of “inspection,” “measure (formal test),” and “expert review,” and included a reference to one of them in the information that accompanies each provision.11

  • Inspection.  Systematic examination of the product to determine whether it possesses a feature or functions specified in the requirements. Requirements to be inspected must be either observable or easily measurable and require no interpretation or judgment in determining whether the standards are met. They may be based on easily taught criteria, which would be known to any professional with appropriate background. They may also be automated with simple tools.
  • Measure (Formal Test). These tests may require specialized measurement equipment or software, such as a software or quality test tool that checks accessibility features, or may simply require that specific steps be followed to determine if a product meets the provision. In some cases, the formal test method is specified in an existing industry or regulator standard.
  • Expert Evaluation/Review.  An accessibility subject matter expert (SME) performs a review of the product or its functionality to determine whether the provision is met. This method extends inspection by requiring expert knowledge and judgment.  Expert evaluation has the most possibility for differences in interpretation. Explanatory notes and examples can help make the requirements of provisions clear, and have been included where needed.

5.3   Assistive Technology and Sections 255 and 508

Is AT ICT?
AT Interoperability and Testing Requirements
Reporting AT Compatibility Testing Results

Sections 255 and 508 cover the requirements for “mainstream” ICT products to be used by people with disabilities. Assistive technology (AT) is often an essential part of accessibility for products that support AT. 12 In many cases, it provides accessibility where the IT product can not do so on its own, and it enhances ease of use and productivity for its users with disabilities.  AT products most often work in concert with a mainstream product to deliver to the user the necessary interface features and flexibility.  The two products must interoperate to a high degree.  In these cases it is important to identify the requirements placed upon the ICT and AT products for compatibility.  The Committee also recognizes that for products with closed functionality, where attaching AT is not possible, the accessibility should be provided by the product itself.

The two laws treat the role of AT differently.  Section 255 requires accessibility in the mainstream telecommunications product, if readily achievable.  If it is not readily achievable, then Section 255 requires compatibility with AT, again if readily achievable.  In contrast, there is no preference for mainstream ICT product accessibility in Section 508.  Accessibility through AT is equally acceptable.

The Committee was fortunate to have members with long experience in developing and using AT, as well as designing for compatibility with AT.  Below are some of the topics the Committee dealt with; some of these are reflected in the Recommendations.

Is AT ICT?
Members of the Committee expressed concern about the status of assistive technology products:  are they subject to the Section 255 and 508 regulations themselves? In some cases this concern was expressed regarding the need to share some of the compatibility burden equitably.  Although we did not completely resolve this issue, on one point we did agree:  whenever an AT product is acting on its own, it could be classified as an ICT product for the purposes of these regulations.  For example, a direct-connect TTY, that is a TTY that can be plugged into a regular phone line is not interoperating with any other device and is considered ICT. If you are originating, routing, or terminating a call from the TTY, then it is defined as customer premises equipment (CPE) within Section 255.

AT Interoperability and Testing Requirements
An application programming interface (API) is a method that establishes interoperability between programs, or between a program and an operating system, and is usually standardized and documented so that new development can proceed without extensive consultations.  Essentially it is a published protocol that lays out how two or more pieces of software shall interact with each other. It is commonly defined by a software platform and utilized by a software application. An accessibility API establishes mechanisms by which ICT and AT products can more easily communicate and interoperate.  Accessibility APIs exist and are used, but none are currently mandated. In addition, some IT and AT vendors have collaborated to achieve interoperability through other methods.

The Committee considered the possibility of recommending an API requirement.  A mandated accessibility API, if there were one that would work across all platforms could resolve the assignment of compatibility responsibilities between the AT software and IT software. Rather than mandating any specific accessibility APIs, which need to be specific to particular existing ICT products, the Committee proposed to describe the minimum set of information that IT products must provide to AT either through accessibility services or another method for cooperating with AT.  Further, the Committee proposed to recommend that ICT platforms should define such a set of accessibility services, so that software applications running on that platform can utilize those defined services rather than needing to invent a new set. The Committee could not reach consensus on this issue. As a result, the provision regarding AT Interoperability is included in Section 7 “Provisions Considered but Not Completed.” For the most part the committee did agree on the text of this provision. The concern lay in whether providing these capabilities alone (i.e., exposing this information alone) was sufficient to pass Section 508 or whether there had to be AT that government employees (and the public) could get that was known to work with the product. It should be noted that this provision is harmonized with the ISO 9241 part 171 provisions enabling compatibility with assistive technology.

The Committee discussed the use and sufficiency of accessibility APIs. Should there be mandatory accessibility APIs? Would an ICT vendor fully meet its responsibilities by building products to those APIs? What if there were no AT product to perform the functionality on “the other side” of the API? Must ICT products be tested with actual AT products? If an API were fully comprehensive, it might be safe to assume that testing to the API is sufficient.  However, some members felt that this may not be possible in many situations, given the complexity of, for example, a software program and a screen reader interface.  Just pairing all the possible settings of both products might involve a large number of tests.  Both products may be going through revision cycles that are not synchronized, adding further testing complexity.

If an API is not comprehensive, and if actual AT product compatibility testing is required, what should be the extent of the testing? How many versions of how many AT products should be tested against, and how thorough should those tests be? The committee struggled with all of these questions but could not reach a consensus.

Reporting AT Compatibility Testing Results

The question about creating a requirement to report accessibility testing results was discussed with no agreement reached.  There was concern regarding legal risks, indemnification clauses, and testing tool license agreements as the reasons publishing test results should be rejected. There was also concern that this information could be important to the procuring agency.

During the course of a pre-procurement negotiation an ICT vendor could be required by an agency to release its compatibility test results, including gaps and workarounds it had discovered or developed. This was a topic that the Committee could not reach consensus on.

5.4   Accessibility for People with Cognitive Disabilities

The Committee considered recommendations for provisions to support accessibility for people with cognitive, language and learning disabilities.  The Committee received presentations from two experts in the field, Dr. Clayton Lewis and Nancy Ward, and learned about the wide range of disabilities covered under this category. They include intellectual and developmental disabilities, dementia (deterioration of cognitive functioning), impairments of memory, aphasia, and a range of specific learning disabilities.  Both presenters shared examples of products and features that help serve the needs of people with cognitive disabilities.

Many of the provisions support people with cognitive disabilities as well as improve access for people with other types of disability. Some examples are the provisions on error identification (3-AA), not changing context on input (3-Z) and on focus (3-Y).  The information ICT must provide to AT also supports the use of AT to provide for several of the broad needs of people with cognitive disabilities that were identified by Dr. Lewis.

Other suggested provisions included in the advisory notes for developers are being passed on to the Access Board.

5.5   Usability of the Standard and Guidelines

Writing Style of the Provisions
Making the Complex Clear
Improving the Usability of the Requirements


The difficulty of understanding the current regulations was one of the recurring subjects of presentations and comments submitted throughout our work. We heard that it is difficult for people from both government and industry to understand the scope, detailed technical interpretation, and applicability of the regulations.

There were many challenges in the process of working towards bringing a high degree of usability to the standards. Our goal was to make them effective at specifying product requirements for accessibility, and useful in both the product development and procurement process. We had to consider:

  1. How to organize the provisions so that it is easy for people to understand which requirements apply in any given situation.
  2. How to harmonize our work with other standards, fitting them into our own style and structure while leaving no doubt about the intended consistency.
  3. How to write the provisions themselves so they are clear and easy to understand, even when the content of the provision is technical.

Writing Style of the Provisions

One answer to the challenge of writing style can be found in the approach to clear communication called “plain language.” Guidance from the National Archives’ information on drafting regulations, for example, says that “Readable regulations help the public find requirements quickly and understand them easily. They increase compliance, strengthen enforcement, and decrease mistakes, frustration, phone calls, appeals, and distrust of government. Everyone gains.”13

Dr. Janice (Ginny) Redish presented to the Committee on “Why Plain Language is Critical for Standards.”14 Dr. Redish pointed out that “Standards are not just statements of facts; they are communications to people. If the purpose of a standard is to get people to behave in a certain way, the standard must communicate successfully to those people. If they do not understand what they are to do (and not to do), how will they follow the standard?” She pointed out that plain language is not at odds with writing a legal document, it supports the legal accuracy and sufficiency of a standard or regulation. She defined plain language as knowing your audiences and creating the document that works for those audiences – creating the document in which they can:  find what they need; understand what they find, and act appropriately on that understanding in the time and effort that they are willing to spend on it.

Dr. Redish offered guidelines that are similar to those found on the Federal Register web site and on other advocacy sites such as the Center for Plain Language and plainlanguage.gov, with examples from regulatory writing.15 For example, use clear heading, keep sentences and paragraphs short, set the context first so there is a logical order to the sentence and use numbered lists where appropriate. In drafting the language of the recommended provisions, we have tried to follow these guidelines, and have worked to make the provisions and definitions as clear and easy to understand as possible. We have also followed guidance from the Federal Register to use the common word “must” in place of the more legalistic (and less well understood) “shall.”

We rejected two recommendations from both Dr. Redish and the Federal Register guidance:

  • Write sections as questions and answers. This structure did not seem appropriate for the TEITAC provisions, but might be useful in guidance or advisory notes.
  • Use the term “you” for whoever must comply. There were many objections to this, including concerns that the provisions needed to identify the scope and target for each provision. Instead, we have tried to be specific, using phrases such as “A product must…” or “Any product with a keyboard must…” to make the scope clear.

Making the Complex Clear

At the same time that the Committee has tried to put these recommendations in plain language using a clear communication style, we have had the further challenge of trying to break down complex technical requirements into understandable requirements with simple explanations. The Committee has used the following measures to achieve this result:

  • Many of the provisions include a “rationale” statement. This provided an opportunity to write an explanation for the goal of the provision outside of the rigorous language of regulatory requirements. The rationale can explain the reason the provision exists, identifies the disabilities or user needs the provision will address, or provide examples of problems it can correct.
  • Some provisions include definitions of technical formulas or other engineering measurements. Where this is true, we have tried to explain the measurement or test in simple language first, so that the provision can be read by both the general public and experts.

Improving the Usability of the Requirements

Section 508 Coordinators and Access Board and FCC staff responsible for technical assistance have gathered useful experience in communicating about the Sections 255 and 508 requirements.  We urge the Access Board to continue to work to make the provisions as clear, unambiguous and understandable as possible while at the same time continuing to allow room for innovation. This ensures that people in government agencies, industry, advocacy groups, and the general public will be able to use the updated regulations to improve the accessibility of ICT products.

The Access Board should provide tools or other educational material to help anyone using the regulation determine accurately (and efficiently) which provisions apply to any specific product or procurement request.

  • Maintain links identifying harmonization to external standards.
  • Continue to work to improve the clarity of the language of the requirements.
  • Continue to work (through clarity of language or separate educational materials) to help users understand the goals of the requirements, especially for the more complex or deeply technical requirements.

5.6   Recommendations for Research

Captions
Speech and Audio Volume and Quality
Cognitive Disability
Biometrics
Audio Menus
Low Vision:  Relationship Between Clinical Metrics and Product Performance
Photosensitive Seizure Disorders
Compatibility Between Prosthetics and Touch Sensitive Input Technologies
Gesture-based Input Technologies

In the course of reviewing the existing regulations the Committee considered how those regulations have been implemented, including the many requests for information and clarification brought to the Access Board, GSA, the FCC, and others by federal agencies, federal employees, and vendors.  It has not always been clear how to meet the regulations, given the diversity of ICT and the need for the regulations to be as general as possible.  Also, the Committee was aware of the many changes in the ICT marketplace since the regulations were first finalized.  Many of these changes involve the evolution of products and services beyond the categories embedded in the regulations due to technological changes, market forces, or both.  For example, websites have become software applications, virtual operating systems downloaded one feature at a time, and the use of Internet and wireless technologies for voice, video, and text communication.  We are seeing the first generation of gesture-based interfaces that call into question many assumptions about touchscreen technologies.  The concern is how can a vendor or procurement officer or average consumer navigate through this rapidly evolving ecosystem?

In the hope of clarifying and possibly future-proofing the new regulations, the Committee addressed the specific issues identified by agencies, vendors, and consumers.  Some of these questions simply can not be answered yet, and require a certain amount of research.

As part of its work, the Committee was asked by the Access Board to identify specific areas that would benefit from additional research.  We believe that the research needs we have identified are feasible.  None require the development of new technologies or groundbreaking scientific work.  In some cases they involve “knowledge translation” from clinical language into a form suitable for technology standards.  In other cases what is needed is a clear review of the existing literature with an eye towards the development of technological standards, especially in light of the desire for international harmonization.

We have phrased the research requests as questions, with some introductory material as needed.

Captions

What are the effects upon legibility and actual user performance of various caption features:  font, font size, style, and text display rate for the different transmission methods (TV, PC, wireless) and display sizes?

Speech and Audio Volume and Quality

Although these topics first arose with respect to voice telephones, they apply to all ICT that uses voice or other audio information features.  The current Sections 255 and 508 regulations only refer to amplification.

What levels of amplification provide what level of functional benefit to what kinds and numbers of users with hearing loss?

Raw amplification is not always an effective solution, especially if the audio being amplified is noisy or unclear.  Is there a definition of “clarity” or intelligibility such that a measurable regulatory standard is feasible and appropriate?

Cognitive Disability

The TEITAC process was the first time that cognitive disabilities were actively factored into the development of technological standards for accessibility in the United States.  We understand that cognitive disabilities are diverse and complex, so the needs of these users may be difficult to translate into clear technical requirements. For this reason, many of our suggestions were advisory notes rather than technical provisions.  We also know that all ICT users occasionally experience cognitive limits such as remembering passwords and understanding product documentation.  Is it currently possible to develop technology standards for mainstream products and services that would benefit real users with cognitive disabilities? If so, where are the specific areas that would provide the greatest benefit? How can any AT and ICT work together for users with cognitive disabilities?

Biometrics

Biometrics used for security or authorization purposes can exclude individuals who lack certain physiological features or who can not remain stationary long enough to be successfully registered.  Are there biometrics that are inherently inclusive? Are there any two or more already commercially available biometrics that, if either option could be used, would be totally inclusive?

Audio Menus

There are anecdotal references that suggest that audio menus should be limited to 4 or 6 maximum items.  What does the body of research say regarding audio menus for non-disabled users? Is there any relevant research regarding people with either hearing or cognitive limitations?

Low Vision:  Relationship Between Clinical Metrics and Product Performance

The existing Section 255 and 508 regulations refer to "20/70 vision." It’s not clear enough how this metric can be translated into a technical specification for the performance of a product, such as character size.  While a provision has been recommended to deal with this, it is a topic in need of more research.

Photosensitive Seizure Disorders

The current Guidelines and Standard have provisions that disallow products that flash in such a way as to cause photosensitive seizures, but we are not sure that these provisions fully address certain research findings regarding flash frequency, size of the flashing object, and color of flash. Our recommendations add significant detail to the design requirements, but a comprehensive report of existing research (e.g., a survey article or equivalent) may be able to provide all the guidance needed; if such a report is not sufficient, new research may be required.

Compatibility Between Prosthetics and Touch Sensitive Input Technologies

Prostheses (especially their surface materials) and touch sensitive input technologies are both evolving. How are these changes affecting the accessibility of touchscreens by people who use prostheses? Can requirements for prosthetic surfaces improve touchscreen accessibility, with or without complementary touchscreen requirements?

Gesture-based Input Technologies

There are several kinds of input devices that use gesture, and these are rapidly finding their way into popular ICT products. The techniques include touchscreens (both single touch and multitouch), accelerometers, and cameras to detect a complex physical motion such as flicking across a surface or giving the "thumbs up" sign. What are their positive and negative accessibility implications? Are accessibility standards feasible for these input systems?