EAA banking compliance is not optional for most retail providers: consumer banking is one of the services the European Accessibility Act names directly. The Act lists "consumer banking services" as a covered service (Directive (EU) 2019/882, Article 2(2)(d)), and it defines that term broadly to include credit agreements, payment services, payment accounts, and electronic money (Article 3(28)). So an online banking portal, a mobile banking app, the sign-up and identity-verification flow, and the ATMs and card terminals a bank operates are all in scope. The Act has applied across member states since 28 June 2025 (European Commission).
The technical bar is WCAG 2.1 Level AA for digital surfaces, applied through the harmonized standard EN 301 549, plus that standard's hardware rules for physical terminals. Banking also carries one requirement no other sector has: consumer banking information must be written at a language complexity no higher than level B2 (Annex I, Section IV). An automated scan finds the machine-detectable defects on your web and app screens fast. Keyboard operation, screen-reader output, and the plain-language duty need a person. No widget makes a bank conformant on its own.
Here is what applies, and how to check it.
Does the European Accessibility Act apply to banks?
Yes, to the consumer-facing parts. The EAA is Directive (EU) 2019/882, and Article 2 lists the consumer services it covers: electronic communications, audiovisual media access, certain transport, e-books, e-commerce, and consumer banking services (Article 2(2)). Banking is on that list by name, which removes the "are we in scope?" guesswork that other sectors have to work through.
What counts as a "consumer banking service" is set out in Article 3(28). It is the provision to consumers of:
- credit agreements under the Consumer Credit or Mortgage Credit Directives;
- certain investment services and activities under MiFID II;
- payment services as defined in the second Payment Services Directive (PSD2);
- services linked to a payment account under the Payment Accounts Directive; and
- electronic money under the E-Money Directive (Article 3(28)).
The point of that list is reach. Retail current accounts, consumer loans, cards, and payment apps are all inside it. The Act also makes clear that the steps around a transaction are in scope, not just the transaction screen: identification methods, electronic signatures, and payment services are named as things that must be accessible because they are necessary to conclude a banking transaction (Recital 40). A login flow that only works with an inaccessible one-time-code step is a conformance problem even if the account screens behind it are clean.
Which banking products and channels are covered?
Split a bank's estate into two legal buckets, because the EAA regulates products and services under slightly different rules.
Services (the digital channels). Online banking on the web, the mobile banking app, the public marketing and product pages, account opening, and customer support surfaces are all consumer banking services. These are judged against the accessibility requirements for services in Annex I, which for web and app content resolve to WCAG 2.1 AA through EN 301 549.
Products (the physical and self-service hardware). The EAA separately covers a set of products, including "self-service terminals... namely payment terminals and... automated teller machines" (Article 2(1)). So a bank's ATMs and the card terminals it provides are regulated in their own right. These have to meet the product requirements in Annex I, and EN 301 549 carries hardware provisions (physical keys, tactile feedback, headphone jacks for audio output, reachability) that a web-only reading of the standard misses.
The practical consequence: a bank cannot treat accessibility as a website project. The same programme has to reach the app, the ATM fleet, the terminals, and the identity and signing steps that stitch a journey together.
What is the special "level B2" language rule for banking?
Banking is the one sector where the EAA regulates how clearly you write, not only how you code. Annex I, Section IV requires that information provided about consumer banking services be made understandable, at a level of text complexity no higher than level B2 (upper intermediate) of the Council of Europe's Common European Framework of Reference for Languages (Annex I, Section IV).
In plain terms: the language in your account terms, fee explanations, transaction confirmations, and security prompts has to be readable by someone at an upper-intermediate reading level, not buried in legal or financial jargon. This sits alongside the WCAG requirements, it does not replace them. A page can pass every automated contrast and label check and still fall short here, because readability is a human judgement. It is worth flagging to compliance and content teams early, because it usually means rewriting live copy, which takes longer than a code fix.
What accessibility standard do banks have to meet?
WCAG 2.1 Level AA for digital content, via EN 301 549, plus that standard's hardware chapters for terminals. The EAA states the outcome, that a service be perceivable, operable, understandable, and robust, but it does not spell out the technical checks. For those it relies on the harmonized standard, and meeting the relevant parts gives a presumption of conformity with the law.
The version cited today, EN 301 549 v3.2.1, incorporates WCAG 2.1 Level AA for web content (ETSI). For an online banking app that means the familiar things done correctly: every control reachable and operable by keyboard, a visible focus indicator, form fields with real labels, sufficient contrast, status and error messages announced to assistive technology, and no keyboard traps in the transfer or approval dialogs. For ATMs and terminals, the hardware clauses add tactile and audio requirements a screen-only audit will not surface. A v4.x update referencing WCAG 2.2 is expected, but until it is formally cited in the Official Journal, 2.1 AA is the legal bar. Building to 2.1 AA now, while watching the 2.2 additions such as focus appearance and target size, keeps the eventual switch small.
How do banks check and document accessibility?
Work in two layers on the digital channels, and treat the hardware as its own track.
Layer one: automated testing. Run your web and app surfaces through a scanner built on a real rules engine, covering the journeys that matter: log-in and identity verification, viewing balances and statements, making a payment or transfer, and applying for a product. This clears the high-frequency, machine-detectable defects quickly, such as missing labels, low contrast, missing page language, duplicate IDs, and basic ARIA mistakes. Banking apps are usually single-page and heavily stateful, so the scanner has to test the rendered view after each step, not just the first HTML response.
Layer two: manual review. A person checks what a machine cannot judge. Can you complete a transfer with the keyboard alone? Does focus move sensibly through a multi-step approval, and return after a confirmation dialog closes? Does a screen reader announce a pending or declined state? Is the one-time-code entry operable without a mouse and without a hard time limit that a screen-reader user cannot meet? And separately, does the copy clear the B2 readability bar?
How much does each layer catch? Deque's analysis of more than 2,000 audits found automated testing identified about 57% of issues by volume; measured as a share of WCAG success criteria, automation lands closer to 30% (Deque, 2021). Either way, much of conformance only appears under human review. Scan first to clear the obvious defects, then run a structured manual pass with our WCAG checklist so the rest does not slip through.
Then document it. The EAA expects an in-scope provider to explain how the service meets the accessibility requirements, and financial regulators and enterprise buyers will ask for a conformance report against EN 301 549. An honest accessibility statement records your conformance level, lists known limitations, gives a plan and timeline, and offers a feedback contact. Documented effort is what the law asks for, not a perfect score, and no tool can promise the score anyway. In 2025 the US Federal Trade Commission approved a final order requiring the overlay vendor accessiBe to pay $1 million over claims that its widget could make any site WCAG compliant (FTC, April 2025). Full conformance needs human review and real fixes in your own code.
Frequently asked questions
Does the EAA apply to all banks?
It applies to consumer banking services, which the Act names directly and defines to include credit, payment services, payment accounts, and e-money. A provider offering those to consumers in the EU is in scope, wherever it is based. The narrow microenterprise exemption (fewer than 10 staff and turnover or balance sheet of €2 million or less) rarely fits a bank.
Are ATMs covered by the European Accessibility Act?
Yes. The EAA regulates self-service terminals, naming payment terminals and automated teller machines as products in Article 2(1). They must meet the product accessibility requirements in Annex I, which through EN 301 549 include hardware provisions such as tactile controls and audio output, on top of any on-screen software.
What WCAG version does online banking need to meet?
The EAA points to EN 301 549 v3.2.1, which incorporates WCAG 2.1 Level AA. A later version referencing WCAG 2.2 is expected, but until it is formally cited in the Official Journal, 2.1 AA is the legal bar for web and app content.
What is the level B2 language requirement?
Annex I, Section IV requires information about consumer banking services to be understandable at a text complexity no higher than level B2 (upper intermediate) of the Common European Framework of Reference for Languages. In practice, account terms, fees, and security prompts must be written in plain language, not dense legal or financial jargon.
Can an overlay or accessibility widget make a bank compliant?
No. Automated tools and overlays catch part of the picture, but keyboard operation, screen-reader behaviour, hardware terminals, and the plain-language duty all need human work. The FTC's 2025 order against accessiBe followed claims that a widget alone could make a site WCAG compliant.
See where your banking channels stand
The fastest way to turn EAA banking compliance from a worry into a plan is to see your actual issues. Run a free scan of your online banking and sign-up surfaces to find the machine-detectable problems, then work through the manual checklist and the B2 readability review for the rest. You will know what to fix, in what order, and what to put in your conformance report.
Pavel Charkasau, founder, wcagc.com. Last updated 10 July 2026.
Sources
- Directive (EU) 2019/882 (European Accessibility Act), EUR-Lex — consumer banking services as a covered service (Article 2(2)(d)); definition (Article 3(28)); self-service terminals, payment terminals and ATMs as products (Article 2(1)); identification, e-signature and payment services (Recital 40); level B2 language requirement (Annex I, Section IV). Accessed 10 July 2026.
- European Accessibility Act, European Commission — application from 28 June 2025. Accessed 10 July 2026.
- EN 301 549 v3.2.1, ETSI — incorporates WCAG 2.1 AA (Chapter 9); hardware requirements (Chapter 8); Annex C conformance format. Accessed 10 July 2026.
- Automated testing identifies 57% of accessibility issues, Deque — automated coverage by volume and by success criteria. Accessed 10 July 2026.
- FTC approves final order requiring accessiBe to pay $1 million, Federal Trade Commission — deceptive WCAG-compliance claims. Accessed 10 July 2026.