Accessibility

Barrierefreiheit dauerhaft sichern: Tests nach Updates und klare Verantwortung

07. November 2026Zensations

Barrierefreiheit bleibt nach einem Update nicht automatisch erhalten. Damit Navigation, Formulare und zentrale Aufgaben weiterhin zugänglich sind, brauchen Sie ein Wartungsprogramm mit drei verbindlichen Elementen: risikobasierte Tests vor der Freigabe, eindeutig zugewiesene Verantwortung und einen dokumentierten Retest behobener Fehler. Automatisierte Prüfungen liefern dafür schnelle Hinweise; Tastaturtests, Screenreader-Prüfungen und redaktionelle Kontrollen ergänzen die notwendige Abdeckung. Entscheidend ist nicht die Anzahl ausgeführter Tests, sondern ob relevante Nutzungspfade und ihre Fehlerzustände tatsächlich geprüft werden.

Dieser Beitrag beschreibt ein solches Programm für Websites und digitale Dienste. Alle beschriebenen Abläufe und Fehlerbeispiele sind hypothetisch. Sie zeigen, wie Sie aus einem einmaligen Audit eine belastbare Wartungspraxis entwickeln, ohne einen fehlerfreien Prüfbericht mit vollständiger rechtlicher Konformität zu verwechseln.

1. Prüfziel und Geltungsbereich zuerst festhalten

Definieren Sie schriftlich, welche Website, Anwendungen, Dokumente und eingebundenen Dienste Ihr Programm umfasst. Halten Sie auch fest, welche Sprachen, angemeldeten Bereiche und mobilen Ansichten dazugehören. Ein Shop endet aus Sicht der Kund:innen nicht am Übergang zum Zahlungsdienst. Für die Wartung muss deshalb sichtbar bleiben, welche Teile Sie selbst ändern können und welche von externen Anbietern abhängen. Eine Liste bloßer URLs reicht dafür nicht: Varianten, Zustände und vollständige Aufgaben gehören ebenfalls in den Prüfumfang.

Als technisches Prüfziel kann WCAG 2.2 auf Konformitätsstufe AA dienen. Das umfasst die anwendbaren Anforderungen der Stufen A und AA. Die WCAG 2.2 sind jedoch nicht mit EN 301 549 austauschbar; ein technischer Audit ist auch keine vollständige rechtliche Compliance-Prüfung. Das österreichische BaFG gilt seit 28. Juni 2025 für erfasste Dienstleistungen, nicht pauschal für alle Websites. Für Anwendungsbereich, Ausnahmen und Abgrenzungen nutzen Sie unseren Leitfaden zur barrierefreien Website in Österreich. Im Wartungsplan dokumentieren Sie das vereinbarte technische Ziel unabhängig von dieser rechtlichen Einordnung.

2. Verantwortung entlang des gesamten Release-Prozesses verteilen

Benennen Sie eine Person, die das Wartungsprogramm koordiniert, aber machen Sie diese nicht zur alleinigen Prüfstelle für jede Änderung. Die Produktverantwortung entscheidet über Umfang und Freigabe. Entwicklungsteams sichern Verhalten und Semantik ab. Die Qualitätssicherung organisiert manuelle Prüfungen und Belege. Die Redaktion kontrolliert neue Inhalte und Dokumente. Für externe Dienste braucht es eine zuständige Person, die Mängel beim Anbieter verfolgt. Jede Aufgabe benötigt eine Vertretung, damit Urlaub oder Personalwechsel keine Prüflücke erzeugen.

In einem hypothetischen Team könnte die Release-Verantwortliche vor jeder Freigabe kontrollieren, ob alle erforderlichen Nachweise vorliegen. Sie muss nicht selbst jeden Screenreader-Test durchführen. Ihr Auftrag ist, fehlende Prüfungen zu erkennen, offene Risiken sichtbar zu machen und die Freigaberegel anzuwenden. Halten Sie diese Zuständigkeiten im selben System fest wie andere Release-Aufgaben. Ein separates Dokument ohne Verbindung zu Tickets und Terminen wird im Alltag leicht übersehen. Auch Entscheidungen über Verschiebungen brauchen einen Namen, eine Begründung und einen nächsten Prüftermin.

3. Änderungen nach Risiko statt nur nach Umfang bewerten

Eine kleine Codeänderung kann viele Menschen blockieren, während eine große Textkorrektur kaum Interaktionsrisiko mitbringt. Bewerten Sie deshalb, welche Funktionen und gemeinsamen Bausteine betroffen sind. Besonders prüfbedürftig sind Navigation, Anmeldung, Suche, Formulare, Dialoge, Zahlungsabläufe und globale Gestaltungseinstellungen. Auch Updates von CMS, Erweiterungen oder Consent-Diensten können Fokusreihenfolge und zugängliche Namen verändern, obwohl Ihr Team keine eigene Funktion angepasst hat. Hinterlegen Sie diese Auslöser direkt in Ihrer Änderungsvorlage.

Ordnen Sie jeder Änderung einen nachvollziehbaren Prüfauftrag zu. Eine Korrektur im Artikeltext verlangt beispielsweise eine redaktionelle Kontrolle der betroffenen Inhalte. Eine Änderung am gemeinsamen Formularbaustein verlangt zusätzlich automatisierte Komponententests und manuelle Prüfungen repräsentativer Formulare. Ein Austausch des Buchungsdienstes erfordert einen vollständigen Buchungspfad einschließlich Fehlern und Bestätigung. Bei unklaren Auswirkungen sollte zunächst die Abhängigkeit untersucht werden, statt vorschnell einen kleinen Testumfang anzunehmen. Die Begründung für die gewählte Abdeckung gehört zum Release-Nachweis.

4. Release-Gates mit überprüfbaren Bedingungen formulieren

Ein Release-Gate ist eine Freigabebedingung, keine unverbindliche Erinnerung. Formulieren Sie konkret, welche Nachweise vorliegen müssen: erfolgreiche automatisierte Prüfungen im vereinbarten Umfang, abgeschlossene manuelle Tests für betroffene Nutzungspfade und geklärte neue Befunde. Als interne Regel kann gelten, dass ein neuer Fehler, der eine zentrale Aufgabe ohne zugängliche Alternative verhindert, die Freigabe blockiert. Diese Regel sollte auch gelten, wenn der Fehler aus einer Bibliothek stammt und nicht aus eigenem Code.

Für einen hypothetischen Sicherheits-Hotfix brauchen Sie einen vorab definierten Ausnahmeprozess. Er kann einen verkürzten Testumfang mit anschließender verbindlicher Nachprüfung vorsehen. Dokumentieren Sie dabei die ausgelassenen Prüfungen, die verantwortliche Entscheidung, gegebenenfalls einen Rückfallplan und einen konkreten Termin. Eine interne Risikoakzeptanz macht eine bestehende Barriere weder technisch konform noch rechtlich zulässig. Kontrollieren Sie nach der Auslieferung außerdem die reale Umgebung: Konfigurationen, zwischengespeicherte Dateien und tatsächlich geladene Drittanbieter-Skripte können vom Testsystem abweichen.

5. Automatisierte Abdeckung gezielt aufbauen

Automatisieren Sie wiederholbare Prüfungen auf mehreren Ebenen. Komponententests können erwartete Beschriftungen und Zustände prüfen. Integrationstests untersuchen zusammengesetzte Formulare. Browserbasierte Tests öffnen zentrale Seiten und relevante Zustände, bevor ein Prüfwerkzeug das gerenderte Dokument untersucht. Prüfen Sie also nicht nur den geschlossenen Dialog, sondern auch seine geöffnete Variante; nicht nur das leere Formular, sondern auch dessen Fehlermeldungen. Ein Scan erreicht nur die Zustände, die Ihre Testvorbereitung tatsächlich herstellt.

Die W3C WAI-Hinweise zur Auswahl von Prüfwerkzeugen verdeutlichen die Grenzen automatisierter Auswertung. Ein Werkzeug kann beispielsweise eine vorhandene Bildalternative erkennen, aber deren inhaltliche Eignung nicht allgemein zuverlässig beurteilen. Ebenso beweist ein unauffälliger Scan nicht, dass ein Buchungsvorgang verständlich bedienbar ist. Dokumentieren Sie deshalb neben den Ergebnissen auch die Grenzen Ihrer Abdeckung. Bekannte Befunde sollten einzeln erfasst werden; eine pauschale Unterdrückung ganzer Regeln kann neue Regressionen verbergen. Werkzeug-Updates selbst benötigen ebenfalls eine kontrollierte Einführung.

6. Kurze manuelle Smoke-Journeys verbindlich machen

Eine Smoke-Journey ist ein kurzer, repräsentativer Nutzungspfad zur Früherkennung gravierender Fehler. Sie ersetzt keinen vollständigen Audit. Wählen Sie Pfade nach den tatsächlichen Aufgaben Ihrer Nutzer:innen und halten Sie die Schritte stabil genug für Vergleiche. Legen Sie außerdem fest, welche Browser-, Geräte- und Screenreader-Kombinationen verwendet werden. Die Auswahl sollte zur Anwendung und ihren Nutzer:innen passen und bei grundlegenden technischen Änderungen neu bewertet werden.

Von der Startseite ausschließlich mit der Tastatur zur Suche wechseln, einen Begriff eingeben, Ergebnisse öffnen und zur Navigation zurückkehren.
Ein Formular ausfüllen, absichtlich eine Pflichtangabe auslassen, den Fehler finden, korrigieren und die Bestätigung wahrnehmen.
Einen Dialog öffnen, seine Inhalte bedienen, ihn schließen und am sinnvollen Ausgangspunkt weiterarbeiten.

Ergänzen Sie diese Pfade durch gezielte Screenreader-Prüfungen sowie Vergrößerungs- und Reflow-Tests. Bei 200 Prozent Textvergrößerung darf die Funktionalität nicht verloren gehen; Reflow wird für die einschlägigen Anforderungen bei 320 CSS-Pixeln Breite geprüft, mit den vorgesehenen Ausnahmen. Notieren Sie pro Schritt erwartetes Verhalten und Ergebnis. „Mit Tastatur getestet“ ist kein ausreichender Nachweis, wenn unklar bleibt, ob Fehlermeldung, Fokus und Abschluss berücksichtigt wurden.

7. Fehlerzustände und Fokus ausdrücklich prüfen

Angenommen, ein Update ergänzt in einem Kontaktformular eine clientseitige Validierung. Danach werden ungültige Felder nur rot umrandet und bereits eingegebene Angaben beim Absenden gelöscht. Ein bloßer Test des erfolgreichen Versands würde beide Probleme übersehen. Die Korrektur sollte verständliche Fehlermeldungen, eine eindeutige Zuordnung zum Feld und den Erhalt sinnvoll weiterverwendbarer Eingaben vorsehen. Die W3C WAI Forms Tutorial bieten dafür Hinweise zu Beschriftungen, Gruppierung, Anweisungen und Rückmeldungen. Der Abnahmenachweis zeigt, wie Nutzer:innen den Fehler erkennen und ohne unnötige Wiederholung korrigieren.

Ein zweites hypothetisches Beispiel betrifft einen aktualisierten Bestätigungsdialog. Der Fokus bleibt versehentlich auf der dahinterliegenden Seite. Prüfen Sie initialen Fokus, Tab-Reihenfolge innerhalb des modalen Dialogs, Schließen mit Escape und eine sinnvolle Fokusrückgabe. Das ARIA Authoring Practices Guide: Dialog (Modal) Pattern beschreibt das entsprechende Interaktionsmuster. ARIA-Attribute allein implementieren dieses Verhalten nicht. Zur Abnahme gehören deshalb tatsächliche Tastaturbedienung und Screenreader-Ausgabe, nicht nur eine Kontrolle der Rollen im Quelltext.

8. Fehlerberichte auf Reproduktion und Wirkung ausrichten

Ein brauchbares Ticket enthält Seite oder Komponente, Build-Version, Testumgebung, Voraussetzungen und genaue Reproduktionsschritte. Beschreiben Sie danach erwartetes und beobachtetes Verhalten sowie die Auswirkung auf die Aufgabe. Ergänzen Sie ein einschlägiges Erfolgskriterium, wenn die Zuordnung belastbar ist. Screenshots, kurze Aufzeichnungen oder relevante Ausschnitte des Accessibility Trees können helfen, ersetzen aber keine nachvollziehbare Beschreibung. Verwenden Sie Testdaten und entfernen Sie personenbezogene Informationen aus Belegen.

Priorisieren Sie nach Auswirkung, Reichweite und verfügbaren Alternativen. Ein nicht bedienbarer Abschlussknopf in einem zentralen Ablauf ist anders zu behandeln als eine unpräzise Überschrift auf einer selten genutzten Unterseite. Die WCAG-Stufe allein ist keine Fehlerpriorität: Auch ein A-Kriterium kann unterschiedliche praktische Auswirkungen haben. Halten Sie die technische Schwere getrennt von der geplanten Bearbeitungsreihenfolge fest. Wenn eine vorübergehende Alternative angeboten wird, muss auch diese geprüft werden. Ein Telefonkontakt ist nicht automatisch eine gleichwertige Lösung für jede Person oder Aufgabe.

9. Redaktionelle Änderungen und Dokumente einbeziehen

Redaktionelle Freigaben brauchen eigene Prüfpunkte: aussagekräftige Überschriften, verständliche Linktexte, passende Bildalternativen und nachvollziehbare Tabellenstrukturen. Prüfen Sie Inhalte in der tatsächlichen Vorlage, nicht ausschließlich im CMS-Eingabefeld. Ein hypothetischer Teaser kann im Editor verständlich wirken, auf der Seite aber mehrere gleich benannte Links erzeugen. Bei Bildern hängt die richtige Alternative vom Zweck ab: Dekoration, Information und verlinkte Funktion benötigen unterschiedliche Behandlung. Eine starre Zeichenbegrenzung ersetzt diese Entscheidung nicht.

Für neue oder ersetzte PDFs legen Sie einen gesonderten Ablauf fest. Sichtprüfung und Textextraktion genügen nicht, um Lesereihenfolge, Struktur oder sinnvolle Tastaturnavigation zu beurteilen. Bei Tabellen müssen auch die Beziehungen zwischen Überschriften und Daten verständlich verfügbar sein. Zensations hat im Rahmen von Arbeiten für die FFG Websites und Tools evaluiert und redaktionelle Workshops einschließlich PDFs durchgeführt. Für die Wartung ist genau diese Verbindung relevant: Redaktionelle Regeln müssen am konkreten Veröffentlichungsprozess geübt werden, damit dieselben Fehler nicht mit jeder neuen Datei zurückkehren.

10. Komponentenbibliothek und externe Anbieter gemeinsam steuern

Hinterlegen Sie für gemeinsam verwendete Komponenten einen dokumentierten Interaktionsvertrag. Er beschreibt zugänglichen Namen, Zustände, Tastaturverhalten, Fokusführung und zulässige Varianten. Ein Formularfeld sollte beispielsweise mit Hinweistext, Pflichtkennzeichnung, Fehlermeldung und deaktiviertem Zustand demonstriert werden. So prüfen Sie nicht nur einen isolierten Idealzustand. Änderungen an Design-Tokens benötigen ebenfalls Regressionstests, weil sie Kontrast, Fokusindikatoren oder Umbrüche an vielen Stellen gleichzeitig beeinflussen können. Versionshinweise sollten betroffene Verbraucher der Komponente benennen.

Externe Anbieter gehören in dieselbe Steuerung. Vereinbaren Sie verfügbare Testumgebungen, Änderungsankündigungen, Meldewege und Zuständigkeiten für Korrekturen. Fordern Sie konkrete Prüfbelege für relevante Nutzungspfade statt ausschließlich allgemeiner Aussagen zur Barrierefreiheit. Wenn ein eingebettetes Terminwerkzeug unangekündigt aktualisiert wird, muss Ihr Monitoring auch diesen Übergang erfassen. Dokumentieren Sie bei ungelösten Problemen Eskalation, eine gegebenenfalls geprüfte Alternative und die nächste Entscheidung. Die technische Abhängigkeit erklärt ein Problem, beseitigt aber nicht dessen Wirkung für Nutzer:innen.

11. Nutzer:innen-Feedback bis zum Retest verfolgen

Bieten Sie einen gut auffindbaren, zugänglichen Meldeweg an. Fragen Sie nach betroffener Aufgabe, Seite, beobachtetem Verhalten und optional nach Browser oder Hilfsmittel. Verlangen Sie keine Diagnose oder Angaben zu einer Behinderung, um einen Fehler zu bearbeiten. Bestätigen Sie den Eingang und erläutern Sie das weitere Vorgehen. Kann Ihr Team ein Problem zunächst nicht reproduzieren, bleibt die Meldung trotzdem relevant: Einstellungen, Inhalte, Gerätekombinationen oder ein wechselnder Dienst können den Unterschied erklären.

Schließen Sie Tickets erst nach einem Retest im korrigierten Build. Wiederholen Sie die ursprünglichen Schritte und prüfen Sie angrenzende Zustände: Eine reparierte Fehlermeldung darf beispielsweise keine doppelte Screenreader-Ausgabe erzeugen. Dokumentieren Sie Version, Umgebung, Ergebnis und prüfende Person. Fügen Sie bei wiederkehrenden Problemen einen geeigneten Regressionstest hinzu oder ändern Sie die redaktionelle Regel. Bei komplexen Befunden ist eine zweite prüfende Person sinnvoll. Melden Sie betroffenen Nutzer:innen die Korrektur zurück, ohne ihnen die Verantwortung für die technische Abnahme zu übertragen.

12. Wartungsrhythmus und Wirksamkeit regelmäßig überprüfen

Kombinieren Sie anlassbezogene Tests mit geplanten Kontrollen. Relevante Releases lösen die vereinbarten Prüfungen aus; größere Umbauten benötigen eine breitere Neubewertung. Ergänzend kann Ihr Team in einem festgelegten Rhythmus Stichproben über länger unveränderte Bereiche und externe Dienste ziehen. Das ist eine organisatorische Empfehlung, keine universelle monatliche oder jährliche Auditpflicht der WCAG. Die W3C WAI-Empfehlungen zur dauerhaften Sicherung von Barrierefreiheit verbinden laufende Beobachtung mit Veröffentlichungskontrollen, Ursachenanalyse und Schulung.

Bewerten Sie nicht nur offene Ticketzahlen. Fragen Sie, welche kritischen Nutzungspfade nachweislich geprüft wurden, welche Fehler wiederkehren und wo Zuständigkeiten unklar bleiben. Überarbeiten Sie daraus Testfälle, Komponenten und Arbeitsanweisungen. Eine wachsende Zahl gefundener Probleme kann zunächst bessere Abdeckung bedeuten; eine leere Fehlerliste kann dagegen ungeprüfte Bereiche verbergen. Entscheidend ist eine nachvollziehbare Verbindung zwischen Änderung, Prüfung, Entscheidung und Korrektur. So bleibt das Programm auch bei Teamwechseln handlungsfähig.

Häufige Fragen

Muss nach jedem Textupdate ein vollständiger Audit erfolgen?

Nein. Prüfen Sie die betroffenen Inhalte und Vorlagen risikobasiert. Ändert sich gemeinsames Verhalten oder eine zentrale Aufgabe, erweitern Sie den Umfang entsprechend.

Reicht ein automatisierter Scan vor dem Release?

Nein. Automatisierte Werkzeuge decken nur einen Teil der Anforderungen ab. Manuelle Prüfungen müssen insbesondere Bedienbarkeit, Fokusführung und verständliche Rückmeldungen ergänzen.

Wer darf die Freigabe erteilen?

Eine ausdrücklich benannte Release-Verantwortung sollte anhand vereinbarter Nachweise entscheiden. Fachliche Prüfungen bleiben bei den zuständigen Rollen; ungelöste Risiken werden dokumentiert.

Wann ist ein Fehler wirklich abgeschlossen?

Wenn die Korrektur im relevanten Build nachgeprüft, das Ergebnis dokumentiert und eine angemessene Prüfung angrenzender Zustände durchgeführt wurde.

Nächster Schritt: Ihr Wartungsprogramm konkretisieren

Zensations ist ein 2010 in Wien gegründetes Digitalstudio. Wenn Ihnen eine belastbare Ausgangslage fehlt, kann ein Barrierefreiheit-Audit helfen, Prüfbereiche und Prioritäten zu bestimmen. Für die Weiterentwicklung Ihres Prozesses besprechen wir im Rahmen unserer Accessibility-Leistungen passende Zuständigkeiten, Release-Gates und Retests. Bringen Sie dafür Ihren Release-Ablauf, zentrale Nutzungspfade und bekannte Befunde mit. Ziel ist ein überprüfbares Vorgehen, keine pauschale Konformitätsgarantie.

Quellen

Inhaltlich geprüft: 7. November 2026.