A website accessibility audit tells you whether people with disability can use your website, what is stopping them, and how to fix it. This guide explains what an audit is, how it works step by step, what you get at the end and how to choose an auditor.
What an accessibility audit is
An accessibility audit is a detailed review of your website against the Web Content Accessibility Guidelines (WCAG). In Australia, the standard to test against is WCAG 2.2 Level AA, which is what the Australian Human Rights Commission recommends.
A good audit is done by a person, using the same tools people with disability use: a keyboard instead of a mouse, screen readers, zoom and voice control. Automated tools help, but they are only one part of it.
How an audit is different from a free scan
Free scanners such as WAVE, axe and Lighthouse check a page for problems that can be measured automatically, such as missing alt text or low contrast. They are fast and useful, but they can’t tell you:
- whether your alt text actually describes the image
- whether someone using only a keyboard can open your menu and submit your form
- whether a screen reader user can understand your error messages
- whether your pages still work when zoomed to 400%
- whether your PDFs can be read in the right order
Read more about automated vs manual accessibility testing.
How an audit works, step by step
- Agree the scope. You and the auditor choose which pages, templates, forms and documents to test. A good sample covers every type of page and every key task, such as signing up, booking or paying.
- Run automated checks. A scanner finds the quick, measurable issues across the sample.
- Test with a keyboard. The auditor works through every page and task using only a keyboard, checking focus, order and traps. Our keyboard-only testing guide shows how this works.
- Test with screen readers. The auditor uses screen readers such as JAWS, NVDA and VoiceOver to check headings, links, images, forms, tables and announcements.
- Check visual design. Colour contrast, zoom and text resizing, small screens, motion and how information is shown with colour.
- Check content and documents. Link text, headings, plain language, captions, and any PDFs or Word documents people need.
- Write the report. Each issue is recorded with where it is, who it affects, which WCAG criterion it fails, how serious it is and how to fix it.
- Walk through the findings. The auditor explains the report to you and your developer and answers questions.
- Retest. After fixes are made, the auditor tests again and confirms which issues now pass.
What gets tested
A WCAG 2.2 AA audit covers more than 50 success criteria. In plain English, these include:
- Images: useful alt text, and decorative images hidden from screen readers
- Keyboard: everything works without a mouse, focus is visible and nothing traps you
- Structure: real headings, lists and landmarks so people can find their way around
- Forms: labels, instructions, clear error messages and no time pressure
- Colour and contrast: readable text and controls, and colour is never the only clue
- Zoom and reflow: pages work at 200% and 400% zoom and on small screens
- Media: captions, transcripts and controls for video and audio
- Links and buttons: they make sense out of context and are big enough to tap
- Documents: PDFs and Word files are tagged and readable
What you get at the end
- A plain-English report listing every issue, where it is, who it affects and how to fix it, ranked by priority so you know where to start. See our sample audit report.
- A summary you can share with managers, boards and funders.
- Support for your developer, so the fixes are done properly the first time.
- A retest to confirm the fixes work.
- A statement of conformance once the tested pages meet WCAG 2.2 AA, saying what was tested, against which standard and when.
What happens after the audit
Fix the highest-priority issues first, because these stop people completing tasks. Many issues come from one template or component, so a single fix can solve the problem on hundreds of pages. Then publish an accessibility statement, train the people who add content, and check new pages and documents before they go live.
Who needs an audit
- organisations that need evidence they are meeting their obligations under the Disability Discrimination Act
- suppliers to government, who are often asked for an audit report or statement of conformance
- NDIS providers, not-for-profits and health services whose clients include people with disability
- anyone launching a new website, or who has had a complaint about their current one
How to choose an auditor
Ask these questions before you engage anyone:
- Do you test by hand, or only with automated tools?
- Which screen readers and devices do you test with?
- Which version and level of WCAG do you test against?
- Can I see a sample report?
- Do you explain how to fix each issue, and help my developer?
- Is a retest included?
Be wary of anyone who offers a “DDA certificate” or promises instant compliance from a widget. Read why there is no such thing as DDA certification.
Want to check your site first?
Work through our free website accessibility checklist, or ask us for a free homepage check. When you’re ready, find out more about our website accessibility audits or contact us for a fixed quote.