W3C yesterday announced a call for review of the Authoring Tools Accessibility Guidelines (ATAG) version 2.0. Like the Web Content Accessibility Guidelines (WCAG) ATAG has been going through a bit of a revamp to bring it more in line with today’s web. Unlike WCAG however ATAG is the much maligned poor cousin who barely gets a look in.
It’s rare to describe accessibility as sexy but if there is a sexy beast in the room it’s WCAG (I kid you not). The web content guidelines are for developers and web page authors so naturally they get the mass attention and appeal that ATAG misses. This may be because ATAG is generally seen to target the smaller audience of vendors of authoring tools such as Content Management Systems, HTML editors, video authoring tools, SMIL packages and so on.
Or so it would seem…in fact ATAG is as relevant to you and me as developers as it is to us as users.
One crucial evolution since the first publication of ATAG 1.0 in 2000 is the explosion of social networking on the web. Most of us work, socialise and keep up to date via our networks of choice all of which are considered “authoring tools”.
So if you blog, Tweet, poke about on Facebook, share photo’s on Flickr or track your mates on Friendfeed you, as well as the website owners, are responsible for creating accessible content. This is where ATAG comes in as it is broken into two sections to help address all these areas:
- Part A: Make the authoring tool user interface accessible – aimed at authoring tool owners such as Adobe, Microsoft, WordPress, Wikipedia, Yahoo! and so on.
- Part B: Support the production of accessible content – aimed at all the guys above in order to enable anyone who is uploading photo’s, writing blog posts, composing Tweets or providing content for Wikipedia to do so in an accessible way.
Help raise the profile of ATAG
So there are a few things that you can do to help get ATAG more mainstream. As a blogger, Twitterer, Facebook or any other social network member make sure that you choose accessible API’s where possible. This is easier said than done and not always within your power but if you blog, for example, try and use an accessible tool with an accessible template. There are also lots of tips on accessible blogging out there that you can follow giving you advice on how to write accessible links, alt text, headings and copy.
As a user let website owners know what the problems are and work with them to fix issues. There are numerous groups on Facebook about making it accessible as well as a lot of work being done to make Twitter accessible. Also flag to W3C working groups any concerns with uses of emerging technologies that may lock people out. It’s key that while these technologies are being developed that we see accessible examples out there rather than ones that set a bad example. Steve Faulkner (just today in fact) flagged to the HTML5 working group the problem with the newly launched code editor Bespin which relies on the graphical HTML5 element canvas to function. Canvas, being graphical, provides the screen reader with nothing to hook into. The irony has not been lost on some commentators given that it is essentially a text editor.
As a developer or site owner make sure you source authoring tools with accessible interfaces so that colleagues can also safely use them. Often the back-end is left behind and forgotten when procuring new software so getting ATAG 2.0 written into procurement contracts and tenders is essential and in my opinion as important as WCAG.
Finally, if you’re into that kind of thing, have a read of the draft ATAG guidelines and email the ATAG working group to let them know what you think.