Accessibility audits
An accessibility audit will check to make sure your product or website meets the WCAG 2.2 Level AA accessibility guidelines and how well it performs with assistive technologies.
An audit will give you an understanding of the types of barriers users may face when using your product or website. It will also provide remediation techniques to help resolve any issues.
It will check whether your product or website meets WCAG 2.2 Level AA and the public sector bodies accessibility regulations.
Before going into public beta, your product or website must work with a combination of assistive technologies and browsers. An audit will ensure this and will also help you to meet Service Standard point 5.
You will use the report to help to create your accessibility statement.
Start to plan for an audit in alpha
Even though you will not need to do an audit until beta, you should start planning earlier.
Delivery and product managers should also consider that when you receive the report, the team will need time and resource to fix issues and potentially redesign sections of your service to make sure they're accessible.
You must get an audit before your service moves into public beta.
Understand the scope of your audit
Before requesting an audit, you need to work out what exactly needs to be audited.
You must audit production-quality code and not prototype code or kit.
The auditors will need essential information to:
- access the service
- understand the scope of the test
- have all the relevant data to complete the user journeys
You'll need to provide these details in advance to avoid delays in testing.
An accessibility statement is a legal document. The contents are informed by the findings of an accessibility audit, so it's important that audit requirements are in line with Website Accessibility Conformance Evaluation Methodology (WCAG-EM).