Accessibility Resources for Plain Language Authors and Editors

What every Plain language author and editor should know about eAccessibility

By David Berman (CPWA, ADS) and other contributors at David Berman Communications, September 23, 2023 (revised October 2024)

[Note: this article is referenced within the Resources section of Accessible Standards Canada’s draft standard for Accessible Plain Language: Annex C]

When we use plain language, and we do it well, everyone benefits.

And anyone authoring or editing text as part of the development of any document will benefit from understanding their role in an accessible publishing ecosystem. 

While understanding all aspects of accessible publishing is an asset to anyone involved in the project (including every WCAG success criterion that the organization has committed to), people who author or edit plain language content will especially benefit from being aware of certain WCAG success criteria (as well as the guidance material related to each that unpacks techniques and failures, whether general or targeting specific document types and formats).

Aside from authoring in plain language in general, authors and editors, in order to fully support the additional editorial assignments that may arise in accessible publishing, may need to learn how to extend their skills into these areas:

  • how to author excellent alternative text (typically invisible, though not always so)
  • how to apply and author a variety of long description techniques for complex images (such as infographics), including advanced techniques that differ depending on the file format
  • If the publication includes multimedia:
    • how to author excellent descriptive text transcripts
    • how to deal with special situations that arise when composing and pacing captions
    • how to author the script for audio descriptions (including extended audio descriptions)

WCAG 2.1 AA Success Criteria that impact plain language authoring the most

Of the 50 success criteria required or WCAG 2.1 AA conformance, we’ve identified the ones that impact plain language authoring the most:

(Keep in mind that WCAG 2.1 AA includes all Level A and Level AA success criteria in WCAG 2.1. Also, keep in mind that WCAG 2.1 AA includes all the success criteria within WCAG 2.0 AA.)

WCAG 2.1 AAA Success Criteria that impact plain language authoring the most

For accessible plain language, it is also crucial to consider these WCAG 2.1 AAA success criteria (even though they are likely not required for regulatory compliance):

Furthermore, here are all the WCAG 2.0 AAA considerations that may apply to authoring your document (assuming no multimedia nor forms).

  • Authoring / editing
    • plain language (Grade 9 reading level or less)
    • purpose of all links apparent from the link text alone, wherever appropriate
    • editorial headings designate every individual section of text
    • abbreviations (write around, code, or spell out on first use)
    • provide a pronunciation guide where vital to understanding
    • avoid or define unusual words
  • If you happen to be responsible for the formatting or appearance of a document as well…
    • minimum 1.5 linespacing
    • spacing between paragraphs at least 1.5 times the main linespacing
    • no rows of text more than 80 characters long
    • no justified text
    • no customizable exceptions for Images Of Text
    • higher contrast ratios (7.5:1 for large, 4.5:1 for small)

Editorial issues for accessible documents

I find that document professionals (even those fluent in plain language) are often still puzzled by the extra editorial components that need be authored as part of the process of making a document accessible for everyone.

These extra bits of wording are actually quite easy to write, once you know how to. And they’re extremely important for anyone using your document with assistive technologies, such as screen readers that announce information to those who can’t see or read.

Alternative text (for anything that’s not text)

There are three kinds of situations where one potentially needs to provide alternative text (or hire us to write and/or translate them for you): images, tables, charts, and formulae.

There are also many other rarer cases where objects other than images would need alternative text. However, my team will typically add alternative text to those objects for you as part of our standard process (examples: a decorated drop capital)… or we’ll brainstorm with you on something especially tricky (such as an interactive graph).

Images (aka “figures” as they are often referred to in PDF files)

We need alternative text for all situational images (such as photos) that you don’t want artifacted (artifacting means that the images have no meaning because they are decorative, redundant, or irrelevant). But how to decide if an image is meaningful or not?

Any image that is essential for the text to make sense or for someone to be able to get all the information in the document requires alternative text.

For other images (those that are there only for tone, drama, or intrigue…), you can choose to consider them decorative (so, not deserving of alternative text) on a case-by-case basis. Both approaches are defensible under WCAG 2.0. 

If you do choose to give an image alternative text, then we are seeking wording such as “Photo of meerkat sitting on a bench playing a banjo” … and if the document is not in English, then we need that wording translated into every other language.

Note that you do not have to include the words “image” or “button” or “link” as alternative text, because the assistive technology (such as a screen reader) does this automatically for you. As long as your coding is structured properly, the screen reader knows it is dealing with an image or a button or a link, and so it will actually announce “image” or “button” or “link” (or the equivalent in non-English languages) without any effort on your part. If you were to include such words it will actually be annoying as the screen reader user will hear that word twice… so in the case of a “Next” button, your alternate text should be “Next” rather than “Next button” or “Button Next”.

Do use proper grammar and spelling wherever feasible without compromising the effectiveness of the alternative text. For example, include a period at the end of sentences, just like you would within visible text. Do this  because even sighted users will sometimes be able to see the alternative text (for example, when hovering a mouse pointer over an image in some technologies.

When referencing parts of a document within alternative text, page numbers are not the main way that a non-sighted user navigates a document. They use heading structure rather than page numbers, with the idea that document is broken down by pages is secondary to them. Therefore, although saying “see page 10.” is an acceptable approach, it would be even better to reference a section of the document rather than a page number (e.g., “…in the first four paragraphs of the History Of Cats section”).

The challenge becomes more complex for charts and data tables.

Other resources authors and editors would also benefit from

Go deeper

Contact us to learn more about plain language accessibility for you and your team, consider bringing our tailored “Writing for the Web with Accessibility in Mind”, “Accessible Multimedia”, and “Introduction to eAccessibility” courses, learning guides, or coaching to you!

You Might Also Like