What does your login ask people to remember?

The sign-in page is the page an audit never reaches

Every automated accessibility tool on the market crawls a site by following links, and every one of them stops at the login form — it cannot authenticate, so it reads the form and nothing behind it. Manual audits sample pages and usually sample the public ones. The result is that the page standing between a customer and the account they are paying for is, on most sites, the least examined page anyone owns.

It is also the page where a defect costs the most. A contrast problem on a marketing page is an inconvenience. A sign-in that cannot be completed is a person locked out of a service they have already bought — which is the complaint that reaches a regulator, because it is the one with a receipt attached to it.

What SC 3.3.8 says, and what it does not

Accessible Authentication (Minimum) is new in WCAG 2.2 and it sits at Level AA, inside the conformance target EN 301 549 and most procurement questionnaires name. It says a step in an authentication process must not rely on a cognitive function test — remembering, transcribing, solving — unless one of four exceptions applies:

another method    a route that needs no cognitive function test
a mechanism       something that gets the person through it
                  → for a password, this is a password manager
object recognition  "pick out the buses"  — PERMITTED at AA
personal content    "which of these did you upload"  — PERMITTED at AA

The second line is the whole criterion in practice. A password is a memory test; nobody has argued otherwise. It stays conformant because a password manager is the mechanism that removes the memory. Which means a page that blocks paste, or tells the browser not to offer the saved credential, has taken away the only thing keeping its own password field inside the standard — and it has done it in two attributes a checker can read.

And the third and fourth lines are why this tool is careful. An image-grid CAPTCHA is object recognition. It is not an AA failure, it will never be reported here as one, and a tool that says otherwise is wrong about a large share of the login pages on the web.

Seventeen sign-in pages, read live on 24 September 2026

Run against real logins, the shape of the result is not the one you would guess. The big server-rendered sign-ins are mostly correct; the defects are in the middle, and the single Level AA failure found was on a federal identity service.

github.com/login                  username + current-password        pass
news.ycombinator.com/login        both forms tokened correctly       pass
pypi.org/account/login            pass
tracker.debian.org/accounts/login pass
mediawiki.org  Special:UserLogin  pass
forum.xda-developers.com/login    pass

bugzilla.mozilla.org              3 fields, no autocomplete token    review
namecheap.com/myaccount/login     3 fields, no autocomplete token    review
accounts.craigslist.org/login     2 fields, no autocomplete token    review
wordpress.org/wp-login.php        no tokens; reCAPTCHA v3 = clear    review

secure.login.gov                  <form autocomplete="off">          FAIL

id.atlassian.com/login            shell — form built in the browser
login.yahoo.com                   shell
dashboard.stripe.com/login        shell
app.netlify.com                   shell
reddit.com/login                  shell
linode.com/login                  shell

The login.gov result is worth reading closely, because it is the exact shape this criterion is about and it is not carelessness. The password field on that page carries autocomplete="current-password" — somebody thought about it. The form element around it carries autocomplete="off", so the email field above, which sets no token of its own, inherits the refusal. One attribute on a parent, on the page the United States government uses to sign people in to federal services.

The other number in that table is the six shells. A sign-in form is more likely than any other form to be drawn by an identity provider’s widget after the bundle runs, which is why this tool reports that shape as unread rather than reporting a clean page it never saw.

Everything this checker reports

Four Level AA failures, six things to read, and two it reports specifically so you know they are not counted against you. Each one is decided from the markup your server sends.

• Paste is blocked in an authentication field

  Level AA failure

  WCAG 2.2 SC 3.3.8 Accessible Authentication (Minimum) (Level AA)

  The page cancels the paste event on a password, username or code field. SC 3.3.8 is satisfied by offering a mechanism that removes the need to remember or transcribe — in practice that mechanism is a password manager, and pasting is how one of those gets a 24-character secret into a field. Blocking it forces the person to read a string out of a vault and retype it by hand, which is transcription: the exact cognitive function test the criterion forbids. It is also the single most common reason someone with a motor or memory disability cannot sign in to a site they are already paying for.

  The fix: Delete the handler. There is no security case for it — it has been recommended against by the NCSC and by OWASP for years, because it pushes people towards short passwords they can type. Remove onpaste="return false" from the input and any addEventListener("paste", e => e.preventDefault()) in the sign-in script.

• autocomplete is switched off on an authentication field

  Level AA failure

  WCAG 2.2 SC 3.3.8 Accessible Authentication (Minimum) (Level AA)

  The field, or the form around it, carries autocomplete="off". That is an instruction to the browser not to offer the saved credential, which is the mechanism that makes a password something a person does not have to remember. Some browsers now ignore it for password fields and some do not, and a person using an external manager or an assistive setup is the one most likely to land on a browser that obeys it. The criterion asks for the mechanism to be available; this is the page asking for it to be withheld.

  The fix: Replace it with the real tokens: autocomplete="username" on the identifier and autocomplete="current-password" on the password — or "new-password" on a sign-up or reset form. On a form element, remove autocomplete="off" entirely rather than overriding it per field.

• A transcription CAPTCHA stands in the sign-in path

  Level AA failure

  WCAG 2.2 SC 3.3.8 Accessible Authentication (Minimum) (Level AA)

  The page asks the person to read characters out of an image and type them in. SC 3.3.8 lists exactly two permitted cognitive function tests — object recognition, and identifying non-text content the person themselves provided — and transcription is neither. Reading distorted glyphs is a test of visual processing and working memory, so it excludes people with low vision, dyslexia and a range of cognitive disabilities, and the audio alternative that usually ships alongside it is a transcription test of hearing instead. There is no reading of 3.3.8 under which this passes at AA.

  The fix: Replace it with a check that asks the person for nothing: a score-based or device-attestation check (reCAPTCHA v3, Cloudflare Turnstile in managed mode), rate limiting, or an emailed link. If a visible challenge is genuinely required, an object-recognition grid is at least inside the exception the criterion names.

• A security question asks for something memorised

  Level AA failure

  WCAG 2.2 SC 3.3.8 Accessible Authentication (Minimum) (Level AA)

  A knowledge-based answer — a first pet, a mother's maiden name, a secret question chosen at signup — is a recall test, and recall is the cognitive function test at the centre of this criterion. It is worse than a password for the people 3.3.8 protects, because a password manager will store a password and nothing stores the answer to a question that was invented on a form two years ago. It is also the step that most often has no alternative route past it, since it usually guards account recovery.

  The fix: Move account recovery to an emailed link or a code the person can paste, and drop the question. If it has to stay for a regulated flow, offer a second route on the same screen rather than behind a support phone number.

• An image-grid CAPTCHA is in the path

  Not a failure — worth reading

  Permitted at AA — fails WCAG 2.2 SC 3.3.9 (Level AAA)

  This is an object-recognition challenge — pick out the buses, the traffic lights, the crosswalks. SC 3.3.8 names object recognition as an explicit exception, so this is NOT a Level AA failure and this tool will not call it one. It is still the step that strands people: it fails 3.3.9 Accessible Authentication (Enhanced) at AAA, it is unusable for a blind person without falling back to an audio challenge that is itself transcription, and the images load slowly on a poor connection. Reported because it is worth knowing it is there, not because it breaks the AA target.

  The fix: If you have the option, move to a score-based or device check that asks for nothing. If the grid stays, make sure the sign-in page offers at least one alternative route — an emailed link, or a passkey — so it is not the only door.

• The one-time code is split across single-character boxes

  Not a failure — worth reading

  Four or more inputs each capped at one character is a code-entry widget. It looks precise and it charges memory: the person has to hold the code in their head while moving between boxes, a screen reader announces each box as a separate unlabelled field, and pasting the whole code only works if the widget was built to intercept it — many are not. Every box is also a focus move, which is expensive for someone driving the page by switch or voice.

  The fix: Use one input with autocomplete="one-time-code" and inputmode="numeric". iOS and Android will then offer the code from the SMS directly, which removes the transcription entirely. If the split boxes are a design requirement, handle a paste on any box by distributing the value across all of them.

• The password field is capped shorter than a generated password

  Not a failure — worth reading

  A maxlength on the password input truncates what a manager generates, silently. The person pastes a 24-character secret, the field keeps the first twelve, the login fails and nothing on screen explains why — and the practical repair they reach for is inventing a shorter password they can remember, which is the memorisation 3.3.8 is trying to remove. Not a conformance failure on its own, which is why it is here rather than above, but it is the quiet reason a manager stops working on a site.

  The fix: Remove the maxlength, or raise it past 64. There is no storage argument for a cap — the password is hashed to a fixed width before it is stored.

• A verification-code field without autocomplete="one-time-code"

  Not a failure — worth reading

  The field is collecting a one-time code and it does not carry the token that lets the operating system offer the code that just arrived. Without it the person reads the code off a notification, holds six digits in working memory, switches app and types them — a transcription task under time pressure, because the code expires. The token turns that into one tap.

  The fix: Add autocomplete="one-time-code" and inputmode="numeric". On iOS and on Android with SMS Retriever, the code is then suggested above the keyboard.

• An authentication field carries no autocomplete token

  Not a failure — worth reading

  Related: WCAG 2.1 SC 1.3.5 Identify Input Purpose (Level AA)

  There is no autocomplete attribute on the identifier or password field. This is an omission rather than a refusal — most managers fall back to guessing from the field's name and type and usually get it right — so it is not counted as a 3.3.8 failure here. It is still the difference between a manager that fills reliably and one that fills on some of your pages, and the tokens are also what SC 1.3.5 asks for at AA.

  The fix: Add autocomplete="username" to the identifier and autocomplete="current-password" to the password on a sign-in form, or "new-password" on sign-up and reset.

• Composition rules are stated on the page

  Not a failure — worth reading

  Text on this page requires a particular mix — an uppercase letter, a number, a symbol. Rules like these are not a WCAG failure and this tool does not call them one. They are on the list because of what they do to the criterion: they make a password harder to hold in memory without making it harder to guess, they are the reason people write passwords down, and they routinely reject exactly the long generated strings a manager produces. NIST has recommended against them since 2017.

  The fix: Drop the composition rules, set a generous minimum length, and check the candidate against a breached-password list instead. That is stronger and it costs the person nothing to remember.

• A no-interaction bot check is present

  Reported as clear

  A score-based or device-attestation check was detected with no visible challenge in the served markup — reCAPTCHA v3, Turnstile in managed mode, or an invisible v2 badge. This asks the person to do nothing, so it is not a cognitive function test and it is not a barrier under 3.3.8. It is listed only so the result is complete: this is the pattern to move to, not away from.

  The fix: Nothing to fix. Worth confirming that the fallback shown when the score is low is not a transcription challenge, because that is where these quietly turn into one.

• The sign-in form is built in the browser

  Verify by hand

  The HTML this page serves is a near-empty shell with a script in it, so the fields, the handlers and any challenge are assembled after the bundle runs and none of them can be read from here. That is a common shape for a login page in particular, because the form is often owned by an identity provider's widget. What is reported above is only what the server sent.

  The fix: Check the rendered page: with the sign-in form on screen, try pasting into the password field, and look at whether the browser offers a saved credential. The free scan renders every page in a real browser, which is what reads a form that does not exist until then.

Questions

What does SC 3.3.8 actually require?

That a step in an authentication process does not rely on a cognitive function test — remembering something, transcribing something, solving a puzzle — unless one of four things is true: there is another method that does not, there is a mechanism to help the person through it, the test is object recognition, or the test is identifying non-text content the person themselves provided. In practice the mechanism is the whole criterion. A password is a memory test; a password manager is the mechanism that makes it acceptable. So a page that defeats password managers has removed the only thing keeping its password field conformant, and that is the shape this tool reads from the markup.

Is an image CAPTCHA a failure?

Not at Level AA, and this tool will not tell you it is. “Object recognition” is written into the criterion as an explicit exception, and picking the buses out of a grid is object recognition. It is reported here in the review band because it is still the step a blind person cannot pass without falling back to an audio challenge — which is transcription — and because it does fail SC 3.3.9 Accessible Authentication (Enhanced) at AAA. A checker that called it an AA failure would be wrong on a very large fraction of the login pages on the web, which is the kind of error that makes a whole report untrustworthy.

What about reCAPTCHA v3 or Turnstile?

Those ask the person to do nothing at all — they score the session and let it through — so there is no cognitive function test and nothing to fail. This tool detects them and reports them as clear, explicitly, rather than counting a vendor script as a barrier. The thing worth checking yourself is the fallback: some deployments drop to a visible challenge when the score is low, and if that fallback is distorted text then the page fails 3.3.8 for exactly the people most likely to score low.

Why is blocking paste a failure rather than a nuisance?

Because of what it does to the mechanism. A 24-character generated password is only usable if something can put it into the field for you. Cancel the paste event and the person has to read the string out of a vault and retype it character by character, which is transcription — a cognitive function test by the criterion's own definition — and it is also a motor task that is expensive for anyone using a switch, voice control or a screen magnifier. The security argument for it was always backwards: the NCSC and OWASP both recommend against it, because blocking paste pushes people towards short passwords they can type from memory.

Chrome ignores autocomplete="off" on password fields. Doesn't that make it harmless?

Chrome does largely ignore it, and that is a browser working around a page rather than a page being correct. Behaviour still differs across Safari, Firefox, older embedded webviews and third-party managers, and the attribute is also read by the identifier field — which Chrome does honour more often. The criterion asks that the mechanism be available, not that a majority browser happens to override your instruction not to offer it. The fix costs one attribute.

You said my page has no password field. It definitely does.

Then it is being built in the browser, which is very common for sign-in specifically — the form is often owned by an identity provider's widget and does not exist in the HTML your server sends. This tool reads the served markup, so it says so instead of reporting a clean result for a page it could not see. Of seventeen real sign-in pages read for this page, six served no form at all. The free scan renders each page in a real browser, which is what reads a form that only exists after the bundle runs.

Why does a one-time code split across six boxes count against the page?

It does not count as a failure — it sits in review. It is there because of what it costs: the person holds six digits in working memory while moving focus six times, a screen reader announces six separate fields, and pasting the whole code only works if the widget was built to intercept a paste and distribute it, which many are not. One input with autocomplete="one-time-code" lets iOS and Android offer the code straight from the message, which removes the transcription entirely.

Does this submit my login form or send you my password?

No. The check is a single HTTP GET of the page you name, exactly as a browser would request it before anyone types anything. The form is never submitted, no credential is ever sent, and nothing is stored — the markup is read inside the request and discarded when it answers.

Is 3.3.8 in the standard my regulator names?

It is in WCAG 2.2, at Level AA, published in October 2023. The EN 301 549 harmonised standard behind the European Accessibility Act has been updated to WCAG 2.2, and US Department of Justice rulemaking under ADA Title II names WCAG 2.1 AA as the floor — so a site built to 2.1 is not wrong about its obligation today and is one revision behind the criterion everything is moving to. Sign-in is also the step regulators hear about most, because failing it locks someone out of an account they already have.

Does a passkey satisfy this?

Yes, and more cleanly than anything else on the list. A passkey is a device-held credential — nothing is remembered, nothing is transcribed, nothing is typed — so the authentication step involves no cognitive function test at all. Offering one as an alternative route also satisfies the criterion even where a password path with a challenge on it remains, because the criterion is satisfied by another method being available.