Development: accessibility guidance
What developers need to do to make digital services accessible.
Check keyboard accessibility
Keyboard accessibility is one of the most important parts of accessibility. It enables other input methods, including switches, speech input and screen readers.
The starting point for keyboard accessibility is to use the correct HTML for links, buttons and form controls. Use components from the service manual, if you can. They've already been tested for keyboard accessibility.
How to test with a keyboard
Check that you can use:
- tab to progress through links and controls
- shift-tab to reverse
- enter to follow links
- space to select form controls (such as checkboxes)
- arrows for radio buttons or tabs
Checklist for each page
- you can tab to all links, buttons and form controls
- you cannot tab to non-functional elements (such as headings and paragraphs)
- you can easily see where the focus is
- the focus does not move to hidden elements
- the focus does not get trapped in an element
- scripted events (for keyboard, mouse and touch) only fire when expected
- the visual order for tabbing progress is left-to-right and top-to-bottom
Set page titles
A good page title helps users find what they want and recognise they're in the right place. It's the link that shows in search results and the first thing a screenreader will read out when the user lands on a page.
Each page title must be unique and descriptive. Keep it concise and consider putting important keywords near the beginning.
Best practice for page titles
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.
You need a small bit of markup on every page for screenreaders (and search engines) to know what language the content (or a part of the content) is in.
How to code for language
In the HTML element, set the language for the whole page to English:
or whatever language the page is in.
If there are changes of language within the page, mark these up as well:
<p>Make sure you are treated by a state healthcare provider in France (<span lang="fr">conventionné</span>).</p>
You can apply the lang attribute to any container.
Use ARIA patterns
ARIA (Accessibility Rich Internet Applications) adds extra information that lets people who use assistive technologies know what's going on. If a component needs more description than HTML provides, you need to mark it up with an ARIA pattern.
How to use ARIA patterns
The W3C note on using ARIA is a good introduction.
If you have a complex component, check whether it fits into a defined pattern from the ARIA authoring practices. Patterns that might be useful are:
If you use an ARIA pattern, include the ARIA attributes, take responsibility for the keyboard interactions as part of the scripting, and test it with assistive technology.
Read more about custom components on the development page.
Discuss any custom components
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
Test that text sizes and zooms correctly
People use their browser to change the size of content, and people with low vision may use that to a more extreme level. The guidelines specify a level of 320 (CSS) px wide. That is equivalent to 400% for a 1280px wide browser.
Users can also override the font-family and spacing for text, which can break a fragile layout. We use this text spacing bookmarklet to test with.
How to test text sizing and zooming
- Check what content and functionality you can see.
- Size your browser window to 1280px wide. (You can use the web developer toolbar in Firefox or Chrome.)
- Zoom into 400%. (Firefox needs a tweak to do this.)
- Check that you can still see all the content and functionality, even if it involves opening show/hide elements or clicking through to another page.
- Activate the text spacing bookmarklet.
- Check for missing or overlapping content and that there is no horizontal scrolling.
- Gradually zoom out to 100%, checking the text spacing at each stage.
NHS services must use a responsive design which helps with zooming and take care with layouts that limit text expansion.
Examples of layouts that cause problems
- Fixed height containers of text often break when text spacing is changed. Use min-height instead.
- Sticky elements, or containers that prevent scrolling, are often unusable at higher levels of zoom in landscape orientation. Use vertical media-queries to make sure there is enough space.
- Large data tables are allowed to scroll horizontally, but you should wrap them in an element that contains the scrolling to the table, rather than making the whole page scroll.
Use alternative text for functional images
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 (nhs.uk) 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.
Make video and multimedia accessible
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
If you are using a video on its own (in other words, if you don't 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
Updated: July 2019