Es gibt keine festgelegte Frist, die für jede App gilt. Eine kleine App mit einer begrenzten Anzahl von Bildschirmen und einer aufgeräumten Codebasis lässt sich in wenigen Wochen auf das gewünschte Niveau bringen; eine App mit vielen maßgeschneiderten Komponenten, mehreren Plattformen und einer langen Geschichte technischer Schulden erfordert eher Monate. Die größte Variable ist nicht die Anzahl der Bildschirme, sondern wie viel der Bedienung außerhalb der Standardkomponenten von iOS oder Android aufgebaut wurde.
Als grobe Orientierung: Eine App, die größtenteils aus Standard-UI-Elementen besteht und deren Team bereits mit Barrierefreiheit vertraut ist, lässt sich in der Praxis oft innerhalb von sechs bis zehn Wochen anpassen. Eine App mit viel eigener Bedienung, Animationen, benutzerdefinierten Gesten oder eingebetteten SDKs von Drittanbietern dauert schnell drei bis sechs Monate, einfach weil jeder Teil separat untersucht und manchmal neu gebaut werden muss. Dies sind keine harten Grenzen, sondern ein Eindruck davon, wo die meisten Vorhaben in der Praxis landen.
Was die Dauer wirklich bestimmt
Die Zeit, die ein Vorhaben kostet, hängt weniger vom Gesetz selbst ab und mehr von drei praktischen Faktoren. Erstens: Besteht die Bedienung aus Standardkomponenten des Betriebssystems oder ist sie größtenteils benutzerdefiniert aufgebaut? Standardkomponenten bieten Barrierefreiheit oft bereits zum großen Teil; eigene Komponenten müssen einzeln mit den richtigen Beschriftungen, Fokusreihenfolgen und Ankündigungen für Bildschirmleser versehen werden. Zweitens: Wie viele externe Komponenten befinden sich in der App, wie Zahlungsmodule, Kartendarstellungen oder Chat-Fenster von Drittanbietern? Diese liegen oft außerhalb der direkten Kontrolle des eigenen Teams, und die Anfrage bei einem Anbieter dauert normalerweise länger als das Testen selbst. Drittens: Gibt es bereits eine Testroutine mit einem Bildschirmleser auf dem echten Gerät, oder muss diese erst noch eingerichtet werden? Letzteres kostet in der ersten Runde die meiste Zeit, zahlt sich aber bei zukünftigen Updates aus.
Wo Planungen in der Praxis ins Stocken geraten
Die meisten Verzögerungen entstehen nicht bei der Anpassung von Text oder Farbkontrast, sondern bei Interaktionen, die sich nicht mit Tastatur oder Bildschirmleser bedienen lassen: eine Wischbewegung ohne Alternative, ein modales Fenster, das den Fokus nicht beibehält, oder ein Formular, bei dem Fehlermeldungen nicht angekündigt werden. Diese Probleme werden oft erst beim manuellen Testen mit einem Bildschirmleser sichtbar, was ein automatisierter Scan nicht vollständig ersetzen kann. Wer sich nur auf eine automatische Prüfung verlässt, erkennt diese Engpässe normalerweise zu spät im Vorhaben, was die Dauer dennoch verlängert. Ein guter Startpunkt ist daher in wenigen Fragen einen ersten Überblick zu erhalten, wo sich die App derzeit befindet, damit die zeitaufwändigen Teile früh sichtbar werden, anstatt kurz vor der Ablieferung.
Auch App-Store-Überprüfungszyklen spielen eine Rolle: Eine Anpassung, die die Barrierefreiheit verbessert, muss immer noch die üblichen Überprüfungszeiträume des jeweiligen Stores durchlaufen, bevor Nutzer davon etwas bemerken. Das liegt außerhalb des Einflusses des Entwicklungsteams und sollte in jeder Planung als feste Zeitpufferung vorgesehen werden.
Barrierefreiheit nach der Ablieferung bewahren
Eine App, die heute barrierefrei ist, kann das nach dem nächsten Update nicht mehr sein. Jede neue Funktion, jeder neue Bildschirm und jeder geänderte Ablauf verdienen dieselbe Aufmerksamkeit wie die erste Runde, sonst schleicht sich das Problem wieder ein. Deshalb endet die Verpflichtung nicht mit einmaligem Testen: Die eigene Bewertung muss aktuell bleiben, und das erfordert einen wiederkehrenden Rhythmus statt eines einmaligen Projekts. Für den Hintergrund, was dabei genau von Ihnen erwartet wird, ist die je nach Situation ausgewählte Erläuterung ein passender Startpunkt.
Was axessia.eu in diesem Vorhaben tut und nicht tut
Axessia prüft, priorisiert, dokumentiert und überwacht: Der Scan zeigt den aktuellen Stand der App, der Bericht fasst die Erkenntnisse in verständlicher Sprache auf einer priorisierten Liste zusammen, und die Erklärung sowie der Verbesserungsplan dokumentieren, was bereits getan wurde und was noch zu tun ist. Manuelle Audits und Reparaturarbeiten an der App selbst gehören nicht dazu; diese Aufgabe bleibt beim Entwicklungsteam oder der Partei, die die App entwickelt. Wie dieser Scan genau durchgeführt wird und welche Quellen dabei verwendet werden, wird erläutert auf der Seite zur Entstehung der Informationen. Was ein vollständiger Prozess einschließlich Bericht und Erklärung kostet, erfahren Sie auf der Übersicht der Abonnements.
Wer wissen möchte, wie eine konkrete App derzeit funktioniert, sollte mit dem kostenlosen Quick-Scan von axessia.eu beginnen. Dieser vermittelt innerhalb weniger Minuten einen ersten Eindruck, ohne dass dafür ein Konto erforderlich ist.