Last week, I gave a talk on web authoring tool accessibility at a Scottish Web Accessibility Briefing event, in Glasgow. It was an excellent chance to catch up with fellow accessibility advocates from Scotland – Mark Palmer, Alan White, Jim Byrne and Colin Hamilton. Co-incidentally, the latest draft of Version 2 of the W3C Authoring Tool Accessibility Guidelines (ATAG) is currently out for public comment.
So I thought I’d summarise the points I made in my talk (my slides are available on Slideshare). Why do web authoring tools have an increasingly important role to play in supporting web accessibility, and why is it so important that we talk about authoring tool accessibility in the right way?
With the web design profession, the challenge was (and still is?) to encourage a web-standards, accessible approach to design. They (should!) have the freedom to make an informed choice about the authoring tools they use – it’s a case of using them correctly. Where authoring tool accessibility becomes most relevant to them is when these professionals are creating web sites with authoring capability – i.e. for others to use to publish content.
However, the democratisation of the Web as a publishing medium, made possible by this Web 2 phenomenon of social networking, user-generated content and rich internet applications, means there is a huge number of people who publish web content who have never picked up a web design book. People who don’t know or care about HTML tags and elements, and don’t have any real awareness of what we recognise as ‘usability’ and ‘accessibility’, beyond perhaps a vague notion of ‘user-friendliness.’ And why should they? For them, the tools they use – whether Facebook, a corporate content management system, Word’s “save as Web page’ option, WordPress, Youtube, whatever – have a huge responsibility in supporting accessible authoring.
Authoring tool accessibility can be defined as:
- Is is possible for the tool to produce accessible content?
- Can a disabled person use the tool to create content?
- Can a non-expert use the tool to produce accessible content?
All questions are valid, all are important, and the answer to all should be YES. But, generally, where any work has been done in this area, it’s been to answer question 1 or 2. In particular, there’s been a fair bit of activity on authoring tool accessibility from the perspective of supporting disabled people in using social networking web sites (reports from AbilityNet and the AFB Access World are two examples).
But by comparison, very little attention has been paid to the third, and for me the most critical question. Why is this?
While some useful guidelines exist (namely W3C ATAG), version 1 is nearly 10 years old, and written for developers of authoring tools. So they are programmer focused, not easily usable by someone who wants to assess an authoring tool for accessibility support; conducting an ATAG review can be challenging (Joe Clark’s ATAG review of WordPress was as much a review of the guidelines as the authoring tool). The last section is particularly difficult to follow without a high level of technical knowledge, but thankfully this is being addressed in ATAG 2.
WCAG is the ‘sexy beast’ of accessibility (to quote @iheni). So ATAG generally doesn’t get a mention when people talk about authoring tools and accessibility support – instead, by asking only for WCAG conformance, the focus is only on the tool’s output, not the quality of the process. And when customers talk about authoring tool accessibility in terms of WCAG, then that is what the developers focus on too. The result is that tool vendors tell customers “This tool generates WCAG-AAA output” without any indication of how difficult it is to actually get the tool to do so.
Without an educated customer base (and who is the customer, when we talk about Facebook or Youtube?), I think there’s an inertia in the willingness to improve a tool’s support for non-expert authors in creating accessible content. Having recently been through a CMS procurement process, I was shocked at the lack of awareness of ATAG amongst vendors, let alone information about how well candidate systems met ATAG‘s requirements. The default position seemed to be that yes, the systems ‘could’ create accessible content, and authors could do what they were allowed to do within the limits of the authoring interface, but admins were responsible for configuring editing workflows, and checking, editing and blocking if need-be content that did not meet accessibility requirements.
I acknowledge that authors will not take kindly to being pestered with all manner of accessibility checking questions as part of the publishing process, but there is still so much more an authoring tool can do to help authors and to save organisations time and effort in meeting accessibility obligations. For the past few months, we’ve been carrying out some research looking at a broad cross-section of authoring tools, from full-blown CMSs to specialist tools, to web site creation tools geared to non-technical authors. Our main focus will be to identify issues where we think support for non-experts is particularly limited.
More detailed results will be published soon, but as an outline, I can cite as recurring themes:
- lack of support for the provision of appropriate alternatives to graphical content;
- limited encouragement to represent content structure appropriately;
- a lack of accessibility checking facilities;
- a scarcity of advice and documentation on accessibility.
In the meantime though, this is a rallying call to all those responsible for commissioning, managing, selecting or using a web authoring tool, whatever format it may take (and I accept there are many!), whatever content it generates. Think accessibility, think ATAG! Review it against ATAG (the latest draft of version 2 will be much more helpful than version 1, and if it’s not, now’s the time to comment!) If it doesn’t meet all ATAG success criteria, consider what sort of impact this will have on the accessibility quality of the content produced, and the likelihood of the target audience experiencing accessibility barriers. Then figure out what you can do to manage these issues (since in most cases, stopping using the tool will be impossible or inappropriate).
The more we can shout about authoring tool accessibility with a common, and accurate voice, the more tool developers will hopefully raise their game.
PS The blog post title experiment didn’t last long. So, instead, this is named after one of the best albums of the last couple of years 🙂