Fintech App Accessibility: Authentication, Forms, and Error Prevention Under the EAA

The EAA does not invent its own technical rules. It points to the harmonized European standard EN 301 549, which adopts WCAG Level A and AA as the baseline for web content and mobile apps. So when someone asks 'what does the EAA require,' the operational answer is: WCAG 2.2 A and AA, plus the documentation and accessibility-statement obligations.

WCAG 2.2 matters here specifically because it added criteria that hit financial flows directly: 3.3.8 Accessible Authentication (Minimum, AA), 3.3.7 Redundant Entry (A), 2.5.8 Target Size Minimum (AA, 24 by 24 CSS pixels), and 2.4.11 Focus Not Obscured Minimum (AA). It also removed 4.1.1 Parsing, so chasing that retired criterion is wasted effort. If you last certified against WCAG 2.1, you have a real gap to close. See the European Accessibility Act overview and how it maps through EN 301 549.

3.3.8 is the criterion most fintech teams fail without realizing it. The rule: no step in your authentication process may rely on a cognitive function test, such as remembering a password or transcribing a one-time code, unless you provide an alternative that does not, or a mechanism to assist.

The trap is the 'enter the 6-digit code from your authenticator app' screen. Reading a rotating TOTP code and retyping it into a field is a transcription test, which is exactly what 3.3.8 targets. The same applies to 'type the code we SMS'd you' if you block paste.

Patterns that pass

• Passkeys (WebAuthn): biometric or device unlock, with no memorization or transcription. The strongest compliant option.
• Allow paste and browser or password-manager autofill on every OTP and password field. Avoid per-character split inputs that defeat paste, unless the whole value can still be pasted at once.
• Magic links and federated sign-in (Sign in with Apple or Google): the user proves identity without recalling or copying anything.
• Email or SMS codes that the user can copy and paste, rather than memorize and retype.

What is explicitly exempt: recognizing objects in images and identifying non-text content the user provided. So an object-recognition CAPTCHA can technically meet the Minimum criterion, but distorted-text CAPTCHAs and puzzle challenges fail. For a regulated product, prefer invisible bot defense (risk and device signals) so no user meets a cognitive test at all.

3.3.4 Error Prevention (Legal, Financial, Data) is the AA criterion written for exactly your product. For any submission that is financial, legal, or that modifies or deletes user-controlled data, you must provide at least one of: reversibility, error checking with a chance to correct, or a confirmation step before the action is final.

Concretely, before a money transfer completes, show a review screen with the recipient, amount, currency, and fees, and require an explicit confirm. An IBAN typo that quietly sends 5,000 EUR to the wrong account is the precise harm this criterion exists to prevent. A confirmation step that a screen reader announces clearly, with a real, focusable Confirm button, satisfies both 3.3.4 and the surrounding form criteria.

Pair it with 3.3.7 Redundant Entry (A): do not force users to re-key information they already provided in the same flow, such as re-typing the IBAN to 'confirm' it. Re-entry is permitted only where essential, for example a password re-confirmation. Auto-populate or let them reuse the prior value instead.

Authentication and confirmation live inside forms, and the supporting criteria are where automated scans catch the most issues. The non-negotiables for a financial form:

• 3.3.1 Error Identification (A) and 3.3.3 Error Suggestion (AA): identify the field in error in text, not by color alone, and suggest a fix ('Sort code must be 6 digits') rather than a generic 'invalid input'.
• 4.1.3 Status Messages (AA): announce validation results and 'Payment sent' confirmations via an ARIA live region so a screen reader user hears them without moving focus.
• Contrast: 4.5:1 for body text, and 3:1 for large text (>=18pt, or 14pt bold) and for UI component boundaries like input borders and focus rings. Low-contrast gray placeholder labels are a recurring failure. Check yours with the contrast checker.
• 2.5.8 Target Size Minimum (AA): interactive targets at least 24 by 24 CSS pixels, which matters for dense number pads and stepper controls.
• Programmatic labels and autocomplete tokens (autocomplete="cc-number", "email", "one-time-code") so assistive tech and password managers can fill correctly.

Treat 1.4.13 Content on Hover or Focus (AA) too: tooltips that explain a fee or a field must be dismissible, hoverable, and persistent, not vanish the moment a pointer or focus shifts.

If you are starting from a WCAG 2.1 codebase, sequence the work by risk. First, audit your auth flow against 3.3.8: enable paste, ship passkeys or a federated sign-in option, and remove any text CAPTCHA. Second, add or verify the confirmation step on every money-moving and account-changing action for 3.3.4. Third, harden the forms: error text, live regions, contrast, and target size.

Automated tools catch contrast, labels, target size, and live-region presence quickly; the authentication and error-prevention logic needs manual testing with a keyboard and a screen reader. Run a free baseline scan with AccessScan at /#scan to see where your auth and payment flows stand before you commit the engineering work.