From 28 June 2025, companies selling digital products and services in the EU must comply with the European Accessibility Act (EAA). E-commerce sites, banking apps, ticketing platforms and e-book services all fall under it. One dimension of the EAA that many product teams still treat as a minor detail is text comprehension: content has to be understandable, not just technically accessible to screen readers.
Meeting the EAA is not only about adding ARIA attributes and colour contrast. It means making sure someone using a screen reader in Polish, or an app with low digital literacy support in Portuguese, can actually understand what they are reading. That is a localisation problem, not just an engineering one.
What the European Accessibility Act requires from text
The EAA covers products and services such as e-commerce websites, banking services, e-readers, self-service terminals, transport apps and electronic communications services. The text-related obligations include:
- Clear and simple language, free of unnecessary jargon and long sentences that make reading difficult for assistive technology.
- Descriptive alt text for images, available in every interface language.
- Consistent labels and instructions across screens, so voice or keyboard navigation behaves predictably.
- Understandable error messages, written so the user knows exactly what to fix.
None of this is solved automatically by translating a string literally. A short, clear sentence in English can become ambiguous or unnecessarily long in French or German if translated word for word. Localising for accessibility means rewriting, not just converting.
Where literal translation breaks accessibility
A screen reader reads text in the order it appears in the code, not the visual order on screen. If a translated button or label changes the grammatical structure of the original sentence, voice output can become incomprehensible, even when the written text looks correct.
Three problems come up repeatedly:
- Gender agreement across languages. "Selected" translates differently depending on whether the referenced element is masculine or feminine in Portuguese or Spanish. Poorly prepared interfaces produce inconsistencies that confuse assistive technology.
- Text length in fixed fields. German and Finnish strings tend to run longer than English. If alt text or a label gets truncated, essential information disappears, which is a direct EAA failure.
- Reading order in RTL languages. For Arabic markets, the logical DOM order has to follow the reading direction, and this needs checking by the people doing the localisation, not assumed by the translation engine.
These cases require human review with visual context of the screen, not just access to an isolated string file.
How to set up the localisation process for accessibility
The starting point is the glossary. Interface terms ("submit", "cancel", "required field") have to be translated consistently across the whole application, because assistive technology relies on that predictability to guide the user.
Next comes visual context. String files reviewed without seeing the actual screen lead to translations that are technically correct but semantically wrong: a "Cancel" label on an irreversible action can carry a different weight than intended, and that only becomes clear once you see the real screen.
Finally, testing with real assistive technology: screen readers, keyboard navigation, text zoom. This catches problems that no isolated text review will find, such as duplicated labels or reversed reading order.
For teams running SaaS platforms or apps with frequent content updates, it's worth building this into a certified workflow, as covered in ISO 17100 localisation for SaaS platforms. Continuous integration between the CMS and the translation team stops every product update from forcing accessibility work to start over.
How M21Global supports EAA compliance
M21Global handles software and digital platform localisation with a focus on terminology consistency and review with visual context, two requirements that European Accessibility Act compliance makes mandatory rather than optional. For high-impact projects, such as banking interfaces or e-commerce platforms subject to regulatory audit, the Estratégica tier applies second-linguist review within an audited ISO 17100 workflow, with dedicated quality control.
If your company sells digital products in the EU and needs to localise interfaces, error messages or help content to meet the EAA, take a look at M21Global's technology and software localisation services and request a quote. You'll get a response within three business hours.
Related Services
Request a free software localisation quote
- Request a free software localisation quote
- Mobile App Localisation Angola Mozambique
- Iso 17100 Localization For Saas Platforms
- A Surprising Amount Of Content Available Online Is Generated By Artificial Intelligence
Frequently Asked Questions
What is the European Accessibility Act and when did it start applying?
It is an EU directive requiring digital products and services, such as e-commerce sites and banking apps, to be accessible to people with disabilities. It has applied since 28 June 2025.
Does machine-translating interface strings meet accessibility requirements?
Usually not. Machine translation without visual context review or testing with assistive technology tends to produce inconsistent labels or truncated text, which breaches EAA requirements.
What kind of app content needs localisation for accessibility?
Interface labels, error messages, image alt text, navigation instructions and help content, in every language the app is offered in.
How long does it take to localise an app for EAA compliance?
It depends on content volume, number of languages and interface complexity. M21Global responds to quote requests within three business hours, with delivery timelines set on a per-project basis.
