So we’re halfway through May already, where has the year gone? Well, we’ve been making progress with the Readability Guidelines project. Read on.

We went live

In March we launched the new Readability Guidelines wiki. It includes advice, explanations and examples based on robust evidence found in Alpha and Beta, plus links to usability studies and academic papers.

I spoke about the project, how the network of collaborators had reached this stage and next steps at CDL’s first ever Content Design Meetup.

4 additional weeks of global discussions

After the new wiki went live, we started to think more about points we did not yet know enough about.

These were:

  • positive contractions
  • mid-sentence links
  • number/letter confusion of 0/O and 1/l/I
  • punctuation and screen readers

We decided to extend the evidence search for this and held 4 more global discussions through April.

Outcomes were:

  • position links at the end of sentences, this helps everyone as it distracts the reading flow less, but particularly helps autistic users
  • clear typography can reduce number/letter legibility but content design can support this through layout and interaction design
  • avoid 0/O and 1/I/l in automatically generated codes and passwords
  • try to use commas in place of en dashes or brackets, since commas are rendered as in natural speech by screen reading software
  • there do not seem to be existing usability studies around positive contractions

Readability Guidelines expand on WCAG

An aim of the Readability Guidelines is to use clear language, examples and evidence studies to demonstrate WCAG 2.1 Readable criteria 3.1.

Currently, WCAG guidance is very technically written and developer-focused. We can support its aims through content design.

Here are some ideas on doing that.

3.1 Readable: “Make text content readable and understandable”
Our wiki has how-to guidance and usability evidence on clear language.

3.1.1 Language of Page, 3.1.2 Language of Parts, 3.1.3 Unusual Words = use plain English, avoid jargon

3.1.4 Abbreviations = avoid abbreviations

3.1.5 Reading Level = use plain English and simple sentences

3.1.6 Pronunciation = make sure meaning is clear from context, test with users to check. Or choose a different word that’s not ambiguous, and does not have multiple meanings depending on pronunciation.

We could add something explicit to the Readability Guidelines about using proper spelling and good grammar. This has been shown to be useful for making content more accessible for several user groups.

Relevant wiki pages, all but particularly:

The Slack community

None of the progress we’ve made could have been possible without the outstanding community of collaborators and contributors.

With a real hive mind approach, we identified, collated and discussed published usability studies and papers, as well as qualitative and quantitative usability studies being done by our own organisations. Karin, a regular contributor to the project, blogged on her Readability Guidelines experiences.

We now have 593 members of our Slack workspace. Join us, or drop in if you’re already a member: bit.ly/2D0OW1F

You’re welcome

Everyone is welcome whether you’re new to content and inclusive design, a linguistic expert, an accessibility professional or a student of human computer interaction. Fresh perspectives and collaboration made the wiki what it is today.

We’d also love to welcome “other” (non-content) designers, developers, technical architects, marketers, project managers and the whole range of digital roles that touch content.

Discussion channels

The Slack space has about 30 channels where people discuss things. Most relevant to the live wiki are:

#plain-english
#sentence-length
#specialist-terms
#words-to-avoid
#abbreviation-acronyms
#hyphens-and-dashes
#links
#numbers
#ampersands
#capitals
#cta-and-buttons
#headings
#i-we-you-audience
#legal
#writing-for-mobile

And we’re scoping out what readability points to explore next in #new-topics. Which brings us neatly to…

What’s next for the project?

First of all, on behalf of CDL I would like to shout out to any potential developer volunteers for a few wiki usability fixes that we need.

Things like creating readable, friendly urls for wiki pages, as myxwiki does not offer a simple page alias option. And improving log-in request functionality.

Wiki sustainability

If as a user you spot usability issues with the wiki itself, please record them in this wiki issues spreadsheet. There’s a column for you or someone else to nominate themselves as able to fix it.

You can flag that you’ve added something onto the spreadsheet, call out for a volunteer fixer, or make other comments, in the #wiki-usability-ideas Slack channel. Thanks!

New topics

I mentioned we’re looking into new topics to explore, do please add any suggestions to the Slack channel.

Is there anything missing that you’d like from a style guide that is not currently referenced by the Readability Guidelines?

A fresh study

Then there’s usability testing that CDL might carry out. Are positive contractions something we should look into testing? Or is there something else, that’s more vital for improving these collaborative inclusive design content guidelines? Tell us.

Over to you

Straight away after launch we had some amazing feedback on Twitter.

Amy Leak told us her BBC UX writing team refer to them regularly as an accessible content checker. Morgan Quinn used the wiki when creating a style guide at her organisation, ServiceNow in California.

And we even had Chris Messina, inventor of using the hashtag on social, congratulate us!

How about you? How are you finding and using the Readability Guidelines? Do you use them regularly?

And has anyone used them to convince stakeholders on a content usability best practice point? If so were you successful?

Please tell us:

on Twitter @ContentDesignLN
by email to lizzie at contentdesign.london
in the Readability Guidelines Slack space

Thank you!