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 “” 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

More Compliance stories
By TJ Koines on September 11, 2018

Advancing the design of NavCog

Every day, over 2.5 million people travel in and out of airports[1]. While air traveling has become an integral part of our lives and despite efforts to provide entertainment, comfort, and assistance, airports cause stress and anxiety. In fact, a recent study found that about 80% of people feel tense when traveling through the airport[2]. […]

Continue reading

By Yiannis Gkoufas on August 12, 2018

Puzzle Solving with Computer Vision and Watson Services

Who doesn’t love the challenge of solving a puzzle? Jigsaw puzzles are a popular hobby for all ages and have been an important tool in a child’s physical, cognitive and emotional development. Children can develop physical skills such as better hand/eye coordination; cognitive skills such as shape recognition, memory, and problem solving; and emotional skills […]

Continue reading

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