Accessibility and Localisation at Scale for Multi-Country Banking Apps

Ship a React Native banking app in one country and accessibility, localisation are two checklist items. Ship the same codebase into eight countries and they become a combinatorics problem: every screen, times every locale, times every screen reader, times every release. This one's for the React Native developer who owns that matrix and has stopped pretending a human can hold all of it in their head. 

A single-market app can get away with a manual accessibility pass before each release and a translator who reads the diff. A multi-country banking app on one React Native codebase can't — not because the team got lazier, but because the surface area grew multiplicatively while the review capacity stayed the same. Two hundred screens across a core banking app, six markets, VoiceOver and TalkBack, and a release cadence measured in weeks, not quarters, is not a QA checklist anymore. It's a coverage problem, and coverage problems are exactly where it makes sense to put an LLM to work — not to write the app, but to keep watch over what a human reviewer can no longer see all of. 

The deadline that already passed, and the one that's about to move 

The European Accessibility Act has applied to consumer banking services since 28 June 2025, and it doesn't grandfather existing apps — a banking app that launched in 2020 has to be fully accessible for any use after that date, the same as one shipped last month. There's no broad transition period for digital services; the narrow exceptions in the Act cover things like pre-existing B2B service contracts and legacy self-service terminals, not a mobile banking app your retail customers use today. If your app serves consumers in the EU, this isn't a future compliance project. It's already the legal baseline. 

What's about to change is which baseline. The harmonised standard behind the EAA, EN 301 549, is still on v3.2.1 and WCAG 2.1 AA as of today. Version 4, currently in draft, moves the reference standard to WCAG 2.2 AA and is expected to be cited in the EU Official Journal around October 2026 — a few weeks out from whenever this piece is read. Two of the six new WCAG 2.2 criteria land directly on banking UI: Target Size, which sets a minimum touch-target size that a lot of dense transaction-list and confirmation-button designs quietly violate, and Accessible Authentication, which prohibits login or step-up flows that rely on a cognitive function test — memorising or transcribing an OTP — without an alternative like copy-paste or a password manager. If your OTP screen currently expects someone to hold a six-digit code in their head while switching apps, that's the exact pattern the new criterion targets. 

None of that is enforced identically across markets, either. The EAA is a directive: the technical standard is harmonised, but each member state transposes it into national law with its own enforcement body and penalty regime — Germany's BFSG is one visible example. A multi-country app isn't meeting one accessibility bar; it's meeting one technical standard under several different national enforcement regimes at once, which is one more reason a manual, country-by-country audit doesn't scale as a review process. 

Where React Native's accessibility API actually breaks down at scale 

React Native gives you the primitives — accessibilityLabel, accessibilityRole, accessibilityHint, accessibilityState — and they work well when a developer remembers to use them correctly on every interactive element. The failure mode isn't ignorance of the API; open-source guides like Nearform's React Native AMA document the patterns clearly enough. The failure mode is that correctness is a per-component, per-PR discipline, and at 200+ screens across a team that rotates and ships weekly, discipline degrades quietly. A toggle ships without an accessibilityState update on press. An icon-only button ships with no label at all. A custom component wraps a Pressable and inherits none of the accessibility props the design system intended. Each one is a one-line fix. Finding them all, before release, across every screen and every locale, is the part that doesn't scale linearly with headcount. 

This is where an LLM earns its place in the pipeline — as a coverage layer over a PR diff, not as the thing writing the label. Wired into CI against the JSX AST of changed files, it can flag a TouchableOpacity with no accessibilityLabel, a custom toggle missing accessibilityState, or an image with an alt-equivalent that just repeats the filename — and propose a specific fix rather than a generic warning. Research on LLM-generated accessible UI code backs up what you'd expect from using these models directly: they're reliable on standard patterns like semantic roles and basic labels, and much weaker on custom components, dynamic content announcements, and focus management inside modals — one benchmark found only about a third of AI-generated sortable tables correctly announced state changes. The gap matters less for what it says about the model and more for what it implies about the workflow: treat the output as a flagged draft requiring review, never as a merge-ready fix, and the same research found that prompts anchored to a specific WCAG success criterion — "this needs an accessibilityState update per SC 4.1.2," not "make this accessible" — measurably improve what comes back. Deterministic tooling still does the enforcement; eslint-plugin-react-native-a11y catches the mechanical cases (missing labels on touchables, images without alt text) reliably and cheaply. The LLM's job is the harder-to-rule-ify layer on top: is this label actually descriptive, does this hint add real information, does this custom component's role match what it does. 

Localisation has the same shape, and the two problems compound each other 

A multi-country banking app's i18n surface isn't just translated strings — it's currency and date formatting per locale, pluralisation rules that don't map cleanly from English, interpolation placeholders that have to survive translation intact, and string length expansion that varies wildly by language. German banking terminology in particular runs 30–40% longer than the English source string, and that's not a cosmetic problem — a label that truncates on a small screen doesn't just look wrong, it silences the screen reader reading it or turns a clear call-to-action into an ellipsis. Localisation and accessibility bugs aren't two separate backlogs on a banking app; a truncated German label is both at once. 

The same coverage-layer approach applies. An LLM reviewing a locale-key diff can catch what a translation memory tool won't: a missing key that silently falls back to the source language in production, an interpolation placeholder ({{amount}}, {{accountLastFour}}) that survived in one locale file but got flattened into plain text in another, or a string that's technically translated but uses consumer-facing phrasing where the source string was written for a KYC or compliance screen and needed the formal register a given market's banking terminology expects. It can also flag, before a string ever reaches a device, which translated strings are likely to overflow a given layout given that locale's typical expansion ratio — catching the German-label problem in CI instead of in a screenshot review three sprints later. 

CI flag on PR #4127 (ro-RO, de-DE locale diff): 

 

de-DE: "transfer.confirm.button" translated but exceeds button's 

  maxLines(1) budget at 98th-percentile string length (+34% vs en-US 

  source). Suggest: shorten label or increase touch target per WCAG 

  2.2 SC 2.5.8 minimum size — current button clips to 38x38pt. 

 

ro-RO: "otp.hint" interpolates {{expirySeconds}} — key present in 

  en-US and de-DE, missing in ro-RO. Falls back to source string 

  in production. 

 

Both: flagged for native-speaker + a11y review before merge. 

Not auto-applied. 

  

What AI should never be the last reviewer of 

The guardrail matters as much as the capability. Interest rate disclosures, consent language, KYC copy, anything a national regulator would read as the actual legal text of the product — that copy gets written and reviewed by a native-speaking compliance reviewer in that market, full stop. What the LLM is good for is making sure that copy exists in every locale it needs to, that it hasn't silently regressed, and that the button it sits in doesn't clip it — not authoring the copy itself. The distinction is the same one that shows up anywhere AI touches a regulated pipeline: use it to raise coverage and catch drift, keep a human accountable for anything a regulator, a screen reader, or a customer in a market you don't personally read the language of would actually rely on. 

Testing like the market surveillance authority will 

EAA enforcement doesn't run against your English staging build. A national market surveillance authority testing a banking app for compliance will test the actual deployed app, in the actual local language, with the actual assistive technology customers in that country use — which means your own test matrix needs to mirror that, not substitute an English-only VoiceOver pass and call the rest "covered by translation." A coverage matrix generated per screen, per locale, and per platform — and kept honest by the same CI layer that flags missing labels and overflowing strings — is what makes "we tested it" mean the same thing in Bucharest and Berlin, instead of meaning "we tested the English version and hoped." 

We've built and shipped React Native banking apps that run across multiple markets on one codebase, and the lesson that stuck is a boring one: neither accessibility nor localisation breaks because a team doesn't care. It breaks because a per-PR discipline doesn't scale to a multi-country release matrix, and nobody notices the gap until either a regulator or a customer does. An LLM in that pipeline isn't a replacement for an accessibility specialist or a native-speaking reviewer — it's the coverage net that makes sure the specialist's judgment gets applied to every screen, in every market, every single release, instead of whichever ones a human had time to click through before the deadline.