- AODA Training Guide
How to Perform an Accessibility Audit: Step-by-Step Process
An accessibility audit is not a single test — it is a structured 7-phase process that combines automated scanning, manual evaluation, and assistive technology testing to build a complete picture of where a website stands against WCAG 2.0 Level AA.
- 4.6
93% Student Satisfaction (2K ratings)
Quantity Discounts
Price per course
6 to 20 courses
$20.95
21 to 50 courses
$17.95
51 to 200 courses
$13.95
201+ courses
Custom offer
An accessibility audit is not a single test. It is a structured process that combines automated scanning, manual evaluation, and assistive technology testing to build a complete picture of where a website or digital product stands against WCAG 2.0 Level AA.
This guide explains each phase in the order it happens — from deciding what to test, through to delivering a report your development team can act on.
The accessibility audit process at a glance
Phase 1: Scoping the audit
Choosing a page sample for large websites
For websites with hundreds or thousands of pages, testing every page is impractical. The standard approach is to select a representative sample that covers:
- The homepage
- Key conversion pages (contact, checkout, booking, sign-up)
- One example of each major page template (product page, blog post, service page, landing page)
- Any page with significant interactive components (forms, modals, carousels, date pickers, maps)
- Any page that has received accessibility complaints or feedback
- Documents (PDFs, Word files) linked from key pages
- AODA Website Compliance Requirements: What Must Be Tested
Phase 2: Automated scanning
What automated tools find — and what they miss
- Accessibility Audit Tools: Free vs Paid Comparison
Phase 3: Manual testing
Keyboard testing protocol
Keyboard testing is the single most impactful manual test because keyboard accessibility is a prerequisite for screen reader access. The testing protocol is:
- 1 Open the page in a browser with no mouse accessible
- 2 Press Tab to move through the page — confirm every interactive element receives focus in a logical order
- 3 Activate each element using Enter or Space — confirm it performs its expected action
- 4 For dropdowns and custom widgets, test arrow key navigation
- 5 For modals and dialogs, confirm focus moves into the modal on open and returns to the trigger on close
- 6 For carousels and sliders, confirm controls are reachable and operable
- 7 Confirm there are no keyboard traps — elements you can Tab into but cannot Tab out of
Phase 4: Assistive technology testing
- Manual vs Automated Accessibility Testing: Which Do You Need?
Phase 5: Issue documentation
Keyboard testing protocol
Phase 6: Writing the audit report
- AODA Accessibility Report: What's Included and What to Do With It
Phase 7: After the report — remediation and retest
An audit report is the beginning of the compliance process, not the end. The most effective organizations treat the report as a project plan and assign findings to owners immediately.
Prioritize by impact
Start with critical issues on high-traffic pages. A critical keyboard navigation failure on the homepage affects every keyboard user who visits — far higher priority than a minor contrast issue on a rarely-accessed policy document.
Assign to the right teams
Developers fix code. Designers address colour contrast and focus indicators. Content editors fix alt text and link text. Document owners remediate PDFs. Route each finding to the right owner to prevent bottlenecks.
Build it into the workflow
Fixing existing issues is only half the work. Add accessibility checks to design review, development QA, and content publishing workflows so new work does not create new compliance debt.
Retest and document
After remediation, retest the fixed elements to confirm issues are resolved correctly. Document the retest — this creates the evidence trail that matters most if a government audit or complaint investigation follows.
- Accessibility Remediation: How to Fix WCAG Issues
Internal audit vs external audit: what's the difference?
- Third-Party AODA Audit: When You Need One
Frequently asked questions
How long does an accessibility audit take?
- A website audit of a small site (up to 20 pages) typically takes two to three days of testing time, plus report writing. A medium site (20–100 pages) takes three to five days. A full organizational AODA audit that also covers policies, training records, and employment documentation adds one to two days. Timeline from scoping to report delivery is typically two to four weeks for a professional external audit.
Can I use a single automated scan as my AODA compliance evidence?
- No. An automated scan captures 30–40% of WCAG failures and cannot assess keyboard usability, screen reader experience, or the quality of alt text and link text. It provides useful baseline data but is not a compliance audit. If your organization needs to demonstrate accessibility compliance — for a compliance report, in response to a complaint, or as part of a procurement requirement — a full audit including manual and AT testing is required.
How often should an accessibility audit be conducted?
- For organizations with active websites, a full audit every one to two years is reasonable, supplemented by automated scanning as part of the regular development workflow. A new audit should be triggered by a major website redesign, a new content management system, a significant expansion of the site, or a complaint about accessibility. For organizations with 20 or more employees, the AODA compliance report filed every three years should be based on a current audit.
What qualifications should an accessibility auditor have?
- Look for auditors with demonstrable experience in WCAG 2.0 Level AA testing, including manual testing and AT testing skills. Recognized credentials include the IAAP Web Accessibility Specialist (WAS) and Certified Professional in Accessibility Core Competencies (CPACC). Ask potential auditors to share sample reports, explain their testing methodology, and confirm which AT combinations they use. The quality of the report matters more than any credential.
Do we need to reaudit after fixing the issues from the first audit?
- Retesting specific fixes is strongly recommended. A retest confirms that remediation was implemented correctly — it is common for a fix to resolve one issue while inadvertently creating another. Full reaudit after complete remediation is not always necessary, but targeted retesting of high-severity findings before filing a compliance report is good practice.
Commission a professional AODA accessibility audit
If you want a full picture of your website’s WCAG 2.0 Level AA compliance — not just what automated tools find — our audit service covers all seven phases: scoping, automated scanning, manual testing, AT testing, issue documentation, reporting, and optional post-remediation retesting.
- Scoped to your key pages and user journeys
- Manual WCAG 2.0 Level AA testing by an accessibility specialist
- Keyboard navigation testing across all interactive elements
- Automated scanning with axe and WAVE
- Screen reader testing with NVDA (Firefox) and VoiceOver (Safari)
- Prioritized audit report with WCAG references, severity ratings, and code-level fix guidance
