Your login form is in the EAA standard now

EN 301 549 V4.1.1, published at the start of September, moves the European accessibility standard to WCAG 2.2. Of the new criteria, the one most login forms fail is 3.3.8 Accessible Authentication. Most of the failures are one line of code or one design decision, and so are most of the fixes.

What changed, and what hasn't yet

V4.1.1 was adopted on 24 August 2026. It carries 3.3.8 three times: clause 9.3.3.8 for web pages, 10.3.3.8 for documents, 11.3.3.8 for software. V3.2.1, the version before it, was based on WCAG 2.1 and never had it.

Is it law now? Not quite. Not yet. No version of EN 301 549 is cited in the Official Journal under the EAA, so V4.1.1 doesn't give a presumption of conformity, as I wrote in the post on apps. (V4.1.1 also names 30 November 2026. Some posts present that as the citation date. It is the date by which national standards bodies have to announce the standard.)

The EAA itself doesn't wait for the citation. For e-commerce, Annex I asks for "ensuring the accessibility of the functionality for identification, security and payment" by making it "perceivable, operable, understandable and robust." The law asks for the result, and the standard now says how to show it.

The criterion

3.3.8 says: "A cognitive function test (such as remembering a password or solving a puzzle) is not required for any step in an authentication process unless that step provides at least one of the following." Then four ways out: another method without such a test, a mechanism that helps with the test, a test that only asks to recognize objects, or one that asks to identify content the user provided.

A cognitive function test is "a task that requires the user to remember, manipulate, or transcribe information." Typing your name, email or phone number doesn't count. Copying a code by hand does.

The scope has edges. The Understanding document says it is "focused on authentication of existing users," so sign-up is out and account recovery is in. With several factors, every step has to pass. It is also the one criterion in WCAG 2.2 that names cognitive function at all.

Five ways to fail it

The most common is blocked paste: an onpaste handler that calls preventDefault(), usually added "for security." The Understanding document is direct about it. Blocking paste into authentication fields "would force the user to transcribe information and therefore fail this criterion, unless another method is available." Since an update in April 2026 it also says that working autofill doesn't excuse blocked paste. Both have to work.

Password managers get blocked too, by autocomplete="off" on the password field, by invented field names, or by a username and password on separate pages without the right hints. According to MDN, browsers may ignore autocomplete="off" on login fields anyway. Give them username and current-password and let them do their job.

Then there are six boxes for six digits, the one-time code split into one input per digit. Failure F109 fails that "unless the user can paste the entire code in the first input, and the remaining inputs are populated automatically." The same failure covers "Enter the 2nd, 6th and last characters of your password," which some banks still ask for. One input with autocomplete="one-time-code" is less work to build and passes.

The codes are also where the criterion is weakest, in a spot I call the clipboard assumption. A code sent by SMS arrives on a phone. If you log in on a laptop, the Understanding document handles that with one sentence: "it is assumed that provisions are in place that make the code available in the user's clipboard." The test then only checks that paste works. Getting six digits from one device to another is still the user's job, and for some users that is the whole problem. Passkeys and push approval avoid the clipboard assumption. A paste-friendly SMS field only moves it.

Puzzle CAPTCHAs are the fourth. At level AA, object recognition is an exception, so "pick all the bicycles" passes, whatever else is wrong with it. Math and logic puzzles are "not excepted." A text CAPTCHA with an audio version doesn't count as an alternative if the user has to transcribe the audio, and a CAPTCHA that only appears after three wrong passwords still counts, because it is still a step in the authentication. A CAPTCHA on a guest checkout isn't part of authentication, so 3.3.8 doesn't cover it. WCAG 1.1.1 does, and the customer is blocked either way.

The fifth is the security question. "Name of your first pet" is personal content, but text-based personal content doesn't qualify for the exception. It is a memory test.

What passes

A password with a password manager and paste passes, once nothing blocks them. So do push approval and hardware keys, which aren't cognitive function tests at all.

Passkeys pass. The Understanding document gives WebAuthn as an example where the user authenticates "with their device," with no code and nothing to remember. EN 301 549 adds one condition in clause 5.3: ICT "shall not rely on the use of a biological characteristic as the only means of user identification." A passkey that unlocks only with a fingerprint needs a device PIN as well, which the platforms provide.

Magic links pass too. Technique G218, email link authentication, is sufficient for 3.3.8. What G218 doesn't cover is the link opening in a different browser than the one that asked for it, and users hit that often enough to test it.

The markup for the common case is short:

<form method="post" action="/login">
  <label for="email">Email</label>
  <input id="email" name="email" type="email" autocomplete="username webauthn">

  <label for="password">Password</label>
  <input id="password" name="password" type="password" autocomplete="current-password">

  <button type="submit">Sign in</button>
</form>

<form method="post" action="/verify">
  <label for="code">Code from your authenticator app</label>
  <input id="code" name="code" inputmode="numeric" autocomplete="one-time-code">

  <button type="submit">Verify</button>
</form>

The webauthn token has to be the last one in the attribute, and it only offers passkeys if the page also calls navigator.credentials.get() with mediation: "conditional". Safari fills one-time-code from SMS, and from Mail on macOS. Chrome on Android supports the WebOTP API for SMS.

Time limits and payments

A 30-second TOTP window is allowed. The Understanding document for 2.2.1 Timing Adjustable says time limits for security, "such as time-based / time-limited two-factor authentication tokens, can be considered essential." The window can stay. Paste and autofill have to work inside it.

Payments add PSD2. Strong customer authentication needs two of three elements, knowledge, possession and inherence, and the technical standard caps inactivity after authentication at five minutes. It sets no lifetime for codes, and it doesn't require a cognitive test. A password manager covers knowledge, and a pasteable code or a push approval covers possession.

The European Banking Authority wrote in 2022 that smartphone-based authentication had excluded "customers with specific disabilities and elderly people." The draft Payment Services Regulation, in the Council's text from April 2026, would require at least one authentication means "adapted to their specific situation," free of charge and not dependent on a smartphone. It isn't adopted yet.

Checking your own login

It takes about ten minutes. Log in with a password manager, then copy the password from somewhere else and paste it. Paste a one-time code into the code field, into the first box if there are six. Go through account recovery the same way. If there is a CAPTCHA, trigger it and try it with a screen reader running.

Most login forms fail at least one of those, and each failure is usually a single attribute or handler. That is a short list of work for a criterion that will be in the cited standard soon.