Visible Focus Indicators: What Ontario's AODA and WCAG Require, and the One CSS Line That Breaks Them (2026)

Most accessibility barriers get built by accident. This one usually gets built on purpose. A developer looks at the glowing outline the browser draws around a button when you tab to it, decides it clashes with the design, writes a single line of CSS, outline: none, and moves on without putting anything back. The page looks cleaner to the person who made it, because that person is using a mouse and never sees the outline anyway. But for a customer navigating with the keyboard, a screen-magnifier user, someone with a tremor who cannot use a trackpad, that outline was the only thing on the screen telling them where they are. Delete it and they are tabbing blind, pressing Enter and hoping. The barrier is invisible to the one person most likely to catch it, and it is one of the most common failures we find on Ontario sites.

Key facts

• WCAG (Web Content Accessibility Guidelines) Success Criterion 2.4.7 Focus Visible is Level AA and has been part of the standard since WCAG 2.0. That matters in Ontario: it sits inside the enforceable legal floor, not above it (W3C).
• WCAG 2.2 added two more focus rules: 2.4.11 Focus Not Obscured (Minimum) at Level AA (new in 2.2), and 2.4.13 Focus Appearance at Level AAA (new in 2.2), which sets a minimum size and contrast for the indicator itself (W3C).
• WCAG 2.2 introduced 9 new success criteria over WCAG 2.1, and 6 of the 9 are Level A or AA (W3C).
• Ontario's IASR (Integrated Accessibility Standards Regulation, O. Reg. 191/11) s.14 requires organizations with 50 or more employees to meet WCAG 2.0 Level AA on public websites (ontario.ca).
• The next ACR (Accessibility Compliance Report) for organizations with 20 or more employees is due December 31, 2026 (ontario.ca).

What does WCAG actually require for keyboard focus?

The plain-language version of 2.4.7 Focus Visible is this: whenever a customer moves through your page with the keyboard, the element they have landed on must show a visible marker of focus. A button, a link, a form field, a menu item, when it is the active element, has to look visibly different from the ones around it. WCAG 2.0 does not dictate the exact style, only that focus is visible. This is the twin of the keyboard walk-through: keyboard operability gets you to every control, and a visible focus indicator tells you which one you are on once you arrive. One without the other is half a door.

WCAG 2.2 tightened the surrounding rules. 2.4.11 Focus Not Obscured (Minimum) (Level AA) says that when an element receives focus, at least part of it must stay visible and not be completely hidden behind a sticky header, a cookie banner, or a floating chat bubble, a real problem on modern sites where a fixed toolbar can sit right on top of the field you just tabbed to. 2.4.13 Focus Appearance (Level AAA) goes further and specifies how large and how contrasting the indicator must be, which is why a focus ring that is technically present but a faint one-pixel grey line still fails the spirit of the rule.

Why does one line of CSS break it, and does the AODA cover it?

Here is the honest legal picture, and it is stricter than the one for some newer criteria. Ontario's AODA (Accessibility for Ontarians with Disabilities Act) names WCAG 2.0 Level AA as the enforceable standard. Focus Visible is a WCAG 2.0 Level AA criterion. So unlike accessible authentication, which arrived in WCAG 2.2 and sits above the legal floor, a missing focus indicator is a failure against the exact version of WCAG that Ontario's IASR points to. This is not a best-practice-to-aim-for gap; it is inside the line, the same distinction drawn in WCAG 2.0 vs 2.2 in Ontario.

Where does it break? Almost always in one of these:

• A global stylesheet with outline: none or outline: 0 on links, buttons, or inputs, with no :focus or :focus-visible style put back to replace it.
• A custom component (a dropdown, a modal, a slider) built in JavaScript that never gives its interactive parts a focus style at all.
• A design system reset that strips the browser default site-wide, so the ring disappears on every page at once.
• A focus ring that is there but gets hidden behind a sticky header or overlay, the exact case 2.4.11 was written for.

None of this is something a bolt-on widget repairs, because an overlay cannot rewrite your CSS: whether your buttons show focus is decided in your own stylesheet, not by a script layered on top. The fix is the reverse of the break, restore a visible :focus-visible style with enough size and colour contrast to actually be seen.

How do you check your focus indicators, and what's the risk if they're missing?

You can test the core of this in about a minute, no tools required:

1. Click once in the address bar, then press Tab repeatedly to walk through your page with the keyboard alone.
2. At every stop, ask one question: can I see where I am? A clear ring, border, or highlight should move with you from control to control.
3. Watch for the marker vanishing on custom menus, modals, or after a pop-up opens, and for it getting covered by a sticky header at the top of the screen.
4. Check that the indicator is strong enough to notice, not a faint hairline a low-vision customer would miss.

The stakes are the ones that attach to any access barrier. In Ontario the AODA has no private right of action, so no one sues under it directly; the live route for an individual is the HRTO (Human Rights Tribunal of Ontario), which hears complaints under the Ontario Human Rights Code, and a customer who cannot tell which button they are about to press is being denied the equal access those complaints describe. If you sell into the United States, invisible focus is a routine allegation in ADA (Americans with Disabilities Act) web litigation. The durable answer is the same one every gap needs: documented remediation, a dated record of what you found and fixed, which is what an honest ACR should reflect by December 31, 2026. And because a machine can confirm an outline: none exists but cannot judge whether a real keyboard user can follow the focus across your custom components, this is one more reason a scan is not an audit.

See whether your site flags missing focus states or other accessibility issues, 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.