AODA Website Accessibility Checklist: Your Complete Compliance Guide

Ensuring your website meets AODA compliance requirements can feel overwhelming, especially when faced with 61 WCAG 2.0 Level AA success criteria. This practical checklist breaks down essential accessibility requirements into actionable items you can test and implement today.

How to Use This Checklist

This checklist organizes AODA requirements by website component rather than WCAG criterion number, making it easier to audit your site systematically. For each item:

✓ Pass: The requirement is fully met
✗ Fail: Issues exist that need remediation
N/A: The requirement doesn't apply to your content

Consider this a starting point. Every website is unique, and you may need additional checks based on your specific features and functionality.

Page Structure and Navigation

Document Structure

[ ] Every page has exactly one <h1> heading
[ ] Headings follow a logical hierarchy (don't skip levels)
[ ] Headings accurately describe the content that follows
[ ] Page <title> accurately describes page content and is unique
[ ] HTML lang attribute is set on the <html> element
[ ] Language changes within content are marked with lang attributes

Landmarks and Regions

[ ] Main content is wrapped in a <main> element
[ ] Navigation is contained in <nav> elements
[ ] Page regions use semantic HTML5 elements or ARIA landmarks
[ ] Repeated content (headers, navigation) can be bypassed with skip links

Navigation

[ ] Multiple ways exist to find pages (menu, search, sitemap)
[ ] Navigation order is logical and consistent across pages
[ ] Current page is indicated in navigation menus
[ ] Navigation menu structure is consistent across the site
[ ] Breadcrumb navigation is provided where appropriate

Keyboard Accessibility

Basic Keyboard Operation

[ ] All interactive elements can be reached using Tab key
[ ] Tab order follows a logical reading sequence
[ ] All functionality available with mouse also works with keyboard
[ ] No keyboard traps—users can navigate away from all components
[ ] Keyboard shortcuts don't conflict with assistive technology shortcuts

Focus Management

[ ] Focus indicator is visible on all interactive elements
[ ] Focus indicator has sufficient contrast (at least 3:1)
[ ] Focus doesn't jump unexpectedly to different page areas
[ ] Focus is managed properly in modals and dynamic content
[ ] Custom widgets (dropdowns, tabs) support standard keyboard patterns

Interactive Components

[ ] Dropdowns can be operated with arrow keys
[ ] Modal dialogs trap focus until closed
[ ] Accordions expand/collapse with Enter or Space keys
[ ] Tab panels can be navigated with arrow keys
[ ] Custom controls announce their state to screen readers

Images and Media

Images

[ ] All informative images have descriptive alt text
[ ] Decorative images use empty alt attributes (alt="")
[ ] Complex images (charts, graphs) have detailed descriptions
[ ] Alt text doesn't include redundant phrases like "image of"
[ ] Images of text are avoided when possible
[ ] SVG icons include appropriate titles or labels

Video Content

[ ] All videos have synchronized captions
[ ] Captions are accurate and include relevant sound descriptions
[ ] Audio descriptions are provided for visual-only content
[ ] Media players have accessible controls
[ ] Auto-playing media can be paused or stopped
[ ] Transcripts are provided for video content

Audio Content

[ ] Audio-only content has text transcripts
[ ] Podcasts include accurate transcripts
[ ] Live audio includes captions when possible
[ ] Background audio is minimal or can be disabled

Color and Contrast

Color Contrast

[ ] Normal text (under 18pt) has 4.5:1 contrast ratio minimum
[ ] Large text (18pt+ or 14pt+ bold) has 3:1 contrast minimum
[ ] Interactive elements have 3:1 contrast against background
[ ] Focus indicators have 3:1 contrast against background
[ ] Disabled elements are visually distinguishable

Color Usage

[ ] Color is not the only way information is conveyed
[ ] Links are distinguishable without relying solely on color
[ ] Error messages use icons or text in addition to color
[ ] Charts and graphs use patterns in addition to colors
[ ] Form validation doesn't rely only on color changes

Forms and Input

Form Labels

[ ] All form inputs have associated <label> elements
[ ] Labels are properly connected using for and id attributes
[ ] Placeholder text is not used as the only label
[ ] Required fields are clearly indicated
[ ] Group labels (fieldset/legend) are used for related inputs

Form Validation

[ ] Error messages clearly identify which field has the error
[ ] Error messages explain how to fix the problem
[ ] Errors are announced to screen readers
[ ] Error identification doesn't rely solely on color
[ ] Forms can be submitted and corrected using keyboard only

Input Assistance

[ ] Input purpose is identified for common fields (name, email, phone)
[ ] Format requirements are explained before input
[ ] Sensitive actions can be reversed, checked, or confirmed
[ ] Instructions are provided before form sections requiring them
[ ] Help text is associated with form fields programmatically

Links and Buttons

Link Accessibility

[ ] Link text clearly describes the link destination
[ ] Links with the same destination have consistent text
[ ] Links with different destinations have unique text
[ ] "Click here" and "read more" are avoided or contextualized
[ ] Links are visually distinguishable from regular text
[ ] External links are indicated for users

Buttons and Controls

[ ] Buttons use <button> elements (not styled divs)
[ ] Button text clearly describes the action
[ ] Icon-only buttons have accessible labels
[ ] Toggle buttons announce their current state
[ ] Disabled buttons are marked as disabled in code

Dynamic Content and Interactions

Content Updates

[ ] Dynamic content updates are announced to screen readers
[ ] ARIA live regions are used appropriately for updates
[ ] Loading states are communicated to all users
[ ] Infinite scrolling has keyboard-accessible alternatives
[ ] Auto-refreshing content can be paused or stopped

Time Limits

[ ] Session timeouts provide adequate warning
[ ] Users can extend or disable time limits
[ ] Auto-advancing carousels can be paused
[ ] Animations can be paused, stopped, or hidden
[ ] No content flashes more than 3 times per second

Modal Dialogs and Overlays

[ ] Focus moves to modal when opened
[ ] Keyboard focus is trapped within modal
[ ] Modal can be closed with Escape key
[ ] Focus returns to trigger element when modal closes
[ ] Background content is marked as inert

Tables

Data Tables

[ ] Table headers use <th> elements
[ ] Simple tables use scope attribute on headers
[ ] Complex tables use id and headers attributes
[ ] Table captions describe table purpose
[ ] Tables are used for tabular data, not layout

Mobile and Responsive Design

Touch and Interaction

[ ] Touch targets are at least 44x44 pixels
[ ] Interactive elements have adequate spacing
[ ] Orientation lock is not enforced
[ ] Content works in both portrait and landscape
[ ] Functionality doesn't depend on device motion

Responsive Behavior

[ ] Content reflows at 320px width without horizontal scrolling
[ ] Text can be zoomed to 200% without loss of content or function
[ ] Line height, spacing, and margins can be adjusted
[ ] Content remains accessible at all supported screen sizes

PDFs and Documents

PDF Accessibility

[ ] PDFs are tagged for accessibility
[ ] PDF reading order is logical
[ ] PDF form fields have labels
[ ] PDFs include document title and language
[ ] Alternative HTML versions are provided when possible

Testing Tools and Methods

While this checklist provides comprehensive coverage, remember that manual testing is essential. Automated tools catch only 30-40% of accessibility issues.

Recommended Testing Approach

Automated scanning: Run tools like axe DevTools, WAVE, or BrowseCheck
Keyboard testing: Navigate entire site using only keyboard
Screen reader testing: Test with NVDA (Windows) or VoiceOver (Mac)
Contrast checking: Verify all text and interactive elements
Zoom testing: Test at 200% zoom level
Mobile testing: Check on actual mobile devices

Prioritizing Remediation

Not all accessibility issues have equal impact. Prioritize fixes based on:

Severity: Does it completely block access or just cause inconvenience?
Reach: How many users are affected?
Frequency: How often is the component used?
Effort: How difficult is the fix to implement?

Critical issues blocking access should be addressed immediately, while minor improvements can be scheduled into regular development cycles.

Common Quick Wins

Some accessibility improvements provide significant impact with minimal effort:

Add alt text to images (often just missing, not wrong)
Fix form label associations
Ensure proper heading hierarchy
Increase color contrast in brand colors
Add skip navigation links
Fix keyboard focus indicators

These foundational fixes often resolve multiple WCAG success criteria at once and dramatically improve usability for people with disabilities.

Maintaining Compliance Over Time

AODA compliance isn't a one-time achievement. As your website evolves, new accessibility barriers can be introduced. To maintain compliance:

Train content creators on accessibility basics
Include accessibility in design reviews before development
Test new features for accessibility during development
Monitor production sites continuously for issues
Conduct regular audits annually or after major changes

Automated monitoring tools like BrowseCheck continuously scan your website, alerting you immediately when accessibility issues are detected. This proactive approach catches problems before they impact users and helps maintain ongoing AODA compliance.

Getting Started

If this checklist feels overwhelming, start small:

Run an automated scan to identify obvious issues
Test your homepage thoroughly using this checklist
Fix critical issues that completely block access
Expand to key user journeys (purchase flow, contact forms, registration)
Systematically address remaining pages and components

Accessibility is a journey, not a destination. Every improvement makes your website more usable for everyone, not just people with disabilities. Better accessibility correlates with improved SEO, enhanced mobile usability, and superior overall user experience.

Conclusion

This AODA website accessibility checklist provides a practical framework for assessing and achieving WCAG 2.0 Level AA compliance. While comprehensive, it's a starting point—your specific website may require additional considerations based on unique features and functionality.

The key to successful AODA compliance is integrating accessibility into your standard workflows rather than treating it as a separate concern. When accessibility becomes part of your design, development, and content creation processes, maintaining compliance becomes significantly easier.

Ready to start checking items off this list? Begin with an automated accessibility scan to identify low-hanging fruit, then systematically work through manual testing to ensure your website provides an accessible experience for all Ontario residents.