There is no fixed deadline that applies to every app. A small app with a limited number of screens and a clean codebase can reach the desired level in a few weeks; an app with many custom components, multiple platforms and a long history of technical debt takes more like months. The biggest variable is not the number of screens, but how much of the interface is built outside the standard components of iOS or Android.
As a rough indication: an app that mostly consists of standard UI elements and whose team is already familiar with accessibility can typically be adapted within six to ten weeks in practice. An app with a lot of custom interaction, animations, custom gestures or embedded third-party SDKs quickly runs to three to six months, simply because each component must be examined separately and sometimes rebuilt. These are not hard limits but an impression of where most projects end up in practice.
What really determines the timeline
The time a project takes depends less on the law itself and more on three practical factors. First: is the interface built from standard components of the operating system, or largely custom built? Standard components often provide accessibility as a given; custom components must each be provided with the correct labels, focus order and screen reader announcements. Second: how many external components are in the app, such as payment modules, map displays or third-party chat windows? These often fall outside the direct control of your own team, and checking with a supplier typically takes more time than testing itself. Third: is there already a testing routine with a screen reader on the actual device, or does that need to be set up first? The latter takes the most time on the first round, but pays back on subsequent updates.
Where schedules typically stall in practice
Most delays do not come from adjusting text or colour contrast, but from interaction that turns out not to be operable with a keyboard or screen reader: a drag gesture with no alternative, a modal window that does not trap focus, or a form whose error messages are not announced. These kinds of issues often only become visible when manually testing with a screen reader, something an automated scan cannot fully replace. Those who rely only on automated checks typically discover these bottlenecks too late in the project, which extends the timeline. A good starting point is therefore to get a first indication in a few questions of where the app currently stands, so that the time-consuming parts come to light early rather than just before delivery.
App store review cycles also play a role: an adjustment that improves accessibility must still go through the usual review period of the relevant store before users notice it. This is beyond the influence of the development team and should be included in every plan as a fixed time buffer.
Remaining accessible after release
An app that meets requirements today may not do so after the next update. Every new feature, every new screen and every modified flow deserves the same attention as the first round, otherwise the problem creeps back in. That is also why the requirement does not stop at testing once: your own assessment must remain current, and that requires a recurring rhythm rather than a one-time project. For context on what is exactly expected of you in this regard, the background tailored to your situation is a suitable starting point.
What axessia.eu does and does not do in this process
Axessia tests, prioritizes, documents, and monitors: the scan shows where the app currently stands, the report presents the findings in plain language in a prioritized list, and the statement and improvement plan document what has been done and what still needs to happen. Manual audits and repair work on the app itself are not part of this; that remains the responsibility of the development team or the party that built the app. How the scan is conducted in detail and which sources are used is explained on the page on how the information is compiled. What a complete process including report and statement costs is shown on the subscription overview.
Anyone who wants to know where a specific app currently stands should start with the free quick-scan on axessia.eu. It provides an initial picture within a few minutes, without requiring an account.