WCAG2ICT describes how Web Content Accessibility Guidelines (WCAG) principles, guidelines, and success criteria can be applied to non-web information and communications technologies (ICT), specifically to non-web documents and software.

This is a shout out to David MacDonald, who while absent of late due to family responsibilities, has been a constant presence in the W3C WAI working groups and contributing to accessibility web standards for many a year.

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.