Ontario IASR: Web accessibility requirements explained

A plain-language overview of what the Integrated Accessibility Standards Regulation means for websites, digital content, and your organization

Who this is for: Organizations that operate in Ontario (or serve customers in Ontario) and want to understand their obligations for accessible websites and digital content.

Note: This page is informational and not legal advice. Requirements can vary by organization type and circumstances; for formal guidance, consult qualified legal or compliance professionals.

IASR at a glance

The Integrated Accessibility Standards Regulation (IASR) is a regulation under Ontario’s Accessibility for Ontarians with Disabilities Act (AODA). It sets accessibility requirements in several areas. For many organizations, its most visible impact is on web accessibility—how websites, documents, and digital communications are designed and function for people with disabilities.

When IASR applies

IASR applies to many organizations in Ontario—including public sector, and many private and non-profit organizations—with requirements that vary based on organization type and size.
Even when legal applicability is unclear, meeting modern web accessibility expectations helps reduce barriers for customers and supports inclusive service delivery.
For websites, IASR requirements are commonly aligned with the Web Content Accessibility Guidelines (WCAG) at a specified conformance level (generally WCAG 2.1 Level AA).

Who must comply and when

In Ontario, web accessibility requirements under IASR most commonly apply based on your organization type and (for many private/non-profit organizations) your employee count. Because applicability can depend on how your organization is structured and regulated, confirm with your legal/compliance team if you’re unsure.

Public sector organizations: many designated public sector bodies (including the Government of Ontario) have web accessibility requirements that apply to their public web content, with compliance timelines set out in the regulation.
Private and non-profit organizations: most organizations with 50+ employees have web accessibility obligations for public web content; requirements and timelines can differ for smaller organizations.
What standard is typically referenced: web requirements are commonly tied to WCAG 2.0 Level AA for public-facing web pages and web content.
Timelines and exceptions: compliance dates and any exceptions/limitations depend on your organization category and the type of content (for example, public web pages vs. some kinds of archived content or third-party content you don’t control).

If your organization publishes content to the public in Ontario, the safest approach is to assume that key customer journeys, core pages, and downloadable content should meet your target WCAG level, and then validate scope and timelines with the appropriate stakeholders.

IASR standards - what they cover

Information and Communications

The Information and Communications requirements are the most relevant for websites. They focus on making digital information and communications accessible—web pages, documents (like PDFs), and media (like video).

Web pages: Your public website, web pages, and web-based applications should be designed and maintained to meet the applicable WCAG requirements.
Documents and downloads: If you publish PDFs or other downloadable files, they should be accessible—or you should provide an accessible alternative (often an HTML page).
Video and audio: You must provide captions for all pre-recorded video with audio, and transcripts for audio-only content. Under current IASR requirements, live captions and audio descriptions are not mandatory but are recommended as best practices.
Accessible formats on request: You must ensure there is a clear way for customers to request accessible formats or communication supports, and a process to respond.

Accessibility feedback process (minimum viable): Publish a clear process for reporting barriers (e.g., email or form), acknowledge requests promptly, track issues to resolution, and maintain a defined workflow for producing alternate formats (including roles and expected turnaround times).

Employment

These requirements relate to accessible hiring and employment practices (typically owned by HR) and are generally out of scope for day-to-day marketing site publishing, but may affect how we support candidates and employees through web experiences.

Transportation

These requirements apply to transportation providers and are typically not relevant to standard marketing websites unless transportation services are offered.

Design of Public Spaces

These requirements relate to the physical built environment and are not web-specific, but may apply to facility information published online.

What IASR means for your website

The accessibility standard you’ll hear about (WCAG)

Common target: Although many organizations aim for WCAG 2.1 Level AA for public web content, the legal requirement is WCAG 2.0 AA.
It’s not only “new builds”: Accessibility needs to be maintained as content changes and new features are added.
Shared components matter: Navigation, forms, and reusable components can create site-wide barriers if they aren’t accessible.

What content is typically in scope

Public website – All public web content: home, key marketing pages, contact flows, forms, and any task a customer needs to complete.
Careers and candidate experiences: job postings, application flows, and any pre-hire assessments or portals you direct applicants to use.
Downloads: PDFs, brochures, and any resources you ask customers (or applicants) to read or fill out.
Media: videos, podcasts, webinars, and embedded players.
Third-party tools: booking widgets, chat tools, forms, maps, and other embedded services.
Intranet and employee-facing tools (when in scope): internal pages and workflows that employees need to do their jobs (especially HR, IT, and policy content).

Scope tip: For public content you control, the requirements are clear and straightforward. For third-party tools, set accessibility requirements in procurement and validate through testing. For internal systems, confirm whether they’re in scope and how risk is addressed.

Core WCAG themes to watch for

Perceivable: Provide text alternatives for non-text content; ensure sufficient color contrast; don’t hide information in images alone.
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.

What an accessible website usually includes

Clear structure: Pages use headings and landmarks so users can navigate efficiently with assistive technology.
Keyboard access: All functionality works without a mouse (including menus, pop-ups, and forms).
Readable visuals: Good color contrast and text that can be resized without breaking layouts.
Text alternatives: Images have appropriate alternative text; icons aren’t the only way information is conveyed.
Accessible forms: Labels, instructions, and error messages are clear and programmatically associated to fields.
Accessible documents: PDFs and downloads are tagged and readable—or replaced with accessible HTML content.
Accessible media: Videos include captions (and transcripts/audio descriptions where needed).

Common pitfalls
(what often causes non-compliance)

PDF-first publishing: posting scanned or untagged PDFs without an accessible HTML alternative.

Forms that only “look” labeled: missing programmatic labels, unclear instructions, or error messages that aren’t connected to fields.

Keyboard traps and focus issues: menus, modals, carousels, and dialogs that can’t be used fully with a keyboard or have invisible focus.

Low colour contrast (and colour-only meaning): text, buttons, charts, and status indicators that rely on colour alone or fail contrast requirements.

Missing text alternatives: decorative vs. informative images not handled correctly; icon buttons without accessible names.

Headings and structure issues: pages that use visual styling instead of true headings, causing poor screen reader navigation.

Third-party widgets: embedded tools (maps, chat, booking, forms) that introduce barriers and aren’t covered by procurement requirements.

No ongoing QA: accessibility is treated as a one-time fix, rather than integrated into releases and content updates.

A practical way to get started

Assess your current site: Identify barriers across templates, key journeys (forms, contact, conversions), and downloadable content.
Prioritize fixes: Address high-impact issues first (navigation, forms, contrast, keyboard access, errors).
Remediate and validate: Fix issues and confirm with a mix of automated checks and manual testing (keyboard and screen reader).
Prevent regressions: Build accessibility into your content process, design system, and release checklist.
Monitor over time: Re-test periodically and after major content or feature changes.

Start with an accessibility audit. If you’re unsure where you stand against Ontario’s IASR (AODA) web accessibility requirements, 4Point can run a practical audit to establish a baseline, identify the highest-risk barriers, and give you a prioritized remediation roadmap aligned to the WCAG requirements that typically apply (commonly WCAG 2.0 Level AA, with many organizations targeting WCAG 2.1 Level AA as a forward-looking standard).

Scoping session: Confirm what’s in scope (e.g., public web pages, key customer journeys, forms, and high-priority downloads like PDFs), the sample size to be reviewed, and the standard(s) to assess against for IASR (typically WCAG 2.0 AA, with an option to assess against WCAG 2.1 AA).
Forms accessibility audit: Review an agreed number of forms and form-related journeys (validation, errors, confirmations) and document accessibility gaps.
Conformance report and prioritization: Provide conformance findings, severity ratings, and a recommended fix order focused on high-impact IASR risk areas (keyboard access, labels, errors, contrast, headings/structure, and document accessibility).
Recommendations and remediation plan: Share recommendations for addressing identified gaps and provide a statement of work for remediation of the audited items (remediation is not included in the audit engagement).

Next step: request an audit by sharing your IASR-relevant digital scope (public site areas, key journeys/forms, and priority documents/downloads), your target standard (WCAG 2.0 AA and/or WCAG 2.1 AA), and any timelines or risk drivers (e.g., compliance deadlines, customer complaints, or procurement requirements). 4Point will confirm the audit approach and sample size, then deliver a prioritized findings summary with recommended fixes.

Contact 4Point: Request an accessibility audit

Anchor 2