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.
If you want to see how your designs test with assistive technology, you can use our assistive technology testing templates
Things to consider as a Content Designer
Alternative text for non-text content
If the content contains images and/or other non-text content such as graphs or charts, then you will need to write alternative content.
If an image is purely decorative then you don’t need to provide alternative text, but if it adds context to the content, then it should have a description.
<img src="cat.jpg" alt="A cat wearing sunglasses." />
You should work with an Interaction Designer and a Frontend Developer to make sure alternative text is provided for images that need it.
For charts or graphs, you should summarise what the chart is showing and provide the data you used to generate the chart. This means people who can’t see it can still easily understand what it is showing, but can also access the raw data if they want to look at it themselves in more detail.
This chart generated from Office for National Statistics data shows that from 1980 to 2020 the number of families in the UK who own a dog has risen from 1 in 20 to 1 in 4.
You should work with a data analyst to make sure the chart, the data and
the summary all align.
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.
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 jeopardize 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.
<h1>Stop the spread of COVID-19</h1> <h2>How to stay safe</h2> <h3>Wearing a mask</h3> <h3>Washing your hands</h3> <h3>Social distancing</h3> <h2>How to get a test</h2> <h3>Getting tested if you're a key worker</h3> <h3>Getting a test for somebody in a care home</h3>
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.
If you need to change the size of the heading, use a different class to style it rather than changing the heading level itself.
<h1 class="govuk-heading-s">This is a small H1</h1> <h2 class="govuk-heading-l">This is a large H2</h2>
Try to avoid hidden content. If content is needed it should be on the page. When we hide content away in collapsible components it’s often because we haven’t done a very good job of explaining something, or we are trying to put too much content on the page.
Both the GOV.UK Accordion component and the GOV.UK Details component have accessibility issues. There is also a lot of research that suggests if you hide content the user is likely to miss it completely.
The GOV.UK Details component is styled to look like a link, but it behaves like a button when using speech recognition software such as Dragon. If it looks like a link, it should be able to be programmatically determined to be one under WCAG 4.1.2 Name, Role, Value.
The GOV.UK Accordion component also has the same issue with section headings. They look like links but behave like buttons. You can read more about the accessibility issues with the Accordion component on the GOV.UK Design System accessibility statement.
Labels and instructions
For anything which requires a user input a label must be provided.
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.
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.
<label for="search" class="govuk-visually-hidden"> Search DWP </label> <input type="search" id="search" class="govuk-input" ... />
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.
Logical reading order
The most obvious way to do this is to keep pages simple and make them read top to bottom.
If you must use columns or complex layouts, make sure that the reading order is still logical and that it still makes sense reading it top to bottom on a mobile device.
Links and form elements should also follow a logical order when using the tab key. If you tab through the page and the focus is missing or moves around the screen in an unpredictable way, this will fail WCAG 2.1.
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 screenreader 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.