Accessibility guidance for: - Design

What graphic and interaction designers need to do to make digital services accessible.

Define page structure

For: Design, Testing

You can help people who use assistive technologies understand the structure of the page and navigate it by including "landmarks" (hidden labels for sections of the page). Landmarks also help users looking at multiple pages skip repetitive sections.

Use ARIA landmarks to identify the regions of a page.

Landmarks you need

Make sure that you've defined these landmarks if your page includes them:

  • banner: at the top of the page, usually contains the logo
  • navigation: elements that link to other pages, usually in the banner
  • search: the search field, usually in the banner
  • main: contains the main content of the page. It should be unique on each page.
  • contentinfo: the footer. This is shared across pages.

You'll need to define headings, lists and data tables in content areas too.

Follow the header and footer components in the service manual.

For: Design, Testing

Use a skip link to help keyboard-only users skip to the main content on a page.

Also add a skip link at the start of a long list of links or form fields (for example, over 20 checkboxes in a filter). This lets people who use keyboard-style access with a switch or head-wand skip to the end and avoid having to keep pressing the same key.

Skip links can be invisible by default, but must be very visible when focused.

Follow the skip link component in the service manual.

Use headings correctly

For: Content, Design, Testing

Everyone relies on meaningful headings to navigate the page but they are especially important for some people with access needs. Make sure your headings reflect the page structure.

Structure headings for accessibility

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.

Read more about styling headings in the typography section of the service manual.

Check colour contrast

For: Design, Testing

It's easier for people to read and interact with content if you use colours that contrast well. The NHS meets at least level AA for contrast and we aim for AAA where possible.


The contrast ratio should be at least:

  • 4.5:1 for small text (smaller than 24px, or 19px if bold)
  • 3:1 for large text (larger than 24px, or 19px if bold) and components (like a text input field) and graphic elements (like an icon)


The contrast ratio should be at least:

  • 7:1 for small text (smaller than 24px, or 19px if bold)
  • 4.5:1 for large text (larger than 24px, or 19px if bold) and components (like a text input field) and graphic elements (like an icon)
Tools to test colour contrast
More about contrast in components and graphic elements

Use a tool to calculate the ratio between the element and the adjacent colour - for example, the white arrow (foreground) and the green circle (background) in an action link.

If you are relying on users understanding a graphic (like an icon) without text, it must meet the minimum contrast ratio. If it also has text, it doesn't have to meet the requirement but this is still recommended.

Components that are visible but not currently active (like a submit button that isn't active until you've filled in the form) are exempt from the requirement, but if you can meet the minimum contrast without it being confusing, that will help people with low vision.

Read more about the colours we use in the service manual.

Define focus styles

For: Design

Everyone should be able to access all interactive components with a keyboard or a similar device. It must be obvious to them which element or link is the current focus position on the page. The browser default is generally not good enough.

Make sure that the focus is clearly visible. You can do this by adding something, like an outline or icon, or changing the colour of part of the component. Check the colour contrast.

We recommend the focus state styles in the service manual.

Discuss any custom components

For: Design, Development

The components in the service manual are well tested and ready to use. Before you design a new component, please test an existing component and show that there's a clear need for something new.

Discuss any new components with other members of your team. You need to make sure that:

  • you have good evidence that the new component is the best way of meeting the user need
  • it will be accessible
  • you test it from a technical and usability point of view
  • you can maintain and update it
  • you share what you've learnt

For: Content, Design, Testing

Links or buttons need to make sense out of context as some people experience them that way. Each link should clearly describe where it will take you. For example: "Find your nearest A&E".

How to write good link and form control names
  • 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)".
Using the same link text for multiple links

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 in the GDS design system. At the end of each row is a link that says: "Change". The context makes it clear what "Change" refers to.

Label form fields clearly

For: Content, Design, Testing

Make sure that every form field has a label that tells users what information they need to enter.

More about labels

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.

Highlight errors in forms

For: Content, Design, Testing

Make sure that error messages clearly describe what went wrong and how to fix the problem.

Include an error message wherever there's a problem with the input and check that it's visibly obvious that the message is connected to that input.

If you have an error summary at the top of a form, check that each error in the list has a link that moves the focus to the relevant form field. This helps users who rely on keyboard navigation.

Use the error message and error summary components in the service manual. They've been tested for accessibility and contain links to useful GOV.UK guidance on writing good error messages.

Do not rely on colour or position alone

For: Content, Design, Testing

Do not rely on colour to convey meaning, for example, an instruction. To communicate with people who cannot see well or distinguish colours, you may need to:

  • word things differently
  • use more than one visual cue, for example, text and an icon as well as colour

Do not rely on people understanding instructions that refer to the position of page elements.

Why you should not say "Press the red button on the right"

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

Do not include text in images

For: Design, Testing

Users need as much information as possible in text format, so that they can adjust its size, spacing or formatting.

Do not include text in graphical (raster) formats like PNG, JPEG or GIF. They do not work well when users zoom in. Instead put text in HTML (styled with CSS) or use SVG.

This does not apply to logos.

Use alternative text for images in content

For: Content, Design, Testing

People who can't see a meaningful image need an alternative to understand the content. You need to add "alt-text" to explain what's in the image.

You can see what alt-text an image has by viewing it with Chrome's Web Developer toolbar.

Informative images

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 screenreaders usually announce that. Keep alt-text to a sentence or 2 and no longer than 250 characters.

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.

Lots of sore red patches with small blisters spread across white skin on a woman's chest.
It can affect large areas of the body or limbs.

The caption underneath the image assumes that the user can either see the image or read the alt-text. It shouldn't duplicate the alt-text. Instead, use it to explain why the image is there and what you want users to conclude from it - for example, how serious their symptom is or what stage their condition has reached.

Here's another example. The alt-text is "Small red spots on white skin". The caption explains that that's how chickenpox starts.

Small red spots on white skin
1. Chickenpox starts with red spots. They can appear anywhere on the body.

If you have a complex image that you can't describe in short alt-text (such as an infographic), include a longer description in some other way. You can use an expander, for example, underneath the infographic with a text explanation.

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

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="").

Use alternative text for functional images

For: Design, Development, Testing

Some images are "functional". That means that they trigger an action. If people can't see the image, they need an alternative.

Use "alt‑text" for images like PNG or JPEG. W3C has information about how to deal with different kinds of functional image, including logos.

The NHS website ( prefers inline SVG files for functional images. SVGs don't have an alt attribute. Instead we use aria-hidden="true" and, if there is no link text, "visually-hidden" in span tags.

For some common NHS examples of SVG functional images, see the close and search icons in the header component in the service manual. The action link is an example with link text.

Make video and multimedia accessible

For: Content, Design, Development, Testing

Consider using video as well as text. Some people find it easier to understand.

With all video and multimedia, make sure that:

  • the interface is accessible for keyboard and screen reader users (including play/pause buttons and the location slider)
  • if the user cannot see or hear it, they can still understand it
Stand-alone videos

If you are using a video on its own (in other words, if you do not repeat the video content elsewhere on the page), it must have a transcript. The transcript should include all the dialogue, relevant sound effects, and visual content.

If the video includes dialogue, it should also have captions.

If the video relies on visual content to convey information (for example, diagrams without a verbal description), it's best to include an audio description. This isn't essential but you must have a transcript.

Videos which supplement page content

If the video says the same thing as the page content, you only need captions.

Make it clear that the video is an alternative to the text content. Put the video near the top of the page so that people don't have to work through the text to find it.

Get in touch

If you’ve got a question about the NHS digital service manual or want to feedback, get in touch.

Updated: July 2019