Accessible Payment Authentication and Identity Checks: 3-D Secure, SCA and KYC Flows Under the EAA

A customer has chosen a product, filled in a form, and reached the last step. Then the bank sends a six-digit code by SMS, the code field times out in 60 seconds, and the only alternative is an app approval on a phone they cannot operate. For many disabled customers, the payment authentication step is where an otherwise accessible journey ends.

Consumer banking and e-commerce are both named in the European Accessibility Act, which has applied to new products and services since 28 June 2025. Authentication and identity verification are part of those services. This article looks at where these flows fail and how to design them to work for more people. It is a practical guide, not legal advice, and it does not attempt to interpret PSD2 exemptions.

Why authentication is a special case

Security flows deliberately add friction. That is acceptable until the friction depends on an ability: hearing a voice call, reading a distorted image, steadying a camera, remembering a code long enough to type it. Accessibility problems in authentication are also high-stakes, because failure means the customer cannot pay, onboard or access their account.

An OneSpan article on EAA-compliant banking authentication frames it as a control requirement and not a UX add-on: accessibility failures can become compliance failures, and the whole path needs testing, including device behaviour, error handling, language support, transaction confirmation and the support-desk fallback.

The common failure modes

One method only. SMS codes exclude people without reliable mobile coverage or who cannot read the message while using a screen reader on the same device. Smartphone-app approval excludes people without a compatible phone or who find the app inaccessible.

Short, fixed timeouts. One-time codes that expire quickly punish slow typists, screen reader users and people with cognitive disabilities. Timing must be adjustable or extendable where security permits (WCAG 2.2.1).

Blocked paste and autofill. Disabling paste in code fields stops password managers and assistive tools from helping. Use autocomplete="one-time-code" and allow paste (1.3.5, and 3.3.8 Accessible Authentication).

Puzzle and recognition steps. Image selection challenges and distorted text are cognitive function tests. WCAG 2.2 SC 3.3.8 requires an alternative that does not rely on them.

Selfie, liveness and document capture. KYC onboarding often requires a live selfie with head movements and a photo of an ID with exact framing. People with low vision, tremor, limited mobility or who use a wheelchair-mounted phone can struggle. Without a manual upload or assisted-review route, they are blocked.

Lost focus and silent errors. Redirects to an issuer's 3-D Secure page, often inside an iframe, can drop keyboard focus or hide errors from screen readers. Error messages and status changes must be programmatically announced (3.3.1, 3.3.3, 4.1.3).

Redundant entry. Asking again for information already supplied in the same process breaks WCAG 2.2 SC 3.3.7.

What good looks like: offer a choice of methods

Worldline's guidance on accessible authentication is a useful practitioner reference. Among its points:

• Offer strong authentication methods that do not depend on a smartphone, such as browser-based soft tokens or FIDO authenticators that need no extra device.
• Use biometrics as an easier option for people with motor impairments.
• For blind users entering a PIN, a dynamic virtual keyboard with vocalisation is one approach.
• Keep authentication pages simple and short; the article notes customers typically spend under two seconds reading them.
• Build accessibility in from design, train designers and developers on WCAG, and test with disabled people using assistive technologies.

The same piece cites policy direction pointing the same way: the European PSD3 and payment services regulation proposals of June 2023 state that authentication should not depend on a single technology, device or mechanism, for instance possession of a smartphone, and a French banking charter from October 2022 asks providers to offer at least one strong authentication solution as an alternative to the banking app, at no extra cost. Check the current status of these texts before citing them.

A decision table for common methods

Method	Common barriers	Mitigation
SMS one-time code	Needs mobile signal and phone; short expiry; blocked paste	Longer expiry, one-time-code autofill, voice or alternative channel
App push approval	Requires compatible smartphone and accessible app	Accessible app testing; offer non-phone alternative
Hardware token	Small display and buttons; cost	Audio output, large display, no extra fee
Biometrics	Not usable by everyone; capture difficulties	Never the only option; fallback method
FIDO / passkey	Device dependence; unfamiliar flow	Clear instructions; multiple authenticator types
Selfie / liveness (KYC)	Sight, motor, positioning demands	Assisted capture, manual review route
Phone call verification	Excludes deaf and hard-of-hearing users	Text-based alternative

Identity verification and KYC specifics

• Offer document upload as well as live camera capture, and allow assisted completion by a trusted person where the regulation allows.
• Give guidance during capture in text and audio, not only through on-screen overlays.
• Avoid time limits on liveness steps, or allow retries without penalty.
• Provide a human-assisted route (video relay, text chat, in person) and make sure it is itself accessible.
• Do not require motion or gestures without an alternative (WCAG 2.5.1, 2.5.7).

Merchant versus provider responsibility

Many merchants rely on a payment service provider's hosted page or an issuing bank's 3-D Secure challenge. You may not control the challenge, but you control which provider you choose, how it is embedded, and what you do when it fails. Ask for conformance evidence, test the full flow with assistive technology in your own configuration, and keep records. EqualWeb's one-year review notes that authorities ask sellers to demonstrate conformance, and Taylor Wessing observes that early enforcement emphasises remediation over penalties. A documented testing programme and a remediation plan put you in a stronger position than a vendor's marketing claim.

A test checklist

1. Complete a purchase and a sign-in using only the keyboard.
2. Complete them with NVDA or VoiceOver, including the 3-D Secure step.
3. Confirm focus moves into and out of any iframe or redirect correctly.
4. Check code fields allow paste and autofill, and that timeouts can be extended.
5. Verify error and success messages are announced.
6. Confirm at least two authentication routes exist, one not requiring a smartphone.
7. For KYC, test with manual upload and an assisted-review path.
8. Test at 200% and 400% zoom on mobile and desktop.
9. Document findings, vendor evidence and exceptions in your conformance file.

The bottom line

Accessible authentication is a design-for-choice problem. Give customers more than one way to prove who they are, remove time pressure and puzzle steps, make sure every step speaks to assistive technology, and keep a human fallback. Done well, it also reduces abandoned payments for everyone.