The s. 7(2) (opens in a new tab) exceptions: how narrow they are

Section 7(1) (opens in a new tab) of the Accessible Information and Communication Standard Regulation, Man. Reg. 47/2022, requires web content to meet WCAG 2.1 Level AA if it was published on or after the date the regulation applies to the organization, or if it is needed to access the organization's goods or services. Section 7(2) (opens in a new tab) then lists five situations where that requirement does not apply.

Exceptions draw questions because they look like a way out. In practice, they are narrow. This article explains each one, how we think about it, and why your reasons should be written down if you rely on one.

The five exceptions

Under s. 7(2) (opens in a new tab), web content does not have to meet WCAG 2.1 Level AA where:

1. it is not technically feasible (s. 7(2)(a) (opens in a new tab)),
2. the technology is not readily available (s. 7(2)(b) (opens in a new tab)),
3. it would cause undue hardship (s. 7(2)(c) (opens in a new tab)),
4. the organization has no direct control over the content (s. 7(2)(d) (opens in a new tab)), or
5. the content concerns product labels or other product information (s. 7(2)(e) (opens in a new tab)).

The same five grounds appear in s. 8(2) (opens in a new tab) for web applications and in s. 6(4) (opens in a new tab) for requests for accessible information. The regulation does not define any of them further. The notes below are our reading, not settled interpretation.

Not technically feasible

This likely covers cases where meeting a particular requirement cannot be done with the technology involved, not cases where it would be inconvenient. The bar is about whether something can be done, not how much effort it takes. Most common problems, such as missing alternative text, low contrast, unlabelled form fields or keyboard traps, can be fixed on almost any platform.

Technology not readily available

This appears aimed at situations where the tools needed to make something accessible do not yet exist or cannot reasonably be obtained. For ordinary web content, the techniques for meeting WCAG 2.1 Level AA are well established, so this exception is unlikely to apply to most of a typical business website.

Undue hardship

Undue hardship is a familiar idea in Canadian human rights law, where it is generally treated as a high threshold. The regulation does not say how it should be measured here. It is reasonable to expect that cost alone, or a preference not to change, would not be enough. If you are considering this exception, get legal advice.

No direct control

This may apply to content you genuinely do not control, such as comments posted by members of the public or an embedded third-party feed you cannot alter. It is much less likely to apply to a website or platform you chose and pay for. Choosing a booking tool that is not accessible is a decision within your control, even if you cannot edit its code. Where a third-party tool is involved, asking the vendor about accessibility and keeping that correspondence is sensible.

Product labels and product information

This excepts content concerning product labels or other product information. It appears intended for information that comes from manufacturers, such as specification sheets or packaging details. The wording does not say how far it extends. It is unlikely to cover the rest of the page around that information: your navigation, your cart, your checkout or your contact form.

How narrow they are in practice

An exception applies to the content it actually affects, not to the whole website. If one embedded map cannot be made fully accessible, that does not excuse the menu, the forms or the text around it.

Where an exception does apply, the person still needs the information. Providing it another way, such as a text description of a map's location or a phone number for bookings, is good practice. Section 6 (opens in a new tab) also lets people request information in an accessible format or with a communication support, and you must consult them and provide it without delay unless a s. 6(4) (opens in a new tab) exception applies.

Why documenting reasons matters

The regulation does not expressly require you to document why you are relying on an exception. We still recommend it.

Under the Act, inspectors can ask for records and written answers (s. 24(5) (opens in a new tab)). If an inspector asks why a piece of content does not meet WCAG 2.1 Level AA, a written explanation prepared at the time is far more persuasive than a reason assembled afterwards. Large employers already have to document their accessible communication measures, policies and practices under s. 3(2) (opens in a new tab), and exception decisions fit naturally there.

A useful record includes:

• the specific content or feature affected,
• which WCAG success criteria it does not meet,
• which exception you are relying on and why,
• what alternatives you considered,
• how people can get the same information another way, and
• the date, and when you will look at it again.

Circumstances change. A tool that was not accessible last year may have been updated, and a cost that was prohibitive may no longer be. An exception decision is worth revisiting rather than treating as permanent.

Next steps

When we audit a website, we identify the content where an exception may genuinely apply and the much larger amount where it does not. We then document the reasoning as part of the compliance documentation. See our services, our guide to the Manitoba standard or the FAQ. If you think an exception applies to part of your site, contact us and we will give you a plain assessment. For a legal view, speak with a lawyer.

Last reviewed October 2026. General information, not legal advice.