The Authoring Tool Accessibility Guidelines, known as ATAG 2.0, offers guidelines for the development of web content authoring tools that are more available to disabled authors (Part A) and intended to facilitate, support, and encourage the creation of more accessible web content by all authors (Part B).
Tim Berners-Lee, the inventor of the World Wide Web and currently a Professorial Fellow of Computer Science at the University of Oxford, captures the essence of web accessibility in concise terms.
“The power of the Web is in its universality. Access by everyone regardless of a disability is an essential aspect,”Tim Berners-Lee
This founding vision to make the Web an open space for all underlies the World Content Accessibility Guidelines (WCAG). Other related regulations, such as the Authoring Tools Accessibility Guidelines (ATAG), also draw upon this overarching objective.
It is good news that some standards exist to guide website developers in their journey to creating web content for public consumption. If there wouldn’t be any web accessibility regulations, people with specific disabilities would be denied the fundamental right to information and services on the Internet. However, are end-users only the vulnerable group of people with disabilities? But if the WCAG protects the rights of end-users, who is responsible for the accessibility needs of content authors? This article discusses the Authoring Tools Accessibility Guidelines -ATAG 2.0 and its importance to web accessibility.
What is ATAG 2.0?
The Authoring Tools Accessibility Guidelines (ATAG) was the brainchild of the World Wide Web Consortium (W3C). ATAG was developed mainly for developers of authoring tools. However, this regulation affects authoring tool users, policymakers, and purchasers of authoring tools. It is as integral to the overall website accessibility initiative as the World Content Accessibility Guidelines. ATAG is to web authors what WCAG is to public consumers. Suppose the World Content Accessibility Guidelines (WCAG) exist to regulate web developers, UX designers, and content developers in producing end-user content. In that case, the Authoring Tool Accessibility Guidelines (ATAG) ensures that developers of authoring tools can make their platforms accessible to web content authors. Like the WCAG, there are three conformance levels to the ATAG: Level A, AA, and AAA.
Basic Glossaries for ATAG 2.0
Many technical terms may confound the understanding of the Authoring Tool Accessibility Guidelines 2.0 document. Words like author, authoring tool, content, and user interface are registered expressions that hold the key to understanding ATAG. For our introductory discussion on the Authoring Tools Accessibility Guidelines, let us have a glance at some of these words and their technical connotations.
Author is an umbrella term that refers to people whose role directly or indirectly impacts the level of a given website’s accessibility. These roles include content writers, UX designers, programmers, QA testers, publishers, etc., whose input tells on an end user’s experience.
An authoring tool refers to any application or software, web-based or non-web-based, that authors employ to create or modify online content for end-users. The authoring tools also encompass content management systems (CMS) such as WordPress, code editors, blogs, document conversion tools, data scripts, et cetera. Examples of software that fall under ATAG 2.0’s definition of authoring tools include:
- Web page authoring tools (e.g what-you-see-is-what-you-get HTML editors)
- Software for creating mobile applications
- Content management systems for creating and managing websites
- Tools for creating multimedia
- Software for editing source code directly
Meanwhile, other applications (or software) do not fall under ATAG 2.0’s definition of authoring tools. Nonetheless, these applications are subject to the WCAG 2.0, provided they are web-based. Some of them are:
- Accessibility checkers that operate independently and do not include automatic or semi-automatic remediation functionality. ATAG 2.0 does not apply to tools like this because they practically do not carry out any modification on web contents
- Order forms on e-commerce platforms do not fall under authoring tools to follow the Authoring Tools Accessibility Guidelines. This is because an order form is not used as a means of communication over the Web but rather a means of making a purchase.
- Personal portals (customizable): whose content is available to the owner, not the general public
ATAG 2.0 comes in two parts:
- Part A deals with making authoring tools accessible.
- Part B dwells on how authors support authors to produce accessible content for end-users.
For the first section of ATAG 2.0, the rules are similar to what we have in the WCAG. Nevertheless, this part ensures that the authoring tool user interface follows accessibility guidelines. Authoring tools functionality, thus, must be accessible whether it is web-based or non-web-based.
Furthermore, this section provides that every authoring tool must be perceivable by web content authors. In website accessibility, content is perceivable only when information or user interface is available to users in a way they can perceive it. Which means that irrespective of their disabilities or assistive technologies, the guidelines require that authors interact conveniently with authoring tools. For this to happen, alternative texts should be available to authors in place of visual content.
ATAG 2.0 Guidelines: Part A
Similarly, the ATAG expects that authoring tools are operable and understandable. An operable user interface implies keyboard access to all functionality for people who cannot use the mouse. Besides, its operability means that keyboard focus does not get stuck in any of the content. For content authors who have difficulty typing, authoring tools should support text to navigate content under editing. Hence, each tool must:
- Be keyboard navigable. That is, the authoring software or application must provide keyboard access to authoring functionalities
- Ensure that previews are accessible. This is necessary so that authors (programmers, designers, testers, and content authors) can have a feel of how web content under construction is presented to end-users after publishing it
- Be free from flashing content (or allow authors to avoid it by providing options) that could trigger a seizure
- Have an organized content structure that enhances editing and navigation
- Provide text search option for content
- Allow users (authors) to manage preference settings
- Help authors avoid mistakes
- Provide enough time for authors to read content
Additionally, authoring tools that provide editing view of content in text format should enable text search. All text should be editable, including alternative contents. Search functionality should also help authors gain focus by presenting marching results and should inform authors when no match results are found.
Authors with disabilities could be prone to more input errors than authors without. This increased susceptibility may be due to difficulty in making smooth movements and errors in the speech recognition system. Due to this, the ATAG requires that authoring platforms help authors avoid and correct mistakes. The least requirement (Level A) in this regard is that all authoring-related actions should require confirmation. If not, they should be reversible if an author commits a mistake.
ATAG 2.0 Guidelines: Part B
In the second part of the Authoring Tools Accessibility Guidelines, the focus is to ensure that creators can produce accessible content for end-users. Since authors rely on these tools to create content (blog post, multimedia, etc.), part of programmers’ obligations who make these web content tools is to help authors produce WCAG compliant content. Specifically, the second part provides authoring tools:
- Ensure the possibility of producing accessible content
- Support authors to create accessible content
- Ensure that automatic processes have accessible content
- Provide accessible templates to authors
- Provide pre-authored accessible content to authors
- Help authors with managing alternative content for content that are not in text form
- Support authors in improving the accessibility of existing content
- Assist and guide authors in checking for accessibility issues
- Assist and guide authors in remediating accessibility issues
Accessibility implementation is climbing the next level of effectiveness. Instead of relying on the favored method of achieving compliance through on-site widgets and toolbars, organizations are trying to wire accessibility from the outset. To make this process much easier, this second section of ATAG helps developers of authoring tools to implement accessibility by guiding them toward creating and maintaining content that conforms to the WCAG.
However, it does not stop there. ATAG 2.0 encourages authoring tools to provide authors with accessible templates in line with the WCAG to improve the accessibility of web content on the go. A best practice (Level AAA) is that all templates available to authors are accessible. If not, there should be a clear distinction between accessible and non-accessible templates.
To assist authors in checking for accessibility errors, authoring tools should be integrated with accessibility checking. However, should this be possible, it becomes easy for authors to keep track of accessibility problems as they create. Consequently, they will be able to rectify these problems immediately.
One interesting thing about the Authoring Tool Accessibility Guidelines – ATAG 2.0 – is that it tackles accessibility from scratch. How? By making sure that website authors with disabilities can participate equally in the process of democratizing accessibility. The Authoring Tool Accessibility Guidelines is a body of standards that could change the face of website accessibility for the better if well-implemented. The bulk of accessibility problems come about during the authoring process. Achieving compliance with these guidelines is the most effective way to nip website inaccessibility in the bud. If authoring tool developers implement these success criteria, then the outcome will be felt across the board.