Most accessibility problems are on pages you look at every day. The login screen is the exception. Once you have signed into your own site, you almost never see it again, so the barrier that lives there is the one you are least likely to catch. And logins are where a very specific group of customers gets stuck: people who can read your page and navigate it fine, but cannot reliably solve the little test you put between them and their account. Remember a complex password. Transcribe a code from an email within sixty seconds. Read the wavy letters in a CAPTCHA. Copy a one-time code from a text message. Each of those is a memory or puzzle task, and for a customer with dyslexia, a cognitive disability, a brain injury, or low vision, any one of them can be the wall they cannot get over, on an account they have already paid for.
Key facts
- WCAG 2.2 (Web Content Accessibility Guidelines) added Success Criterion 3.3.8 Accessible Authentication (Minimum) at Level AA. It became a W3C Recommendation on October 5, 2023, and it did not exist in WCAG 2.0 or 2.1 (W3C).
- 3.3.8 states that a cognitive function test (such as remembering a password or solving a puzzle) must not be required for any step of login unless that step also offers an alternative method, a mechanism to help, object recognition, or content the user themselves provided (W3C).
- WCAG 2.2 introduced 9 new success criteria over WCAG 2.1, and 6 of the 9 are Level A or AA, meaning they sit inside the AA conformance target most Ontario sites aim for (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, a floor set before 3.3.8 existed (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 2.2 actually require at the login screen?
The plain-language version of 3.3.8 is this: a customer should be able to log in without having to remember, retype, or figure something out, unless you give them another way through. A "cognitive function test" is anything that leans on memory or problem-solving: recalling a password, solving a puzzle CAPTCHA, transcribing a string of characters, doing math. The criterion does not ban those outright. It says that if you use one, you must pair it with at least one accepted alternative, such as an authentication method that does not rely on a memory or puzzle test at all.
The two big compliant patterns are simple. First, let the machine do the remembering: your password field must accept paste, and must work with browser autofill and password managers, so the customer never has to recall or hand-type anything. Second, offer a path that skips the puzzle, such as a magic link emailed to the customer, a passkey, or biometric sign-in. There are also two exceptions the criterion carves out at AA: a test that asks the user to recognize common objects (the "select all images with a bus" style), and one that asks them to identify content they personally provided. Both are still cognitive tests, but W3C excepts them at Level AA, so a familiar-object CAPTCHA is not itself a failure.
Where do Ontario logins fail this, and does the AODA require it?
Here is the honest legal picture, the same one drawn in WCAG 2.0 vs 2.2 in Ontario. Ontario's AODA (Accessibility for Ontarians with Disabilities Act) names WCAG 2.0 Level AA as the enforceable standard, and 3.3.8 is newer than that, arriving in WCAG 2.2. So a puzzle CAPTCHA at login is not, on its own, a breach of the letter of the IASR. It is a gap against the current standard, part of the same law-versus-best-practice distance covered in what changed with WCAG 2.2: the legal minimum is 2.0, the standard worth building to is 2.2.
Where does it actually break? Usually in one of these:
- A password field that blocks paste, so autofill and password managers cannot fill it and the customer must type from memory.
- A puzzle or distorted-text CAPTCHA with no non-cognitive alternative offered.
- A checkout or B2B portal that forces account creation with a memorized password before you can buy, which is the same friction the accessible checkout and forms guide warns about, and the same barrier that makes an accessible Shopify build convert better for everyone.
- A one-time code the customer must read and retype under a timer, with no way to paste it.
None of this is something a bolt-on widget fixes, because an overlay cannot rebuild your authentication flow: whether paste is allowed or a passwordless option exists is a decision in your own code, not a script layered on top.
How do you check it, and what's the risk if you leave it?
You can test the core of this in a couple of minutes:
- Open your login in a private browser window and try to paste into the password field. If paste is blocked, that is the first fix.
- Confirm your browser's password manager or autofill can populate the fields without you typing.
- Look for a CAPTCHA or puzzle. If there is one, is there an alternative that does not require solving it? The same keyboard walk-through applies here: can you complete login with the keyboard alone?
- Check whether a customer can buy or use the service without a memorized password, via guest checkout, a magic link, or a passkey.
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 being unable to reach an account a sighted, non-disabled customer can reach is exactly the kind of unequal access those complaints describe, as an HRTO complaint plays out. If you sell into the United States, inaccessible logins are among the issues raised 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 whether a real customer can actually get through your login is a human judgment, this is one more reason a scan is not an audit: a crawler can flag a blocked paste, but it cannot tell you whether a person with a cognitive disability can sign in.
See whether your site flags login, CAPTCHA, 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.