8. Other Accessibility Standards

ATAG: Authoring Tool Accessibility Guidelines

Authoring tools come in many forms. Some familiar web-based examples of authoring tools include blogs (e.g., WordPress), wikis (e.g., Mediawiki), content management systems (e.g., Drupal), learning management systems (e.g., Canvas), document authoring tools (e.g., Google Docs), and video production environments (e.g., YouTube). Some other tools that are not web-based include HTML editors (e.g., Adobe Dreamweaver), video authoring tools (e.g., Camtasia Studio), and document authoring tools (e.g., Microsoft Word) that are all capable of creating content for the Web.

In addition to providing guidance on developing web content that is accessible through WCAG 2.0, the Web Accessibility Initiative (WAI) has introduced the Authoring Tool Accessibility Guidelines (ATAG 2.0) which provide guidance for web authoring tool developers to ensure that:

  1. Tools are accessible to be used by people with disabilities
  2. Tools make it possible to create WCAG 2.0 conformant Web content

Conformance

ATAG 2.0 guidelines are sorted by levels of importance, much like WCAG 2.0. Because ATAG 2.0 covers tools that are not web-based, it does not specifically refer to “accessibility supported” requirements like those of WCAG 2.0 because those refer to web-based strategies that are supported by assistive technology.

ATAG 2.0 conformance for authoring tools is more complex than WCAG 2.0 conformance for web content, as it subsumes WCAG 2.0 and adds a range of requirements specific to authoring tools.

Partial ATAG 2.0 process component conformance is also possible in cases where additional add-on components would be needed to claim full conformance. For example, if the tool does not provide accessibility checking capability (a requirement for ATAG 2.0 conformance), it can claim partial conformance if it is possible to add a plugin that provides accessibility checking. Partial conformance can also be claimed when the platform limits compliance. For example, if a tool runs on multiple operating systems, and conformance is possible on one platform (e.g., Windows) that has an add-on accessibility checking service available, but a similar service is not available for the system run on on a different platform (e.g., Linux), a platform limitation conformance claim can be made.

More details about conformance claims can be found in the ATAG 2.0 specifications itself:

Readings and References: ATAG 2.0 Conformance Claims

ATAG 2.0 Part A

Part A of ATAG 2.0 provides guidance on making the authoring tool user interface accessible. Generally speaking, these guidelines reflect WCAG 2.0 with the addition of accessibility requirements for tools that are not web-based.

The four top level guidelines in Part A are as follows:

  • Principle A.1: Authoring tool user interfaces follow applicable accessibility guidelines
  • Principle A.2: Editing-views are perceivable
  • Principle A.3: Editing-views are operable
  • Principle A.4: Editing-views are understandable

ATAG 2.0 Part B

Part B of ATAG 2.0 focuses on guidelines for creating tools that are able to generate WCAG 2.0 conformant web content. It too has four top level guidelines, and a series of sub-guidelines for each. For a full listing of these guidelines, refer to the the full ATAG specification.

  • Principle B.1: Fully automatic processes produce accessible content
    • This set of guidelines refers to functions within the authoring tool that automatically generate web content.
      Technical: For example, if a tool automatically generates a basic HTML template when authoring a new page, that template must include a DOCTYPE declaration, a proper <head> area and <title> element, as well as a <body> area, and it must validate based on a given HTML specification.
    • When existing content is being edited in the authoring tool, it must provide a means to preserve any accessibility information contained within the original content.
  • Principle B.2: Authors are supported in producing accessible content
    • If, for example, the tool provides a means to add images, it must also provide a means to add a text alternative, and that means must be prominent.
    • If, for example, an image is added but no alt text has been provided, the tool prompts the author to include it, and explains why it is necessary.
    • If existing accessibility information is available in previously existing content, a means is provided to edit that information.
    • The tool does not attempt to automatically repair existing accessibility information, unless specific issues are identified, such as default alt text like “image”.
    • Accessible templates provided by the system are identified as such.
  • Principle B.3: Authors are supported in improving the accessibility of existing content
    • Tools are provided to check the accessibility of the authored content against WCAG 2.0 or other accessibility specifications.
    • Guidance is provided where manual checking is required.
    • If issues are found, the tool provides suggestions to repair the issues.
  • Principle B.4: Authoring tools promote and integrate their accessibility features
    • Accessibility features in the tool are enabled by default.
    • Tool does not have an option to turn off accessible authoring features.
    • If accessibility features can be turned off, a warning is provided explaining the potential dangers of doing so.
    • Documentation is provided on authoring accessible content.

License

Icon for the Creative Commons Attribution-ShareAlike 4.0 International License

Professional Web Accessibility Auditing Made Easy Copyright © 2019 by Digital Education Strategies, The Chang School is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License, except where otherwise noted.

Share This Book