Your audit or scan has come back, and alt text is on the findings list. Under the European Accessibility Act (EAA), the question is not only whether that alt text is good. It is whether you can say something true about it in a public document, because your accessibility statement has to list what does not yet conform. For a native app, the requirement is EN 301 549 clause 11.1.1.1. For a website, it is Web Content Accessibility Guidelines (WCAG) success criterion 1.1.1. Both sit at Level A. Here is which rule applies, why a passing scanner does not settle it, and what your statement should say.
Which rule applies to your product
Anyone looking for EAA alt text regulations will find that the Act, Directive (EU) 2019/882(opens in new tab), applying since 28 June 2025, sets functional requirements rather than techniques. Annex I asks that products and services be perceivable, operable and understandable, and that they support assistive technologies. It does not prescribe a technical standard.
That gap is filled by EN 301 549, the EU's harmonised standard, which incorporates WCAG 2.1 Level AA. The current version is v3.2.1, from March 2021. Which part applies depends on what you ship.
- Your website falls under Clause 9, which takes in WCAG 2.1 Level AA directly. The requirement is WCAG 1.1.1, Non-text Content(opens in new tab).
- Your native app falls under Clause 11, which adapts 44 of the 50 WCAG 2.1 Level A and AA criteria for non-web software. The EN 301 549 non-text content clause is 11.1.1.1, which maps to WCAG 1.1.1.
- A hybrid app falls under Clause 11 for its WebView content, because that content is not a standalone web page. A mobile site or progressive web app (PWA) in a browser stays under Clause 9.
Our guide to EN 301 549 Chapter 11 covers the rest of the chapter. WCAG 1.1.1 is a Level A criterion, the lowest conformance tier. Missing text alternatives is a failure at the floor of the standard, not a gap in the polish.
Why a clean scanner report does not clear it
Independent industry research consistently puts the share of WCAG issues an automated tool can detect at roughly 30 to 40 percent, as our website accessibility audit guide sets out. A scanner can prove an alt attribute exists. Only a person can say whether it describes the image.
A screen where every image carries alt="image" can pass a scanner and still fail an audit. A statement published off the back of that scan is wrong, and wrong in public.
In an app, the failure sounds like this:
- An icon-only button that TalkBack announces only as "button".
- A transit app that renders route maps as images, so VoiceOver announces "image" and no route information.
- Labels that exist but describe nothing useful.
The platform fix is one property. On iOS, every meaningful UIImageView or icon-only button needs an accessibilityLabel. On Android, every meaningful ImageView needs a contentDescription. Hide decorative elements with accessibilityElementsHidden on iOS or importantForAccessibility="no" on Android.
The four decisions, per element
Every non-text element needs one of four answers. This is triage, not a style guide. For writing rules, see our post on common web accessibility mistakes.
- Informative. It carries meaning, so describe the meaning, not the picture. It fails when a product photo is announced by its file name.
- Functional. It is a control, so describe the action, not the icon: "Search", not "magnifying glass". It fails when it is announced only as "button".
- Decorative. It carries nothing, so hide it from assistive technology. It fails when a screen reader still stops on it and announces "image" or an empty label.
- Complex. A chart, map or diagram needs a short alternative plus a longer description elsewhere. It fails when a route map is reduced to "map".
What goes in your accessibility statement
Article 13 of the EAA requires you to publish accessibility information, and Annex V sets what it must cover for services. A credible statement names the standard, declares a conformance position and lists non-conformant content with a rationale. Our guide to the EAA accessibility statement covers the full anatomy.
Declaring partial conformance is a statement of position, not an admission of failure. The alt-text row tests that position. It is a Level A criterion, it recurs on every screen rather than once per product, and its absence is machine-detectable while its quality is not. That makes it the row most likely to be both found and disputed.
A defensible entry covers four things:
- Scope. Which product and which surfaces: the website, the iOS app, the Android app, or a named flow.
- The criterion, by number. EN 301 549 clause 11.1.1.1 for an app, or WCAG 1.1.1 for a website.
- What does not conform. In plain terms, which elements lack a usable text alternative and what a screen reader user misses.
- The rationale. Why it does not conform.
In substance, an entry reads like this:
Android app, journey planner screen. Route maps come from a third-party mapping service we do not control and are shown as images with no text alternative, so TalkBack announces "image" and no route information. This does not meet EN 301 549 clause 11.1.1.1 (WCAG 1.1.1).
The rationales the EAA accepts are narrow: technical impossibility, disproportionate burden under Article 14 (assessed against Annex VI), or third-party content outside your control. "We have not got to it yet" is not one of them. If that is the honest answer, the item stays on the list until it is fixed.
Alt text also changes every time the product ships. A statement written once against a six-month-old audit stops being true quietly.
What this is worth getting right
On 4 June 2026, a French court ordered Carrefour to make its website and app fully accessible within six months, with an astreinte of €500 per day. An astreinte is a prospective daily penalty that only starts if the deadline is missed. This is an order, not a fine, and no fine has been issued under any EAA transposition anywhere in the EU. Carrefour argued that 71% conformity with RGAA, France's national framework, was enough. The court held that accessibility is an obligation of result. See our analysis of the Carrefour ruling and our overview of EAA enforcement.
Partial conformance recorded honestly is a defensible position. Partial conformance recorded nowhere is not.
Keep your statement current as you ship
AUDITSU is the guided audit toolkit that lets your product team run the check against EN 301 549 and WCAG 2.1 AA itself. Every finding is kept as a live record, and your accessibility statement is generated from that record, so the non-conformance list stays current as the team ships. Your team makes every judgement, including what counts as decorative. It's in beta with a limited number of customers. If you'd like to see it on your own product, book a call.