Online Banking Accessibility Under the EAA: What Banks and Fintechs Must Do Now

Banking is one of the few sectors the European Accessibility Act names explicitly. That is not a technicality - it is a signal about enforcement priority. Consumer banking services are explicitly named in Article 2 of Directive 2019/882, which means retail banking interfaces fall squarely inside the rule. The deadline passed on 28 June 2025. National market surveillance authorities are now active, complaint mechanisms are open, and the first enforcement actions are already in motion.

If your organisation provides banking, payment, or financial services to EU consumers - regardless of where you are headquartered - this post maps exactly what is in scope, where the common failures are, and what a credible remediation plan looks like.

---

Why banking is a high-priority target

The EAA was designed to harmonise accessibility requirements across the single market. Banking was included because financial exclusion is one of the most consequential forms of digital exclusion: if a person with a disability cannot independently log in, authenticate, or read a statement, they cannot manage their own money.

According to the 2025 Finnoscore study, the majority of banks surveyed still fail to meet accessibility requirements, and the average international accessibility score has actually decreased by 1.5%. That is the baseline regulators are starting from.

Individual EU Member States have transposed the EAA into their national legal frameworks, and enforcement began in June 2026. Non-compliance with the EAA can lead to fines, market restrictions, and lost business opportunities.

---

What is in scope: the full customer journey

The rule covers far more than the public marketing website. Anything a consumer uses to access or manage a banking service is in scope, including public websites and account login pages, mobile banking apps on iOS and Android, authentication flows such as multi-factor authentication and biometric prompts, transaction confirmation screens and receipts, account statements and downloadable PDFs, customer support chat, contact forms, and chatbots, as well as ATMs and self-service kiosks.

In short, any product or service that enables a consumer to manage their finances, open an account, transfer funds, or communicate with their bank must be accessible under the EAA.

The table below maps the customer journey to the specific touchpoints in scope:

A note on ATMs and physical terminals

Existing cash machines and payment terminals may continue to be operated until the end of their economic life - in individual cases until 2040. However, the EAA defines specific accessibility requirements for new ATMs and self-service kiosks installed in the EU after June 28, 2025, which provide consumer services like payment, ticketing, check-in, banking services, and access to passenger travel information.

EN 301 549 includes additional requirements for hardware and devices - for example, compatibility with assistive technologies, tactile indicators on keypads, and auditory feedback for kiosks or ATMs. Speech output is essentially mandatory for transaction-based systems to allow users to verify receipts and actions.

---

The technical standard: EN 301 549 and WCAG 2.1 AA

Banks offering consumer services to EU customers must align with EN 301 549, which references WCAG 2.1 Level AA as the technical standard for web and mobile interfaces.

Following EN 301 549 creates a "presumption of conformity" with the EAA - meaning regulators will presume your products meet legal requirements if you comply with the standard.

The current version, EN 301 549 v3.2.1, aligns with WCAG 2.1 Level AA and extends beyond web content to address non-web software (desktop applications, mobile apps, operating systems), non-web documents (PDFs, Word documents, spreadsheets), and hardware (self-service terminals, kiosks, telecommunications equipment).

The four POUR principles - Perceivable, Operable, Understandable, Robust - apply across every touchpoint. For banks, this means that many common digital and physical customer touchpoints must be perceivable, operable, understandable, and robust for users with disabilities.

Many banks target WCAG 2.2 AA because it adds criteria that further support customers with cognitive and motor disabilities, and because future revisions to EN 301 549 are expected to incorporate 2.2. Targeting 2.2 now is the pragmatic choice - it covers 2.1 AA entirely and future-proofs your work.

---

Where banks most often fail

Many banks view accessibility in isolation, focusing on specific systems like the website or the app. In practice, banking does not work this way. A typical transaction consists of several consecutive steps: login, authentication, the transaction itself, and documentation. These steps are interconnected and are often managed by different underlying systems. The critical factor is not whether individual components are accessible, but whether the entire workflow functions.

Here are the failure patterns that appear most consistently across banking audits:

Authentication flows

Authentication is where banks most often fall short. Time-limited one-time passcodes, CAPTCHAs without accessible alternatives, and biometric prompts that lack screen reader support all create issues for customers who rely on assistive technology.

Session timeouts should provide warnings with the ability to extend. Never rely on a single visual-only verification method as the sole authentication path.

Fix: Offer at least one path that avoids puzzle-solving or memory tests. Allow copy-paste/auto-fill and support device prompts, passkeys/WebAuthn, or one-time codes. If a CAPTCHA is required, provide an accessible, non-puzzle alternative with clear instructions.

Inaccessible PDF statements

Documents (commonly PDFs) that are part of the product or services covered by the EAA also have to be accessible if they are intended to be read by users as part of the service. This includes terms and conditions and similar documents, but also interactive form documents like loan application forms in PDF.

PDFs for statements, rate sheets, and disclosures should be tagged, follow logical reading/tab order, use real text (not images), and include labeled fields/links so they work with screen readers and keyboard navigation.

For a detailed remediation approach, see our guide to accessible PDF documents.

Unlabelled form controls and poor contrast

Account dashboards and payment forms frequently ship with unlabelled buttons, missing form field labels, and text that fails the 4.5:1 contrast ratio required at WCAG 2.1 AA. Account dashboards often use data visualisations (charts, graphs) without text alternatives, leaving screen reader users unable to understand their financial status. Transaction tables frequently lack proper header associations, making it impossible to correlate amounts, dates, and descriptions.

Transaction timeout limits

Session timeouts that expire without warning can cause users with motor disabilities to lose unsaved work mid-transaction. The fix is straightforward: warn users before a session expires and give them a mechanism to extend it.

Third-party components

The bank is the service provider under the EAA, so the legal responsibility sits with the bank, not the vendor. Payment widgets, identity verification SDKs, and chatbot platforms embedded in your product are your responsibility. Procurement teams should request a current Accessibility Conformance Report (ACR) from every vendor and verify the claims through independent evaluation.

---

The accessibility statement obligation

The EAA requires an accessibility statement that explains how the service meets the requirements, lists any content that is not accessible, and provides a way for customers to report issues. Banks should publish this statement somewhere customers can find it from any page.

The statement is not a formality. National authorities can request it during an investigation, and customers can use it to file complaints.

Organisations subject to the EAA must publish accessibility statements explaining how their products and services meet accessibility requirements. These statements should outline known accessibility issues, provide mechanisms for user feedback, and describe planned accessibility improvements.

In the Netherlands, the obligation goes further: if your banking service or financial e-commerce service is not fully accessible in accordance with the EAA, you must notify the Dutch Authority for the Financial Markets (AFM). It depends on how serious the impact is on your consumers whether you need to report within one week or one month.

For guidance on what a compliant statement must contain, see our post on writing an EAA accessibility statement.

---

Penalties and enforcement reality

The EAA does not set a single EU-wide penalty. Each member state sets its own regime, and the directive requires penalties to be "effective, proportionate, and dissuasive."

At the top tier, Spain (up to €1,000,000 plus two-year operational bans), Hungary (up to €1,260,000 or 5% of turnover), and the Netherlands (up to €900,000 or 10% of turnover) and Sweden (approximately €900,000) have the highest financial exposure.

For banking specifically, the Netherlands is the most significant jurisdiction to watch. The AFM has been designated as the authority for supervising banking and financial e-commerce services. In 2026, the AFM expects institutions to adopt a proactive approach: report non-compliance, indicate what steps you are taking, and structurally embed accessibility in your organisation.

In Germany, Germany transposed the EAA through the Barrierefreiheitsstärkungsgesetz (BFSG), which came into force on June 28, 2025. The Bundesnetzagentur can impose fines up to €100,000 for each individual accessibility violation. That per-violation structure matters: a website with 15 accessibility failures could theoretically face €1,500,000 in aggregate penalties, though regulators typically apply proportionality.

Germany also carries a private enforcement risk: within weeks of the BFSG taking effect, e-commerce operators in Germany began receiving private warning letters (Abmahnungen) citing accessibility violations. These letters were not sent by regulators or disability organisations - they came from opportunistic law firms using Germany's competition law framework. Early enforcement activity has focused on e-commerce platforms and banking apps, sectors where Germany sees the highest consumer impact.

If your service operates across multiple EU markets, each national authority can enforce independently. A non-compliant website serving customers in France, Germany, and Spain could face enforcement actions from all three countries simultaneously.

---

What to do now: a prioritised action plan

Take stock of your bank's digital experiences to understand the full scope of assets covered by the EAA. Remember that web accessibility is just one part of EAA compliance in banking: banks must also ensure that mobile apps, digital documents, and ATMs are usable by people with a range of disabilities.

---

The bottom line

Consumer banking is explicitly named in EAA Article 2, with enforcement active since 28 June 2025. The scope is broad - every digital and physical touchpoint a consumer uses to manage their money - and the standard is clear: EN 301 549, referencing WCAG 2.1 AA for web and mobile, with separate hardware provisions for ATMs and kiosks.

The banks that will navigate this well are the ones treating it as a product quality problem, not a compliance checkbox. The AFM expects institutions to adopt a proactive approach: report non-compliance, indicate the steps you are taking, and embed accessibility structurally within your organisation. After all, accessibility is not only a legal requirement - it is also a lasting part of serving the customer's best interests.

Start with an audit of your authentication and payment flows. Fix your PDF templates. Publish your accessibility statement. Then build the processes that keep new releases from regressing. The path is well-defined; the question is how quickly you walk it.