Compliance

Impact of New Accessibility Standards on Authoring Tools

Share this post:

There are new provisions in the 2017 revised U.S. Section 508 standards, as well as European requirements, that are creating additional focus on the accessibility of authoring tools.

We wanted to provide guidance for anyone seeking to understand how the new standards define authoring tools, and requirements for helping ensure accessibility.

What is an Authoring Tool?

The revised Section 508 standards define an authoring tool as: “Any software, or collection of software components, that can be used by authors, alone or collaboratively, to create or modify content for use by others, including other authors.”

Simply put, a software product whose primary job is to create content for publication is an authoring tool.

Products such as InDesign, Dreamweaver and Premiere fall into this category. Similarly, software that creates documentation or applications (whether for web, mobile or non-web) is an authoring tool. Eclipse and other development suites fit here, as do wiki applications.

However, there are questions about applications whose primary function isn’t to author content. Especially on the web, many pages have mechanisms which allow users to publish content, such as comment fields.

It is less clear where the division is between a simple input and something that needs to be considered as an Authoring Tool. Since these are new requirements, consensus on the criteria has yet to form, but generally any application or website that offers an ability for authors or end users to create rich text content for others is considered to include authoring tool functionality.

Example of an authoring tool: A comment mechanism on a web page which allows for text styling (bold, italics or headings) or the inclusion of actionable elements such as hyperlinks or images.

Image of a Facebook comment box.

This Facebook status tool with the ability to do more than just type text would be considered an authoring tool.

May not be an authoring tool: A comment mechanism that only offers an ability to include plain text with no styling or user-settable attributes (such as language).

Image of a generic comment box.

A comment field with no apparent ability for the user to control the appearance of text may not be an authoring tool.

Note that any input mechanism whose output is incorporated into the application’s content should be assessed to see if it qualifies as an authoring tool. For a comment field that appears to create just plain text, the product team should consider whether it contains functions that could allow the user to make richer content, such as:

  • typing an “@” to initiate a user reference
  • typing “http://exampleURL.com” that is turned into a ‘clickable’ link in the output by the tool

If such features exist, they could potentially have accessibility considerations and should be tested against the requirements. The new IBM Accessibility Checklist v7.0 contains a section on “Authoring Tools” and will provide guidance based on the new standards.

New Requirements

Until the release of the revised U.S. Section 508 standards, the primary accessibility requirements for authoring tools were the same as any other user interface component in an application. Can users reach and operate all the editorial toolbars by keyboard? Are all the text styling buttons labelled? Is the contrast sufficient?

The revised standards added requirements for features of the authoring tool that promote the author’s ability to generate accessible output, as well as requiring the output itself to be accessible.

Production teams should focus around two distinct ways of consuming authoring tool material:

  • Are users of the application guided to create accessible content?
  • Is the output that is created via the authoring tool accessible?

Are users of the application guided to create accessible content?

The new 504.3 Prompts checkpoint in the IBM Accessibility Checklist affects designers, developers, and testers. The Section 508 language is intentionally vague – not only on what constitutes a “prompt,” but on how many accessibility features need to include prompting in order for the checkpoint to be met.

For the question, ‘What is a prompt?’ there is general agreement that if a user who is adding an image is provided with an “alternative text” input field, then this has met the need to prompt a user to meet 1.1.1 Non-Text Content. This is the case even if the ALT text field is not coded as a required field.

When designing prompts, the US Access Board is clear that there is a requirement for an active UI role. In our ALT text example, if the user needs to right-click an image to bring up a context menu in order to add alternative text, that is not considered sufficient. The user should not need to hunt to find accessibility attributes. The requirement is not just to provide the ability to make content accessible, but to prompt the user to carry out those steps.

On the question of how many prompts need to be provided, the goal should be to guide the user to achieving all possible accessibility features supported by the tool.

Is the output that is created via the authoring tool accessible?

The new 504.2 Content Creation or Editing checkpoint is the farthest reaching of the requirements in the Authoring Tools section. It requires a team to provide a tool that can produce accessible content, and then to confirm that the output from the tool has achieved WCAG 2.0 accessibility to the extent possible by the output format.

Complying with 504.2 means incorporating an authoring tool whose features address accessibility, and then testing the output of the authoring tool against the WCAG section of the 7.0 checklist to ensure conformance.

Some WCAG checkpoints are more likely to be pertinent. The list of documentation considerations in the General techniques section of Checkpoint 602.3 is a good starting point for considerations that also apply to authoring tool output.

Additional Requirements for Specific Situations

There are other considerations, depending on the features included in an authoring tool.

If the tool can convert formats, use templates, or checks for accessibility defects, there are other requirements that need to be met. See 504.2.1 (Format Conversion), 504.2.2 (PDF Export) and 11.6.4 (Repair Assistance) for more details.

Document the Accessibility Features

Finally, any new features which application teams may create to meet the requirements for Authoring Tools need to be documented in order to meet 602.2 Accessibility and Compatibility Features.

For more information, please visit www.ibm.com/able

More Compliance stories
By Erich Manser and Charu Pandhi on June 11, 2018

Call for Code Brings Unique Opportunities for Inclusive Innovations

These are exciting times at IBM, following CEO Ginni Rometty’s May 24th announcement about Call for Code. As Laurent Sauveur of the United Nations Human Rights office points out, Call for Code is an excellent opportunity to explore how technology can play a role in addressing the needs of the most vulnerable populations.  IBMer Daniel […]

Continue reading

By Si McAleer on June 7, 2018

Erich Manser Inducted into The Carroll Society

Today IBM Accessibility evangelist Erich Manser was inducted into The Carroll Center for the Blind’s ‘Carroll Society.’ Each year the Carroll Center for the Blind and the Massachusetts Commission for the Blind recognize blind and visually impaired professionals who have made significant contributions to the companies for which they work. Established in 1936, The Carroll […]

Continue reading

By Si McAleer on May 17, 2018

Free Accessibility Tools and Technology Pay It Forward

May 17 marks the seventh anniversary of Global Accessibility Awareness Day (GAAD). GAAD was introduced to spark a conversation around digital accessibility to get people thinking and learning about accessibility. While the conversation is important, we must remember this is not a theoretical exercise. These are real challenges affecting people daily, but tackling these challenges […]

Continue reading