Making the content as easy to understand as possible makes it better for everybody. There are common scenarios where people might benefit from simple content. For example, people where English is not their first language or people who have Dyslexia.
You should read the GOV.UK Content Design guidance for content design best practice.
Things to consider as a Content Designer
Alternative text for non-text content
If an image is purely decorative then you don’t need to provide alternative text. If the content contains important images, graphs or charts, then you do need to write alternative text.
All images should be marked as decorative using an empty alt attribute, and the alternative text should be part of the page content. Research has shown that although you can apply alt-text directly to an image, it is also useful to people may not be using a screen reader.
<img src="corona-virus-vaccinations.jpg" alt="" />
This chart generated from GOV.UK Coronavirus Data shows that on 2 August 2021, 88% of the UK adult population had been given their first dose of the vaccine.
Captions and transcripts
If you’re providing audible content then you need to provide a transcript so that people with hearing impairments can still understand the information.
The same applies if you provide a video. Closed captions should be available for any dialogue to help people with hearing impairments, and audio description should be available for people with visual impairments.
A transcript can be provided as an alternative format to audio and video. It should be available in HTML and linked to on the same page as the video. It should include any dialogue and a description of what each scene in the video is portraying.
The content should be consistent across the service. For example, if the button at the bottom of each page is labelled “Continue”, then it should be labelled “Continue” on other pages, and not something similar like “Next”.
Consistent doesn’t always mean identical. For example if you have a link which says ‘Go to page 4’, then it would be acceptable to have ‘Go to page 5’ on the next page.
Links on the same page which go to the same place should be consistent in their wording.
Do not rely on sensory characteristics
Do not design anything which relies solely on one of your senses. For example, “The button on the left” implies that the user can see and can decipher left from right. In reality, they could be blind and using a screen reader so cannot know which button you are referring to.
Another example is “Use the green button for yes and the red button for no”. If your user is red/green colour blind then both buttons may look the same.
For any content, make sure there is more than 1 way to obtain the information. If it’s an image, provide alternative text. If it’s audio, provide a transcript. If it’s a video, provide subtitles etc.
WCAG 3.3.3 error suggestion states that if an input error is detected then suggestions are made to the user provided it does not jeopardise security.
For example, a user does not fill in their name. We should create an error message which reads: “Enter your name”.
However, if there are security considerations, then we still need to provide an error message but it can be more vague. An example of this might be an email and password combination.
For example, if somebody was trying to gain access to somebody else’s account, by only telling them they got the password incorrect, you are also telling them that they actually got the email address correct. So for situations like this the error message might instead read: “Enter both your email and password correctly.”
You should work with a Frontend Developer and a QA Tester to work out what error messages you might need to write content for.
Always use the correct heading levels.
A heading can have any level from H1 to H6. However, each heading level should relate to all the headings above it. The higher the number the more detail on the topic you should be going into.
For example, your might have a page to provide information on COVID-19. On that page you might have a section for information on how to protect yourself, and you might have another sections getting tested.
Heading 1: Stop the spread of COVID-19 Heading 2: How to stay safe Heading 3: Wearing a mask Heading 3: Washing your hands Heading 3: Social distancing Heading 2: How to get a test Heading 3: Getting tested if you're a key worker Heading 3: Getting a test for somebody in a care home
If there’s no connection between the heading you’re writing and the ones above it, consider moving that content to another page where it makes more sense.
Labels and instructions
For anything which requires a user input a label must be provided.
There are some examples of inputs without labels such as the Search field at the top of the GOV.UK site. These will still need descriptive labels, even if they’re not visible on the screen.
Every label should describe what is expected in the input. Keep labels simple at first and only had hint text or additional instructions if your user research shows there is a need for it.
Links make sense out of context
For any link, remove everything else on the page and make sure it still makes sense. For example “Change” is not clear when you view it in isolation, but “Change bank details” is.
If you need to, you can use visually hidden text to add context to a link. This is text which is still read out by a screen reader but cannot be seen on the screen. For example:
<a href="#"> Change <span class="govuk-visually-hidden">bank details</span> </a>
Never use a link which tells the user to “Click here”. The word “click” makes an assumption that a mouse is being used, but the user could be using a keyboard or some form of assistive technology.
Titles should describe the topic or purpose of the page.
The standard format for titles on a service is to set the context in 3 parts and separate them using en dashes (not hyphens). The 3 parts are:
‘Page context – Service context – Domain context`.
<title>What is your name? – Apply for Universal Credit – GOV.UK</title>
Page context should describe the topic or purpose of the page. They are usually identical to the H1, apart from when the H1 contains identifiable information.
For example, if the H1 is “What is your date of birth?” then the title would be the same.
However, sometimes the H1 can contain personal information, for example “What is John Smith’s date of birth”. In this case, the title should not be the same as there is a risk the information would be sent as analytics data.
In cases like this, the title should be as close as possible but not identical. For example, “What is your partners date of birth?”.
If there are errors on the page, then the page context part of the title should be prefixed with
Error:. You can read more about this on the GOV.UK pattern for validation errors.
You should work with a Frontend Developer and QA Tester to make sure the titles are correct when deciding if the page is finished.
It should be clear from the URL what the purpose of the page is. URLs are often overlooked as something that should be designed. But they’re an important part of accessibility as they can orientate users. They can also make content easier to find if a user needs to come back at a later date.
An example of a good url:
An example of a bad url:
You should work with a Frontend Developer to make sure when the service is built the URLs can follow the most helpful format for the user.
It is recommended that we write for a reading age of 9. This makes it easier for everybody to understand regardless of their education or background.
You can read more about reading age in the GOV.UK guidance or from the following GDS blog post: Writing content for everyone.
Every page should have a unique heading. Don’t have multiple pages with the same vague H1, for example: “Your details”.
Think about the journey as a whole. Consider the page that came before or the one that comes after.
If a screen reader user submits some information on one page, but the heading on the following page is the same, they may think the page has not changed, even if it’s obvious to a sighted user that it has.
Use of tables
Tables are known to cause a lot of accessibility issues. This is usually because a table was the wrong option for that content.
Tables should only be used to present tabular data. If it does not fit easily into columns and rows with headers then there is probably a better alternative.