The EU Accessibility Act and your banking app

Accessibility arrives in most banking projects as a late-stage audit against a checklist, which is roughly the worst possible way to meet it. The European Accessibility Act is worth reading properly instead, because two of its requirements for banking are not in any generic WCAG checklist, and one of them lands squarely on the part of the app your security team owns.

This is not legal advice. It is an engineering read of Directive (EU) 2019/882 and the standard behind it. Quoted passages below are from the directive text and from EN 301 549 V4.1.1 itself.

Your login screen is in scope, by name

Annex I of the directive sets additional requirements for specific services. For consumer banking services, it requires — and this is the directive's own wording — "providing identification methods, electronic signatures, security, and payment services which are perceivable, operable, understandable and robust".

Read what that actually says. Perceivable, operable, understandable and robust are the four WCAG principles. The directive applies them, by name, to identification methods and security. Your login, your step-up authentication and your transaction authorisation are not adjacent to the accessibility obligation. They are the named subject of it.

This matters because authentication screens are the ones least likely to have been designed with accessibility in mind. They are usually specified by a security function, built to a threat model, and reviewed for whether they can be defeated rather than for whether they can be used. Common patterns that fail here: an OTP field that steals focus and breaks screen-reader flow, a biometric prompt with no equivalent path, error messages that say only "authentication failed", and a CAPTCHA with no accessible alternative.

The sharpest case is the timed one. We wrote recently about how push-based second factor works in OBDX, where a transaction waits on the user tapping accept or reject inside a window that defaults to five minutes. A countdown that cannot be extended is an operability problem for anyone who needs longer — someone using a screen reader to understand what they are approving, or with a motor impairment, or simply switching apps to read a code. WCAG has a timing criterion precisely for this, and a transaction timer is exactly the kind of thing that gets exempted on security grounds without anyone checking whether it needs to be.

You do not have to abandon the timer. You do have to be able to justify its length, warn before it expires, and offer a path for someone who misses it that is not "start again and fail again".

The B2 rule

The second banking-specific requirement is one we have never seen in an accessibility checklist. The directive requires "ensuring that the information is understandable, without exceeding a level of complexity superior to level B2 (upper intermediate)".

B2 is a Council of Europe language level. The directive is placing a reading-level ceiling on the information a consumer banking service presents.

That is not a code obligation and no automated scanner will catch it. It lands on the things nobody puts through a readability pass: terms and conditions, fee disclosures, the text explaining why a payment was rejected, the consent copy in onboarding. Banking writing tends toward the defensive and the legally precise, which is the opposite direction from B2.

Practically, this is a content workstream with an owner and a review step, not a development ticket. It is also the requirement most likely to be discovered after launch, because the engineers reading the checklist are not the people who wrote the terms.

Which version of the standard applies

Conformance is usually described as "meet EN 301 549, which means WCAG 2.1 AA". That shorthand went out of date two months ago, and the detail is worth understanding because it affects what you scope.

EN 301 549 V4.1.1 was published in September 2026. Its own change note records that the requirements of clauses 9, 10 and 11 — web, non-web documents and non-web software, which between them cover a mobile app — "have all been updated to align with the WCAG 2.2 recommendation". It also adds an Annex ZB mapping the document against the essential requirements of Directive (EU) 2019/882.

But here is the part to be careful about. The standard describes itself as providing "one voluntary means of conforming to the essential requirements of Directive (EU) 2019/882", and says that compliance with its normative clauses has that effect "once the present document is cited in the Official Journal of the European Union under that directive". That is conditional, and deliberately so: ETSI publishing a version and the European Commission citing it are two different events, usually separated by a meaningful gap.

I could not establish from public sources which version is cited in the Official Journal today, and I would rather say that than guess. Your counsel can confirm it.

Fortunately the engineering decision does not depend on the answer. The standard notes that content conforming to WCAG 2.2 also conforms to WCAG 2.0 and WCAG 2.1. Build to 2.2 AA and you satisfy the older reference as well. One useful consequence of the move: the old 4.1.1 Parsing criterion has been removed in WCAG 2.2, because the problems it addressed "either no longer exist or are addressed by other criteria" — so if your last audit raised parsing findings, those may simply no longer be findings.

Who is actually on the hook

Microenterprises providing services are exempt — fewer than 10 employees and turnover or balance sheet total not exceeding two million euro. In practice this almost never helps on a banking project, because the service provider in scope is the bank, not the firm building its app. A small supplier's own exemption does not travel to the client's obligation, which is worth being clear about in a contract rather than assuming.

There is also a transitional provision. EUR-Lex ties a 28 June 2030 deadline to Article 32(1), covering continued use of products already in service, and the directive caps similar continued use at "no longer than 20 years after their entry into use" for self-service terminals. None of that extends the 2025 application date for a new app, and treating 2030 as a deadline for new work misreads it.

What to actually do

1. Put authentication in the accessibility scope explicitly. It is the named requirement and the usual blind spot. Test login, step-up and transaction approval with a screen reader before anything else.
2. Review every timeout. Justify the length, warn before expiry, and design the recovery path. Timers are where security and accessibility actually collide.
3. Give the B2 requirement an owner. It is a content workstream. No scanner will raise it and no developer will fix it.
4. Target WCAG 2.2 AA rather than arguing about which version is cited.
5. Test with assistive technology on real devices, not just an automated scan. Automated tooling catches a useful minority of issues and none of the ones above.
6. Confirm the cited version with counsel before relying on presumption of conformity in any formal statement.

The reason to do this properly rather than as an audit is that the two banking-specific requirements cannot be retrofitted cheaply. Rewriting an authentication flow after launch is a security change as well as a design one, and rewriting the terms is a legal review. Both are much easier before the first release than after a complaint.

Questions we get asked

If you are building or refreshing a consumer banking app for an EU market, the accessibility work is cheapest when it shapes the authentication design rather than auditing it afterwards. That is how we scope it on fintech builds, and it is the same argument as every other compliance requirement: the cost is in the retrofit, not the requirement.