Why Europe’s accessibility law turns every bank release into evidence

The week

June 28, 2026 marked one year since the European Accessibility Act began to apply across the European Union. The directive, adopted in 2019 and transposed into national law by each member state, sets accessibility requirements for a list of products and services. A directive is an EU law that sets goals each country must then write into its own national legislation, which is why the details can differ from one country to the next.

The Act is meant to prevent moments like this one. Suppose a blind customer tries to pay a bill on her bank’s app. She uses a screen reader, software that reads the screen aloud and lets her move through it by swiping and tapping. The payment screen works well. Then the app asks for a one-time passcode, and the box where she must type it has no label. Her screen reader announces only “edit text.” She cannot tell what the field wants, the session times out and she is locked out. For her, the bank’s service has stopped working.

The services and products covered include consumer banking services, e-commerce, and self-service terminals such as ATMs and payment terminals. Service providers must meet the requirements and publish information explaining how their services meet them. National authorities enforce the rules, and penalties and procedures vary by member state.

There are limits. Microenterprises providing services are exempt, and transition rules let some existing contracts and terminals continue for a period. That gave larger institutions some breathing room on physical equipment, but not on the apps, websites and documents customers use every day.

In the last week of June 2026, banks serving EU consumers completed their first year under the regime. For many, that first year brought an uncomfortable discovery. They had treated accessibility as a project: audit, fix, publish a statement, done. But a bank’s digital service is never finished. It changes every week, and each change is a chance for a fix to come undone. The anniversary was a natural moment to stop asking whether the bank had complied last June and start asking whether it could prove it complies today.

Many banks ran the Act as a project with an end date. They audited the app and website against WCAG criteria, using the European standard EN 301 549 as the working benchmark while standards bodies revised it for the Act. They fixed what the audit found and published an accessibility statement. That was necessary work.

The difficulty a year later is that a banking service changes every week. App releases, new document templates, vendor updates and terminal replacements each can undo a fix. A statement that the service conforms is only as good as the most recent change.

We divide the service into four parts, each with its own way of drifting and its own evidence: digital releases, documents and communications, physical terminals, and embedded vendor components. First, some vocabulary.

Screen readers, WCAG and the public statement

Digital accessibility means designing apps, websites, documents and machines so that people with disabilities can use them independently. That includes people who are blind or have low vision, people who are deaf or hard of hearing, people with limited movement in their hands, and people with cognitive or learning disabilities. It also helps a much wider group: older customers, people using a phone in bright sunlight, anyone with a broken wrist.

Many disabled customers use assistive technology, tools that sit between them and the screen. A screen reader reads content aloud and announces buttons and fields. Magnification enlarges part of the screen. Switch access lets someone with very limited movement operate a device with one or two buttons, stepping through each item on the screen in turn. These tools work well only if the app or website is built to cooperate with them. A button that looks obvious on screen may be invisible to a screen reader if it has no text label behind it.

WCAG, the Web Content Accessibility Guidelines, is the international reference for what “accessible” means in practice. It is a long list of testable criteria: text must have enough contrast against its background, every form field needs a label, content must be usable with a keyboard alone, and so on. EN 301 549 is the European standard that builds on WCAG and extends it to documents, software, hardware and terminals. WCAG works like a building code for web pages; EN 301 549 is the wider code that also covers the furniture and the front door.

An accessibility statement is the public information the Act requires: a description of how the service meets the requirements. It is, in effect, a promise made in public, so it has to stay true.

How a compliant service drifts out of compliance

Start with how a modern retail bank actually changes its products.

The mobile app may be updated every two weeks, sometimes more often. Each release is assembled by several teams working in parallel: one on payments, one on cards, one on onboarding, one on security. A designer adds a new button style. A developer reuses a component from another screen. A marketing team adds a promotional banner. Each change is small and sensible on its own. None of the people making it may have accessibility in mind, and none of them may know that the component they reused had been carefully fixed last year.

Meanwhile, the operations side is changing too. A new regulation requires an extra paragraph in a customer letter, so a template is edited. A product launch needs a new fee notice. A vendor pushes an update to its chat widget overnight. A branch replaces a broken ATM with whatever model the supplier had in stock.

An audit before a deadline is useful, but the service is changing again the day the auditor leaves. What keeps it accessible is routine: checks built into each change, a checklist everyone works from, someone responsible for checking. A bank that treats accessibility as a one-off clean-up will find, a year later, that its service looks the way services look when nobody has a routine.

So the useful test is what routine keeps the bank passing, rather than whether it passed the audit once. Each of the four parts below needs its own routine, because each changes in a different way, at a different pace, under a different owner.

Digital releases

Apps and websites received most of the investment, and the main journeys are usually in good shape. The failures cluster at the edges. Authentication steps, one-time passcode screens, CAPTCHA alternatives, session timeouts and error messages are where a customer using a screen reader, magnification or switch access is most likely to be stopped. A CAPTCHA is the puzzle a website shows to check you are human, such as picking out traffic lights in a grid; for a blind customer, an image puzzle with no alternative is a locked door. Those edge screens are also the ones that change most often, because security and fraud teams adjust them.

That creates a tension inside the bank. The fraud team’s job is to make logging in harder for criminals. Each change it makes, a new verification step, a shorter timeout, a different passcode screen, can make logging in harder for disabled customers too. Neither team is doing anything wrong. They simply need to work from the same checklist.

Evidence here comes from the delivery pipeline, the automated assembly line that takes code from developers through testing to release. Automated accessibility checks can run on every build and catch a meaningful share of problems, such as missing labels and contrast failures. They cannot judge whether a flow makes sense with a screen reader. That needs periodic manual testing by people who use assistive technology, focused on complete tasks such as logging in, paying a bill or disputing a card transaction.

A bank that keeps the results of both, with defects tracked to closure like any other release defect, can show a supervisor what state the service was in on a given date. A bank that relies on last year’s audit cannot.

The public information the Act requires belongs in the same loop. If the published description of how the service meets the requirements is written once and never revisited, it will drift from the product. Versioning that statement, assigning an owner and reviewing it at each major release keeps the public claim and the internal evidence in step. It also gives complaint handlers something accurate to point to.

Documents and communications

Statements, contracts, fee information, notices and letters are part of the service. Many are produced as PDFs by older document composition systems that were never designed to output tagged, structured files. A document composition system is the back-office software that merges customer data into templates to produce letters and statements in bulk. A tagged PDF contains hidden structure, marking which text is a heading, which is a table and in what order things should be read, so a screen reader can make sense of it. An untagged PDF can be little more than a picture of text, and a screen reader may read it as a jumble or not at all.

Customer service channels, including chat and video, must work for people with disabilities too. This part usually sits with operations teams, outside the digital program, which is why it lags. The people who own the app rarely own the monthly statement.

Volume is the practical starting point. A small number of templates typically produce most customer documents. Converting those templates to accessible output, and offering alternative formats on request through a defined and logged process, covers most customers first. The evidence is a template register showing which templates have been remediated and tested, plus records of alternative-format requests and how quickly they were met. Every new template should pass the same check before it goes live, or the register goes stale.

Suppose a mid-sized bank operating in three EU countries discovers it has several hundred letter templates, but a handful of them, the monthly statement, the card statement, the fee notice and a few standard letters, account for most of what customers receive. Fixing those first delivers most of the benefit quickly. The remaining long tail is handled through a clear request process: a customer who needs a statement in large print or an accessible electronic format can ask, the request is logged and someone checks it is met on time.

Physical terminals

ATMs and payment terminals are covered as products, and the product obligations fall mainly on manufacturers, importers and distributors. Banks still choose and operate the fleet. An accessible terminal might offer a headphone socket with spoken instructions, tactile keys that can be identified by touch, and a screen positioned so that a wheelchair user can read it.

The directive allows self-service terminals already in use before June 28, 2025 to continue until the end of their economically useful life, up to a maximum of twenty years. That gives banks time, but only if replacement plans account for it. A machine bought just before the deadline could, in principle, stay in service for a very long time, and customers will judge the bank by the machine in front of them, not by the transition rule behind it.

The evidence a bank needs here is mostly procurement evidence. New terminal purchases should require the manufacturer’s declaration of conformity, a formal statement that the product meets the requirements, and the supporting technical documentation. Fleet records should show which units fall under the transition rule and when each is due for replacement. Branch staff guidance on assisting customers at terminals, and on reporting faults that affect accessibility, completes the record. A broken headphone socket is an accessibility failure even if the machine was compliant on the day it was installed. Banks should confirm with counsel how the transition rules apply in each member state where they operate.

Embedded vendor components

The fourth part runs through the other three. Banks rely on vendors for digital banking platforms, identity verification flows, card management widgets, chat tools, payment authentication screens and document generation. Many of these appear inside the bank’s own journeys at the most important moments. When a vendor component fails, the customer sees the bank’s name, and the bank remains the service provider answerable to the authority.

Consider the identity check a new customer goes through when opening an account online, often photographing an ID document and taking a selfie. That flow is frequently supplied by a specialist vendor and embedded in the bank’s app. If it cannot be completed with a screen reader, a blind customer cannot open an account at all, however accessible the rest of the app may be.

Evidence from vendors should be tested rather than filed. Contracts can require conformance with the applicable standard, notice before releases that change customer-facing screens, test results for each major release and remediation timelines for defects. The bank’s own task-based testing should cover vendor screens, since that is where the customer actually experiences them. A vendor accessibility report that is two years old describes a product the bank no longer runs.

What a locked-out customer costs

Managing accessibility as a legal obligation at minimum cost would miss most of the value, and most of the risk.

• Customers. Disabled customers, older customers and their families are a significant share of any retail bank’s base. A service that locks them out drives complaints, branch visits and call-center volume, all of which cost money.
• Regulators. National authorities enforce the Act, and supervisors increasingly expect firms to show evidence, not intentions. A dated record of testing is far more persuasive than a statement written a year ago.
• Reputation. Accessibility failures are easy to demonstrate and easy to share. A short video of a customer unable to log in can travel far.
• Cost of rework. Fixing accessibility in a design before release is cheap. Retrofitting it after customers complain, across many screens and documents, is not.

For US banks and fintechs, the Act matters where they provide covered services to consumers in the EU, and counsel should confirm scope. The same engineering habits also support accessibility obligations and litigation defense in the United States.

A bank that can prove its state on any date

A bank in good shape can answer, for any date, “what was the accessibility state of our service then, and how do we know?” It has automated checks in every build, regular task-based testing with assistive technology users, a register of document templates, a terminal fleet record and vendor contracts with real teeth. Accessibility has a named senior owner, and the accessibility statement is reviewed as often as the product changes.

The usual failures run the other way:

• Treating the first audit as the finish line. The audit describes one moment; the service keeps moving.
• Relying on automated tools alone. They catch many technical faults but cannot tell whether a real person can complete a task.
• Leaving documents to someone else. Statements and letters fall between the digital team and operations, and nobody fixes them.
• Filing vendor reports instead of testing vendor screens. The customer experiences the vendor’s component as the bank’s service.
• Forgetting the fraud team. Security changes to login and verification screens are the most frequent source of new barriers.

Evidence a supervisor could ask for tomorrow

• If a supervisor asked tomorrow, could we show the accessibility state of our app and website on a specific date, with evidence?
• Who reviews accessibility when the fraud or security team changes a login or verification screen?
• Which document templates produce most of what customers receive, and which of them are accessible today?
• Which of our ATMs and payment terminals rely on the transition rule, and when is each due for replacement?
• Do our vendor contracts require notice of customer-facing changes and test results for each major release?

Answering them does not require a leader to understand how a screen reader works or how a PDF is tagged. It requires only a willingness to ask for evidence rather than reassurance. A team that answers with dates, records and named owners has turned accessibility into a routine. A team that answers with last year’s audit report is still treating it as a project, and the service it describes may no longer exist.

With hindsight

The first year turned out like the early period of most EU service rules. Each member state had to designate enforcement authorities, and their readiness varied. Germany’s joint authority for its national law, set up by the 16 states and based in Magdeburg, took up full nationwide work only in September 2025, three months after the obligations applied.

By June 2026 that authority described its work as partly reactive, acting on consumer reports and complaints, and partly proactive through multi-year market surveillance strategies, and said it was handling close to 700 reports. The mix means a bank cannot assume enforcement will only follow complaints. Market surveillance, the regulator’s own planned checks, is part of the picture too. Penalties and procedures still differ by country, so a bank operating across several member states faces several slightly different enforcement environments at once.

For banks, the ordinary pace of release change means a 2025 audit says little about the service a supervisor would test in 2026. Documents produced by older composition systems remain a weak area for many institutions. Neither point is surprising, but both reinforce the central idea of this piece: accessibility is a property of the service as it stands today, not a certificate earned once.

The standards picture has also moved. The revised European standard, EN 301 549 V4.1.1, was published in September 2026; it gives a presumption of conformity only once it is cited in the Official Journal. A presumption of conformity means that meeting the standard is treated as meeting the law, which is why the formal citation matters. Until then, banks are measuring themselves against a benchmark whose legal status is still settling.

Enforcement is building rather than finished, and the evidence banks gather now is what they will rely on when authorities look more closely. Banks should follow guidance from the authorities in each member state where they serve consumers, and confirm obligations with counsel. Above all, they should make sure that the habits built for last year’s deadline, testing, tracking and reviewing, keep running every week.