The AODA’s Information and Communications Standards and the Information and Communication Standard under the Accessibility for Manitobans Act (AMA) both require organizations to make their information and communication accessible to people with disabilities. While the two standards share a lot of the same processes and practices for ensuring accessibility, there are some key differences. I took the time to outline the exceptions in AODA and what AMA adds to the requirements for companies who have employees in both provinces.
Web Accessibility Laws in Ontario and Manitoba
Both the AODA’s Information and Communications Standards and the Accessible Information and Communication Standard of the AMA require web accessibility. Both laws make it clear that organizations need to follow the Web Content Accessibility Guidelines (WCAG). In Ontario, only public-sector organizations and larger private-sector companies (those with 50 or more employees) need to comply. In Manitoba, however, all organizations must make their websites accessible.
Ontario organizations only need to comply with version 2.0 of WCAG.
There are two (2) WCAG standards in Version 2.0 that organizations do not need to follow: Live captions and Pre-recorded Audio Descriptions.
Exceptions under AODA
What they are | The exception | Why the exception exists | Important note | |
Live captions
|
Live captions are text that appears in real-time, transcribing the spoken words of a live event, such as a webinar, conference, or online video stream.
|
While the AODA encourages live captioning, it currently doesn’t mandate it. This means organizations are not legally required to provide live captions for their live online events.
|
Live captioning can be technically challenging and expensive to implement flawlessly, especially for events with fast-paced dialogue or complex terminology.
|
This exception is under review. There are recommendations to remove this exception in the future, meaning organizations should start preparing to provide live captions for live online audio content. |
Pre-recorded audio descriptions
|
Audio descriptions are verbal narrations of visual elements in a video, such as actions, settings, and facial expressions. They make videos accessible to people with visual impairments. | The exception: Similar to live captions, the AODA currently doesn’t require pre-recorded audio descriptions for video content.
|
Creating high-quality audio descriptions can be time-consuming and resource-intensive. | This exception is also under review, with recommendations to revoke it. Organizations should be prepared to provide audio descriptions for their pre-recorded video content. |
Manitoba organizations need to comply with a more advanced version of WCAG, Version 2.1. This version includes all guidelines from Version 2.0, as well as new guidelines explained below. In addition, the Manitoba mandate for web accessibility does not exempt organizations from any of the guidelines.
WCAG 2.1 in Brief
Requirement | What it means |
Displaying content in portrait and landscape orientations
|
Create flexible content that adapts to both portrait and landscape screen orientations. Restricting content to a single orientation can exclude users who cannot easily rotate their devices (e.g., wheelchair users) or who have set their devices to a specific orientation for accessibility reasons (e.g., visually impaired users with large monitors). Ideally, websites and apps should respect users’ preferred orientation settings. While generally avoidable, restricting orientation is acceptable when essential for the content, such as with virtual reality or specific document formats like bank checks. |
Online forms | Online forms should clearly instruct users on the expected type and format of information. For example, forms should specify whose email is required and provide date format examples (YYYY-MM-DD, MM-DD-YY, etc.). Critically, these prompts must be programmatically accessible so assistive technologies like screen readers can convey the instructions to users with disabilities. |
Designing text users can reformat | Websites and apps should ideally be designed for single direction scrolling (usually vertical). Requiring both vertical and horizontal scrolling can hinder users, especially those who magnify content. When text is enlarged (e.g., to 400%), it should reflow into a single column for easy reading. While layout may adapt, no content should be lost. Exceptions to single direction scrolling include elements like images, videos, tables, editing interfaces, and spacing, which may legitimately require both vertical and horizontal scrolling. Furthermore, all text should remain visible even when users increase letter, word, line, or paragraph spacing. |
Non-text colour contrast | Web designers must ensure sufficient color contrast (3:1 ratio) not only between text and background, but also between non-text elements (graphics, controls, interactive elements) and their backgrounds. Borders around non-text elements don’t need to contrast, but the element within the border must. |
Content that appears and disappears | Avoid “appearing and disappearing” content like tooltips, sub-menus, and pop-ups, as they can disrupt the user experience. If such content is necessary, provide an easy, non-disruptive way to dismiss it (without changing mouse or keyboard focus), unless it’s an error message or non-overlaying content. Furthermore, this content should remain visible until the user scrolls away, dismisses it, or it becomes invalid. |
Keyboard shortcuts | Keyboard shortcuts should generally require a combination of at least one character key (letters, numbers, symbols) and at least one non-printable key (Control, Alt, Command, Option). Shortcuts using only character keys are too easily triggered accidentally and should be avoided. If designers do use character-only shortcuts, they must provide a way for users to disable or remap them to include non-printable keys. |
Pointer gestures | Websites and apps should be usable with various input devices, including single-pointer assistive technologies like head pointers, eye-gaze systems, and speech-controlled mouse emulators. Avoid requiring complex pointer gestures like specific paths or multi-pointer actions (e.g., two-finger zoom). Instead, prioritize simpler, universally accessible gestures like single/double clicks/taps, long presses, and click-and-hold. This ensures accessibility for users with limited motor skills or those relying on single-pointer devices. |
Status Messages | Status messages (e.g., form errors, search results) must be accessible to assistive technologies like screen readers and screen magnifiers. These messages should be programmatically associated with the relevant content so they can be announced to the user without moving the user’s cursor or focus. |