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 Mary Jo Mueller on September 2, 2022

Accessible Tech: A Compliance Update

For those familiar with generating or receiving compliance reports on the accessibility of technology products, the VPAT, or Voluntary Product Accessibility Template is a familiar term.  The VPAT form was created by the Information Technology Industry (ITI) Council for companies to report how well their technology products and services meet widely adopted accessibility standards. The […]

Continue reading

By Shari Trewin on May 17, 2022

New tools for designers from IBM Accessibility

For Global Accessibility Awareness Day 2022, let’s give a shoutout to designers, who play a critical role in accessibility. IBM Accessibility is proud to offer new free tools for accessibility in the everyday work of designers. The tools support both applications and web content. Streamlined designer guidance in the Equal Access Toolkit Accessible Design Kit […]

Continue reading

By Alexandra Grossi on December 3, 2021

Accessibility offers the Ultimate User Experience

Today is International Persons with Disabilities Day, which provides an opportunity to further reflect on IBM’s contributions to accessibility and inclusivity when it comes to the ever-evolving world of technology and design. I am the Lead UX Designer for IBM Accessibility. I am an inclusive design advocate. I also happen to be a profoundly deaf, […]

Continue reading