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 workable 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 (like our Website Design System) makes things easier in the long run.

Different types of testing you could ask for in your audit, include:

• Conformance auditing - to the Web Content Accessibility Guidelines WCAG 2.0 or WCAG 2.1 or the Australian Accessible ICT Standard AS EN 301 549:2016.
• Assistive technology testing - this shows how well your service performs with things like screen readers and magnification software.
• A usability review - this involves experienced testers with a range of disabilities going through your service and finding accessibility issues.

Ask for assistive technology testing to be included in your audit, even if you’ve used assistive technology in your own testing.

Office for Digital Government can help you with the type of accessibility audit you need.

Don’t leave your conformance audit until the last minute, make sure there’s time to act on the recommendations. You can:

• Ask a specialist from your department to do the audit - they’ll need good accessibility and assistive technology knowledge, and experience of evaluating services against WCAG 2.0 or WCAG 2.1 or the Australian Accessible ICT Standard AS EN 301 549:2016.
• Find a third party - these usually cost between $7,000 and $12,000 depending on the size and scope of your service.

Remember to arrange a follow-up audit when you book your initial audit, so you can check you’ve fixed any issues.

You’ll need to write a brief so potential suppliers know what you need from them.

Make sure you get to discuss the process and outcome with your auditors and that they don’t rely exclusively on automated tools.

In your brief, include:

• the name of your service and a description of what it is - it’s helpful to include some screenshots and hyperlinks pointing to the location
• 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.0 or WCAG 2.1 level AA or level AAA compliance
• if you're aiming for the Australian Accessible ICT Standard AS EN 301 549:2016
• 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 World Wide Web Consortium's (W3C) evaluation methodology if you’re not sure which pages to get tested or how the evaluation process works.

Don’t automatically go for the cheapest supplier - they often won’t represent the most valuable choice.

Look for suppliers that:

• have extensive experience of doing audits, preferably of government services
• are familiar with the Digital Service Standard criteria
• 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 (for example developing coding solutions to WCAG 2.0 or WCAG 2.1 or AS EN 301 549:2016). 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.