Getting an accessibility audit
Getting an expert audit can help find accessibility problems with your service and make sure it meets accessibility requirements.
If you’re working on a GOV.UK service (that’s a service published on a .service.gov.uk subdomain), you must get an audit before your service moves into public beta.
Accessibility audits can also help public sector bodies understand:
- how accessible their website or app is
- what they need to fix in order to meet the new public sector accessibility regulations
The full name of the new regulations is the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018.
Work out what needs to be audited
Before you start searching for someone to carry out your audit, you’ll need to work out which elements of your service you want the audit to focus on.
It’s not usually feasible to audit the whole service. You should focus on:
- getting a representative sample of your page templates and content types tested
- any key interactive features
- your most common or important user journeys
- any particularly problematic areas you’ve seen in testing
If you build a reusable components library, get all of the components tested. Using a library makes things easier in the long run: if you hard-code all of your pages you’ll need to fix each instance of a problem manually, rather than just updating the library.
If you’re getting a website audited
Equally, it’s not feasible to audit an entire website. Your auditor will usually work with you to identify exactly which pages to check. But start by putting a sample together to give them an idea of what’s on your website.
Your sample should include:
- your site’s homepage
- content pages that are mostly text based
- images, video and audio content
- interactive tools and transaction, like forms
- pages including login functionality, if your website has them
- PDFs and other document types you have
- dynamic content like pop-up windows
- navigation pages, including your sitemap and pages with search functionality
You should also include in your sample any pages or websites containing information about accessibility, how to contact you, how to use your site, legal information (for example terms and conditions pages, or things like your privacy policy) and any settings or preferences pages.
What’s involved in an audit
You’ll need to get your service or website checked against the Web Content Accessibility Guidelines (WCAG) 2.2 (known as conformance testing), to make sure it meets the WCAG 2.2 AA accessibility standard.
The audit should also include testing with assistive technologies (even if you’ve used assistive technology in your own testing). This shows how well your service performs with things like screen readers and magnification software.
If your service is being assessed against the Service Standard you must get an accessibility audit - and fix any issues - before your service moves into public beta.
Do not leave your audit until the last minute - make sure there’s time to act on the recommendations.
How to get an audit
You can:
- ask a specialist from your department to do the audit - they’ll need good accessibility and assistive tech knowledge, and experience of evaluating services against WCAG 2.2
- use a third party auditor - you can use the Digital Marketplace to help you find a supplier
If you’re working to the Service Standard, arrange a follow-up audit when you book your initial audit, so you can check you’ve fixed any issues.
If you’re using a third party auditor, there are a couple of extra steps you’ll need to take.
Write an accessibility audit brief
You’ll need to write a brief so potential suppliers know what you need from them. In your brief, include:
- the name of your service or website and a description of what it is - it’s helpful to include some screenshots and URLs
- who your users are
- which user journeys, tasks, patterns or page types you’d like the auditor to look at - it’s helpful to provide a list of components in your pattern library
- your timescale for the audit - allow enough time for bug fixes before you move on to the next stage of user testing
- which assistive technology and browser combinations you want the auditor to test with, if that’s something you’ve asked for
- whether you’re aiming for WCAG 2.2 level AA or level AAA compliance
- who will read the audit report - for example, product managers or developers
- how much support you want - it’s a good idea to get support from the start and ongoing support after the audit
- whether you’ll need help fixing any issues identified in the audit
You should also tell potential suppliers:
- where you are in your development cycle
- if you want to attend any of the testing and the dates you could attend
- if any part of your service was built by a third party
Check that you’ll get to discuss things face-to-face with your auditors and make sure they do not rely exclusively on automated tools.
Check W3C’s evaluation methodology if you’re not sure which pages to get tested or how the evaluation process works.
Pick a supplier
Do not automatically go for the cheapest supplier - they often will not represent the most valuable choice. Look for suppliers that:
- have extensive experience of doing audits, preferably of government services
- are familiar with the service standard and GOV.UK design patterns, if you’re building a service for GOV.UK
- provide clear and actionable reports - it’s okay to ask to see examples
- are involved in the wider accessibility community - for example through publishing blog posts, running training and contributing to standards
- can help you prioritise issues and provide support in fixing them - it’s worth paying more for a supplier that can help with this
- meet your needs - for example if you need support tickets raised in a specific project management tool
What happens after the audit
If you’re building a GOV.UK service, you’ll need to prioritise and fix the issues raised in your audit report before you move into public beta. Your supplier should be able to help you with this - it’s worth choosing a supplier that offers this service, and paying a bit extra if necessary.
Use your follow-up audit to check you’ve fixed all the issues.
If you’re a public sector body, you’ll need to work out which issues are reasonable for you to fix now and what you’ll fix later.
Once that’s done, think about what needs doing to help your organisation continue to meet accessibility standards. For example, you might want to consider:
- appointing an accessibility champion and reviewing the organisation’s policies on accessibility
- using common patterns or components
- arranging accessibility training for staff
- making sure that any technology suppliers you use in future know about accessibility standards (auditors are often happy to share details of the tools and processes they use for accessibility testing)
If you need extra help, start with the cross-government accessibility community Google group or accessibility community Slack channel.
You could also use the:
Publishing an accessibility statement or accessibility page
Once you’ve finished your audit, you’ll be ready to start working on an accessibility page for your GOV.UK service.
If you’re a public sector body and you’ve worked out what you’re going to fix now, you’re ready to publish an accessibility statement for your website.
- Last update:
-
Added detail on getting a public sector website audited.
-
Clarified what should be involved in an audit.
-
Guidance first published