Accessibility Hub: AODA (Ontario)

Accessible Ontario – what AODA requires, who it applies to, and what it can mean for your website and digital content

AODA at a glance

The Accessibility for Ontarians with Disabilities Act (AODA) is Ontario legislation aimed at identifying, removing, and preventing barriers for individuals with disabilities. For websites and digital content, AODA requirements are primarily implemented through the Integrated Accessibility Standards Regulation (IASR), specifically the Information and Communications standard, which includes web accessibility requirements.

AODA is Ontario’s accessibility law that aims to identify, remove, and prevent barriers for individuals with disabilities.
For most organizations, web accessibility requirements are set out in the IASR (Information and Communications) standard.
Web accessibility expectations are typically met by conforming to WCAG 2.0 Level AA.
Accessibility extends beyond websites: documents, videos, and third-party tools can also create barriers.
Accessibility is ongoing—content changes and new features can introduce new issues over time.

Note: This content is provided for general information only and does not constitute legal advice. If you need a formal interpretation of requirements for your organization, consult qualified legal counsel and your compliance team.

When AODA applies

Public-facing digital experiences: If your site or digital content is used by people in Ontario, AODA-aligned accessibility is an expected standard and a practical requirement.
Organizations covered: AODA obligations apply to public sector, private, and non-profit organizations in Ontario with at least one employee.
Common web standard: AODA-related web accessibility requirements are typically met through conformance with WCAG 2.0 Level AA, unless otherwise required by applicable law or contract.

Does AODA apply to me?

If you are part of Ontario’s public sector (or a designated broader-public-sector organization), AODA requirements generally apply.
If you are a private business or non-profit that provides goods or services in Ontario, AODA requirements may apply depending on your organization and obligations.
If you are a private business or non-profit operating in Ontario with one or more employees, AODA requirements apply, with specific obligations varying based on your organization’s size and type.
If you use third-party tools (embedded forms, chat widgets, booking tools), accessibility still matters—either through vendor conformance or an accessible alternative.

If you’re unsure whether AODA applies to your organization, treat this page as a practical overview and confirm your specific obligations with qualified legal counsel.

AODA standards: what they cover

1) Customer Service Standard

Accessible service experience: Provide service in ways that respect dignity, independence, integration, and equal opportunity.

Communication supports: Be prepared to communicate in a way that accommodates different needs (for example, providing information in alternative formats when feasible).

Feedback: Ensure there is a way for people to provide accessibility feedback (and that requests are routed to the right team).

Training: People involved in customer interactions and content publishing should receive accessibility training appropriate to their role.

2) IASR (Integrated Accessibility Standards Regulation)

IASR contains multiple standards. For digital content, the most relevant is the Information and Communications standard (including web accessibility).

Information and Communications: Provide information in accessible formats and ensure websites, documents, and digital content meet accessibility requirements (including web accessibility).
Employment: Ensure accessible hiring, onboarding, and workplace practices (typically HR-led).
Transportation: Meet accessibility requirements if providing transportation services (generally not applicable to typical marketing sites).
Design of Public Spaces: Ensure physical spaces are accessible where applicable (not a web requirement).

What you may need to do

AODA includes multiple standards, but many organizations feel the impact most through how they communicate and provide services to the public. In practice, this often involves the following:

Make your website usable for everyone: Aim for WCAG 2.0 AA on key pages, navigation, forms, and core user journeys.
Provide accessible documents and media: Use accessible web pages; make PDFs accessible when they are used; add captions to videos and provide transcripts where appropriate.
Offer a way to ask for help or alternate formats: Ensure people can request information in an accessible format or with communication supports.
Have a feedback process: Provide a way for users to report accessibility barriers and ensure requests are handled in a timely way.
Train the right people: Staff who publish content, design experiences, build features, or support customers should understand their accessibility responsibilities.
Keep it from slipping over time: Accessibility needs ongoing checks as content changes, new features launch, or third-party tools are introduced.

Web accessibility under AODA -
practical requirements

In practice, AODA web accessibility expectations are commonly met by building and maintaining content to WCAG 2.0 Level AA. This section explains what that means for websites and digital content.

Target standard

Baseline: WCAG 2.0 AA for all new pages and significant updates. 4Point recommends aiming for WCAG 2.1 or higher to support better mobile accessibility and future-proofing.
Consistency: If a component or pattern is reused across the site, it must be accessible everywhere it appears.
Ongoing compliance: Maintain accessibility over time as content changes, new features are introduced, and third-party tools are added.

What’s in scope

Web pages: Navigation, content pages, landing pages, forms, and interactive widgets.

Non-HTML content: PDFs, slide decks, and downloadable resources; use accessible web pages where possible.

Media: Videos, audio clips, webinars, animations, and any embedded players.
Third-party tools: Embedded forms, chat widgets, maps, and other integrations (requires vendor checks and/or accessible alternatives).

Core WCAG themes to watch for:

Perceivable: Provide text alternatives for non-text content; ensure sufficient color contrast; do not rely on images alone to convey information.
Operable: Everything must work with a keyboard; focus must be visible; avoid time limits that can’t be adjusted.
Understandable: Clear labels and instructions; consistent navigation; predictable interactions; helpful error messages.
Robust: Use semantic markup so assistive technologies can interpret content reliably; avoid misusing ARIA.

Content author requirements

Headings and structure: Use headings in order (H1 → H2 → H3) and keep sections short and scannable.
Links: Use descriptive link text that explains the destination or action (avoid “click here” or raw URLs).
Images: Write alternative text that communicates purpose and meaning. Decorative images should have empty alt text.
Lists: Use real lists for list content (instead of manual line breaks or dashes).
Tables: Use tables only for data; include clear column/row headers and avoid merged cells when possible.
Documents: Default to HTML pages. If a PDF is required, ensure it is tagged, has a logical reading order, proper headings, and selectable text.
Video: Provide accurate captions. Where needed, provide transcripts and/or audio description for key visual information.

Testing and release expectations

Minimum manual checks: Keyboard-only pass and a quick screen reader smoke test on key templates/flows.
Automated checks: Run an automated scan and resolve high/critical issues before publishing.
Regression checks: Re-test affected templates/components when global navigation, styles, or component libraries change.
Document decisions: If something cannot be made fully accessible, document the reason, the impact, and the alternative provided (for example, an accessible version or an alternate way to complete the task). If you need help, contact our accessibility team.

How 4Point can help

If you’re unsure how AODA and WCAG apply to your organization or where to start, 4Point can help you assess your current state, prioritize fixes, and build a practical plan to improve accessibility over time.

Accessibility audit (recommended first step): 4Point will conduct a targeted review of key templates and user journeys across websites, apps, and documents. Deliverables typically include a prioritized issue backlog, severity ratings, and remediation guidance mapped to WCAG criteria.
Remediation planning and delivery: 4Point will provide hands-on support to resolve issues, validate improvements, and reduce regression risk through re-testing.
Conformance reporting and procurement support: 4Point will deliver conformance summaries, document exceptions, and define procurement-ready acceptance criteria for SOWs and delivery teams.
Accessible design and content support: 4Point will provide design reviews, accessible patterns, document/PDF guidance, and content authoring practices aligned to accessibility requirements.
Design system and development enablement: 4Point will develop accessible component libraries, standards, and QA workflows integrated into your SDLC.
Program support: 4Point will help define governance, roles, metrics, evidence artifacts, and repeatable processes for feedback and alternate-format requests.

Next step: Share what you’d like reviewed (for example, a set of pages, forms, documents, videos, or a key user journey) and the platforms involved. We’ll confirm the approach and provide a prioritized summary of findings with recommended fixes.

Reach out if you’d like help understanding how AODA/WCAG applies to your digital content, or if you’d like an accessibility assessment.

Contact 4Point: Request an accessibility audit

Anchor 2