The European Accessibility Act, turned into a mobile app checklist

Since 28 June 2025, EU member states apply their national versions of the European Accessibility Act, Directive (EU) 2019/882. For a large group of consumer apps, accessibility stopped being a nice-to-have and became a condition for selling in the EU.

This piece does two things. First, it lays out what the Act actually says about scope, dates and standards, quoted from the directive rather than from vendor summaries. Second, it turns that into the checklist we use when we design and build iOS and Android apps.

Who the Act covers

The Act covers listed products placed on the market and listed services provided to consumers after 28 June 2025 (Article 2). The word consumers matters: a purely internal or business-to-business tool is not the target. Most apps we see in scope fall into one of the service categories below.

The product side covers things like consumer computers and their operating systems, smartphones, e-readers, payment terminals, ATMs and ticketing machines. If you only ship software, the service list is usually the one that applies to you.

Exemptions and exclusions

Microenterprises providing services are exempt from the service accessibility requirements (Article 4(5)). A microenterprise is one that employs fewer than 10 people and has an annual turnover or annual balance sheet total of no more than €2 million (Article 3(23)). The exemption is for services only; microenterprises that make covered products are not exempt in the same way.

Two cautions. The exemption belongs to the service provider, not to the agency that builds the app: a small studio building a banking app for a large bank is building an in-scope service. And Article 14 allows a provider to argue that a requirement would be a fundamental alteration or a disproportionate burden, but that is an assessment you have to make and document, not a blanket opt-out.

Article 2(4) also excludes some content: pre-recorded video and office files published before 28 June 2025, online maps when the essential information is given in an accessible way, third-party content you neither fund, develop nor control, and archives that are not edited after 28 June 2025.

The dates that matter

• 28 June 2022: deadline for member states to adopt their national laws.
• 28 June 2025: the national rules apply. New in-scope services must meet the requirements from this date.
• 28 June 2030: end of the transitional period during which service providers may keep using products they lawfully used before that date to provide similar services. Service contracts agreed before 28 June 2025 may continue without alteration until they expire, but no longer than five years from that date (Article 32(1)).
• Up to 20 years: member states may let self-service terminals already in use before 28 June 2025 continue until the end of their economically useful life, capped at 20 years after entry into use (Article 32(2)).
• 28 June 2027: latest date for the accessibility rules on answering calls to the European emergency number 112.

Our working assumption, which you should confirm for your own case: the 2030 transition protects existing products and unchanged contracts. It is not a reason to keep shipping new app releases that ignore the requirements.

The standard behind the requirements

The Act itself sets out functional requirements in Annex I: information must be perceivable, operable, understandable and robust. It does not list pixel values. Under Article 15, services that follow harmonised standards whose references are published in the Official Journal of the EU are presumed to conform.

The relevant standard is EN 301 549, the European standard for ICT accessibility from ETSI, CEN and CENELEC. Version 3.2.1 (2021) is the harmonised standard under the Web Accessibility Directive for the public sector. It brings in WCAG 2.1 Level A and AA and applies those criteria to web content (clause 9), documents (clause 10) and non-web software, which includes native apps (clause 11).

A revised version, EN 301 549 V4.1.1, is being finalised to support the EAA. It moves the baseline to WCAG 2.2 Level A and AA. It only gives a presumption of conformity under the Act once its reference is published in the Official Journal, so check that before you cite a version in a conformance report.

Enforcement

Each member state designates authorities to check that services comply (Article 23) and sets its own penalties, which must be effective, proportionate and dissuasive (Article 30). National law must also give consumers and organisations routes to act (Article 29). Enforcement practice differs per country, so the country you sell in matters as much as the directive.

One obligation is easy to miss. Under Article 13 and Annex V, service providers must publish information on how the service meets the accessibility requirements, in the general terms and conditions or an equivalent document, in an accessible format. That is the last item on our checklist.

The mobile app checklist

We group checks by what a person experiences, not by success-criterion number. Each item names the WCAG criterion where there is one, plus the platform value we design to.

Perception

• Text contrast is at least 4.5:1, large text at least 3:1WCAG 1.4.3. Large means 18 pt, or 14 pt bold. Android's guidance uses 18 sp and 14 sp bold. Check every state: disabled, pressed, on images and on brand gradients.
• Icons, borders and focus indicators reach 3:1 against what is next to themWCAG 1.4.11 non-text contrast. Outline-only text fields on light grey backgrounds fail this often.
• Text scales with the system settingWCAG 1.4.4 asks for 200% text without loss of content. Use Dynamic Type text styles on iOS and sp units on Android, where Android 14 and later support font scaling up to 200%. Test at the largest size: labels wrap, nothing is clipped, buttons grow.
• Colour is never the only signalWCAG 1.4.1. An error field needs an icon or text as well as red. Chart series need labels or patterns.
• Meaningful images have a text alternative, decorative ones are hiddenWCAG 1.1.1. A product photo needs a short description; a background flourish should be ignored by screen readers.
• The app works in portrait and landscape unless one orientation is essentialWCAG 1.3.4.

Operation

• Touch targets are at least 44 × 44 pt on iOS and 48 × 48 dp on AndroidWCAG 2.2 criterion 2.5.8 sets a floor of 24 × 24 CSS pixels (with a spacing exception). We design to the platform values from Apple's Human Interface Guidelines and Android's accessibility guidance, which are larger. The visible icon can be smaller than the hit area.
• Every gesture has a simple alternativeWCAG 2.5.1 and 2.5.7: swipe-to-delete also needs a button or menu action; drag to reorder needs move up and move down. Shake-to-undo needs an on-screen control and a way to turn it off (2.5.4).
• No timing trapsWCAG 2.2.1. If a session or one-time code expires, warn first and let people extend it. Auto-advancing carousels need a pause control (2.2.2).
• Nothing flashes more than three times per secondWCAG 2.3.1.
• Motion respects Reduce Motion and Remove animationsNot a Level AA criterion, but both platforms expose the setting and vestibular disorders are real. Swap large parallax and zoom transitions for fades.
• The app works with a hardware keyboard and switch accessWCAG 2.1.1. Focus must reach every control and never get stuck (2.1.2).

Screen readers

• Every control has a label that says what it doesaccessibilityLabel on iOS, contentDescription on Android. "Delete address", not "Button" or "Trash icon".
• Roles and states are exposedA custom toggle must announce as a switch with its on or off state; tabs as tabs with selected state; expandable rows as expanded or collapsed (WCAG 4.1.2).
• Focus order follows the visual orderWCAG 2.4.3. Group related elements, such as a price and its label, so VoiceOver and TalkBack read them as one item.
• Changes that happen without a tap are announcedWCAG 4.1.3 status messages: "Added to basket", "3 results", upload complete.
• Sheets and dialogs move focus in and give it backFocus goes to the sheet on open, stays inside it, and returns to the trigger on close.
• Tested by a person on a real deviceRun each core flow end to end with VoiceOver and TalkBack. Automated scanners such as Xcode's Accessibility Inspector and Android's Accessibility Scanner catch missing labels and small targets, but not a confusing flow.

Forms and errors

• Every field has a visible label, not just placeholder textWCAG 3.3.2. Placeholders disappear as soon as people type.
• Errors are described in text and suggest a fixWCAG 3.3.1 and 3.3.3: "Enter a date in the format DD/MM/YYYY", placed next to the field and announced.
• Fields declare their purpose so autofill worksWCAG 1.3.5. Use textContentType on iOS and autofill hints on Android for name, email, address and one-time codes.
• People are not asked for the same information twice in one flowWCAG 2.2 criterion 3.3.7 Redundant Entry. Pre-fill the billing address from the delivery address.
• Login does not depend on a memory or puzzle testWCAG 2.2 criterion 3.3.8. Allow paste and password managers; passkeys and email links help.
• Input survives an errorNever clear a long form because one field failed.

Media

• Pre-recorded video has captionsWCAG 1.2.2. Burned-in captions cannot be resized or styled; prefer a caption track the player renders.
• Video with important visual information has audio description or a text alternativeWCAG 1.2.5 at Level AA.
• Audio never autoplays for more than three seconds without a controlWCAG 1.4.2.
• Player controls are labelled and reachable by screen readersPlay, pause, seek, captions toggle and full screen, including when controls auto-hide.

Accessibility statement and feedback

• Publish how the service meets the requirementsAnnex V: a description of the service in accessible formats and how it meets Annex I, in the terms and conditions or an equivalent document. The W3C guide to accessibility statements is a good structure.
• Offer a working contact route for accessibility problemsAn email address or form that a person reads, linked from the app's settings or help screen.
• List known gaps honestly, with a planA short list of what does not yet work and when it will be fixed is better than a blanket claim of full compliance.
• Name an owner and retest on every releaseAccessibility regresses quietly. Put the screen reader pass into the release checklist, not into a once-a-year audit.

How we use this list

1. In design, the perception and operation items become tokens and component rules: contrast pairs, minimum hit areas, type styles that scale.
2. In build, the screen reader and form items become part of the definition of done for each component.
3. Before release, we run automated scans, then a manual VoiceOver and TalkBack pass through the core flows.
4. For an audit or a conformance report, we test with disabled people as well. A checklist tells you what to check; only users tell you whether it works.

If you start a new app today, none of this costs much when it is built in from the first screen. Retrofitting it into a finished app is where the time goes.

Sources

1. Directive (EU) 2019/882 on the accessibility requirements for products and services · EUR-Lex
2. European Accessibility Act (EAA) · European Commission
3. EN 301 549 V3.2.1: Accessibility requirements for ICT products and services · ETSI
4. Web Content Accessibility Guidelines (WCAG) 2.2 · W3C
5. Understanding Success Criterion 2.5.8: Target Size (Minimum) · W3C WAI
6. Accessibility, Human Interface Guidelines · Apple
7. Make apps more accessible · Android Developers
8. Developing an Accessibility Statement · W3C WAI