You must build your service so it’s accessible to everyone who needs to use it. As a developer you must design and build interfaces that do not introduce barriers for disabled people and users of assistive technology.
Building in an accessible way helps to future-proof your service, as this will protect it against any changes in technology or your users’ accessibility requirements.
This also helps your service:
- meet the success criteria of the WCAG 2.1 design principles
- meet public sector accessibility requirements
- not breach the Equality Act 2010
Using the Design System
You should use the GOV.UK Design System to build your service wherever possible. The Design System provides accessible styles, components and patterns consistent with other GOV.UK services.
Building your service with components from the GOV.UK Design System helps your service be accessible and responsive. The Design System is regularly tested against the most commonly used assistive technology and browser combinations. It also meets level AA of WCAG 2.1.
It’s possible that your service needs to use something not available in the GOV.UK Design System. If that’s the case you should make sure anything you add to your service is accessible. You can also propose a component or pattern for the Design System.
Building accessible services
Code that does not follow accessibility best practice may exclude people from using your service. This could mean that:
- users relying on a keyboard cannot access or control the user interface or certain elements
- users cannot customise the appearance of the interface
- screen readers read the content out in the wrong order, or not at all
- screen reader users cannot build a mental model of the page or navigate to relevant content
- screen reader users cannot tell that visual-only content has updated
- speech recognition software users cannot interact with the interface, for example not being able to activate links, buttons or form fields
Before turning a design or prototype into production code you should check if there are any accessibility issues in the design. These can include:
- a confusing layout
- poor colour contrast
- non-obvious interactive elements
There could also be issues with the content, such as:
- links that aren’t descriptive
- images that don’t have alt text
- descriptions that rely on the user’s ability to see the page, like ‘click the button on the left’
- page titles on the service that are not unique
Work with your content designer or technical writer to fix these issues.
Some users may need to extend time limits, for example how long they’re logged in to your service before being automatically signed out. Make sure users are able to extend these time limits if they need to.
Writing accessible HTML
You should follow the principles of Semantic HTML. Using the correct HTML elements and attributes to mark up the content means the right information is available to assistive technology. It also means assistive technology users can interact with the content or interface as they would expect.
Using the correct elements in your HTML helps users of assistive technologies navigate through your pages, including letting them jump to relevant sections. For example, make sure you use
footer elements to outline the page structure.
Using appropriate HTML elements allows assistive technologies to understand and operate your interface more easily. For example, buttons should always use
Use heading elements in your content. Headings tell screen readers how the content on the page is organised, giving users an overview of the content. Avoid skipping heading elements, such as from
h3, as this can confuse screen readers.
Other common accessibility errors introduced when writing HTML can include:
- not providing labels for form fields or associating labels with form fields correctly
- not using the correct list type
- using a table to build page layout - you should only use tables to display tabular data
Writing accessible CSS
Take care when writing CSS as it’s easy to accidentally introduce accessibility barriers.
You should make sure you:
- do not use
display:noneto hide content that screen readers need to announce
- set text and background colour contrast to an acceptable level
- add a focus state to any interactive or focusable element
- avoid interface elements that have a small touch area
Some users customise the appearance of web pages to suit their needs. To support these users you should make sure:
- all content is still readable if the user increases the font size
- users can change the colours on the page, without essential elements becoming invisible
If possible, you should avoid using CSS to reorder content on a page as this could cause issues for keyboard and screen reader users.
You must tell your users if content dynamically changes. For example, screen readers cannot pick up search results that update in real time. You can use ARIA live regions to announce dynamic content changes as they happen.
WAI-ARIA can be easy to implement incorrectly, which can result in disabled people being unable to use your service. You must follow the correct specifications and recommended approaches for WAI-ARIA.
When using WAI-ARIA, make sure you:
- add interaction-specific WAI-ARIA attributes such as
trueonce a user expands an element
Testing your service’s accessibility
You should perform a manual check against WCAG 2.1 and test with the most common assistive technology and browser combinations.
Your manual tests should cover common accessibility issues, for example testing that:
- your service works with a keyboard
- users can adapt the interface, such as by increasing font size or changing colour in the browser
You must test for accessibility regularly when you’re writing production code. Once your service is in public beta, you must test for accessibility each time you add a new feature.
Using accessibility criteria
Accessibility acceptance criteria are specific rules you can apply to service components to help with accessibility testing. Accessibility criteria help you decide what you need to test.
For example, a link does not need an associated label, but it does need clear text to describe where the link goes. Acceptance criteria like this can help maintain the accessibility of a service as you add or update features.
Contact the accessibility community to:
- discuss how to build accessible services and meet accessibility requirements
- share ideas across government
- find support from teams that have worked on similar services or faced similar challenges
You might find the following things useful:
Added more information to the guidance, as well as links to resources for developers to help build accessible services.
Guidance first published