Accessible login, password reset, and CAPTCHA: how to reduce friction without weakening access

Let's discuss your project →

Accessible login is not just a screen design problem. If a user has to hunt for help, re-enter data already provided, or solve a CAPTCHA to continue, the authentication journey has become harder than it needs to be. The practical fix is simple to state: keep help in the same place, avoid redundant entry, and make sure the path back in does not depend on one cognitive challenge alone.

WCAG 2.2, published as a W3C Recommendation on 5 October 2023, makes that discussion more concrete with criteria such as Consistent Help, Redundant Entry, and Accessible Authentication (What’s New in WCAG 2.2). For teams that own login, password reset, and account recovery, the useful question is not “Do we have a CAPTCHA?” but “Can a real user still enter, recover, and continue without unnecessary friction?”

Who this article is for

This article is for product owners, UX designers, front-end developers, and IT or security leads who need to decide whether an authentication flow is acceptable as it is, needs targeted fixes, or should be redesigned.

It is also relevant for support teams, because authentication problems quickly become tickets: lost access, reset failures, verification loops, and complaints about controls that are technically present but practically unusable.

This is not a full accessibility audit and it is not a legal opinion. It is a limited operational reading of a common flow, using WCAG 2.2 as a reference point and a simulated case to make the decision process concrete.

The three failure modes that matter most

The practical risk is usually not one dramatic failure. It is three small ones that accumulate:

  1. Help moves around. The support link, FAQ, or contact option changes position between login and reset, so users must search again.
  2. The flow repeats information. The reset process asks for data already provided moments earlier in the same session.
  3. The only way through is a cognitive test. A CAPTCHA or similar challenge becomes the only way to prove you are allowed to continue.

WCAG 2.2 addresses those issues from different angles. The Consistent Help criterion says that, when help mechanisms are repeated across pages, their relative position should remain the same (Understanding SC 3.2.6: Consistent Help). The Accessible Authentication criterion says users should not be forced to solve, remember, or transcribe something as the only way to authenticate, subject to the rule’s exceptions (Understanding SC 3.3.8: Accessible Authentication (Minimum)). The W3C also keeps a dedicated note explaining why many CAPTCHA mechanisms can exclude people with visual, auditory, cognitive, or reading disabilities (Inaccessibility of CAPTCHA).

Redundant Entry, another WCAG 2.2 addition, is especially relevant when login and recovery are split across multiple screens. Even without turning the flow into a formal compliance exercise, the practical takeaway is clear: if the same information has already been collected in the same session, ask why it needs to be collected again.

What a good review starts with

Before changing anything, map the whole path. Not the design system, not the button style, just the sequence a user has to complete.

For a typical account flow, write down:

  • login screen;
  • error state after failed credentials;
  • password reset request;
  • email or code verification;
  • new password entry;
  • any CAPTCHA or anti-bot step;
  • success confirmation.

Then mark three things on each screen:

  • where help is placed;
  • whether previously entered information is asked again;
  • whether a user can continue without completing a memory or transcription task.

That simple map often shows the real problem faster than a long list of accessibility comments.

Simulated case: a customer portal with a brittle recovery flow

The following example is synthetic and used only to illustrate the workflow.

Portal: Customer Area Demo
Domain: area-clienti.demo
Test users:
- user A: maria.rossi@example.test
- user B: account.accessibilita@example.test

Current flow:
1. Login with email + password
2. After 2 failed attempts, an image CAPTCHA appears
3. “Need help?” appears in the top left on the login page, but at the bottom of the password reset page
4. The reset asks again for email, customer code, and date of birth
5. The OTP arrives by email and is valid for 10 minutes

At first glance, this looks secure enough. But from the user’s point of view it creates a fragile recovery path:

  • the help link is not where users expect it;
  • the reset asks for data the user has already typed earlier in the same session;
  • the CAPTCHA can become a dead end if it is the only way to continue.

Now compare that with a more usable version.

Revised flow:
1. Login with email + password
2. Help link stays in the same relative position on every screen in the flow
3. Password reset keeps the values already provided in session when they are needed again
4. The anti-bot step is not the only route to recovery
5. The user can complete the reset and return to the account page

The difference is not cosmetic. It changes whether the flow can be completed by a real user who is under time pressure, using a keyboard, or relying on assistive technology.

What to change first

If you only have time for one review cycle, start with the points that create the most friction for the least implementation cost.

Keep help in a consistent location

If the login page shows “Need help?” in the header and the reset page hides it in the footer, users must re-learn where to find support. Consistent Help is about predictability, not decoration. The control can be visually simple and still fail the test if the user has to search for it again on every page.

Avoid forcing users to re-enter data without a reason

If the reset flow already knows the email address or customer number entered on the previous step, do not ask for it again just because the form was designed as two isolated screens. Repeated entry is one of the easiest problems to miss because it feels harmless to the team that built the page. To the user, it is extra work and extra opportunity for error.

Treat CAPTCHA as a risk decision, not a default answer

A CAPTCHA can be one anti-abuse measure, but it should not become the only way to get back into an account. W3C’s note on CAPTCHA remains useful because it highlights how many common implementations can block people who cannot complete the challenge in the expected way (Inaccessibility of CAPTCHA).

That does not mean never use any challenge. It means the recovery flow should not depend on one cognitive or perceptual task as the only possible route.

If you are translating this into a broader accessibility review, the service page Digital accessibility for websites, software and business workflows is the most direct next step.

How to test the revised flow

A practical check does not need a large lab. It does need a repeatable sequence.

  1. Keyboard-only pass. Move through login, reset, and recovery without using a mouse. If the focus order becomes confusing or the help link is hard to reach, the flow is not ready.
  2. Screen reader pass. Check that labels, errors, and help text are announced in the order a user needs them.
  3. Recovery pass after an error. Trigger a failed login and make sure the next screen does not break the user’s mental model.
  4. Repeat-entry pass. Note any field that asks for information already provided in the same session.
  5. Anti-bot pass. Verify that the user is not trapped if they cannot complete the CAPTCHA-style step.

If you want a second, closely related check, the article Accessible contact forms: instructions and messages that help people complete the request is useful for understanding how labels, instructions, and errors affect completion.

The goal is not to certify compliance from this short test. The goal is to discover whether the flow is obviously safe to release, obviously broken, or somewhere in between.

Acceptance criteria a responsible team can use

A flow like this is in better shape when all of the following are true:

  • help is present and appears in a consistent relative location across the whole authentication path;
  • users are not asked to retype information already provided in the same session unless there is a documented reason;
  • the recovery path does not depend on one cognitive challenge as the only way forward;
  • keyboard navigation reaches all the critical controls;
  • the error states explain what happened and what to do next.

If any one of those fails, the issue should be treated as a release blocker or at least as a change that needs a documented exception.

For a hands-on verification mindset, Keyboard-only test of the e-commerce purchase flow: from catalog to order summary shows how a step-by-step pass can reveal problems that a visual review misses.

Troubleshooting when the fix is not obvious

The CAPTCHA comes from a third-party provider

Then the question is not only “Can we style it?” but “Can we move it, replace it, or provide an alternative route?” If the answer is no, the architectural choice itself needs review.

Security pushes back with “we need this”

That may be true, but it still needs to be stated as a concrete risk and mitigation. Ask what abuse scenario the control prevents, and whether the same protection can be achieved without making account recovery the hard part of the journey.

Help exists, but users still miss it

That is usually a consistency or placement problem, not a content problem. The wording may be fine; the user still has to hunt for it again.

The page looks readable, but the flow still feels hard

Accessibility is not only contrast and font size. A flow can be perfectly legible and still be confusing because the order of actions is wrong or the same information is requested too many times.

What changes for the business

For a product team or manager, the value of this review is practical:

  • fewer support requests from users who cannot complete recovery;
  • less rework in the design and development cycle;
  • a clearer decision on whether the current authentication pattern is acceptable or needs redesign;
  • a cleaner basis for future audits.

It also helps separate three things that are often mixed together: security requirements, user experience choices, and accessibility obligations. When those are separated, the team can decide what must stay, what can be changed, and what needs a documented exception.

If the issue is the whole path rather than one field, the relevant service page is Digital accessibility for websites, software and business workflows. If the team needs help turning the flow into a repeatable review process, the more general Academy, workshops and R&D page is the best fit for training and method support.

Bottom line

Login, password reset, and CAPTCHA should be reviewed as one user journey, not as disconnected screens. WCAG 2.2 gives teams a clearer language for that review: keep help consistent, avoid unnecessary repeat entry, and do not make a cognitive test the only door back in.

For many organisations, the first win is not a redesign. It is simply making the existing flow easier to complete without weakening access or creating more support work.

Sources