EAA Banking Compliance: How the European Accessibility Act Applies to Banking and Payment Services

The EAA explicitly names consumer banking services and payment services as in-scope. In practice that means the customer-facing digital surfaces a retail user touches: the public website where someone opens a current account, the online banking portal, the mobile banking app, payment initiation and confirmation screens, and the self-service terminals and ATMs that fall under the Act's hardware provisions.

Scope is broad but not unlimited. It centres on services offered to consumers — not bespoke corporate treasury platforms used purely B2B. A useful test: if a natural person can sign up for and operate the service, assume it is covered. Microenterprises (fewer than 10 staff and either annual turnover or balance-sheet total not exceeding €2 million) that provide services are exempt, but that exemption rarely helps a regulated credit or payment institution.

The directive also reaches e-money and account-information services delivered under PSD2. If your fintech provides a regulated payment or account-aggregation service to consumers in the EU, you are inside the perimeter. See our overview of the European Accessibility Act for how the same rules apply across other sectors.

In practice, conformance is demonstrated through the harmonised European standard EN 301 549, which incorporates the Web Content Accessibility Guidelines at Level A and AA. The operative target for a 2025 build is WCAG 2.2 Levels A and AA.

WCAG is organised around four principles — Perceivable, Operable, Understandable, and Robust. For banking interfaces, a handful of success criteria do the heavy lifting:

• Contrast (1.4.3 / 1.4.11): at least 4.5:1 for normal text, and 3:1 for large text (at least 18pt, or 14pt bold) and for UI components such as input borders and toggle states. Branded greys on white are a frequent failure in transaction tables.
• Keyboard operability: every flow — including a payment-confirmation modal and a date picker for scheduling transfers — must work without a mouse.
• Labels and error handling: form fields need programmatic labels, and validation errors (a rejected IBAN, an insufficient-funds warning) must be announced, not conveyed by colour alone.
• Robust markup: name, role, and value exposed to assistive technology, which matters for custom-built React or native components.

WCAG 2.2 added several criteria that hit financial UIs directly: 2.4.11 Focus Not Obscured (Minimum, AA) — sticky headers or cookie banners must not hide the focused field; 2.5.7 Dragging Movements (AA) — any slider-to-confirm payment needs a single-pointer alternative; 2.5.8 Target Size (Minimum, AA) — tap targets of at least 24×24 CSS pixels, which catches cramped numeric keypads and dense action menus; 3.2.6 Consistent Help (A); and 3.3.7 Redundant Entry (A), so a multi-step onboarding flow should not force the user to re-type data they already gave. WCAG 2.2 also obsoleted 4.1.1 Parsing — it is no longer a requirement.

The single most consequential addition for banking is 3.3.8 Accessible Authentication (Minimum, AA). It requires that a cognitive function test — remembering a password, transcribing a one-time code, solving a puzzle, or identifying objects in images — is not the only way to authenticate, unless an alternative is provided, or the test has a mechanism to assist, or it relies on recognising objects or user-provided non-text content.

This collides with how strong customer authentication is often built. A login that forces the user to memorise and re-enter a code, a CAPTCHA gating account access, or a step that blocks the browser from pasting an OTP all risk failing 3.3.8. Compliant patterns include: allowing password managers and paste into OTP fields; supporting device-based authenticators, passkeys, or biometrics as an alternative; and letting an authenticator app or push approval satisfy a factor without a transcription test. Crucially, SCA under PSD2 and 3.3.8 are compatible — possession and inherence factors generally avoid cognitive-function tests, so the fix is design, not a regulatory conflict.

Audit your login, transaction-signing, and step-up flows specifically against this criterion, then structure the rest of the review across the remaining WCAG 2.2 success criteria.

The EAA requires providers to document how a service meets the accessibility requirements. For digital banking, the practical deliverable is a published accessibility statement that states the conformance target (EN 301 549 / WCAG 2.2 AA), lists known limitations honestly, and gives users a feedback route and an enforcement-contact path. Vague claims that you take accessibility seriously do not satisfy this — the statement should be specific and dated.

Accessibility is not a one-time certification. Each release of a banking app can introduce regressions — a redesigned card carousel, a new KYC vendor widget, an updated charting library. Build automated checks into CI and pair them with periodic manual audits using a keyboard and screen reader. You can draft a starting document with our accessibility statement generator.

The core requirements have applied since 28 June 2025. There is no general grace period for new consumer banking and payment services — they are expected to be accessible now. Limited transition arrangements exist for certain self-service terminals already in use and for some pre-existing service contracts, but these are narrow and should not be treated as a reason to delay digital remediation.

Enforcement is handled by each member state's designated authority. Consequences can range from corrective orders to financial penalties and, for non-compliant products, withdrawal from the market. For a regulated institution, the reputational and supervisory exposure usually outweighs any penalty itself.

A realistic sequencing for a product team:

• Run an automated baseline scan to surface machine-detectable issues across your highest-traffic flows — start with a free pass using AccessScan's free accessibility checker.
• Fix the high-frequency basics: contrast, form labels, focus order, link and button names, keyboard traps.
• Manually test authentication, payment confirmation, and onboarding against WCAG 2.2 — especially 3.3.8, 2.5.8, and 2.4.11.
• Publish a specific, dated accessibility statement and wire accessibility checks into your release pipeline so new features ship compliant.

Treat EAA banking compliance as a product-quality programme, not a legal checkbox. The same work that satisfies the directive removes friction for every customer.