Recent Forum Posts
From categories:
page »

In my digging, I was particularly interested in trying to find evidence that explored whether or not the presence of a link affected readability. However, it was quite hard to find much evidence along these lines. There are lots of articles around writing descriptive link text and all the stuff that we should already know. However, finding evidence purely about the readability effects of links was tough!

Caroline Jarrett and Whitney Quesenbery discuss how mid-sentence hyperlinks affect readability.

Fantastic report from 2000 that is still very valid today. Features several sections where hyperlinks are discussed (pages 368 and 370).

"If readers choose to follow a link, they should have an accurate idea concerning where they are going."
"Embedded links should be concrete enough that readers can grasp their meaning without having to read surrounding text."

This document also reference several other interesting papers and studies, unfortunately a number of them are behind paywalls…

It would be great to read these studies if at all possible.

One of the best style guide articles on writing and presenting links. Also covered several topics that I've been interested in and haven't seen covered elsewhere eg how to handle email addresses and the placement of links on pages.

I have tried to take elements of what we found and use them to update some best-practice guidelines I wrote a few years ago. Maybe we could flesh these out as needed for the Wiki?

- When it comes to using numerals or digits, context is key. For most audiences, using the year and months is most comprehensible. For example: 1 year 6 months. However, for some audiences, it may be more appropriate to talk in months e.g. 18 months.

- Don't use two different numerical words within the same context if it could cause confusion. For example: it is clearer to say that 'A 1 year old child should be weight every month' rather than 'A 1 year old child should be weighed once a month'.

- When using numbers to explain data, make sure that it tells the whole story. For example, 20% of 10 people, is very different to 20% of 500 people.

- Look out for 0O and 1I.

- Use a clear and familiar typeface.

- Numerals easier for more people to comprehend since they are the same in many languages.

On November 1, we had a discussion on Slack:

There is no key evidence to support that experts prefer plain language when going over specialist content. However, most articles support the fact that, regardless of your audience, content should be easy to scan, accurate, and certifiable.

Outcomes of the discussion:

  • "Specialist material will always be new to a beginner"
  • Specialist users need an inclusive design
  • compose some best practices such as having comprehensible titles and headings and using active voice
  • difficult to provide very specific details such as sentence length
  • Find a balance between the guidelines and knowing your audience
  • Clear need for more user testing to share and build up a solid bank of evidence:
  • listen to content using screen reader for proofing and approval
  • test specialist content with specialists
  • Found some articles and videos on Nielsen Norman Group but even with this evidence, we still get push back from the stakeholders. We all felt that unless people witness users struggle with the content, they will not take advice from us
  • add user testing as a step in the process of producing specialist content

As well as a short sentence length, choosing a non-complex sentence structure is important for plain English and clear language.

This Beta discussion took place in Slack: Joining link: Key evidence is posted on the relevant wiki Article pages – see also plain English.

  • Looked at definitions of complexity.
  • Analysed example sentences.
  • Cited usability studies, published and from our own recent experience, hoping to be able to share the latter.
  • Veered into we/you communicator/audience descriptors underlining need for further discussion of audience labels

This took place in Slack: Joining link: Key evidence is posted on the relevant wiki Article pages.

  • There was a search for definitions of literacy level, as opposed to reading Grade level based on US education system.
  • This wikipedia article on plain language bore a lot of useful references, including the UN Convention on Human Rights of Persons with Disabilities.
  • We also found an NNg article.
  • We also looked at Sentence-structure which has its own Readability Guidelines wiki page now.

Regarding Readability formulas, the following are not based on the US education system:

Flesch Reading Ease
CEFR Level

Lizzie BruceLizzie Bruce 17 Oct 2018 00:36
in discussion Hidden / Per page discussions » Legal Material

Agree, Zach. Information users need at the point of need better than everything upfront – cognitive overload coupled within incomprehension may cause alarm and distress, confusion at the very best. Users know this sort of information is Very Important which ups the anxiety levels. If anything, legal and medical language should be especially clear for that reason alone. Best practice service and content design principles should equally apply for legal user journeys. Weird that it's mostly still the opposite way round.

by Lizzie BruceLizzie Bruce, 17 Oct 2018 00:36

Thanks Lauren also on this point » "Keep its promise and appropriately set up expectations (Don't mislead to get a click)"

Expectations by Lizzie BruceLizzie Bruce, 16 Oct 2018 22:10

Agree Laura, great points (though 2 words can be a challenge!)

Particularly glad you mention: "Describe specifically what happens when people use the button." For trust, usability and time-efficiency the CTA needs to be consistent with the place the button takes users to.

So if it takes them to another page the CTA should reflect the page title to some extent. It could be a case of changing the page title itself, if the CTA is a more accurate reflection of the task on the page than the page title. For example, "Buy pet food" should lead to something like "Choose and buy pet food" rather than something like "Our range of amazingly delicious kitty nibbles are the best ever".

This might sound bland to copywriters, but the user has already chosen to buy pet food by clicking on the CTA so they don't need a lot of adjectives to entice them, and don't have time to read them. If anything, better to use something quantifiable like "high quality" as a descriptor, so "Choose and buy high quality pet food" – because who says it's delicious? The company selling them? Well that isn't much to go on! Sorry I've strayed into an entirely different discussion now…

I am just wondering, given that for date ranges "to" is preferable to "-" for screenreading software, wouldn't "to" also be preferable to an en-dash for all the en-dash usage examples?

World War l (1914–1918)
pages 32–85
L5–S1 disc herniation
Blue Jays win 4–2 in the eleventh inning


World War l (1914 to 1918)
2001 to
pages 32 to 85
L5 to S1 disc herniation
Blue Jays win 4 to 2 in the eleventh inning

I'm not massively versed on what screenreaders read out for en-dash, but it seems they read out either "dash" or nothing at all, which with a) would be disruptive to user's thought flow and with b) would impair the understanding. So "to" would always feel preferable, e.g. compare "pages 32 dash 85" / "pages 32 85" with "pages 32 to 85".

Incidentally, what do screenreaders read out for parenthesis? According to the article below, some say nothing. I tend to avoid parenthesis in my content, using en-dashes instead or restructuring the sentence. But I'm now thinking that for accessibility en-dashes should also be eliminated.

Many people use readability formulae to guide and assess their writing. Microsoft uses the Flesch Reading Ease Test and the Flesch-Kincaid Grade Level Test to assess the readability of a text. A guy called William H DuBay (interesting for other reasons, BTW) has written a number of books about readability which are useful. His perspective is as a technical writer but he focuses on context and doesn't have an axe to grind or particular formula to promote (he things readability formulas are useful). A lot of his work is downloadable for free on his website. The Principles of Readability for example.

I have edited the draft wiki to I think clarify some of the points. as Karl says, there's not a lot here that is susceptible to user testing and a lot that is about custom and practice.

On that, I have pointed out that em dashes are not really used in UK-English text these days, but lacked the courage to just delete the text about use of em dashes - so the draft text is now contradictory.

by Mark BarrattMark Barratt, 18 Sep 2018 14:06

I've been looking for research that might show evidence that acronyms and abbreviations might make it harder to read and understand the meaning of a sentence.

The best I could find is this paper, Do acronyms belong in medical literature?

TLDR summary quote: "Although acronyms might save space and sometimes might increase reading speed when they are familiar, there is little evidence that they increase readability and abundant information to the contrary."

Some evidence..? by Karl TKarl T, 17 Sep 2018 18:50
Karl TKarl T 17 Sep 2018 16:53
in discussion Hidden / Per page discussions » Headings

Another key point noted in the eye tracking research by NNG covers use of headings in tables

The key finding - "People are generally drawn to tables, especially those with descriptive headings and conservative amounts of text" - is unsurprising.

The recommendations are:

  • Make table headings look like headings, using visual treatments such as larger text, all capital letters, bold text, or a background color for the row.
  • Position the table heading across the entire width of the table, not just in the top, left cell of the table, where it could be mistaken for the heading for just that column.
Additional by Karl TKarl T, 17 Sep 2018 16:53

This is from the NNG report, How people read on the web - the eye tracking evidence.

Relevant recommendations:

  • Headings should look different and stand out from the rest of the text on the page
  • Headings should look visually stronger—for example, larger, bolder text, a different color or typeface—than the body text
  • The words used in headings should be concise and describe the content within that section
  • Make table headings look like headings, using visual treatments such as larger text, all capital letters, bold text, or a background color for the row
  • Use headings and match the content’s importance to that of the html coded heading type. For example, H1 should be the page’s main heading which summarizes the content on the entire page; H2 should summarize the information in that respective section of the page, and so on

This is the standout quote: "But by far, the single most important thing you can do to help users consume content is to use meaningful headings, and make these headings visually pop as compared to body text. Headings, when styled appropriately, make it vastly easier for users to read and understand web pages. As content designers, if you are not calling out sections of your web pages or prose on those pages with headings, you are making a big mistake! If you take nothing else from this report, please take this: use headings and subheadings."

But also these two key points summarised:

"If there are only a few headings, bolded words, or links on a page of text, it is almost guaranteed that the eye will be drawn to these elements."


"People scan the headings before they choose a section that they want to read further in. A gaze plot or heat map of this behavior will show horizontal lines, reminiscent of a layer cake."

This relates to the F-shaped reading pattern that is widely reported online:

There's a few competing standards and schemes for writing in plain or clear English.

If you are in the UK the Plain English Campaign probably springs to mind, thanks to some very good PR over the years.

But there are alternative standards for writing in English (, and an international body trying to develop a set of consistent, widely applicable standards. (

One of the real successes of Web Content Accessibility Guidelines has been its widespread adoption at the expense of alternatives. With this is mind, I don't think there's much need for us to try and branch too far into plain / clear English turf.

One standard to rule them all? by Karl TKarl T, 17 Sep 2018 14:34

I couldn't see anything about the impact on readability in the research (though clearly it has a bearing on how people feel about what you write).

But I did find a little more on inclusive style, which MailChimp appears to have drawn from.

This article summarises the Conscious Style Guide approach,, and the guide itself is here: (though it seems to me to be more an aggregator of links to how representative groups for particular identities prefer to have language used.

The US Government page on inclusive writing is here: - it seems based on the Conscious Style Guide.

There's an interesting discussion on the UX Stack Exchange page here:

The Graphic Design Stack Exchange has a thread too:

Nothing standing out on the readability issues in general but there are some good points about formatting, and other aspects of text presentation.

It looks like another example where there are preferences, but it is really a matter of style and preference - and of course, best tested with users if possible.

This from A List Apart digs deeper into the history and differences between the types of dashes and the implications for digital encoding them:

Late contributions to the theme by Karl TKarl T, 17 Sep 2018 13:36

Mailchimp is a US company. Americans tend to use the term 'people with disabilities' but UK disability charity Scope uses the term 'disabled people' because we subscribe to the social model of disability.

This model of thinking says:
• people don’t ‘have’ a disability (they have an impairment such as Cerebral Palsy or Autism)
• people are disabled by society’s barriers (such as information in an inaccessible format or lack of level access).

The social model of disability was developed by disabled people. It says that disability is caused by the way society is organised, rather than by a person’s impairment or difference. It looks at ways of removing barriers that restrict life choices for disabled people. When barriers are removed, disabled people can be independent and equal in society, with choice and control over their own lives.


by AlexGWhiteAlexGWhite, 13 Sep 2018 15:39

Tere is an assumption that it’s usually (or should be) we and you. There ought to be consideration about who the document is for, and often it isn’t for you.
For example, in a guide for the people who are caring for people with dementia. Or in a description of benefits for, say, Citizens Advice Bureau.

In some docs are quite hard to work to work out who they are ‘for’ - eg a form/process to claim benefits for disability or long-term illness are often/usually filled by carers or advisers. Who should they address?

This is something that I've come up against various times in my career, both in tech writing and marketing content. The use of 'the user' to mean the reader causes so much confusion (not to mention the fact that it creates instant disengagement). For clarity, address the reader as 'you' and only use 'the user' if you are talking about other users that are not 'we' (i.e. the writer/company) or 'you' (i.e. the reader).

Anecdotal - The most common places I've seen it cause problems is in software content. For example, if the software has server admin settings that affect how it works for all the 'normal' operators. Instructions for the server admin user should address the server admin as 'you' and not 'the user', because 'the user' could mean a normal operator. 'You' is the server admin who is reading the content and 'the user' is a third person who will use the software that is affected by the server admin's actions. Similar sort of problem occurs in API docs, where there's a need to differentiate between a programmer and an end user.

Personally, I try to avoid 'the user' and be more specific, but it's not always possible.

page »
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License