Who must comply

As of January 1, 2021, the AODA requires you to make all public websites accessible if you are either:

The organization that controls the website (either directly or through a contractual relationship) must meet the accessibility requirements.

These requirements only apply to websites and web content published on a website after January 1, 2012.

Internal websites

You do not have to make your internal website (intranet or extranet) meet WCAG 2.0 levels A/AA.

However, if an individual asks you to make content available to them in an alternate accessible format (such as large print or braille), you must work with the individual to meet their needs.

Terms

Controlling a website

This means you either have direct control or control though a contractual relationship over the website’s:

  • appearance
  • functionality
  • content

Content

Content means any information that may be found on a web page or web application, including text, images, forms and sounds.

WCAG 2.0 Guidelines

WCAG 2.0 is an internationally accepted standard for web accessibility developed by the World Wide Web Consortium (W3C), an international team of experts.

Following these guidelines should make it easier for everyone to access your website and content.

Under each guideline, there are “success criteria” that describe specifically what must be achieved to meet the standard at each level of accessibility.

Levels of web accessibility

Each guideline has three levels of accessibility: A, AA and AAA.

How to comply

As outlined in the Information and Communications Standards (see sections 9 – 19) part of Ontario Regulation 191/11 under the AODA, your public website and web content posted after January 1, 2012, must meet the WCAG 2.0 Level AA success criteria, except for:

Make sure you know the success criteria your public website must meet for each level and guideline.

In most cases, you must meet the Level A criteria before you can meet the required Level AA criteria.

Level A

Guideline 1.1: Provide text alternatives for non-text content

Guideline 1.2: Provide alternatives for time-based media

Guideline 1.3: Adaptable content

Guideline 1.4: Distinguishable content

Guideline 2.1: Keyboard accessible

Guideline 2.2: Provide users enough time to read and use content

Guideline 2.3: Don’t design content in a way that is known to cause seizures

Guideline 2.4: Navigable content

Guideline 3.1: Readable text content

Guideline 3.2: Predictable web pages

Guideline 3.3: Input assistance

Guideline 4.1: Compatible

Level AA

Guideline 1.4: Distinguishable content

Guideline 2.4: Navigable content

Guideline 3.1: Readable text content

Guideline 3.2: Predictable web pages

Guideline 3.3: Input assistance

Read Understanding WCAG 2.0 to learn more about how to meet the requirements.

If you can’t comply

Sometimes it may not be possible or feasible to meet the WCAG 2.0 requirements. For example, you may have used software and other tools that predate WCAG 2.0 to develop your website.

You may be able to update or repair the products you used to support accessibility. If this is not possible or feasible, make sure you use software that supports accessibility the next time you refresh your site.

It may not be possible to post some content in a way that complies with WCAG 2.0. For example, it may be impossible to make some online maps and complex diagrams accessible to people with visual disabilities. In such cases, you may still post the content, but if someone asks for it in an accessible format, and you cannot provide this, you must:

  • explain why the information or communication is unconvertible
  • provide a summary of the unconvertible content

Section 14 of O. Reg. 191/11 under the AODA outlines certain situations where after making best efforts to make webpages meet the WCAG 2.0 Levels A/AA, the accessibility requirements may not apply.

Learn what to do when, despite best efforts, you cannot make your website accessible.

Tips for testing websites for accessibility

There are a number of ways to know if your website is accessible:

1. Automatic assessment and assistive technology

Do a final evaluation of your site using an automatic assessment to flag any issues that may not have been resolved. For example, you can review your site using assistive technology such as a screen reader to make sure the design and technical aspects of the site are accessible.

2. User testing and feedback

If possible, ask people with disabilities to test your website before you launch. Get feedback from customers and other site users to find out if there are any improvements needed.

3. Review key milestones and changes

Keep a record of the accessibility issues that have been resolved or ask your web developer to maintain such a record. This will show you the completed work and the new level of accessibility. It will also be helpful if your organization is asked to show that your website is WCAG 2.0 Level AA compliant.

Tips for working with web developers

If you don’t manage your website or don’t have web development experience, the following steps may help you work with a web developer to make your website more accessible.

Determine your web developer’s level of expertise

Make sure your in-house developer or the developer you plan to hire has the expertise needed to make your website more accessible.

Here are some questions you may want to ask:

  • Are you familiar with WCAG 2.0 Level A and AA criteria?
  • Have you developed/refreshed an accessible website (WCAG 2.0, Level A or higher)? Do you have links or references for these sites?
  • Do you code manually or with the assistance of a program? If you use a program, does it support accessibility?
  • Do you test the website for accessibility using automated and manual assessments and assistive technology?

Communicate your expectations

Think about accessibility from the start. When working on the website design, let your web developer know your expectations for:

  • making the website and web content accessible (WCAG 2.0)
  • the level of accessibility (Level A or AA)
  • timelines for completing the website

Ask for a project plan

Your developer should provide you with a project plan for completing the website. The plan should include the following steps:

  • identifies techniques or software used: developers should tell you if they are using accessible coding techniques or software that supports accessible websites
  • outlines how your website will be tested: the plan should include automated and manual tests, as well as testing using assistive technology, such as screen readers
  • identifies how the site will be maintained: this could include training you or your staff on how to make changes to the website, how to create accessible content, or an agreement to maintain the website
  • outlines key deliverables and timelines: whether the developer is fixing accessibility issues or creating an entirely new website, they should be able to clearly tell you when and how the project will be delivered

Disclaimer

The aim and purpose of this webpage is to help individuals and organizations with information related to the Accessibility for Ontarians with Disabilities Act, 2005 and its associated Integrated Accessibility Standards regulation OReg 191/11. While we aim to provide relevant and timely information, no guarantee can be given as to the accuracy or completeness of any information provided. This guidance is not intended to nor does it provide legal advice and should not be relied upon or treated as legal advice. Those seeking legal advice should consult with a qualified legal professional.

In case of discrepancy between website content and relevant Ontario legislation and regulations, the official version of Ontario Acts and Regulations as published by the Queen's Printer for Ontario will prevail.

The Ministry for Seniors and Accessibility and the Government of Ontario do not endorse or recommend any accessibility consultant(s), their advice, opinions or recommendations.