Barrierefreiheit im Website-Relaunch: Anforderungen und Abnahme planen

Planen Sie Barrierefreiheit im Website-Relaunch als verbindlichen Qualitätsstrang: mit einem definierten Geltungsbereich, überprüfbaren Anforderungen, verantwortlichen Personen und Abnahmen während des Projekts. Ein technischer Test kurz vor dem Start kann Probleme sichtbar machen, ersetzt aber keine zugängliche Konzeption, Beschaffung und Umsetzung. Entscheidend ist, dass Nutzer:innen vollständige Aufgaben erledigen können, nicht nur, dass einzelne Seiten einen automatisierten Test bestehen.

Für individuell entwickelte Corporate Websites bedeutet das: Prüfen Sie früh die wichtigsten Nutzungspfade, übersetzen Sie Anforderungen in Komponenten und CMS-Regeln und vereinbaren Sie die erforderlichen Nachweise vor der Beauftragung. Dieser Fahrplan zeigt, wie Sie dafür sinnvolle Entscheidungspunkte setzen. Sämtliche nachfolgenden Projektbeispiele und Fehlerszenarien sind hypothetisch; sie beschreiben keine Ergebnisse konkreter Kund:innenprojekte.

Inhaltlich geprüft am 7. November 2026.

1. Projektziel und Geltungsbereich verbindlich festlegen

Beginnen Sie mit einer Scope-Entscheidung, die mehr umfasst als die Hauptdomain. Welche Sprachversionen, Subdomains, Formulare, Downloads und eingebundenen Dienste gehören zum Relaunch? Werden Bewerbungen extern abgewickelt? Bleibt ein bestehendes Kund:innenportal unverändert? Dokumentieren Sie auch Übergänge zu Systemen außerhalb des Lieferumfangs. Ein ausgeschlossener Dienst verschwindet dadurch nicht aus dem Nutzungspfad; sein Risiko braucht weiterhin eine verantwortliche Stelle.

Als technisches Projektziel lässt sich beispielsweise WCAG 2.2 auf Konformitätsstufe AA einschließlich aller anwendbaren A- und AA-Erfolgskriterien vereinbaren. Die WCAG 2.2 des W3C bilden dafür die normative Grundlage. EN 301 549 ist damit nicht austauschbar, und eine technische Prüfung belegt nicht die vollständige rechtliche Compliance. Das österreichische BaFG gilt seit 28. Juni 2025 für erfasste Dienstleistungen, nicht automatisch für jede Website. Die Einordnung von Anwendungsbereich und Ausnahmen finden Sie im Leitfaden zur barrierefreien Website in Österreich; sie sollte vor der technischen Leistungsbeschreibung geklärt werden.

2. Discovery an vollständigen Nutzungspfaden ausrichten

Eine Inventarliste von Seitentypen ist hilfreich, reicht aber nicht. Beschreiben Sie zusätzlich Aufgaben mit Einstieg, Entscheidung, Interaktion und Abschluss. Ein hypothetischer Pfad könnte lauten: Eine Interessentin findet eine Leistung über die Suche, vergleicht Angebote, öffnet ein Anfrageformular und erhält eine verständliche Bestätigung. Ein anderer führt von einer Stellenausschreibung in ein externes Bewerbungsportal. Beide Pfade können dieselbe Navigation nutzen, aber völlig unterschiedliche Risiken enthalten.

Halten Sie pro Pfad fest, welche Informationen benötigt werden, welche Komponenten beteiligt sind und woran der erfolgreiche Abschluss erkennbar ist. Berücksichtigen Sie Tastaturbedienung, Screenreader, Vergrößerung und mobile Darstellung. Interviews oder moderierte Tests mit Menschen mit Behinderungen können Nutzungshürden aufdecken, ersetzen jedoch keine systematische Kriterienprüfung. Das Ergebnis der Discovery ist eine priorisierte Prüflandkarte: Welche Aufgaben sind geschäftskritisch, welche technischen Muster wiederholen sich, und welche Abhängigkeiten müssen vor dem Design geklärt werden?

3. Anforderungen in überprüfbare Arbeitspakete übersetzen

Die Vorgabe „barrierefrei umsetzen“ ist weder für die Entwicklung noch für eine Abnahme ausreichend. Jede relevante Anforderung braucht einen Gegenstand, ein erwartetes Verhalten, eine Prüfmethode und eine zuständige Rolle. Verknüpfen Sie diese Angaben mit dem Nutzungspfad und dem betroffenen Erfolgskriterium. So wird aus einer allgemeinen Absicht ein Arbeitspaket, das im Backlog geschätzt, umgesetzt und geprüft werden kann.

Für ein hypothetisches Anfrageformular könnte die Anforderung lauten: Alle Eingaben haben programmatisch zugeordnete Beschriftungen; Pflichtangaben werden vor dem Absenden erklärt; fehlerhafte Werte lassen sich ohne erneute Eingabe bereits korrekter Daten verbessern. Die Abnahme umfasst dann nicht nur einen Screenshot, sondern auch Bedienung mit Tastatur und Prüfung der ausgegebenen Beschriftungen und Meldungen. Trennen Sie verpflichtende Kriterien von zusätzlichen Qualitätszielen. Eine vollständig sichtbare Fokusmarkierung ist beispielsweise ein sinnvoller Anspruch; WCAG 2.2 AA verlangt bei „Focus Not Obscured“ konkret, dass fokussierte Komponenten nicht vollständig durch autorenerstellte Inhalte verdeckt sind.

4. Zuständigkeiten und Beschaffung vorab klären

Benennen Sie eine Person, die den Barrierefreiheitsstrang im Projekt koordiniert, ohne ihr sämtliche Fachaufgaben zu übertragen. Design verantwortet unter anderem Zustände und visuelle Spezifikationen, Entwicklung das technische Verhalten, Redaktion die Inhalte und Projektleitung die Entscheidungspunkte. Die fachliche Prüfung benötigt Zugang zu Zwischenständen und ausreichend Zeit für Rückmeldungen. Wer einen Fehler behebt, sollte nicht allein über dessen abschließende Akzeptanz entscheiden.

Verankern Sie bei der Beschaffung konkrete Nachweise, Testzugänge, Korrekturschleifen und Übergabeunterlagen im Leistungsumfang. Fragen Sie Anbieter:innen nicht nur nach einer allgemeinen Erklärung zur Barrierefreiheit, sondern nach überprüfbaren Informationen zur vorgesehenen Produktversion und Integration. Bei einem Buchungsdienst wäre beispielsweise relevant, ob Kalender, Zeitauswahl, Fehlermeldungen und Bestätigung geprüft werden können. Vereinbaren Sie außerdem, wer mit dem Hersteller kommuniziert und welche Alternative vorgesehen ist, wenn eine wesentliche Barriere nicht rechtzeitig behoben wird.

5. Designsystem und Komponenten vor Seitenausbau prüfen

Prüfen Sie wiederverwendete Muster, bevor sie in zahlreiche Vorlagen einfließen. Navigation, Akkordeons, Dialoge, Karten, Formularfelder und Hinweismeldungen benötigen mehr als einen Standardzustand. Spezifizieren Sie Fokus, Fehler, ausgewählte Optionen, deaktivierte Funktionen und lange Inhalte. Textkontrast beträgt für normalen Text mindestens 4,5:1, für großen Text mindestens 3:1; groß bedeutet hier mindestens 18 Punkt beziehungsweise 14 Punkt bei fetter Schrift. Für relevante grafische Informationen und Komponentenbegrenzungen gelten, soweit das Kriterium anwendbar ist, andere Kontrastanforderungen.

Ein hypothetischer Filterdialog zeigt, warum frühe Interaktionsprototypen wichtig sind: Er sieht korrekt aus, lässt den Tastaturfokus aber hinter das Dialogfenster wandern. Die Korrektur betrifft das Verhalten, nicht nur die Darstellung. Nach dem Dialogmuster der WAI-ARIA Authoring Practices sind unter anderem geeigneter Anfangsfokus, Fokusführung innerhalb des modalen Dialogs, Schließen mit Escape und sinnvolle Fokusrückgabe zu berücksichtigen. ARIA-Attribute allein implementieren diese Funktionen nicht. Als Nachweis dient ein reproduzierbarer Interaktionstest am tatsächlich eingesetzten Baustein.

6. CMS-Vorlagen und redaktionelle Freiheiten gemeinsam entwickeln

Ein zugänglicher Prototyp schützt nicht vor problematischen CMS-Inhalten. Legen Sie fest, welche Überschriftenebenen, Linkvarianten, Bildfelder und Inhaltskombinationen Redakteur:innen verwenden dürfen. Gute Vorlagen ermöglichen semantisch sinnvolle Strukturen, ohne dass jede Person HTML verstehen muss. Verhindern Sie beispielsweise, dass die optische Größe einer Überschrift automatisch eine unpassende Hierarchie erzeugt. Hilfetexte im CMS sollten Entscheidungen erklären statt nur Pflichtfelder markieren.

Testen Sie jede Vorlage mit realistischen Grenzfällen: langen Überschriften, fehlenden Bildern, mehreren Links, Übersetzungen und umfangreichen Tabellen. Prüfen Sie Textvergrößerung auf 200 Prozent, Umbruch bei 320 CSS-Pixeln mit den vorgesehenen Ausnahmen sowie die vorgeschriebenen Textabstandsänderungen ohne Informations- oder Funktionsverlust. Diese Abstandsprüfung schreibt nicht die Standardgestaltung vor. Abnahmefähig ist eine Vorlage erst, wenn auch zulässige Inhaltsvarianten funktionieren. Dokumentieren Sie deshalb nicht nur den Idealzustand, sondern auch Grenzen und redaktionelle Regeln.

7. Drittanbieter als Teil der Nutzer:innenreise behandeln

Consent-Management, Videos, Karten, Chat und Bewerbungsplattformen können einen ansonsten gut umgesetzten Relaunch blockieren. Erstellen Sie ein Register mit Produkt, Version, Einbindungsart, zuständiger Stelle und betroffenen Nutzungspfaden. Prüfen Sie die konkrete Integration: Eine zugängliche Anbieter-Demo belegt nicht, dass Ihre Konfiguration, Ihr Theme oder die Verbindung mit anderen Skripten ebenso funktioniert. Beziehen Sie auch Zustände vor und nach einer Einwilligung ein.

Angenommen, ein hypothetisches Consent-Fenster verdeckt den fokussierten Absenden-Button vollständig. Dann muss der Fehler im Zusammenspiel geprüft und korrigiert werden, etwa durch angepasste Positionierung oder ein anderes Verhalten des Fensters. Ein allgemeiner Hinweis auf den Fremdanbieter genügt nicht als technische Abnahme. Wenn eine zugängliche Alternative erforderlich ist, sollte sie dieselbe Aufgabe möglichst gleichwertig ermöglichen. Eine Telefonnummer allein ist nicht automatisch ein angemessener Ersatz für einen digitalen Vorgang, der jederzeit und ohne mündliche Kommunikation nutzbar sein sollte.

8. Inhalte, Formulare und Dokumente früh migrieren

Planen Sie Inhaltsmigration als Qualitätsarbeit, nicht als bloßen Import. Priorisieren Sie nach Nutzung und Bedeutung: Leistungsinformationen, Kontaktmöglichkeiten, zentrale Downloads und häufig verwendete Formulare zuerst. Überprüfen Sie Linkzwecke, Alternativtexte, Tabellenüberschriften und Sprachwechsel. Dekorative Bilder benötigen keinen beschreibenden Alternativtext; funktionale Bilder müssen ihren Zweck vermitteln. Eine pauschale Zeichenbegrenzung für sämtliche Alternativtexte ist kein brauchbares Qualitätskriterium.

Für Formulare liefern die WAI Forms Tutorials konkrete Orientierung zu Beschriftungen, Gruppierung und Rückmeldungen. In einem hypothetischen Fehlerfall wird eine ungültige E-Mail-Adresse nur rot umrandet und beim Absenden das gesamte Formular geleert. Die Korrektur ergänzt eine verständliche, zugeordnete Fehlermeldung und erhält korrekte Eingaben. Für migrierte PDFs prüfen Sie zusätzlich Lesereihenfolge, Struktur und gegebenenfalls Tabellenbeziehungen. OCR kann Text erschließen, stellt aber keine vollständige Dokumentstruktur her. Ordnen Sie jedem kritischen Dokument eine Entscheidung zu: überarbeiten, durch zugängliches HTML ersetzen oder begründet aus dem neuen Angebot entfernen.

9. Definition of Done auf mehreren Ebenen vereinbaren

Eine gemeinsame Definition of Done verhindert, dass „fertig entwickelt“ mit „abgenommen“ verwechselt wird. Auf Komponentenebene gehören implementierte Zustände, dokumentierte Bedienung und bestandene Prüfschritte dazu. Auf Vorlagenebene kommen Inhaltsvarianten und responsive Darstellung hinzu. Auf Ebene des Nutzungspfads muss die gesamte Aufgabe einschließlich externer Übergänge und Rückmeldungen funktionieren. Diese Ebenen benötigen unterschiedliche Nachweise, sollten aber in einem gemeinsamen Statusmodell zusammenlaufen.

Definieren Sie vorab, welche offenen Befunde einen Entscheidungspunkt blockieren und wer über verbleibende Risiken entscheidet. Ein nicht erreichbarer Formularabschluss wiegt anders als eine kleinere redaktionelle Unklarheit; die Einstufung muss nachvollziehbar sein. Eine interne Freigabe trotz bekannter Abweichung macht diese nicht konform. Halten Sie Ausnahmen, Auswirkungen, Verantwortliche und Korrekturtermine ausdrücklich fest. Vermeiden Sie dabei pauschale Zusagen wie „WCAG bestanden“, wenn tatsächlich nur ausgewählte Komponenten oder Seiten geprüft wurden.

10. Abnahme mit reproduzierbaren Nachweisen durchführen

Vereinbaren Sie die Prüfumgebung, bevor die Abnahme beginnt: Build-Version, Browser, assistive Technologien, Bildschirmgrößen, Testdaten und Zugänge. Wählen Sie repräsentative Vorlagen und ergänzen Sie diese um alle einzigartigen Interaktionsmuster sowie kritische Nutzungspfade. Ein Stichprobenbericht muss erkennen lassen, was untersucht wurde und was nicht. Er darf nicht den Eindruck einer vollständigen Prüfung aller Inhalte erzeugen, wenn diese nicht stattgefunden hat.

Automatisierte Prüfungen unterstützen die Suche nach wiederkehrenden technischen Fehlern. Wie das W3C bei der Auswahl von Prüfwerkzeugen erläutert, können Werkzeuge jedoch nicht sämtliche Aspekte der Barrierefreiheit bewerten. Ergänzen Sie manuelle Tastatur-, Screenreader-, Vergrößerungs- und Inhaltsprüfungen. Ein belastbarer Befund enthält Fundstelle, Voraussetzungen, Schritte, tatsächliches und erwartetes Verhalten, betroffene Anforderung und Beleg. Damit kann die Entwicklung den Fehler reproduzieren, statt zunächst erraten zu müssen, welche Situation gemeint war.

11. Korrekturen, Retests und Veröffentlichung trennen

Reservieren Sie im Terminplan ausdrücklich Zeit für Korrektur und erneute Prüfung. Ein geschlossener Entwicklungstask ist noch kein Nachweis einer erfolgreichen Behebung. Beim Retest wird derselbe Fehler unter dokumentierten Bedingungen erneut geprüft; zusätzlich werden benachbarte Funktionen auf unbeabsichtigte Auswirkungen untersucht. Ändert sich eine zentrale Komponente, muss die Regression auch ihre Verwendung in relevanten Vorlagen berücksichtigen.

Ein hypothetischer Fix für die Fokusrückgabe eines Dialogs kann beispielsweise nach dem Filtern auf einen inzwischen entfernten Button verweisen. Der Retest muss deshalb auch den Zustand nach einer Ergebnisänderung abdecken. Führen Sie Befunde mit nachvollziehbaren Statuswerten wie offen, zur Nachprüfung bereit und bestätigt behoben. Vor der Veröffentlichung erhält die verantwortliche Projektleitung eine kompakte Entscheidungsgrundlage: geprüfter Umfang, offene Barrieren, Auswirkungen und nächste Schritte. Die technische Veröffentlichung und die fachliche Abnahme bleiben getrennte Entscheidungen.

12. Übergabe und laufende Qualität absichern

Übergeben Sie nicht nur Dateien, sondern ein nutzbares Betriebsmodell. Dazu gehören Komponentenregeln, CMS-Hilfen, bekannte Einschränkungen, Prüfprotokolle und Zuständigkeiten für neue Inhalte und Änderungen. Schulen Sie Redaktion und Entwicklung anhand der tatsächlichen Website. Eine Übung zum Erstellen einer Leistungsseite mit Bild, Tabelle und Formularverlinkung ist unmittelbar verwertbarer als eine Präsentation ohne Bezug zu den eingesetzten Werkzeugen.

Die WAI-Empfehlungen zur dauerhaften Sicherung von Barrierefreiheit betonen laufende Kontrollen, Schulung und die Behandlung von Fehlerursachen. Legen Sie eine risikobasierte Prüfroutine fest: beispielsweise bei neuen Vorlagen, größeren Drittanbieter-Updates oder veränderten Nutzungspfaden. WCAG schreibt keinen universellen monatlichen oder jährlichen Auditzyklus vor. Wichtig ist eine verbindliche Reaktion auf Änderungen und Rückmeldungen. Ein gut geplanter Relaunch hinterlässt deshalb nicht nur eine Website, sondern auch die Fähigkeit, ihre Qualität weiterzuentwickeln.

Häufige Fragen zur Relaunch-Planung

Wann sollte die erste Prüfung stattfinden?

Bereits bei Nutzungspfaden und Komponentenentwürfen. Frühe Prüfungen vermeiden, dass strukturelle Probleme in sämtliche Vorlagen übernommen werden. Die Prüfung der fertigen Implementierung bleibt trotzdem erforderlich.

Reicht ein automatisierter Scan zur Abnahme?

Nein. Er liefert Teilbefunde, bewertet aber weder alle Kriterien noch zuverlässig die Nutzbarkeit vollständiger Aufgaben. Manuelle Prüfungen und dokumentierte Nachweise gehören dazu.

Wer verantwortet externe Dienste?

Benennen Sie intern eine zuständige Person und vertraglich die Pflichten des Anbieters. Fremdcode darf nicht dazu führen, dass kritische Übergänge ohne Prüfung bleiben.

Wie starten wir mit einem bereits laufenden Relaunch?

Erfassen Sie zuerst Scope, kritische Nutzungspfade und wiederverwendete Komponenten. Ein gezieltes Barrierefreiheits-Audit von Zensations kann Befunde für die nächsten Entscheidungen liefern. Für Anforderungen, Umsetzung und Übergabe unterstützt das 2010 in Wien gegründete Digitalstudio mit seinen Accessibility-Leistungen. Ziel ist ein nachvollziehbarer Verbesserungsprozess, keine pauschale Konformitätsgarantie.

Quellen

• W3C: Web Content Accessibility Guidelines (WCAG) 2.2 – normative Erfolgskriterien und Konformitätsanforderungen.
• W3C WAI: Forms Tutorial – Formulare, Beschriftungen und Rückmeldungen.
• W3C WAI: Dialog (Modal) Pattern – Fokus und Tastaturverhalten modaler Dialoge.
• W3C WAI: Selecting Web Accessibility Evaluation Tools – Einsatz und Grenzen automatisierter Werkzeuge.
• W3C WAI: Sustain Accessibility – Barrierefreiheit im laufenden Betrieb.