The accessibility of your service is your team’s responsibility.
Before you request an accessibility audit, you should check the accessibility of your service.
To help you we’ve listed some things you can check for throughout development.
As an absolute bare minimum, we recommend following these three tasks:
- Make sure each page contains valid HTML.
- Make sure each page is free from WCAG errors.
- Test each page with a screen reader.
Carrying out these checks will help you:
- improve the accessibility of your service
- save time by eliminating issues early
- make sure it meets the public sector accessibility regulations
You can validate your HTML on a page-by-page basis using browser plugins. However, it is time consuming. We recommend that you automate your HTML validation as part of your CI build; see Stage three: Continuous Integration tools.
Accessibility is a user need. You should be thinking about the access needs of your users from the start of design, research and development. Do not leave it until the end.
Build accessibility tasks into each sprint and include them in your workflow. Here are some examples that you can use.
Ideally you should test your service regularly in the accessibility lab, using a range of devices. This will get you a long way towards avoiding the most common accessibility failings.
Avoid the most common GOV.UK Design System and usability issues that we see when auditing services.
We recommend that you share the load between all team members so that everybody owns at least one accessibility task.