For most people, contact with their bank no longer begins at the branch door but in a browser or an app. 86 percent (Bitkom, 2025) of people in Germany handle their banking online - and the latest growth comes from a group that depends on accessibility more than most: among people over 75, online banking use jumped from 22 percent (Bitkom, 2025) in 2023 to 43 percent (Bitkom, 2025) in 2025. At the same time, the German Accessibility Strengthening Act (BFSG) has made consumer banking services explicitly mandatory since 28 June 2025: account opening, online banking and payment services must be accessible (Bundesfachstelle Barrierefreiheit). The WebAIM Million Report 2026 shows how much work remains: 95.9 percent (WebAIM Million, 2026) of the home pages analysed had detectable WCAG failures. This guide explains what the BFSG requires of banks, savings banks and fintechs - from login through TAN approval to the mobile app - and how to build an accessible portal step by step.
Key takeaways
- Consumer banking services fall squarely within the scope of the BFSG: account opening, online banking and payment services must be provided accessibly since 28 June 2025 (Bundesfachstelle Barrierefreiheit).
- The need is real and growing: 86 percent (Bitkom, 2025) of the population use online banking, and among people over 75 use rose from 22 to 43 percent (Bitkom, 2025) within two years.
- The benchmark is WCAG 2.2 at Level AA via the harmonised standard EN 301 549. What matters most is sufficient contrast, programmatic labels, full keyboard operation and clear error messages.
- TAN and payment approval is the most critical point: hard time limits, purely visual codes and methods without an alternative lock out people with visual, motor or cognitive limitations.
- The BFSG applies to the banking app too. Portal and app must both be accessible, because many customers use only their smartphone for banking.
- The most common technical defects are also the easiest to fix: 83.9 percent (WebAIM Million, 2026) of home pages had insufficient contrast and 53.1 percent (WebAIM Million, 2026) missing alternative text.
Why Banks Face Pressure on Online Banking
Banking has shifted almost entirely into the digital sphere within a few years. When 86 percent (Bitkom, 2025) of people run their accounts online and older customers are catching up fastest, the quality of the portal decides who can independently make a transfer, change a standing order or check a balance. Germany is home to 7.9 million (Statistisches Bundesamt) people with severe disabilities, plus everyone with a temporary or situational limitation. A portal that only works with precise mouse control, good eyesight and quick reactions excludes a relevant share of a bank's own customers from a basic function of everyday life.
For banks, savings banks and fintechs, accessibility is therefore not only a legal duty but a question of reaching their customers. An accessible account-opening flow loses fewer applicants in the funnel; an accessible TAN approval reduces calls to the branch and the service centre. The basics and deadlines of the act are summarised in the article on what companies need to know about the BFSG 2025; the concrete technical demands that follow are set out in the overview of BFSG requirements.
Banking Services Are Explicitly Covered
What the BFSG Counts as Banking Services
The scope reaches further than many institutions first assume. It is not only the login page that must be accessible but the entire journey a customer follows - from opening an account through day-to-day account management to approving a payment. Each of these steps contains forms, selection fields, status messages and confirmations that must be understandable to assistive technology and operable by keyboard. The overview below shows the areas an institution should examine first.
Account Opening
The online application with identity check and contract conclusion must be fully operable without a mouse and with a screen reader.
Online Banking Portal
Transactions, transfers, standing orders and mailbox: every core function needs clear structure, labels and sufficient contrast.
Banking App
The mobile app falls under the BFSG equally and must meet the platform guidelines for iOS and Android.
Payment Authentication
Strong customer authentication and TAN approval need an accessible alternative that is not purely visual.
Forms and Applications
Transfer, loan and change forms need programmatic labels and understandable error messages.
Documents and Contracts
Statements, price and service lists and contracts should be provided as accessible PDF or HTML.
This list is not an edge case but the normal operation of an institution. That is exactly why patching a single page is not enough: accessibility has to cover the whole customer journey, because one impassable step - such as a TAN entry with a hard time limit - makes the entire process fail. Examining the journey as a whole reveals break points that a page-by-page check leaves invisible.
The Most Common Barriers in Online Banking
| Barrier | Impact | Conformant implementation |
|---|---|---|
| Insufficient contrast on amounts and buttons | Balances and actions are hard to read with low vision | Meet 4.5:1 text contrast and 3:1 control contrast (WCAG 1.4.3, 1.4.11) |
| Fields without a programmatic label | Screen readers announce only input field, not its purpose | Label every field unambiguously via label or aria-label |
| TAN entry mouse-only with a hard time limit | People with motor or visual limitations abandon | Full keyboard operation, extendable time, an alternative approval |
| Error signalled by red colour only | Colour-blind users do not perceive the error | Signal errors additionally by text and programmatically, announce via live region |
These patterns are the rule, not the exception. The WebAIM Million Report 2026 found insufficient text contrast on 83.9 percent (WebAIM Million, 2026) of home pages and missing alternative text on 53.1 percent (WebAIM Million, 2026) - an average of 56.1 errors (WebAIM Million, 2026) per page. In banking such defects weigh more heavily than elsewhere, because a misread number or an overlooked error message has immediate financial consequences. That the same corrections also improve discoverability is shown in the article on accessibility and SEO as a double lever.
TAN and Strong Customer Authentication, Accessibly
Payment approval is the most delicate step in all of online banking. Strong customer authentication requires two independent factors, and many institutions rely on a TAN method with a tight time window. This is exactly where barriers arise: a code that appears only as a distorted image is unreadable for blind users; a limit of a few seconds overwhelms people with motor or cognitive limitations; a push method that runs only in a non-accessible app locks out screen reader users. WCAG 2.2 therefore requires adjustable time limits (SC 2.2.1) and bans cognitive function tests at sign-in without an alternative (SC 3.3.8). How to build accessible sign-in without a memory or puzzle task is covered in the article on accessible authentication and CAPTCHA alternatives.
- Offer at least one TAN method that works without perfect eyesight and without a mouse
- Make time limits extendable or allow approval without a hard deadline (WCAG 2.2.1)
- Put one-time codes in a single field with autocomplete=one-time-code so pasting stays possible
- Do not block copy and paste in the code field
- Provide push approvals in an app that is itself accessible
- Announce every step of the approval by screen reader and name errors clearly
Time Limits and Missing Alternatives
Contrast, Labels and the Keyboard: WCAG Basics
The technical bar for accessible online banking is WCAG 2.2 at Level AA, which enters European and German law via the harmonised standard EN 301 549. How that standard relates to the BFSG is explained in the article on EN 301 549 as the standard behind the BFSG. For a banking portal, Level AA means above all four things: a text contrast of at least 4.5:1 and a 3:1 contrast for controls, a programmatically linked label on every input field, full keyboard operability with a visible focus, and error messages that are not conveyed by colour alone. These basics are not optional extras but the core of every audit.
Do Not Forget Motion and Animation
The Banking App: the BFSG Applies on Mobile Too
Many customers use only their smartphone for banking - for them, the app is the portal. The BFSG explicitly covers mobile applications, which is why the app must meet the same standard as the website. On iOS and Android that means using the platform accessibility features properly: meaningful labels for VoiceOver and TalkBack, sufficiently large touch targets, respected system font sizes and contrast that holds up in sunlight. What matters in detail for app testing is covered in the article on accessible apps under the BFSG for iOS and Android. Portal and app should be tested together so that a continuous path of access emerges.
Online banking is only accessible once a customer can hear her balance, initiate a transfer by keyboard and approve the TAN without time pressure.
Deadlines, Enforcement and What to Do Now
The obligation has applied since 28 June 2025. It is overseen by the competent market surveillance authority, which can identify defects and demand remediation; consumer associations can pursue violations. There is no blanket exemption for legacy systems - the disproportionate-burden exception provided for in the act is narrowly framed, must be documented, and does not permanently release an institution from implementation. The pragmatic path is therefore to assess the current state and fix the most critical barriers - payment approval above all - first. A structured WCAG 2.2 audit provides the prioritised basis for this.
- Take stock: test login, account management, transfers and TAN approval along real usage, with keyboard and screen reader.
- Prioritise: fix barriers that block a process entirely - such as impassable TAN entries - first.
- Secure the basics: correct contrast, labels, focus and error messages across all core paths.
- Include the app: test the mobile application against the same criteria and align it with the portal.
- Anchor and document: build accessibility into development and release processes and publish an accessibility statement.
Whether a portal actually meets the requirements only becomes clear in a manual test with keyboard and screen reader - automated tools catch only part of the defects. That is exactly the test we carry out in the WCAG 2.2 audit, after which we support institutions in implementing accessible banking services. Anyone who wants to gauge the individual steps and the effort in advance will find the framework under pricing; for a concrete assessment of your portal, a short message via the contact form is enough.