On authoring tools in EN 301 549

Today I was at the IAAP-EU event in Paris, where we spent a morning workshopping and clarifying parts of EN 301 549, the procurement standard that is used in the Web Accessibility Directive.

I managed to get a spot in the group that focused on 11.8, the part of EN 301 549 that focuses on authoring tools. In this post, I'll share some insights from that session.

This post was written, as always, in personal capacity. And sorry, I don't have an HTML link for EN 301 549 (there isn't one currently, but there is a PDF).

What actually are authoring tools?

When my job was to promote the use of ATAG, I used to say authoring tools are “tools that create web content”. In EN 301 549, they are defined more broadly, beyond web:

software that can be used to create or modify content

(from EN 301 549, chapter 3: Definition of terms, symbols and abbreviations)

In other words, this definition includes web content as well as non-web content. The EN defines “non-web content” as “not a web page, not embedded in any web pages or used in the rendering or functioning of the page”. Examples of such content includes PDFs, Word documents and EPUB files. There's also a W3C document specifically about accessibility of “non-web content”, WCAG2ICT (which is informative, not normative) .

EN 301 549's authoring tool definition is followed by three notes, that all demonstrate the extent to which these tools exist:

• authoring tools can have multiple users collaborating on content (this makes me think of tools like Sanity Studio or Google Docs where lots of people can edit content at the same time)
• authoring tools could be a collection of multiple applications. For instance, some content goes through multiple applications before end-users access it
• authoring tools could produce content that's used or modified later

In our group we quickly realised that there are indeed a lot of different authoring tools. The most obvious one is Content Management Systems (CMSes). Others that people mentioned are social media, online forums, video editing tools, WYSIWYG editors, and email clients. ATAG at a glance also mentions Learning Management Systems, blogs and wikis. It's a broad category, there are a lot of tools that can make (web) content.

The ATAG reference

ATAG, the Authoring Tool Accessibility Guidelines, is the standard that provides recommendations for both making authoring tools themselves accessible (part A), as well as the content they produce (part B). See my earlier post ATAG: the standard for content creation for an overview.

Conforming with EN 301 549 requires that all of our web pages meet all of WCAG (up to Level AA, see EN 301 549, clause 9.6). But it doesn't require ATAG. ATAG is merely mentioned as something that is worth reading for “those […] who want to go beyond [EN 301 549]” (in 11.8.0). In other words, there is no normative requirement to read it, let alone to apply it.

Still, some CMSes do. For instance, Drupal supports ATAG (part A and B) from version 8. Joomla, Wagtail and Craft CMS also have done a lot of work towards improving accessibility, see the W3C's List of authoring tools that support accessibility.

However, that doesn't mean ATAG isn't an incredibly useful standard for people who make and use authoring tools. In fact, it is. In 11.8.2 to 18.8.5, some ATAG requirements are explicitly added. These clauses are requirements, because they use “shall”, which in ETSI standards implies a “mandatory requirement” (say their drafting rules).

Note: that EN 301 549 requires these things, doesn't mean the law in European countries does. These laws often refer to specific parts of the EN, or refer to EN 301 549 specifically in relation to web content.

Note 2: clause 48 of the Web Accessibility Directive is interesting. It includes various points I'd love to see member states adopt:

• “EU member states should promote the use of authoring tools that allow better implementation of the accessibility requirements set out in this Directive”
• recommendation to “[publish] a list of compatible authoring tools” (as suggestions, so not requiring them specifically)
• recommendation to “fund their development”

11.8.2: “enable” and “guide”

Out of the authoring tool requirements, we talked most about 11.8.2. It says:

Authoring tools shall enable and guide the production of content that conforms to clauses 9 (Web content) or 10 (Non-Web content) as applicable.

The key words to me are enable and guide. My personal interpretation of what that means, and maybe partially what I want it to mean:

• enable: that tools have, for all types of content they can produce, functionality to create any necessary accessibility aspects for that type of content. For instance, if they let you add an image, they need to let you add a text alternative. There's a lot of grey area, because some very complex images might require linked descriptions that don't fit as alternative text. And what about types of content that the tool creator users aren't supposed to create? LinkedIn might say it only lets users create plain text with links, not headings. Is the fact that users will try and add faux bold text and whitespace instead of headings LinkedIn's fault or the user's?
• guide: that tools tell authors about accessibility issues and help them get it right. I would love for more authoring tools to do this (see also my pledge in Your CMS is an accessibility assistant). Let authoring tools guide authors to more accessible content, this should have a large multiplier with fewer barriers across the web as a result.

What I like about the “guide” part especially: it addresses problems where they surface first. It lets authors fix accessibility problems before they ship to production, if the authoring tool guides them.

Other requirements

We didn't get to the other clauses, but they are interesting too:

• preservation of accessibility information in transformation: a real example I dealt with: if you turn HTML into PDFs with PrinceXML, it's tricky to get it to take the text alternatives from your images and embed them correctly into the PDF.
• repair assistance: there are CMSes already that tell authors when they're about to choose a new colour that would cause contrast issues (like WordPress' editor). Again, this lets authors fix problems before they exist in the produced content. Drupal has a list of modules that may improve accessibility.
• templates: when templates are available, accessible ones should be available. Again, a focus on making accessible templates could have a huge multiplier effect, as they could be reused in many different places. WordPress has a list of accessibility themes

Summing up

It was fun to dive into one of the requirements specifically, and my hope is for two things. First, I'd find it useful for there to be more extended guidance on these clauses. They are fairly minimal and more concrete examples would help. Second, the testability could improve. What makes a template an accessible template (one that meets WCAG?), what sort of assistance is sufficient, and what sort of “guiding the author” is? And then my last open question would be: when does an authoring tool fall into or outside of the scope of the organisation trying to comply with EN 301 549? Is this when they use an authoring tool or only when they create one? To be continued!