Accessibility guidance for: - Content

Best practice is generally: Page name – Site name

For example: Achalasia – NHS

The first element (here "Achalasia") is the main heading of the page.

If you can, use templates to keep things consistent and use your content management system to generate what comes after dash.

The H1 is the same as the page title. You should have only 1 H1 on a page.

Each main section of your page should start with an H2 and each sub-section of an H2 with an H3. It is possible to have sub-sub-sections which start with an H4.

With each heading, ask yourself if it's a sub-section of the previous heading. If not, it should be at the same level as (or higher than) the previous section.

Make sure that headings follow the correct "nesting" order and don't skip levels. The structure of the page is the key thing, not the size and style of the text.

You can use a web developer toolbar (Chrome or Firefox) to see the overall heading structure of the page.

• Ideally link text should match the heading of the target page. If the target page has the heading "Sleep and tiredness", that's good link text.
• If the target page heading is too long, shorten it but use words from it so that users can predict where the link will take them.
• Avoid ambiguous phrases such as "click here", "read more" and "find out more". It's OK to say: "Read more about how to deal with stress."
• Avoid having links or buttons open new windows or tabs. If you need to open a link in a new window, say this in the link phrase. For example, "Link name (opens in new window)".
• If the link goes to a document, include the file type and size in the link phrase. For example: "Link name (PDF, 200KB)".

You can use the same text for multiple links when they're in a good structure. The table row headings together with the link text must make the meaning clear.

There's an example in the summary list component. At the end of each row is a link that says: "Change". The context makes it clear what "Change" refers to.

Put the label next to the form field so that the user is clear which field it relates to.

Generally the label should be visible. (There are exceptions. For example, there's a hidden label "Search the NHS website" on the search box in the NHS.UK header. It doesn't need a visible label because people can see the search icon and the word "Search" in the box.)

Give grouped items a "legend". You can see examples in the checkboxes and radios components in the service manual.

To test the code is correct, you can usually click on the label and the field should be focused by the browser. Otherwise, check there is a "for" attribute on the label and that it matches the "id" attribute of the field.

The content of the alt-text depends on the image and its context. If the image is part of the main content of the page (not a functional image - one that triggers an action), use the alt-text to describe the image in a way that makes sense in the context.

You don't need to explain that it's an image because screen readers usually announce that.

Keep alt-text to a sentence or 2 and ideally under 125 characters including spaces. If there's important information that you cannot fit in 125 characters (for example, you're describing a complex chart), include this information in the alt-text or consider linking to more information for screen reader users. (For example, the NHS website team is testing long descriptions to describe images of conditions appearing on a range of skin tones.)

Imagine you were reading the page out to a friend. How would you describe the image?

This is an image from the bullous pemphigoid page on the NHS website. It comes under a heading "Check if you have bullous pemphigoid". The alt-text is: "Lots of sore red patches with small blisters spread across white skin on a woman's chest." It explains what users can see in the picture.

This example has a caption underneath the image as well as alt-text. Read about captions and how they work with alt-text in the images component.

If you have a complex image that you cannot describe in short alt-text (such as an infographic), include a longer description in some other way. Find out how to provide a long description in our skin symptoms guidance.

If your image has text which conveys its meaning, follow the guidance on functional images. An example would be a link to a health app which includes a brand image and the name of the app. The app name says the same as the brand image, so the image doesn't need explaining.

Decorative images are there to attract users' attention or motivate them, but they don't help users understand the topic. An example might be a bowl of fruit on a healthy eating page.

If your image is decorative, give it a null text alternative like this: (alt="").

Here is an example from the tables component in the service manual.

Screen readers would read out the last row as: "Skin symptoms: itchy blisters. Possible cause: shingles, chickenpox".

Audio description provides content for people who are blind or cannot see the video well. It is additional commentary that describes what's happening on screen in between narration, including any text, graphics or scene changes in the video.

You must include an audio description for any key information that's visible on the screen but not part of the soundtrack, for example diagrams without a verbal description. If all the visual information in the video is included in the regular soundtrack, you do not need an audio description.

If the video says the same thing as the page content, you do not need an audio description but you must make it clear that the video is an alternative to the text content. Our experience tells us, however, that even in these cases audio description can be valuable to blind people, some of whom do not read the page content.

For audio description, you can do 1 of the following:

• publish an alternative version of the video with audio description added in relevant places
• add a separate audio description track (if the media player supports this)

If you have a separate audio description track, make sure it includes the audio description voice-over and the original video audio (mixed and synced together). The audio description track must be the same length in seconds as the main video’s audio.

People who are Deaf or have hearing loss may find captions helpful. Closed captions are a text alternative to audio information in video and animations that you can turn on or off.

Use closed captions rather than subtitles. They look similar but subtitles are only a text alternative for dialogue, while closed captions are a text alternative for all the audio, including important background noises.

Closed captions must include:

• the words people say
• who is speaking, if it's not obvious, or where they are (for example, off-screen)
• important sounds like music, laughter or a door slamming

Check that any auto-generated captions are accurate and synchronise them with the visual content.

Use a contrast ratio of 4.5:1 for the text. If possible, use a fully opaque (no transparency) coloured box behind the text. We recommend a black background with white text. Find out more about using colour and accessibility, including colour contrast.

For caption fonts, follow the typography guidance in the design system.

Transcripts provide audio and video content for people who:

• are both Deaf and blind
• people who process text information better than audio and visual information

It's best practice to provide a transcript for a video but it is not required to pass WCAG2.1 AA. You must, however, provide a transcript for any audio-only content, such as a podcast.

A transcript should include all the dialogue, relevant sound effects, and audio description content.

If someone is:

• "colour blind", they may not be able to tell the difference between red and green
• zoomed in, the button may not be on the right
• using a screenreader, they may not see the colour - and position, for them, is simply up or down