In web accessibility circles, most people would be intimately familiar with the Web Content Accessibility Guidelines (WCAG 2.0), the definitive standard for producing accessible web content.
Yet for many information and communications technologies (ICT) professionals, accessibility starts with the use of an authoring tool, whereby the lesser-known Authoring Tool Accessibility Guidelines (ATAG) play an important role in ensuring that accessibility is incorporated into daily work practices.
A few people have asked me recently about the significance of the W3C's near-ready ATAG 2.0 and what it means for web and application development, so it's a good time to look at the upcoming ATAG 2.0 standard.
A few months ago, I was talking at the Perth .NET Community of Practice whose members focus on the development of apps around the Microsoft platform. As I was explaining the importance of the National Transition Strategy (NTS) discussed in last month's column, the question was asked: how does all this apply to web-based apps?
It was a really good question, and followed up with another similar question by an attendee at the recent Access iQ™ launch about where the line is drawn between web content and authoring tool in making tools such as a content management system (CMS) accessible. How does WCAG apply to these types of scenarios?
To try and address questions such as these, the W3C have been developing the Authoring Tool Accessibility Guidelines 2.0. The W3C describes ATAG as being primarily for developers creating authoring tools, and defines authoring tools as:
"… software and services that people use to produce webpages and web content."
Further information on the definition can be found in the W3C resource Who ATAG is for.
So on the surface, ATAG appears to have a very narrow definition. Yet in the world of apps, where web content, software and services converge, it can become confusing as to when ATAG applies. The ATAG Working Group has been addressing this with several changes in its Working Draft update on 10 April 2012, and its Last Call Working Draft, which closed in June.
Changes from earlier versions of ATAG 2.0 definitions included amendments and clarifications to the definitions of accessible content, reversible authoring action, author generated content, content transformations and the definition of keyboard interface was expanded to clearly include virtual keyboards. Such changes will help to keep ATAG 2.0 applicable for development across a range of platforms and devices.
How does ATAG 2.0 work?
ATAG 2.0 is designed to complement WCAG 2.0 and essentially has two significant parts to it:
- Part A: Make the authoring tool user interface accessible; and
- Part B: Support the production of accessible content.
From the perspective of a developer or designer using an authoring tool, the two parts are distinctly different, but both are essential in ensuring that accessibility is supported. Part A refers to ensuring that the authoring tool itself is accessible, and thereby ensuring that people with disabilities are able to create web-based content or applications. In essence, a person with a disability should be able to use the tool, and the content created with the tool should be accessible.
While Part A focuses on using the features of the authoring tool for the creation process, Part B focuses on the accessibility of the finished product.
In addressing the questions mentioned earlier, Part A is extremely significant in ensuring that people with disabilities are able to use an authoring tool. In the CMS example, it could be argued that ATAG 2.0 Part A requires that the backend that allows content to be created is just as significant as ensuring that the website itself is accessible. The principles in ATAG 2.0 Part A as it stands are:
- Principle A.1: Authoring tool user interfaces must follow applicable accessibility guidelines
- Principle A.2: Editing views must be perceivable
- Principle A.3: Editing views must be operable
- Principle A.4: Editing views must be understandable
Here we can see the close relationship between WCAG 2.0 and ATAG 2.0, with three of the four POUR principles (Perceivable, Operable, Understandable, Robust) being applied to editing views and accessibility guidelines being broadly adopted. So for authoring tool creators such as the designers of a CMS, it's not so much about choosing between WCAG or ATAG when it comes to providing accessible authoring tools, it's actually about doing both as ATAG and WCAG are so closely entwined.
You may be using ATAG Part B already
The guidelines in Part B shift the focus from 'How do I build an authoring tool that people with disabilities can use?' to 'How do I make sure that users of my program produce accessible content?'
The Part B guidelines are about ensuring that an authoring tool includes features that support and encourage the creation of accessible content:
- Principle B.1: Production of accessible content must be enabled
- Principle B.2: Authors must be supported in the production of accessible content
- Principle B.3: Accessibility solutions must be promoted and integrated
So in our CMS example, we're now looking at making sure whatever's put into the authoring tool will display in an accessible way, assuming the CMS is compliant with the standard. Ideally, if you are looking to create an authoring tool, it's best if accessibility is so integrated into your tool that people who produce content with it are producing accessible content without having to specifically think about it.
What if I just want to create an app, not an authoring tool?
Many people often ignore ATAG because they don't believe it's relevant if they are not building an authoring tool.
On this issue, and also tying in with the question asked by the Perth .NET group, I'd make two points: firstly, keep in mind that the authoring tool or software development kit (SDK) that you're using to make the next hit app is likely to already be ATAG 1.0 compliant or have elements of the draft 2.0 standard, which means your tool has accessibility features in it. Keeping ATAG in mind reminds us to enable the accessibility features in the tools we use to make sure the content we create turns out accessible to people with disabilities.
Secondly, the convergence of software, social media and online content means that the lines of what defines an authoring tool are likely to get blurrier in the future and ATAG may become more relevant in the future, so it's a good thing to keep in mind.
What if my authoring tool isn't ATAG compliant?
There is great frustration among ICT professionals who want to incorporate accessibility but discover that their tool won't let them. For example, a client has asked you to install a cloud-based document creator that is not accessible. When you protest, the client reminds you that this tool is absolutely essential, and then goes on to say it's your responsibility to make their whole web presence accessible.
To avoid this situation, it may be worth looking at whether a product is ATAG compliant before a project begins, as there may be accessible alternatives. If a product is open source, such as a CMS, there are likely to be many discussion forums where you can post your question and find alternative accessible modules. Considering the implications of ATAG at the beginning of a project may save you from many headaches by the end.
So, whether you're using or creating an authoring tool, consider ATAG as a helpful guide to incorporating accessibility into your work practices. For more information on ATAG 2.0 there are a number of great W3C resources including the ATAG Overview and an insight into how draft standards evolve with How WAI Develops Accessibility Guidelines through the W3C Process.
Note: At the time of writing, ATAG 2.0 is still in draft form. While its final release is close and the Principles in Parts A and B haven't changed much, the guidelines under them are still being tweaked. I'll go into more detail on these refinements once ATAG 2.0 is finalised.