1. Service manual
  2. Technology
Technology

Making your frontend accessible

Give feedback about this page

From:
Accessibility community

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:

Using the GOV.UK Design System

You should use the GOV.UK Design System to build your service wherever possible. The GOV.UK 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 GOV.UK Design System is regularly tested against the most commonly used assistive technology and browser combinations. It also meets level AA of WCAG 2.2.

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 GOV.UK Design System.

It’s easy to accidentally introduce accessibility barriers into the HTML, Cascading Style Sheets (CSS) and JavaScript layers of code. This is true even if you use the GOV.UK Design System.

Use progressive enhancement to make sure your service is still usable if any of the layers above the HTML, such as CSS or JavaScript, fail or if the user switches them off.

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:

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 header, main and 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 button, not div.

Always make sure the content of a page is in a logical order and does not rely on CSS or JavaScript to reorder content after the page loads. This means screen readers read out the content in the right order.

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 h1 to 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:

Some users customise the appearance of web pages to suit their needs. To support these users you should make sure:

If possible, you should avoid using CSS to reorder content on a page as this could cause issues for keyboard and screen reader users.

Writing accessible JavaScript

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 aria-controls using JavaScript, so that users without JavaScript are not confused
  • update WAI-ARIA attributes as JavaScript changes occur on the page, for example set aria-expanded to true once a user expands an element

Testing your service’s accessibility

You should perform a manual check against WCAG 2.2 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.

You can test your service with an automated accessibility testing tool. However, accessibility tools will not catch all errors, so you must carry out manual tests as well.

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.

Getting help

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

Further reading

You might find the following things useful:

From:
Accessibility community
Last updated
almost 5 years ago
Last update:

Added more information to the guidance, as well as links to resources for developers to help build accessible services.

  1. Guidance first published