Ir al contenido principal
Accessibility

AODA Website Accessibility: A Practical Guide

AIOCANA Team6 min read
aodawcagaccessibility
WCAG 2.2 accessibility audit results showing AODA compliance for an Ontario business website

The Accessibility for Ontarians with Disabilities Act (AODA) requires that businesses make their websites accessible to people with disabilities. As of January 2021, all organizations with 50 or more employees must meet WCAG 2.0 Level AA standards, and the Accessible Canada Act (ACA) is extending similar requirements federally. Here's a practical guide to making your website accessible.

Understanding AODA and Web Accessibility

AODA's Integrated Accessibility Standards Regulation (IASR) includes requirements for information and communication, which covers websites and web content. The standard references the Web Content Accessibility Guidelines (WCAG), an internationally recognized set of guidelines for web accessibility.

WCAG 2.2 Level AA is the current recommended standard and covers four key principles — content must be Perceivable, Operable, Understandable, and Robust (POUR).

Common Accessibility Issues

Many business websites have accessibility barriers that can be fixed with straightforward changes:

Images Without Alt Text

Every meaningful image on your website needs descriptive alternative text. Screen readers use alt text to describe images to visually impaired users. Decorative images should have empty alt attributes (alt="") to be ignored by assistive technology.

Poor Color Contrast

Text must have sufficient contrast against its background. WCAG 2.2 AA requires a minimum contrast ratio of 4.5:1 for normal text and 3:1 for large text. Many websites fail this requirement with light gray text on white backgrounds.

Missing Keyboard Navigation

All interactive elements — links, buttons, forms, menus — must be fully operable using only a keyboard. Users who cannot use a mouse rely on keyboard navigation (Tab, Enter, Space, arrow keys). Focus indicators should be clearly visible.

Inaccessible Forms

Form fields need associated labels that programmatically connect the label text to the input field. Error messages should be clear, specific, and announced to screen readers. Required fields should be clearly indicated.

Missing Document Structure

Proper heading hierarchy (H1 → H2 → H3) helps screen reader users navigate page content. Don't skip heading levels or use headings purely for visual styling.

Step-by-Step Accessibility Improvements

  1. Run an automated audit — Use tools like axe DevTools, WAVE, or Lighthouse to identify common issues. Automated tools catch roughly 30–40% of accessibility problems
  2. Fix critical issues first — Address missing alt text, form labels, and keyboard traps before moving to more nuanced issues
  3. Test with keyboard only — Navigate your entire website using only the Tab, Enter, and arrow keys. Can you reach everything? Can you see where focus is?
  4. Check color contrast — Use a contrast checker tool to verify all text meets the 4.5:1 ratio requirement
  5. Test with a screen reader — Try navigating your website with VoiceOver (Mac), NVDA (Windows), or TalkBack (Android) to understand the experience for visually impaired users
  6. Review multimedia — Ensure videos have captions and provide transcripts for audio content
  7. Check responsive behavior — Content should remain accessible when zoomed to 200% and on mobile devices
  8. Document your efforts — Maintain an accessibility statement on your website describing your commitment and providing contact information for accessibility concerns

WCAG 2.2 New Success Criteria

WCAG 2.2 introduced several new criteria relevant to business websites:

  • Focus Not Obscured (2.4.11) — When an element receives keyboard focus, it should not be entirely hidden by other content like sticky headers
  • Target Size Minimum (2.5.8) — Interactive targets should be at least 24×24 CSS pixels to accommodate users with motor impairments
  • Accessible Authentication (3.3.8) — Authentication processes should not rely on cognitive function tests like puzzles
  • Redundant Entry (3.3.7) — Don't ask users to re-enter information they've already provided in the same process

Building Accessibility Into Your Process

Accessibility is most effective when built into your development process from the start, rather than retrofitted afterward. When choosing a website builder or platform, look for built-in accessibility features, semantic HTML output, and ARIA support as standard features.

← Back to Resources