Digital Banking Accessibility and the EAA

Why banking and accessibility intersect badly

Banking is supposed to protect people. Managing your money — checking balances, making payments, applying for loans, reviewing statements — is a fundamental part of modern financial life. When digital banking platforms are inaccessible, the people most likely to be excluded are often those with the fewest alternatives.

Elderly customers with age-related vision loss who depend on screen readers. People with motor disabilities who can’t use a mouse. Deaf customers who cannot use phone-based customer service and need to conduct everything online. These are real users, present in every bank’s customer base, and the European Accessibility Act now makes their access a legal requirement.

Banking and financial services are explicitly named in the EAA’s scope. The deadline of June 28, 2025 applied to financial services just as it did to ecommerce and telecoms. For banks, this is not optional.

The most common accessibility failures in banking

Inaccessible login and authentication

Login flows are the front door to every banking service, and they frequently have accessibility problems:

• CAPTCHA with no audio alternative, leaving blind users unable to pass authentication
• One-time password (OTP) flows that rely on SMS — some users with cognitive disabilities have difficulty managing multi-step authentication under time pressure
• Session timeouts that don’t warn users before ending a session, and that can’t be extended — users who take longer to complete tasks (which includes many users with disabilities) find themselves repeatedly logged out

WCAG 2.1 2.2.1 Timing Adjustable (Level A) requires that session time limits be adjustable or extendable.

Unlabeled and inaccessible form fields

Banking involves a lot of forms: fund transfers, payment setup, address changes, loan applications. The same form accessibility failures that affect any website are particularly costly in banking — a blind user who can’t complete a payment form cannot access a core banking service.

The most common failure: form fields without properly associated <label> elements. Without a label, screen readers announce “edit text, blank” and the user doesn’t know what to enter. We cover this in detail in our guide to accessible error messages and it applies equally to standard form fields.

Inaccessible PDF statements and documents

Monthly statements, terms and conditions, loan agreements, product information documents — banks produce enormous volumes of PDF content, and almost all of it is generated from systems that produce inaccessible PDFs.

An accessible PDF has a tagged structure, a logical reading order, meaningful heading levels, and alt text for any images containing information. A PDF exported from a Word document or generated by a report engine without accessibility processing typically has none of these. For more on this see our PDF accessibility guide.

Poor keyboard navigation in transaction flows

Transfer funds, set up a payee, view transaction history — complex, multi-step flows that are commonplace in banking often contain components that only work with a mouse: dropdowns that don’t respond to keyboard input, date pickers with no keyboard support, confirmation dialogs that trap keyboard focus.

Inaccessible mobile apps

The EAA covers mobile applications as well as websites. Banking apps in particular tend to have native components that behave differently from web elements, with accessibility layers that require explicit work to implement correctly.

Common mobile banking failures include: interactive elements too small to tap reliably (WCAG 2.5.5 Target Size, Level AAA, suggests 44×44 CSS pixels minimum), insufficient contrast in custom UI themes, and custom tab bars or navigation patterns that don’t expose their state to accessibility APIs.

Insufficient contrast in interface design

Banking UI design often tends toward minimalism and the use of light grey on white for secondary information — account numbers, transaction references, supporting text. These frequently fail WCAG 1.4.3 Contrast Minimum (Level AA), which requires a 4.5:1 ratio for normal text.

The trust cost of inaccessibility

Banking is a trust relationship. When a disabled user can’t access their account statements, can’t set up a direct debit independently, or is forced to call a phone line (which may itself have accessibility barriers) to complete tasks their non-disabled peers do online, the message is clear: this service wasn’t designed for you.

The reputational cost of that message, in a sector where customer trust is foundational, is significant. The legal cost under EAA is increasingly concrete. And the practical cost — the customers who quietly move to a competitor that works with their assistive technology — is harder to measure but very real.

Where to start

The EAA requires a WCAG 2.1 Level AA standard across your digital services. For most banks, achieving this across all digital touchpoints simultaneously is not feasible — there’s too much surface area. Prioritize by customer impact:

Highest priority:

1. Login and authentication flows — if customers can’t get in, nothing else matters
2. Core account management: view balance, view transactions, transfer funds
3. Statement downloads and PDF documents

Second priority:

1. Payment setup and management
2. Loan and product application flows
3. Mobile app core flows (matching the web priorities)

For each area, run both automated scanning (which catches contrast, labeling, and structural issues) and manual testing with assistive technology (which catches keyboard navigation failures, focus management problems, and screen reader announcement issues).

Run a free scan of your public-facing banking website to see where you currently stand on the automatable issues. For a comprehensive review of authenticated banking flows — where most of the complex accessibility failures live — talk to our team about a structured audit program.