Accessibility Starts in the Style Guide
This article will discuss the deficiencies of WCAG 2.0 in addressing cognitive disabilities, how a style guide can help, and why it all matters.
Content and accessibility are not independent, parallel strategies. They intersect so early, and criss-cross so often, that their relationship could be classified as symbiotic. Accessibility cannot happen without good content, and an accessibility-conscious writer is automatically equipped to write better content. What is good for the flower is good for the bee.
WCAG 2.0 touches the codependency of accessibility and content in Guideline 3.1, “Readable: Make text content readable and understandable.” The specific recommendations are development-oriented, focused more on language accessibility than content meaning. That’s OK, because the mechanical stuff is what enables assistive devices to be, well, assistive. Points like defining the default language, defining abbreviations and providing a glossary can be specifically measured and graded. They support the letter of the law.
But Guideline 3.1 loses the spirit of the law. Again, the title is “Readable: Make text content readable and understandable.” — but there are no guidelines on tone or voice, just technical nods to reading level and a nudge to reduce jargon. This is like teaching someone to drive by spending the entire lesson on how to read a map.
Contrast this with Guideline 14 of WCAG 1.0, the since-replaced recommendation from 1999:
Using clear and simple language promotes effective communication. Access to written information can be difficult for people who have cognitive or learning disabilities. Using clear and simple language also benefits people whose first language differs from your own, including those people who communicate primarily in sign language.
Guideline 14 — “Ensure that documents are clear and simple” — was marked as Priority 1 in WCAG 1.0, which makes its absence from WCAG 2.0 even more mystifying1.
Content Strategy to the Rescue
Here’s where an organized content strategy can support a conscientious accessibility strategy.
In many organizations, the writing or brand team maintains a document describing tone, voice, and overall writing style. Sometimes it governs just a website, sometimes the entire company. To support accessibility, this document should encourage writers to use natural, straightforward, jargon-free language. Where WCAG 2.0 fails, your team can make the difference.
Here is an example from a style guide we recently published:
Though our topics can be complex in nature, how we communicate the message should be clear, direct and conversational. Make word choices that are plain-spoken, not meaningless jargon, and when a shorter phrase works, use it.
Elsewhere in the guide:
Copy and content should always be relevant to the reader, knowledgeable about what specifically ails them … This means using familiar language/terminology and examples that speak to the unique needs/pain points of that audience.
Our style guide never calls out accessibility explicitly, much less discusses WCAG guidelines. It doesn’t need to. Writing teams are encouraged by their managers and functional editors to focus on creating content unpolluted from balderdash, banality and bullshit. This is enough for our team. More explicit direction and justification may be needed for yours, and if so, the following bits might help justify the direction.
Why Language Matters
Obviously the marketing benefits of clarity are, um, clear.
From an accessibility standpoint, writing sans hackneyed argot helps address three core issues:
- Cognitive disabilities.
- English as a second language.
- Machine interpretation.
There are two kinds of cognitive disabilities: clinical and functional2. Where numbers for physical disabilities like vision, dexterity and hearing are well-published, the cognitive side is harder to pin down, starting with the very definition, which loosely includes ADD, dyslexia, reasoning deficits, memory loss, and more.
Most experts agree this group is the largest of all types of disabled folks. Unfortunately, it is also the least researched and most poorly represented by the W3C because not many mechanics of web development can be uniquely applied to helping the mentally challenged.
The challenges of the cognitively disabled in reading your content are nearly identical to people whose first language is not English3.
Finally, machine interpretation (screen-reading and voiceover technology, automatic translation and captioning) does not necessarily require simple language to function, but the human on the receiving end is going to be able to process and retain “red” better than “garnet”, “long journey” over “protracted peregrination”, “our product is great” over “imagine the prodigious theatre of life-changery unfolding even as you attenuate to its scintillating grandeur”.
You laugh, until you see real-life examples.
- Writing a Style Guide: What You Need to Know
- Web accessibility for cognitive disabilities and learning difficulties (good tips, and accurate personas to better humanize the issues)
- Developing sites for users with Cognitive disabilities and learning difficulties (older, but solid — note the very first issue is content)
1 This deficit in WCAG 2.0 was recognized at the time. There was a formal objection issued in 2006.
2 The differences in clinical and functional cognitive disabilities are well-covered by WebAIM.
3 Replace “English” with your website’s primary language of course.