axessia.eu

Wie lange dauert es, einen Onlineshop nach WCAG zugänglich zu machen?

Es gibt keine feste Frist im Gesetz für das Zugänglichmachen einer Website; sehr wohl aber für den Umfang und die Erklärung. In der Praxis bestimmen Größe, CMS und interne Entscheidungsfindung, wie lange das Vorhaben dauert.

Die Richtlinie selbst nennt keine feste Frist für das "Zugänglichmachen" eines Onlineshops. Was feststeht, ist der Termin, ab dem die Verpflichtung gilt: Seit dem 28. Juni 2025 ist die Anforderung für Dienste, die darunter fallen, durchsetzbar. Wie lange das eigentliche Vorhaben dauert, um von einer aktuellen Website zu einer Website zu gelangen, die EN 301 549 erfüllt (in der Praxis WCAG 2.1 Level AA), hängt vom Umfang der Website, der Anzahl der Mängel und der Geschwindigkeit ab, mit der eine Organisation intern handeln kann.

In der Praxis gliedert sich ein Vorhaben in vier Phasen: Erfassung, Priorisierung, technische Behebung und Dokumentation. Ein kleiner Onlineshop mit einem Standard-CMS-Theme und einem begrenzten Bestellvorgang durchläuft diese Phasen in der Regel schneller als eine Plattform mit einer eigenen Anmeldungsumgebung, einem maßgeschneiderten Checkout und mehreren Sprachen. Es gibt keine Zahl, die für jede Organisation passt; aber es gibt ein Muster, wo Vorhaben ins Stocken geraten.

Was das Gesetz regelt und was nicht

Die Verordnung beschreibt, welche Dienste in den Anwendungsbereich fallen, welche technische Norm gilt und welche Informationen eine Erklärung zur Barrierefreiheit enthalten muss. Eine konkrete Frist für "zuerst scannen, dann innerhalb von X Wochen verbessern" ist darin nicht vorgesehen. Die Aufsichtsbehörden prüfen den aktuellen Zustand eines Dienstes und die Frage, ob eine Organisation nachweislich und strukturiert an der Einhaltung arbeitet, nicht nach einer festen Durchlaufzeit, die überall gleich sein würde. Für die genauen Anforderungen für jeden Teil einer Website ist es ratsam, den Text selbst zu konsultieren; für jedes Thema wurde nachgeprüft, was die Regeln genau bedeuten und wo sie im offiziellen Text stehen.

Wo Vorhaben in der Praxis feststecken

Die erste Verzögerung entsteht oft nicht bei der Technik, sondern bei der Übersicht: Unternehmen wissen nicht, welche Seiten, Formulare und Prozesse in den Anwendungsbereich fallen und welche nicht. Ein zweiter Engpass ist die Bezahlungsschritt und die Anmeldungsumgebung; das sind oft maßgeschneiderte Komponenten, die nicht in einem Standard-Theme vorhanden sind und daher nicht automatisch von einem CMS-Update profitieren. Ein dritter Engpass ist die Abhängigkeit von einem externen Anbieter für das CMS oder das Zahlungsmodul, wobei eine Änderung manchmal auf eine Freigabe dieses Anbieters warten muss. Und ein vierter Engpass ist intern: eine Liste mit Feststellungen in technischer Sprache bleibt liegen, weil niemand weiß, wer welche Regel umsetzt.

Vier Phasen und wo sie ins Stocken geraten

Die Erfassungsphase befasst sich mit der Feststellung, was nicht stimmt, auf welchen Seiten und wie schwerwiegend es für jemanden ist, der einen Bildschirmleser oder nur eine Tastatur nutzt. Dies ist die Phase, in der ein automatisierter Scan die meiste Arbeit leistet, aber auch die Phase, in der klar sein muss, was ein solcher Scan nicht sehen kann; nicht jedes WCAG-Kriterium lässt sich maschinell überprüfen.

Die Priorisierungsphase setzt Feststellungen in eine Reihenfolge um: Was blockiert eine Bestellung vollständig, und was ist ein kleineres Hindernis. Dies steckt oft fest, weil eine technische Liste von Feststellungen nicht angibt, wer innerhalb der Organisation für welchen Teil zuständig ist.

Die Behebungsphase ist die Phase mit der längsten Durchlaufzeit, und deren Dauer hängt stark davon ab, ob Anpassungen intern vorgenommen werden können oder über einen Anbieter erfolgen müssen. Formularbeschriftungen und Farbkontrast lassen sich oft schnell beheben; ein Bestellvorgang, der technisch nicht nur mit einer Tastatur bedienbar ist, erfordert mehr Entwicklungsarbeit.

Die letzte Phase ist die Dokumentation: die Erklärung zur Barrierefreiheit aufstellen, einen Verbesserungsplan mit Fristen festlegen und nachweisen, dass eine eigene Bewertung durchgeführt wurde. Dies ist keine Phase, die man auslässt, wenn die Technik einmal stimmt; die Erklärung sollte den aktuellen Stand widerspiegeln, auch wenn dieser noch nicht perfekt ist.

Was die Durchlaufzeit tatsächlich beeinflusst

Eine Organisation, die im Voraus weiß, welche Seiten in den Anwendungsbereich fallen und welche Mängel am schwerwiegendsten sind, verschwendet weniger Zeit mit Hin- und Herschalten zwischen Technik und Entscheidungsfindung. In wenigen Fragen lässt sich kostenlos sehen, wo eine Website derzeit steht, ohne dass dafür ein Konto erforderlich ist. Für den nächsten Schritt, also den vollständigen Scan des Bestellvorgangs und des Login-Flows sowie eine priorisierte Maßnahmenliste in verständlicher Sprache, gilt: Die Ausarbeitung pro Anforderung mit den zugehörigen Fristen ist Teil des kostenpflichtigen Prozesses; was darin enthalten ist, wird übersichtlich aufgelistet.

Ein letzter Faktor, der die Durchlaufzeit beeinflusst: Barrierefreiheit ist kein Projekt mit einem Enddatum, sondern ein Zustand, der nach jeder Änderung der Website neu gilt. Ein neuer Checkout-Schritt oder ein überarbeitetes Kontaktformular kann ein Problem zurückbringen, das zuvor bereits gelöst war. Wer wissen möchte, woher die Informationen in einem Bericht stammen und wie oft diese aktualisiert werden, findet dies auf der Seite, die erklärt, wie der Prozess funktioniert.

Für die eigene Situation, mit dem eigenen CMS, Anbieter und interner Planung, bleibt es schwierig, im Voraus eine feste Frist zu nennen. Wer unsicher ist, ob ein Prozess realistisch zu planen ist, tut gut daran, zunächst klar zu definieren, was genau getan werden muss, bevor ein Zeitplan drumherum erstellt wird. Der kostenlose Quick-Scan ist dafür ein logischer Ausgangspunkt, ohne dass sofort ein Konto oder eine Zahlung erforderlich ist.

Dieser Artikel ist allgemeine Information und keine rechtliche Beratung.