Ontario Human Rights Code and digital accessibility: What organizations in Ontario need to know

A practical, plain-language overview of digital accessibility obligations and expectations under Ontario’s human rights framework—and how they can impact your website, apps, documents, and customer/employee journeys

Who this is for: Organizations operating in Ontario—including employers, landlords/housing providers, service providers, membership organizations, and public-sector bodies—who publish content, run digital services, or provide digital customer/employee experiences.

Note: This page is informational and not legal advice. Human rights obligations are fact-specific and can depend on your organization, the context, and individual needs. For formal guidance, consult qualified legal or compliance professionals.

Ontario Human Rights Code at a glance

The Ontario Human Rights Code (the “Code”) is Ontario’s foundational human rights law. It protects people in key social areas—such as services, employment, housing, and contracts—from discrimination and harassment based on protected grounds, including disability. The Code is enforced through Ontario’s human rights system (including the Human Rights Tribunal of Ontario), and accessibility barriers—digital or otherwise—can lead to human-rights applications/complaints depending on the facts. From a digital accessibility perspective, the Code is most often engaged when a website, app, portal, online form, PDF, or other digital process creates barriers for people with disabilities.

When Code-related accessibility obligations apply

Services

If you provide services to the public (or a defined customer base) in Ontario, you have a duty to provide those services without discrimination based on disability. Digital channels that gate access—online applications, booking, account management, support, payments—are commonly in scope.

Employment

If you employ people in Ontario, the Code applies to hiring and recruitment, onboarding, training, workplace tools, performance processes, and return-to-work. Digital systems used for these activities (HR portals, applicant tracking systems, internal tools, e-learning, intranets) must not create disability-related barriers.

Housing

Housing providers and landlords must provide accommodation and access without discrimination. Digital rental applications, tenant portals, and required electronic notices or forms can engage Code obligations.

End-to-end journeys matter

Even if your main website looks accessible, barriers can exist in PDFs, embedded third-party tools, authentication flows, and support forms—anywhere a person must interact to get what they need.

What the Code typically requires in practice (digital accessibility)

1) Preventing disability-related barriers and discrimination

Digital barriers can lead to discrimination when they deny equal access or impose disadvantage on people with disabilities (including barriers that arise unintentionally through design choices). Examples include forms that can’t be completed with a keyboard, missing labels for screen readers, critical information conveyed only by color, inaccessible PDFs needed to apply for a job or service, or authentication methods that are not usable for some users.

2) The duty to accommodate (including in digital channels)

Organizations generally have a duty to accommodate disability-related needs in the areas the Code covers. In digital contexts, that may mean removing barriers in an online journey, providing an alternative accessible method to complete a task, offering content in accessible formats, or enabling assistive-technology compatibility—based on the individual’s needs and the context.

Examples of digital accommodation: providing an accessible alternative format for a form or PDF; offering assistance to complete an application (e.g., by phone or in person) when a digital barrier exists; ensuring CAPTCHAs/authentication methods have accessible alternatives; extending time limits where feasible; providing accessible customer support channels (not voice-only) and escalation paths when accessibility issues are reported.

3) Limits: undue hardship

The duty to accommodate is not unlimited. Under the Code, accommodation may be limited where it would cause undue hardship (commonly assessed using factors such as cost and health and safety). Undue hardship is generally considered a high threshold; whether it exists is context-specific and typically requires evidence—not assumptions.

What this means for your website and digital channels

The standard you’ll hear about (WCAG)

Common benchmark: WCAG 2.0 Level AA is widely used as the minimum acceptable baseline in Canada, but we recommend targeting the latest WCAG Level AA where possible.

Accessibility must be maintained: New content, new features, and vendor updates can introduce barriers if accessibility isn’t built into design, development, QA, and publishing workflows.

Shared components matter: Navigation, authentication, search, templates, and forms can create organization-wide issues if they are not accessible.

What content is typically in scope

Core public journeys: eligibility checks, applications, bookings, sign-up/sign-in, payments, account management, and cancellations.
Customer support and issue resolution: contact flows, complaint paths, chat, web forms, and knowledge-base content.
Documents and downloads: PDFs and forms people must read, understand, sign, or submit (including policies, notices, and contracts).
Employment-related digital systems: careers sites, online assessments, applicant tracking systems, onboarding portals, timekeeping, HR self-serve, and required training.
Third-party tools and embedded services: identity providers, chat widgets, scheduling tools, maps, payment providers, and any vendor platform you rely on. Using a third party doesn’t remove the need to ensure people with disabilities can access your service end-to-end.

Core accessibility themes to watch for

Perceivable: Provide text alternatives for non-text content; ensure sufficient color contrast; don’t convey meaning by color alone.
Operable: Everything works with a keyboard; focus is visible; users can pause/stop/move content where applicable.
Understandable: Clear labels and instructions; consistent navigation; helpful, specific error messages.
Robust: Use semantic structure so assistive technologies can interpret content reliably; ensure accessible name/role/value for interactive controls.

A practical way to get started

Identify high-impact journeys: List the pages, workflows, and documents people rely on to access your services, employment opportunities, or housing.
Assess current accessibility: Combine automated testing with manual checks (keyboard-only and screen reader testing) across key templates, forms, PDFs, and vendor tools.
Prioritize by human impact: Address navigation, forms, errors, contrast, document accessibility, and authentication barriers first—these often block access entirely.
Fix and validate: Remediate issues, then re-test and document outcomes so teams can ship changes with confidence.
Prevent regressions: Embed accessibility into procurement, design reviews, content publishing, development standards, and release QA.

How 4Point can help

Start with an accessibility audit. If you’re unsure where you stand against federal expectations and WCAG, 4Point can run a practical audit to establish a baseline, identify the highest‑risk barriers, and provide a prioritized remediation roadmap.

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

Next step: share your digital scope (sites/apps/documents and platforms), your target standard (e.g., WCAG 2.1 AA), and any upcoming procurement or reporting deadlines. We’ll confirm the audit approach and sample size (templates/journeys) and deliver a prioritized findings summary with recommended fixes.

Contact 4Point: Request an accessibility audit

Anchor 2