In 2011, Media Access Australia and the University of South Australia co-founded the Professional Certificate in Web Accessibility Compliance course. As part of the course, we believed at the time it was vital to ensure that the then-draft Authoring Tool Accessibility Guidelines (ATAG) 2.0 was included to support ICT professionals in the creation and use of authoring tools that can be used both by people with disabilities and produce accessible content. While the journey towards ATAG 2.0 was a long one, it’s now a recommendation. From my perspective, the timing of this new standard couldn’t be better and its relevance will be quite profound.
Regular readers of this column may feel the discussion on ATAG 2.0 is eerily familiar, possibly because of the 2012 article Authoring Tool Accessibility Guidelines (ATAG) – does it apply to me? And last year's article Why does WCAG get all the credit? Indeed looking back it seems I was a little optimistic about the final release of ATAG 2.0, but in some ways its evolution is well placed to provide support in ways it never imagined across a range of development platforms. With its recent release it's a good time to look at the new standard and why this lesser-known work of WAI will become so important
ATAG 2.0 recap
For those not familiar with ATAG 2.0, the standard “…provides guidelines for designing web content authoring tools that are both more accessible to authors with disabilities (Part A) and designed to enable, support, and promote the production of more accessible web content by all authors (Part B).” Essentially Part A is saying that people with disabilities should be able to use the tool, and Part B explains that anything made with the tool should come out of the process as accessible.
Within Part A there are four guidelines: A.1. Authoring tool user interfaces follow applicable accessibility guidelines, A.2. Editing-views are perceivable, A.3. Editing-views are operable and A.4. Editing-views are understandable. In essence, Part A highlights that all the user interface elements need to work (such as being correctly labelled) and be able to work with assistive technologies, and the editing view must be perceivable, operable and understandable so that information can be entered in the tool, framed in a similar way to the four POUR principles of WCAG 2.0. The thinking is that if all the UI elements of a tool are accessible and a person with a disability can enter information into the tool successfully, then they should be able to create something with the tool.
While Part A has familiarity around the language used to explain the concept, Part B works a little differently. There are four guidelines for Part B featuring B.1. Fully automatic processes produce accessible content, B.2. Authors are supported in producing accessible content, B.3. Authors are supported in improving the accessibility of existing content and B.4. Authoring tools promote and integrate their accessibility features. In short, the creation of accessible content should be as smooth as possible, with any content the tool generates itself being accessible and any content being created can be made accessible and have accessibity features.
The practical importance of ATAG
To explain why ATAG 2.0 was so important four years ago that we included it in our course basically comes down to two reasons. Firstly, people doing the course wanted to understand how to create their own authoring tools in a way that was accessible. However, this was a relatively minor issue at the time when compared with the second reason which was a desire to understand how their own tools could be used by people with disabilities and could create accessible content. This ultimately led to the question 'Is my tool ATAG 2.0 compliant', sparking the creation of an assignment for developers to explore the authoring tools they relied on and share their thoughts as to the compliance level of their own working environment. This became highly significant in the course as it basically separated the important technical detail around WCAG compliance from the practical ability of being able to implement WCAG within the authoring tools they were expected to use.
The ability to implement WCAG is something that is often overlooked when teaching its merits – it's often assumed that once you understand the guidelines, success criteria and techniques that WCAG just happens. While this may be true for some, it's easy to forget the final link in the chain, being the authoring tool used to make it happen. While many popular authoring tools on the marked do comply with ATAG 2.0 to some degree, the formal arrival of the standard is incredibly important to the web development industry that the commercial tools that are often relied on to generate web content will be capable of supporting accessibility, and that can now be tested against an official web standard.
What is an authoring tool anyway?
While the main reason for interest in ATAG back in 2011 when we started the course was around the accessibility of students own workplace tools, momentum in recent times has swung back to the first point – how can I build my own authoring tool and make it accessible? Many developers that have come through the course in recent times have been interested in ATAG because they want to build something people can use. The interesting thing though is trying to understand exactly what that 'thing' is, and what exactly defines an authoring tool.
These days there are many things that could be considered an authoring tool. Perhaps it’s standalone desktop software like Dreamweaver that creates web content or perhaps it’s a cloud-based product like Google Docs. Perhaps it’s an app on an iPad that allows users to create an amazing visual piece of web content and instantly upload it. Perhaps it’s a video caption editor on our favorite social media platform. The reality is that there’s a lot of people creating tools across different platforms, apps and the cloud which have been crated to produce web content, some on a large scale like Google Docs or some much smaller like a clever app. The thing that they're likely to all have in common is that they create things, and it somehow connects to the web. Whether you are a developer who wants to build something that achieves these things or wants to use a tool that can achieve these things, the fundamental point is that people with disabilities should be involved too, whether it’s creating tools or using them. When the process of creating ATAG 2.0 first commenced I’m sure many of the authoring tools around today weren’t envisioned, but we’re fortunate that with ATAG 2.0, guidance is available, regardless whether we build the tools or use them, which can ensure people with disabilities are able to interact with the tools and produce something accessible from it.
Where to from here
In my view, there’s two things that are likely to happen in the near future related to this topic which I think is incredibly exciting. The first is that the definition of exactly what is an authoring tool will continue to become extremely blurry due to disruptive innovation; and secondly the significance of ATAG 2.0 will become far more important than perhaps is currently considered.
A few months ago I wrote a column discussing the merits of internet of things (IoT) where more household appliances become connected online. Currently there is an oven on the market which can download recipes from the web and cook your food accordingly, but what happens when that process is reversed and your oven starts uploading web content, forming a recipe by observing what ingredients were used and how the cooking process was implemented? Does this mean our oven just became a web authoring tool? Probably not, but whenever it ends up I’ll be happy as long as people with disabilities can drive it and the things I need to know are available in an accessible way. It seems to me that the appeal of auto-generated accessible content is only just beginning.