Try this on your own site: put the mouse away and move through the page with the Tab key alone. Focus jumps from one link or button to the next, and the page scrolls to keep up. Then, on many Ontario websites, something quietly breaks. A sticky header slides down over the top of the page, or a cookie banner sits pinned to the bottom, or a live-chat bubble floats in the corner - and it covers the exact element you just landed on. You can no longer see where you are. For someone who navigates without a mouse, that is the moment the site stops being usable. WCAG 2.2 gave this failure a name, and it is worth understanding before Ontario's December 2026 reporting date.
Key facts
- 2.4.11 Focus Not Obscured (Minimum) is a Level AA success criterion that is new in WCAG 2.2 (Web Content Accessibility Guidelines), published by the W3C in October 2023 (W3C).
- The criterion requires that when a component receives keyboard focus, it is not entirely hidden by content the author added, such as a sticky header, a sticky footer, or a cookie banner (W3C).
- Ontario's IASR (Integrated Accessibility Standards Regulation, O. Reg. 191/11, s.14) currently mandates WCAG 2.0 Level AA - not 2.2 - for organizations with 50 or more employees (ontario.ca).
- The next ACR (Accessibility Compliance Report) is due December 31, 2026 for organizations with 20 or more employees (ontario.ca).
- AODA (Accessibility for Ontarians with Disabilities Act) has no private right of action; the individual route is a complaint to the HRTO (Human Rights Tribunal of Ontario) under the Ontario Human Rights Code (ontario.ca).
What does "focus not obscured" actually mean?
A keyboard user moves through a page one focusable element at a time. Each stop should show a visible focus indicator so the person can see which link, button, or field is active. Criterion 2.4.11 adds a second, separate requirement: the focused element itself must not be completely hidden by something the site places on top of it.
The word "minimum" matters. This rule only asks that at least part of the focused element stays visible. A stricter cousin, 2.4.12 Focus Not Obscured (Enhanced), is Level AAA and asks that nothing cover it at all. For most Ontario businesses, the practical target is the Level AA version: nothing you built should swallow a focused element whole.
Where does this go wrong in real life? Almost always with content that stays fixed while the page scrolls:
- A sticky navigation header that scrolls up to meet a focused link and buries it.
- A cookie or consent bar pinned to the bottom of the viewport, sitting on top of the last focused control on the page.
- A live-chat widget or a floating "back to top" button parked in a corner.
None of these look broken to a mouse user, because a mouse never depends on the browser scrolling focus into view. That is exactly why the problem survives so long: the people who ship the site rarely tab through it.
Does Ontario actually require this yet?
Here is the honest answer, because it is easy to overstate. Ontario's IASR web requirement points at WCAG 2.0 Level AA. Criterion 2.4.11 is a WCAG 2.2 addition, so on its own, failing 2.4.11 is not a breach of the current IASR wording. Anyone telling you this specific number is "the law" in Ontario today is getting ahead of the regulation.
Two things keep it from being academic, though.
First, the goal behind 2.4.11 is already required. WCAG 2.0 Level AA - the version Ontario does mandate - includes keyboard operability (2.1.1) and a visible focus indicator (2.4.7). A focus you literally cannot see because a banner is on top of it undercuts both of those. The newer criterion did not invent the obligation to let keyboard users work; it sharpened the description of one common way sites break it. If you are already meeting the keyboard requirements, an obscured focus is a gap in that same coverage.
Second, the standard is moving. Ontario references WCAG 2.0 today, but 2.2 is the current best-practice bar, and building to it now means you are not redoing the work later. We walk through what changed between 2.0 and 2.2 and why 2.2 is where the province is heading separately. The through-line: the person who files an HRTO complaint is a real customer who could not finish what they came to do, not a regulator checking a version number.
How do you find it and fix it?
Finding it is free and takes a few minutes. Unplug the mouse. Tab from the top of the page to the bottom and watch whether focus ever disappears behind a fixed element. Do it with the cookie banner still open, with the chat widget loaded, and on a phone-width screen, since sticky bars are most aggressive there.
Fixing it belongs in your source code, not in a widget. The usual repair is CSS: set scroll-padding-top on the scrolling container equal to the height of your sticky header, and add scroll-margin to focusable targets, so the browser scrolls each focused element into the clear instead of under the header. An accessibility overlay cannot reliably reposition your own sticky elements, because it does not know their height or your layout. This is a layout fix, and layout fixes live in the stylesheet.
When you are done, keep a dated note of what you tested and changed. That record is worth far more than a badge if a complaint ever lands.
Want to know what a keyboard user actually hits on your site before a customer does? Free Vayle Report, about 30 seconds: vayle.art. It detects overlay widgets, surfaces real WCAG failures, and tells you exactly what legally applies to your organization in Ontario. No obligation.
Vayle is a remote-first accessibility-engineering studio serving Ontario. General information, not legal advice.