The internet is for everyone.

Internet access is shaping the future. It’s a requirement for education, in the workplace, for many forms of entertainment, and it’s a massive part of the economy. Yet many people cannot use the internet—not because they don’t have web access, but because websites aren’t designed to be accessible. From vision and hearing impairment to paralysis, epilepsy, and other neurological differences, roughly 22% of Canadians have at least one disability. Web accessibility is no longer optional; it’s the path to the future.

“It’s easy to say you’re customer-focused, but incorporating accessibility measures into your website is a perfect opportunity to show it. Any time we stop to think about our customers and their needs, it helps us serve them better and build a stronger business.”​​

Caroline Topolovec

What are the Web Content Accessibility Guidelines (WCAG)?

The World Wide Web Consortium (W3C) is an international community that develops open standards to ensure the long-term growth of the Web. As part of its mission, the W3C Web Accessibility Initiative (WAI) publishes and maintains a list of guidelines for keeping the internet accessible for people with disabilities. The Web Content Accessibility Guidelines (WCAG) are the international standard for web accessibility.

WCAG covers a wide range of recommendations that make web content more accessible for people with disabilities. The limitations addressed include blindness and low vision, deafness and hearing loss, limited movement, speech disabilities, photosensitivity, and some learning disabilities and cognitive limitations. It doesn’t cover every possible disability but seeks to address common issues on desktops, laptops, tablets, and mobile devices.

The guidelines in WCAG fall into three different levels: A, AA, and AAA. Level A is the most basic and the other two build upon it. A higher level of conformance indicates a more accessible website.

What is the Accessibility for Ontarians with Disabilities Act (AODA)?

The Accessibility for Ontarians with Disabilities Act (AODA) mandates that Ontario must be accessible to persons with disabilities “with respect to goods, services, facilities, accommodation, employment, buildings, structures and premises on or before January 1, 2025.” Included in that is the requirement that all websites belonging to “a private or non-profit organization with 50+ employees; or

a public sector organization,” must conform to WCAG 2.0.

As of 2018, all Ontario-based organizations with more than 20 employees are required to file an accessibility compliance report. Organizations of all sizes must make their public information accessible upon request.

What are the compliance deadlines under AODA?

As of January 1, 2014, all new public websites, significantly refreshed websites, and any web content that had been posted since January 1, 2012, needed to meet WCAG 2.0 Level A. A “significant refresh” is defined as “changing more than 50% of the content, design or technology of the website.”

On January 1, 2021, that same content must conform to a slightly modified version of WCAG 2.0 Level AA. According to AODA, you don’t need to meet the requirements for live captions and pre-recorded audio descriptions (criteria 1.2.4 and 1.2.5). Focus on the other criteria.

What does it mean to “conform” to WCAG 2.0?

There are five criteria needed to conform to WCAG.

1.    LEVEL

The webpage must satisfy all of the requirements for (at least) one of the three conformance levels. Always aim to meet as many criteria as possible, even if you can’t meet all the requirements for the next level.


If part of a webpage doesn’t conform, the page doesn’t conform. You can’t cherry-pick the accessible components of a page.


If a webpage is part of a series of pages needed to accomplish something (e.g., purchase a product or register for an event), all webpages in the process must conform.


Many of the requirements rely on accessibility through assistive technology or accessibility features in mainstream devices and applications. Content must solely rely on these to satisfy the criteria. Accessibility must be standardized.


You can use non-accessibility-supported technology, but you must also present the information in an accessibility-supported way. The non-supported material also cannot interfere with a user’s interaction with the webpage.

Compliance Checklists

The official WCAG 2.0/2.1 compliance guide is available online. You can use filters to hide any unnecessary success criteria for a specific level. While the WCAG guide is the most comprehensive, it’s also a technical and lengthy read. To simplify the process, we’ve compiled a straightforward AODA compliance checklist.

The WCAG 2.0 success criteria fall under four principals to ensure web content is:

  1. Perceivable — “Information and user interface components must be presentable to users in ways they can perceive.”
  2. Operable — “User interface components and navigation must be operable.”
  3. Understandable — “Information and the operation of user interface must be understandable.”
  4. Robust — “Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.”

Each principal is broken down into guidelines. Each guideline contains one or more actionable success criteria.

WCAG 2.0 Level A Success Criteria

1.1.1 Non-text content
  • All user-facing non-text content has an equivalent text alternative.
  • All exceptions meet the following requirements:
    • Input & Controls: Non-text controls or objects that accept user input must have a name that describes its purpose.
    • Time-Based Media: Time-based media requires descriptive identification of the non-text content (at least).
    • Test: You only need descriptive identification for any test/exercise non-text content that would be invalid if presented as text.
    • Sensory: Non-text content meant to create a specific sensory experience requires descriptive identification.
    • CAPTCHA: Any non-text content used to distinguish between human users and computers must have text alternatives identifying and describing the purpose of the material. You must provide at least one alternative sensory perception CAPTCHA form.
    • Decoration, Formatting, Invisible: Content that is solely decorative must be able to be ignored by assistive technology.
1.2.1 Audio-only and video-only (Pre-recorded)
  • All pre-recorded audio-only content includes a transcript.
  • All pre-recorded video-only content includes a transcript or audio description of relevant content unless the video is decorative.
1.2.2 Captions (Pre-recorded)
  • All pre-recorded video includes synchronized captions.
1.2.3 Audio Description or Media Alternative (Pre-recorded)
  • Provide either a transcript or audio description for all pre-recorded videos that contain relevant content not presented in the audio.
1.3.1 Info and relationships
  • Semantic markup is used appropriately to designate different text styles, such as headings, lists, and emphasis.
  • Present tabular data in tables. Data cells are associated with headers. Data table captions, if present, are associated with data tables.
  • Form fields are labelled using text. Group related form elements with fieldset/legend. You may use ARIA labelling when standard HTML is insufficient.
1.3.2 Meaningful sequence
  • The page has a logical and intuitive reading and navigation order.
1.3.3 Sensory characteristics
  • Instructions do not depend on visual cues.
  • Instructions do not depend on auditory cues.
1.4.1 Use of colour
  • No instances where colour alone is used to convey content or distinguish visual elements.
  • Links are not only distinguishable from the surrounding text because of colour—unless the contrast ratio is at least 3:1 and an additional distinguishing characteristic appears upon hovering and receiving focus.
1.4.2 Audio control
  • All audio that plays automatically for more than 3 seconds includes a way to stop, pause, mute, or adjust the volume.
2.1.1 Keyboard
  • Page functionality is accessible by keyboard except in cases where there is no known way to do so (e.g., freehand drawing).
  • Any page-specific shortcut keys do not conflict with existing browser and screen-reader shortcuts.
2.1.2 No keyboard trap
  • No page element locks or traps the keyboard focus (i.e., a user can navigate all page elements using only a keyboard).
2.2.1 Timing adjustable
  • Any time-limited page or item also includes an option to turn off, adjust, or extend the limit. Exceptions include real-time events with required time limits or if the limit exceeds 20 hours.
2.2.2 Pause, stop, hide
  • Content that automatically moves, blinks, or scrolls for longer than 5 seconds can be paused, stopped, or hidden.
  • Users can pause, stop, or hide content that automatically updates or they can control such updates manually.
2.3.1 Three flashes or below threshold
  • Nothing flashes more than three times per second.
2.4.1 Bypass blocks
  • Users can skip blocks of content repeated across multiple pages (such as navigation bars).
2.4.2 Page titled
  • Each web page has an informative and descriptive title.
2.4.3 Focus order
  • You present all navigable content logically and intuitively.
2.4.4 Link purpose (in context)
  • It is easy to determine the use of all links and associated buttons by reading the link text and its context.
  • Distinguishing any links using the same text but pointing to different locations is easy.
3.1.1 Language of page
  • All pages have a defined HTML lang attribute (e.g., <html lang=”en”>).
3.2.1 On focus
  • Focusing on a page element does not cause any substantial changes to the page that could cause disorientation or confusion.
3.2.2 On input
  • Inputting information or interacting with an interface does not cause any substantial changes to the page that could cause disorientation or confusion unless a clear warning is present.
3.3.1 Error identification
  • If a form element requires a specific length, format, or value, you provide all necessary details in the element’s label.
  • Errors resulting from invalid inputs are clear, intuitive, and accessible. A user can fix the error and resubmit the form.
3.3.2 Labels or instructions
  • All interactive elements include sufficient labels, cues, and instructions.
4.1.1 Parsing
4.1.2 Name, role, value
  • Appropriate markup is used, including using forms, form labels, frame titles, and following HTML/XHTML specifications.
  • Where HTML is insufficient, ARIA is used appropriately to enhance accessibility.

WCAG 2.0 Level AA Success Criteria

All Level A success criteria
  • You’ve met all Level A success criteria.
1.4.3 Contrast (Minimum)
  • You use a contrast ratio of 4.5:1 or better for all text and images of text.
  • You use a contrast ratio of 3:1, or better for all large text (over 18 pt if regular or 14 pt if bold).
1.4.4 Resize text
  • Zooming to 200% maintains the readability and functionality of the page.
1.4.5 Images of text
  • Wherever technology permits, text is used instead of images of text.
  • Images of text that are considered customizable (a user can adjust the image) or essential (the presentation of the text is a necessary part of the information) are exempt. Any text that is part of a brand name or logo is essential.
2.4.5 Multiple ways
  • There is more than one way for users to find other pages on a multipage site (e.g., a search mechanism, links between pages, table of contents, providing a sitemap).
2.4.6 Headings and labels
  • You use only informative headings and labels.
2.4.7 Focus visible
  • The keyboard focus is visually apparent.
3.1.2 Language of parts
  • You identify any content in a language other than the default language using the lang attribute.
3.2.4 Consistent identification
  • You consistently identify components with the same functionality within a set of webpages (e.g., navigation links don’t change order).
3.3.3 Error suggestion
  • You provide suggestions for correcting improper or incomplete input in a timely and accessible manner.
3.3.4 Error prevention (legal, financial, data)
  • Any legal, financial, or test data that can be altered or changed by a user also allows for such changes to be reversed, verified, or confirmed.

WCAG 2.0 or 2.1?

In searching for the WCAG guidelines, you’ll find that WCAG 2.0 is already outdated. In 2018, WCAG 2.1 replaced it—making it obsolete before the final AODA deadline. Additional changes will likely come in the next few years. To meet the AODA requirements, you still only need to meet the requirements for WCAG 2.0, but these are the minimum requirements. WCAG 2.1 represents the best practices for web accessibility and is a better standard. Remember: The international standard for web accessibility is the most current version of WCAG. Keep track of updates and stay current.

“There are some things we should do not just because we’re required to, but because it’s the right thing to do. Accessibility considerations are ultimately human rights considerations. If you believe in an equal access world with fewer barriers, this is one small way you can help create it.”​

Graeme Barlow

WCAG 2.1 is backwards-compatible with version 2.0. It includes all of the same success criteria for each level, plus a few new ones:

WCAG 2.1 Level A New Success Criteria

2.1.4 Character Key Shortcuts
  • Any keyboard shortcuts using only letter, punctuation, number, or symbol characters have at least one of the following:
    • A mechanism to deactivate the shortcut.
    • A mechanism to switch the shortcut to include at least one non-printable characters (e.g., Ctrl, Alt).
    • A mechanism that ensures the shortcut is only active while the user interface component for which it is used has focus.
2.5.1 Pointer Gestures
  • Any function using multipoint or path-based gestures works with a single pointer without a path-based gesture, unless such a gesture is essential (e.g., freehand drawing).
2.5.2 Pointer Cancellation
  • Any function using a single pointer abides by at least one of the following:
    • The down-event (i.e., touchstart or mousedown) doesn’t execute any part of the function.
    • Function completion occurs on the up-event, and there’s a way to cancel the function before or after completion.
    • The up-event reverses any down-event outcome.
    • Using the down-event to complete the function is essential (e.g., functions that emulate a keyboard/keypad keypress).
2.5.3 Label in Name
  • User interface controls have visual labels and programmatic names (i.e., accessible names) that match.
2.5.4 Motion Actuation
  • Any function operated by device or user motion also works via user interface controls
  • Users can deactivate responses to any such motion, except when:
    • The motion works through an accessibility-supported interface.
    • The motion is essential to the function.

WCAG 2.1 Level AA New Success Criteria

1.3.4 Orientation
  • The view/operation is not restricted to a single display orientation unless it is essential (e.g., a bank cheque, a piano application, projector slides, or some VR content).
1.3.5 Identify Input Purpose
  • Each input field that collects user information can be programmatically determined when:
1.4.10 Reflow
  • If a user scales the browser zoom to 400%, the content reflows into a single column so that they needn’t scroll in more than one direction, except for content which requires 2D layout for usage or meaning (e.g., images, maps, diagrams, video, games, presentations, data tables, and interfaces where it is necessary to keep toolbars in view while manipulating content)
1.4.11 Non-Text Contrast
  • The following have a visual presentation contrast ration of 3:1 or greater for adjacent colours:
    • User interface components, except when inactive or if the user sets appearance.
    • Any parts of graphics that are necessary to content understanding, except when a specific presentation is essential to the information conveyed.
1.4.12 Text Spacing
  • Users can change the following text style properties without losing content or functionality:
    • Line height (line spacing) to at least 1.5 times the font size;
    • Spacing following paragraphs to at least 2 times the font size;
    • Letter spacing (tracking) to at least 0.12 times the font size;
    • Word spacing to at least 0.16 times the font size.

Note: Human languages and scripts that don’t use one or more of the above properties can conform by using only the properties used.

1.4.13 Content on Hover or Focus
  • Any cases where receiving pointer hover or keyboard focus reveals additional content (e.g., custom tooltips, sub-menus, and other nonmodal popups), and hidden upon loss of focus, must:
    • Include a way to dismiss the additional content without moving focus, unless such content communicates an input error or doesn’t obscure/replace other content.
    • Allow the pointer to move over the new content without that content disappearing.
    • Keep the content visible until the user removes the focus trigger, the user dismisses it, or the information is no longer valid.
4.1.3 Status Messages
  • Any content changes that don’t shift the focus are presented to the user by assistive technologies without unnecessarily interrupting their work (e.g., when a user presses an “Add to Shopping Cart” button, a section of content near the Shopping Cart icon adds the text “5 items”. A screen reader announces “Five items” or “Shopping cart, five items”).

What are the risks of non-compliance?

To prevent companies from choosing to pay a “tax” to keep their websites inaccessible, the Ontario government is imposing severe fines for non-compliance. Failure to comply with the AODA web accessibility requirements can result in penalties of $50,000 per day or part day for directors and officers and up to $100,000 per day or part day for the corporation. See AODA Part X, section 37, for more details.

If your company fails to meet the requirements for a full year, it could incur $36.5M in fines. An individual or director could incur up to $18.25M for the same timeframe.

In addition to the legal and financial ramifications, public opinion is shifting towards inclusivity. The future reputation of your company depends on your willingness to embrace these changes and adapt going forward.

What if I have content that can’t comply with WCAG 2.0?

Compliance is all-or-nothing for each page—and a website as a whole. However, the Ontario government (and WCAG) recognize that some things are out of your control — like third-part apps.

According to the Ontario government website, you may use content that is not WCAG 2.0-compliant, but you must provide it in an accessible format upon request.

“In the future, providing accessible services will be a given, not a nice-to-have. Acting proactively will go a long way to show you believe in the principles of universal access.”​

Vicki Iverson

How can I verify website compliance?

There are a few ways to check if your website is WCAG 2.0 Level A or AA compliant.


Ask people with disabilities to test your new or refurbished website before it launches. Get feedback from customers and other users and implement any necessary changes.


Track accessibility issues and repairs. Such a record is useful for demonstrating progress, areas of need, and is helpful if your organization is asked to show that your website is WCAG 2.0 compliant.


Online tools like AChecker can help identify accessibility issues. Always have a person review the site as well; these tools aren’t a guarantee.


AODA experts will perform an accessibility audit to ensure WCAG 2.0 AA compliance. They will provide details on all issues and recommendations on how to fix them.

Summary: Key Takeaways

We’ve covered lots of technical information, and you will likely need to refer back to this resource as you move towards improved web accessibility. While everything covered is vital, we’ve summarized the key points below:

  • WCAG is the list of guidelines used as the international standard for web accessibility. AODA uses these guidelines to determine the minimum acceptable requirements in Ontario.
  • By January 1, 2021, all public websites and web content must conform to WCAG 2.0 Level AA (with two exceptions).
  • Try to keep up-to-date with the most current version of WCAG, even if it’s not a legal requirement.
  • For a website to conform to WCAG 2.0:
  • You must meet all success criteria for a specific level;
  • All content on the page must comply;
  • All additional pages in a process must conform;
  • All content must be accessible using standard practices;
  • Nothing on the webpage can interfere with the perception of or interaction with the webpage.
  • The goal of WCAG 2.0 is to ensure that all web content is perceivable, operable, understandable, and robust for all users. The best way to ensure that is to work through the checklists provided.
  • There are massive fines for failing to conform to the AODA requirements—up to $36.5M per year.
  • While the Ontario government acknowledges that not all content can be made to be accessible, such exceptions will not last forever. Start working on it now.
  • There are four main ways to confirm that your website conforms:
  • User testing & feedback
  • Review key milestones & changes
  • Use an online accessibility checker
  • Complete an accessibility audit

While the January 1, 2021, AODA requirements may seem daunting at first, everything is manageable if you get started now. Accessibility shouldn’t be an afterthought—you should incorporate it into everything you do. Make the internet more accessible for everyone by following our handy checklist. Share your progress and any tips you have for other companies making the move toward accessibility.

Leave a Reply

Your email address will not be published. Required fields are marked *