A website accessibility audit should answer three questions: what barriers exist, who is affected, and what should be fixed first? A useful audit goes beyond a single score. It combines repeatable automated checks with human evaluation of real tasks and leaves the organization with evidence that can guide remediation.
Ontario’s guidance for making websites accessible recommends automatic assessment, assistive technology, user testing, feedback, and records of resolved issues. That layered approach is a strong model for organizations across Canada, even when the exact legal framework differs by jurisdiction or industry.
1. Define scope before testing
Inventory domains, subdomains, web applications, third-party services, PDFs, videos, and mobile experiences. Select representative templates and high-value journeys rather than scanning only the homepage. Include account creation, sign-in, search, contact, checkout, applications, bookings, and complaint or accommodation requests.
Record the target standard and conformance level. Many Canadian teams use WCAG 2.1 or WCAG 2.2 Level AA as a modern testing target, while Ontario’s current AODA website rule references WCAG 2.0 Level AA for covered content. Document both the legal baseline and the organization’s internal standard.
2. Run automated accessibility scans
Automated tools can quickly identify missing accessible names, absent labels, invalid ARIA, colour contrast failures, duplicate IDs, structural defects, and other machine-detectable issues. Save the tested URL, timestamp, source snippet, selector, viewport, and tool version.
Do not treat the automated score as a certification. Automated testing cannot reliably judge whether alternative text is meaningful, headings communicate a logical outline, instructions are understandable, focus order matches the task, or captions convey essential information.
3. Test every journey with a keyboard
- Reach every interactive control without a mouse.
- Confirm that focus is visible and never obscured.
- Check that focus order follows the visual and logical sequence.
- Open and close menus, dialogs, date pickers, and disclosures.
- Confirm there are no keyboard traps.
- Verify that skip links and landmarks support efficient navigation.
4. Evaluate screen-reader output
Test with at least one widely used screen reader and browser combination. Listen for the page title, heading hierarchy, landmarks, link purpose, button names, form labels, required states, validation errors, status messages, and dialog announcements. Confirm that decorative images are ignored and meaningful images have useful alternatives.
5. Check visual and responsive accessibility
Review colour contrast, text spacing, 200% zoom, reflow at narrow widths, orientation, content on hover or focus, visible focus indicators, and touch target size. Make sure meaning is not communicated by colour alone. Test mobile layouts with both touch and an external keyboard where relevant.
6. Review content and documents
Plain language, descriptive headings, useful link text, captions, transcripts, and accessible office documents are part of the user experience. Check PDFs for tags, reading order, document title, language, headings, lists, tables, form fields, and alternative text.
7. Prioritize and verify remediation
Prioritize blockers in critical journeys, issues affecting many pages, and barriers with severe user impact. Fix shared components before isolated content because template-level remediation produces broader results. Every closed issue should be retested in the live experience and linked to evidence.
8. Monitor accessibility drift
Websites are not static. Content publishing, design changes, third-party widgets, and software updates can reintroduce barriers. Schedule scans, add accessibility checks to release workflows, and report meaningful changes to owners.
The W3C’s current WCAG 2.2 Recommendation is the authoritative technical reference for modern success criteria. Legal applicability depends on jurisdiction and organization type, so use qualified advice where needed.