The German Accessibility Strengthening Act became binding on June 28, 2025, and many companies think first of their website. Yet the law explicitly names mobile applications as a distinct offering. Anyone running an app for shopping, banking, ticketing or customer service falls under the obligation just as much as an online shop in the browser. And unlike some existing services with long transition periods, an app that is newly published or substantially updated must meet the standard immediately. This article translates WCAG 2.1 AA and the European standard EN 301 549 into concrete requirements for iOS and Android apps: from screen reader labels and tap targets to operation without forced gestures.
Key takeaways
- The BFSG draws no line between a website and a native app. An app released or substantially reworked after 28 June 2025 cannot claim transitional relief; the accessibility standard applies immediately.
- The benchmark is EN 301 549 V3.2.1, whose Chapter 11 maps WCAG criteria onto software and adds software-only requirements. Implementation runs through the platform APIs with VoiceOver on iOS and TalkBack on Android; a web-only audit does not cover the app.
- Every control needs a name describing its function, not its icon: Delete rather than Trash can, with role and state exposed programmatically. On mobile, 70.6 percent use VoiceOver and 34.7 percent TalkBack (WebAIM Screen Reader Survey 10, 2024).
- Touch targets measure at least 44 by 44 points on iOS (Apple Human Interface Guidelines) and 48 by 48 dp on Android (Google Material Design). Text must scale to 200 percent and contrast reach 4.5 to 1, checked separately in light and dark mode.
- Every swipe or drag gesture needs a single-tap alternative (WCAG 2.5.1), motion-triggered actions must be switchable off (2.5.4), and the app has to work in portrait and landscape (1.3.4). Focus moves into dialogs and returns to a sensible place.
- Cross-platform builds lose accessibility through custom views without a role, text rendered as graphics, wrong traversal order and ignored system preferences. Test on real devices with a screen reader, plus Accessibility Inspector and Scanner.
Why the BFSG Now Covers Apps Too
The German Accessibility Strengthening Act (BFSG) transposes the European Accessibility Act into German law and obliges providers of certain products and services to ensure digital accessibility. Covered services include electronic commerce, consumer banking, passenger transport and telecommunications, among others. What matters for app operators: the law does not distinguish between a website and a native application. A shopping app, a banking app or a booking app delivers the same service as the associated website and must meet the same requirements (Bundesfachstelle Barrierefreiheit).
Two figures show how large the affected group is. At the end of 2023, around 7.9 million people with a severe disability lived in Germany, corresponding to 9.3 percent of the population (Federal Statistical Office, 2024). Worldwide, the World Health Organization estimates that about 1.3 billion people, roughly 16 percent of the population, live with a significant disability (WHO, 2023). A considerable share of these people use smartphones with assistive technologies. Among screen reader users, 91.3 percent also use a screen reader on a mobile device (WebAIM Screen Reader Survey 10, 2024). An app that ignores these technologies excludes a measurable share of its potential customers.
No Automatic Grace Period for New Apps
For an overview of which companies and offerings the law covers and which deadlines apply, our article BFSG 2025: What Companies Need to Know helps. Whether and when the narrow microenterprise rule applies is addressed in the article on the microenterprise exemption. Both texts make clear that the exemptions are narrower than many assume.
The Legal Frame: EN 301 549 and WCAG 2.1 AA
The technical yardstick for accessibility comes from the harmonized European standard EN 301 549 in version V3.2.1 of March 2021 (ETSI EN 301 549). For web content this standard references the Web Content Accessibility Guidelines in version 2.1 at level AA (W3C Web Accessibility Initiative). For native apps a separate chapter is decisive: Chapter 11 of the standard applies the WCAG success criteria to software that does not run in a browser and adds requirements that apply only to non-web applications. A pure web audit therefore does not cover this software part.
In practice this means the four WCAG principles, perceivable, operable, understandable and robust, apply to the app as well, only the technical implementation differs. Instead of HTML semantics and ARIA, native apps use the platform accessibility APIs. On iOS this is UIAccessibility with the VoiceOver screen reader, on Android the accessibility APIs with the TalkBack screen reader. Which concrete duties follow from this is summarized on our page on BFSG requirements.
| Aspect | Website (Browser) | Native App (iOS/Android) |
|---|---|---|
| Standard basis | EN 301 549, reference to WCAG 2.1 AA | EN 301 549 Chapter 11 (software) plus WCAG criteria |
| Semantics | HTML elements, ARIA roles | Platform accessibility APIs (UIAccessibility / Accessibility) |
| Screen reader | depends on system and browser | VoiceOver (iOS), TalkBack (Android) |
| Text scaling | Browser zoom, resize text | Dynamic Type (iOS), font size / display size (Android) |
| Testing | Web audit against WCAG 2.1 AA | App audit including the software criteria of the standard |
The Key Sentence for App Teams
Screen Reader Labels for VoiceOver and TalkBack
The most common and most consequential error in apps is missing or unintelligible control labels. An icon button without a label is announced by VoiceOver or TalkBack at best as an unnamed button, often not captured meaningfully at all. For blind and visually impaired users such a button is simply not operable. This is no fringe issue: VoiceOver is used by 70.6 percent (WebAIM Screen Reader Survey 10, 2024) and TalkBack by 34.7 percent (WebAIM, 2024) of surveyed screen reader users on mobile devices, sometimes in parallel.
Every interactive element therefore needs a meaningful, accessible name that describes the function, not the appearance. A trash can symbol is not called trash can but delete. In addition, role and state should be programmatically available so that the assistive technology announces button, selected or disabled correctly. The underlying logic of name, role and state is described in our article on screen reader optimization for the web; at the app level the same principles apply through the platform APIs.
Meaningful Labels
Every icon, button and functional image element receives an accessible name that describes its purpose. Purely decorative graphics, by contrast, are hidden from the screen reader so the output is not cluttered with ornament.
Role and State
Through the accessibility APIs the app communicates whether an element is a button, a switch or a selection field and in which state it is. This way the screen reader announces selected, activated or disabled correctly.
Grouping and Order
Related elements are grouped into meaningful units so the screen reader reads a card as a whole rather than in fragments. The reading order follows the logical structure, not the arbitrary position in the layout.
Heading Semantics
Screen titles and section headings are marked as headings so users can jump via the rotor or heading navigation. Merely enlarging the font without semantic marking is not enough for this.
Announce Status Messages
Dynamic feedback such as added to cart or form incomplete is actively conveyed to the screen reader without moving the focus. This way users who cannot see the screen also notice that something has changed.
Keep Focus Visible
The current operating focus is clearly visible and moves to the new element after a dialog opens. After closing it returns to a sensible place so the operating path remains traceable.
A button without a label is invisibly harmless to a sighted developer and a closed door to a blind user. The difference costs a few minutes in implementation, yet in operation it decides between usability and exclusion.
Tap Targets, Text Sizes and Zoom
Motor impairments, tremor or simply operating on the move make small controls a problem. Both platforms therefore specify minimum sizes for tap targets. Apple recommends at least 44 by 44 points per tappable area in its Human Interface Guidelines (Apple Human Interface Guidelines). Google's Material Design guidance specifies at least 48 by 48 dp for Android, which corresponds to about nine millimeters physically (Google Material Design). What matters is the tappable area, not the visible graphic: a small icon can have a sufficiently large invisible hit zone.
WCAG has matching criteria. Success criterion 2.5.5 Target Size requires at least 44 by 44 CSS pixels at level AAA (W3C Web Accessibility Initiative). With WCAG 2.2, criterion 2.5.8 Target Size Minimum was added, requiring at least 24 by 24 CSS pixels at level AA (W3C Web Accessibility Initiative). Since the BFSG references WCAG 2.1 via the current standard version, the platform guidelines are the practically binding yardstick, while the WCAG values set the direction. Sufficient spacing between neighboring targets additionally prevents accidentally triggering the wrong action.
Equally important is freely scalable text. Users set larger font sizes in the system settings, and the app must respect that rather than cutting off text or forcing it into fixed pixel heights. WCAG criterion 1.4.4 requires text to be enlargeable up to 200 percent without loss of content or function (W3C Web Accessibility Initiative). On iOS this happens via Dynamic Type, on Android via the system font size and the display size. Layouts must grow along without controls disappearing.
| Requirement | iOS | Android |
|---|---|---|
| Minimum tap target | 44 x 44 pt (Apple HIG) | 48 x 48 dp (Material Design) |
| Scalable text | Dynamic Type | Font size and display size |
| Screen reader | VoiceOver | TalkBack |
| Contrast test | Color and contrast check | Color and contrast check |
| Focus control | accessibilityElements, focus order | Traversal order, focus handling |
The third building block is color contrast. Text must stand out from the background with a ratio of at least 4.5 to 1, large text from 3 to 1 (W3C Web Accessibility Initiative, WCAG 1.4.3). Controls and their states also need sufficient contrast so that borders and focus indicators remain recognizable. How to plan and check reliable contrast values is shown in our article on color contrast in accessibility.
Think Dark Mode and Contrast Together
Focus Order and Operation Without Forced Gestures
Touch interfaces invite complex gestures: swipe, drag, pinch, tilt. For people with motor impairments or for screen reader users such gestures are often impossible to perform. WCAG therefore requires that any function demanding a complex or path-dependent pointer gesture is alternatively operable with a simple tap (W3C Web Accessibility Initiative, WCAG 2.5.1 Pointer Gestures). A carousel that can only be moved by swiping needs additional previous and next buttons.
Related is criterion 2.5.4 Motion Actuation: functions triggered by shaking or tilting the device, such as undo by shaking, must also be reachable through a visible control and be switchable off (W3C Web Accessibility Initiative). Likewise an app must not lock use to a single screen orientation unless the function strictly requires it. Criterion 1.3.4 Orientation requires that portrait and landscape are equally supported (W3C Web Accessibility Initiative), which particularly concerns people who have their device fixed to a wheelchair.
- Single-pointer alternative: Every swipe, drag or multi-finger gesture has an operation via a simple tap (WCAG 2.5.1).
- Motion switchable: Actions triggered by shaking or tilting are also reachable via a button and can be disabled (WCAG 2.5.4).
- Free orientation: The app works in portrait and landscape, unless the function strictly requires an orientation (WCAG 1.3.4).
- Logical focus order: The operating focus moves in a traceable order, dialogs trap the focus and return it correctly.
- Enough time: Time limits can be switched off or extended so that slower operation does not lead to abandonment.
- No color-only coding: States such as error or selection are conveyed not by color alone but additionally by symbol or text.
Focus control in particular is demanding in dynamic interfaces. When an overlay or a bottom sheet opens, the focus must move there and must not remain stuck behind the dialog in the background. The patterns for this closely resemble those on the web; our article on focus management in single-page applications describes the principles that transfer one to one to app navigation. Anyone additionally supporting physical keyboards or switch controls will find the relevant basics in our article on keyboard navigation.
Overlay Tools Do Not Solve the App Problem
Common Mistakes in Cross-Platform Frameworks
Many apps are not built twice natively but once in a cross-platform framework that produces an iOS and an Android app from a single codebase. This saves effort but shifts the responsibility for accessibility: the shared code must pass the right information to both platform APIs. This is exactly where typical gaps arise, because custom canvases and custom components do not automatically bring native semantics.
Missing Semantics in Custom Views
Self-drawn controls look like buttons but to the accessibility API they are just a surface without a role. Without explicit marking as a button with a name they remain mute to screen readers.
Wrong Focus Order
If the tree structure of the interface does not match the visual order, the screen reader focus jumps unpredictably. The traversal order must follow the logical reading order, not the order in the source code.
Text as Graphic
If text is rendered into an image, it does not scale with the system font size and carries no readable meaning. Real text with Dynamic Type or scalable units stays legible and machine-readable.
Duplicate or Orphaned Elements
Some frameworks create invisible duplicates or leave dimmed layers in the accessibility tree. The screen reader then reads out elements that are not operable at all and confuses navigation.
Missed Status Updates
When content changes dynamically, the app must actively report the change to the platform. Without this notification a screen reader does not notice new error messages or updated prices.
Ignored System Settings
Reduced motion, larger text or increased contrast are system preferences the app should query and respect. Overriding them disables the aids the user has individually configured.
The good news: all established frameworks offer interfaces to set role, name, state and focus correctly. In cross-platform development, accessibility is not a question of technology but of care and testing on real devices with an active screen reader. Building in the semantics from the start avoids expensive rework shortly before release.
Testing App Accessibility: Manual and Automated
Automated testing tools find part of the problems, such as missing labels or insufficient contrast, but they do not replace manual testing. Whether an app is actually operable with VoiceOver or TalkBack, whether the focus order is right and whether gestures have alternatives can only be judged in real operation. Both platforms provide built-in tools for this: the Accessibility Inspector on iOS and the Accessibility Scanner on Android. What role automated tests play in the overall picture is set out in our article on accessibility testing tools.
- Screen reader run: Operate the central flows once completely with VoiceOver and once with TalkBack, without looking at the screen, and check whether every element is announced and reachable.
- Tap-only test: Operate the app exclusively with simple taps and determine whether every swipe or drag gesture has an alternative.
- Check scaling: Set the system font size to the maximum and verify whether text stays legible and no controls disappear.
- Measure contrast: Check text and controls in light and dark mode against the thresholds 4.5 to 1 and 3 to 1.
- Orientation and motion: Test portrait and landscape and check motion-controlled functions for a switchable alternative.
- Use built-in tools: Use Accessibility Inspector and Accessibility Scanner to detect missing roles, names and hit zones.
From Test to a Robust Proof
An external review against WCAG 2.1 AA and EN 301 549 provides the necessary distance from your own development team. A WCAG audit for your app uncovers barriers in a structured way and prioritizes remediation by impact. Afterwards we accompany accessible development across the whole lifecycle so that the next feature release stays compliant too. What scope your app has and which testing path makes sense we are glad to clarify via the contact page.
Sources and Studies