An accessibility audit checklist systematically evaluates whether your website meets WCAG standards and relevant Canadian requirements, identifying barriers that prevent users with disabilities from accessing content. This framework covers technical compliance, usability testing, and remediation prioritization.
Define which pages and user flows you're auditing before running any tests. For most Canadian organizations, evaluate the homepage, primary conversion paths, key service pages, and at least one complete transaction flow. Federal entities must comply with the Accessible Canada Act, which mandates WCAG 2.1 Level AA. Ontario organizations under AODA follow the same standard. Quebec's Standard sur l'accessibilité du Web references WCAG but adds French-language requirements. BC lacks provincial legislation but municipal sites often adopt WCAG voluntarily.
Document your target conformance level explicitly. Level A covers baseline access, Level AA addresses common barriers and is the regulatory standard, Level AAA includes specialized accommodations rarely required by law. Choose your testing browsers and assistive technology stack upfront: typically NVDA or JAWS on Windows, VoiceOver on macOS/iOS, and TalkBack on Android. Testing only in Chrome with a single screen reader misses real-world diversity.
Run automated scans with browser extensions like Axe DevTools, WAVE, or IBM Equal Access to identify low-hanging technical violations. These tools flag missing alt text, insufficient color contrast, heading hierarchy jumps, empty links, and form labels. Axe integrates with Chrome and Firefox DevTools and reports WCAG criterion violations with code snippets. WAVE visualizes page structure with inline icons showing errors and alerts.
Automated tools typically catch HTML structure problems, ARIA misuse, and measurable attributes like contrast ratios, but they cannot evaluate contextual appropriateness. A decorative image with alt="" passes automated tests but may still confuse users if it's functionally important. Complex interactions, dynamic content loaded after page render, and semantic meaning require human judgment. Treat automated scans as the first pass, not the complete audit. Export results to spreadsheet format with page URLs, violation counts, and affected elements for tracking.
Unplug your mouse and navigate the entire site using only Tab, Shift+Tab, Enter, Spacebar, and arrow keys. Every interactive element—links, buttons, form fields, modals, carousels—must be reachable and operable. Watch for keyboard traps where focus gets stuck inside a component with no escape route. Dropdown menus and modal dialogs are common culprits.
Focus indicators must be visible at all times. Many sites suppress the default browser outline without providing an alternative, making it impossible to track position. Test that focus order follows logical reading sequence, not DOM order if CSS repositions elements visually. When a modal opens, focus should move into it and be constrained until dismissed. When it closes, focus returns to the trigger element. Skip-to-main-content links should appear on first Tab press, allowing users to bypass repetitive navigation. Custom widgets built with divs and spans instead of semantic HTML often fail here unless ARIA roles, tabindex, and keypress handlers are implemented correctly.
NVDA on Windows is free and widely used. JAWS is commercial but prevalent in enterprise environments. VoiceOver ships with macOS and iOS. TalkBack is Android's built-in reader. Test in at least two to catch platform-specific quirks. Navigate by headings (H key in NVDA/JAWS), landmarks (D key), and forms mode to verify content structure.
Check that images have meaningful alt text or are marked decorative. Form labels must be programmatically associated with inputs, not just visually proximate. Error messages and validation feedback should announce to assistive tech when they appear. Dynamic content updates—live chat, notifications, search filters—require ARIA live regions with appropriate politeness levels or they remain silent. Tables need proper headers and scope attributes so data relationships are clear aurally. Test that links make sense out of context; "click here" repeated across a page is useless when browsing a list of links. Record issues with element selectors and expected versus actual announcements.
Use the WebAIM Contrast Checker or built-in browser tools to verify text meets WCAG thresholds: 4.5:1 for normal text, 3:1 for large text (18pt or 14pt bold) at Level AA. Graphics and UI components require 3:1 against adjacent colors. Gray text on light gray backgrounds commonly fails. Test that users can zoom to 200% without horizontal scrolling or content overlap. Responsive layouts should reflow gracefully. Fixed-width containers and absolute positioning often break.
Evaluate color-reliance in data visualizations, form validation, and interface states. Required fields marked only with red asterisks exclude colorblind users unless text labels or patterns supplement the color. Link text should be underlined or otherwise distinguishable from surrounding text without depending solely on hue. Test in Windows High Contrast Mode and browser reader modes to ensure content remains perceivable when user stylesheets override author CSS.
Forms are critical conversion points and frequent accessibility barriers. Every input needs a visible, programmatically associated label. Placeholder text alone does not satisfy this. Required fields must be indicated in text, not just visually. When validation fails, error messages should appear near the problematic field, be announced by screen readers, and explain how to fix the issue—not just state "invalid entry."
Test multi-step processes like checkout or account creation end-to-end. Users must be able to review, correct, and confirm submissions before finalizing, especially for legal or financial transactions. Time limits on forms or sessions should be avoidable, adjustable, or extendable unless security-critical. CAPTCHAs present significant barriers; offer alternatives like invisible reCAPTCHA, hCaptcha with audio fallback, or email verification. Auto-advancing carousels, auto-playing media, and moving animations should have pause controls and not start automatically if they last longer than five seconds.
Categorize findings into critical, major, and minor based on user impact and WCAG conformance level. Critical issues block core functionality: form submission failures, keyboard traps, missing page titles. Major issues impede significant user groups: missing alt text on informative images, poor contrast, unlabeled form fields. Minor issues affect usability but have workarounds: suboptimal heading hierarchy, redundant links.
Document each issue with a screenshot, affected page or component, specific WCAG success criterion (e.g., 1.4.3 Contrast Minimum), user impact description, and recommended fix. Link to WCAG Understanding documents for developer reference. Create a remediation backlog in your project management tool with effort estimates. Quick wins like alt text and label additions can be batched. Complex fixes like keyboard interaction refactoring for custom components need dedicated sprint cycles. Assign owners and set realistic deadlines. Plan regression testing after fixes deploy since changes to one component can inadvertently break another.
Run a comprehensive audit quarterly or whenever you launch major features, redesigns, or CMS upgrades. Continuous monitoring with automated CI/CD integration catches regressions between full audits. Third-party widgets, ad networks, and chat tools frequently introduce new violations without warning, so monitoring detects drift. High-traffic sites or those under regulatory scrutiny benefit from monthly spot-checks of key conversion paths.
No. Automated tools identify 30-40% of WCAG violations—primarily technical and measurable issues like missing labels or contrast failures. They cannot assess semantic correctness, contextual appropriateness, or subjective usability. Manual testing with keyboard navigation, screen readers, and real users with disabilities is essential to catch nuanced barriers that algorithms miss. Combine both approaches for meaningful compliance.
Level AA is the legal baseline for federal entities under the Accessible Canada Act and Ontario organizations under AODA. Quebec's standard also aligns with WCAG 2.1 AA. Level AAA includes specialized accommodations rarely mandated but may be appropriate for government services or sites serving populations with specific needs. Private sector organizations not under provincial mandates should still target AA as best practice and future-proofing.
Assemble a cross-functional team: developers who understand HTML, CSS, and ARIA; designers who make visual and interaction decisions; content creators who write alt text and manage media; QA testers who verify fixes; and ideally users with disabilities who provide real-world feedback. External auditors or accessibility consultants bring specialized expertise and objectivity. Product owners prioritize remediation within broader roadmaps.
Document violations in third-party components separately since you cannot directly fix their code. Contact vendors with specific WCAG citations and request timelines for remediation. Evaluate whether accessible alternatives exist or if you can override styles and add ARIA attributes via JavaScript. In some cases, replacing inaccessible tools is necessary. Include third-party accessibility conformance requirements in procurement contracts to prevent future issues.
An audit evaluates technical conformance to WCAG standards using tools and expert review. It identifies code-level violations and structural barriers. User testing involves people with disabilities attempting real tasks on your site, revealing usability friction that meets technical standards but still creates poor experiences. Both are complementary. Audits establish baseline compliance; user testing uncovers whether the experience is genuinely usable and satisfying for your audience.