STATUS IS UPWEBSITE‑OPTIMIERUNGS‑WIKI
14Befähigen
Design und UX / Befähigen

Checkliste zur Barrierefreiheit von Websites für Eigentümer

Ein praxisorientierter Eigentümer‑Prozess zum Überprüfen wesentlicher Kundenpfade, Beheben von Barrieren und zur Nutzung von WCAG 2.2, ohne einen Scan mit Konformität zu verwechseln.

Checkliste zur Barrierefreiheit von Websites für Eigentümer — VISUELLE ANLEITUNG
LESEN
7 Minuten
QUELLEN
5
ERNEUT PRÜFEN
2027-03-27
geprüft
Fachperson für Barrierefreiheit und Web‑Qualitätsprüfer
DIE KURZE ANTWORT

Mit der Entscheidung beginnen.

Verwenden Sie diese Checkliste zur Website‑Barrierefreiheit für die Kundenerlebnisse, die am meisten zählen: Informationen finden, Kontakt aufnehmen, Anmelden, Buchen, Kaufen und Hilfe erhalten. Legen Sie ein WCAG‑2.2‑Ziel fest, wählen Sie repräsentative Vorlagen und Zustände in diesen Pfaden und testen Sie dann mit Tastatur, Zoom, Inhaltsprüfung und einem automatischen Checker. Wandeln Sie jeden Befund in eine konkrete Aufgabe mit einem Verantwortlichen um und testen Sie nach der Freigabe erneut.

Ein sauberer Scan oder eine kurze Seitenprüfung ist kein Beweis für Barrierefreiheit oder Konformität. W3C sagt, kein Tool allein könne bestimmen, ob eine Seite die Zugänglichkeitsstandards erfüllt, und seine Schnellprüfungen sind nicht erschöpfend. SIU kann proaktive Pre‑Launch‑Prüfung und Behebung unterstützen; es ist keine WCAG‑Zertifizierung, keine rechtliche Stellungnahme und keine Garantie, dass jede Besucherin/jeder Besucher jeden Drittanbieterdienst nutzen kann.

VISUELLE ANLEITUNG

Verstehen Sie die Arbeit als zusammenhängendes System.

Nutzen Sie diese Karte, um die Entscheidungen des Artikels zu verbinden, bevor Sie einzelne Taktiken umsetzen.

SIUBefähigen
011. Überprüfungsumfang festlegen
022. Den Tastaturpfad testen
033. Struktur und klare Bedeutung überprüfen
044. Text, Layout, Farben und Medien belasten
01

1. Überprüfungsumfang festlegen

Beginnen Sie mit vollständigen Ergebnissen, nicht mit zufälligen URLs. Kartieren Sie die Startseite, wichtige Inhalte, Suche, Kontakt, Konto, Buchung oder Checkout, Bestätigung, Hilfe und jeden eingebetteten Dienst, der auf dem Weg verwendet wird. Schließen Sie wiederverwendbare Navigation, modale Dialoge, Cookie‑Steuerungen und Formulare ein, denn ein einzelner Fehler kann sich site‑weit wiederholen.

Ziel festlegen

Dokumentieren Sie WCAG‑Version und Level, Abdeckung, unterstützte Browser und Geräte sowie bekannte Ausnahmen.

Behandeln Sie Journeys als vollständig

Überprüfen Sie jeden Schritt und Zustand, einschließlich angemeldet, leer und Fehleransichten.

02

2. Den Tastaturpfad testen

Schließen Sie jede ausgewählte Aufgabe ohne Zeigegerät ab. Verwenden Sie Tab und Shift+Tab durch Links, Bedienelemente, Dialoge, Menüs, Filter, Datumswähler, Medien und Widgets von Anbietern. Der Fokus muss sichtbar sein, einer sinnvollen Reihenfolge folgen, darf niemals gefangen werden und muss nach dem Schließen eines Dialogs an eine nützliche Stelle zurückkehren. Tastaturbedienung ist zentral für WCAG; gehen Sie nicht davon aus, dass eine eigene Maussteuerung automatisch per Tastatur funktioniert.

Wiederholungen überspringen

Stellen und testen Sie eine Möglichkeit bereit, den Hauptinhalt zu erreichen, ohne mit der Tab‑Taste durch wiederholte Navigation zu müssen.

Drag‑Interaktionen prüfen

Wenn eine Oberfläche Ziehen erfordert, überprüfen Sie, ob eine geeignete nicht‑ziehen‑Alternative verfügbar ist.

03

3. Struktur und klare Bedeutung überprüfen

Geben Sie Seiten beschreibende Titel und verwenden Sie Überschriften für Hierarchie, nicht nur für Aussehen. Prüfen Sie, dass Bedienelemente eine nützliche Bezeichnung, Rolle und Zustand für unterstützende Technologien bereitstellen; native HTML‑Controls verringern oft das Risiko. Bedeutungsvolle Bilder benötigen prägnanten Alternativtext entsprechend ihrem Zweck, dekorative Bilder sollten keine zusätzlichen Geräusche verursachen. Verwenden Sie Farbe nicht allein zur Kennzeichnung von Status oder Anweisungen und legen Sie die Seitensprache fest.

Linkzweck prüfen

Machen Sie Ziele oder Aktionen im Kontext verständlich; mehrfach verwendete vage Links erzeugen Mehrdeutigkeit.

Quellreihenfolge kontrollieren

Wenn Layouts sich ändern oder Styles fehlen, sollten Inhalte und Bedienelemente weiterhin logisch gelesen werden können.

04

4. Text, Layout, Farben und Medien belasten

Erhöhen Sie Browser‑Zoom und Textgröße und wiederholen Sie zentrale Aufgaben. Inhalte sollten lesbar und nutzbar bleiben und nicht kollidieren, verschwinden oder zu einem unerwünschten horizontalen Suchen führen. Prüfen Sie die tatsächlichen Farbkombinationen für Text, Bedienelemente, Fokus, Fehler und Diagramme in relevanten Zuständen. Für aufgezeichnete Medien stellen Sie Untertitel für notwendige Audio‑Informationen bereit und geeignete Textalternativen je nach Inhalt.

Mehr als die Standardansicht testen

Beziehen Sie Hover, Fokus, deaktivierte, Fehler‑ und jede dunkle oder alternative visuelle Darstellung mit ein.

Mediensteuerungen prüfen

Testen Sie den Player per Tastatur sowie Untertitel, Transkripte und essentielle visuelle Informationen.

05

5. Formulare und Kontoaufgaben wiederherstellbar machen

Senden Sie fehlende, falsch formatierte und gültige Daten über Ihre wichtigsten Formulare. Eingaben benötigen dauerhaft zugeordnete, programmatisch verknüpfte Labels; Platzhalter allein sind kein verlässlicher Ersatz. Kennzeichnen Sie Pflichtfelder vor dem Absenden, erklären Sie Fehler in klarer Sprache, weisen Sie auf das betroffene Feld hin und erhalten Sie eingegebene Daten nach Möglichkeit. Testen Sie Anmeldung, Passwort‑Reset, Einmalcodes, Checkout und Bestätigung als vollständige Journeys.

Fehler nicht nur per Farbe kennzeichnen

Kombinieren Sie Fehlerfarbe mit einer Klartextmeldung und einem erkennbaren betroffenen Feld.

Anbietergrenzen testen

Testen Sie per Tastatur die Übergabe, Weiterleitung, Fehlerwege und Rückkehr von Zahlungs‑ oder Identitätsanbietern.

06

6. Werkzeuge mit Personen‑ und manueller Prüfung kombinieren

Führen Sie einen automatisierten Checker auf repräsentativen Seiten aus und nutzen Sie dessen Ergebnisse als Hinweise, nicht als Freifahrtschein. Tools können nicht beurteilen, ob Alternativtext sinnvoll ist, eine Reihenfolge logisch bleibt, Anweisungen verständlich sind oder eine Journey mit unterstützender Technologie funktioniert. Ergänzen Sie mit manuellen Tastatur‑ und Zoom‑Prüfungen sowie einer gezielten Screenreader‑Überprüfung. Beziehen Sie, wenn möglich, frühzeitig Personen mit relevanter eigener Erfahrung ein und vergüten Sie sie fair.

Belege zusammenhalten

Speichern Sie Tool‑Ausgaben, Prüfernotizen, Entscheidungen, Behebungen und Retest‑Ergebnisse in einem Issue‑Datensatz.

Verhältnismäßig eskalieren

Ziehen Sie einen qualifizierten Gutachter für formelle Aussagen, regulierte Dienste, komplexe Anwendungen oder strittige Befunde hinzu.

07

7. Behebung in Releases einbauen

Barrierefreiheit kann nach Theme‑, Kampagnen‑, Plugin‑, Script‑, Design‑Token‑ oder Anbieteränderungen wieder zurückgehen. Fügen Sie eine verhältnismäßige Prüfung in Design, Inhalt, Qualitätssicherung und Launch‑Arbeiten ein. SIU konzentriert sich auf proaktive Uptime‑Optimierung und Behebung: Pflegen Sie einen Pre‑Launch‑Pfad, identifizieren Sie kundenrelevante Defekte, führen Sie sichere Fixes durch und haben Sie einen Rollback‑Plan. Die Barrierefreiheitsprüfung ergänzt diese Arbeit; sie wird nicht durch Verfügbarkeitsprüfungen oder Ausfallalarme ersetzt.

Blocker setzen

Blockieren Sie ein Release, wenn eine primäre Aufgabe nicht per Tastatur abgeschlossen werden kann oder ein kritischer Fehler nicht verständlich ist.

Im Kontext retesten

Prüfen Sie die ursprüngliche Aufgabe, Mobil‑ und Fehlerzustände nach einer Korrektur, bevor Sie das Issue schließen.

AKTION / ÜBERPRÜFEN

Ihr praktischer To‑Do‑Leitfaden.

  1. 01

    Ziel festlegen

    Dokumentieren Sie WCAG‑Version und Level, Umfang, Verantwortliche und wann eine Spezialistenprüfung nötig ist.

    ÜBERPRÜFEN: Eine einseitige Scope‑Übersicht benennt Schlüssel‑Journeys, Abdeckung, Ausnahmen und Entscheidungsträger.
  2. 02

    Journeys kartieren

    Listen Sie Start‑bis‑Ende‑Routen für Informationen, Kontakt, Konto, Kauf oder Buchung, Zahlung, Bestätigung und Support auf.

    ÜBERPRÜFEN: Jede kritische Aufgabe hat repräsentative Seiten und Zustände ausgewählt.
  3. 03

    Einen Basisscan durchführen

    Verwenden Sie einen automatisierten Checker und weisen oder dokumentieren Sie dann jeden Befund zu.

    ÜBERPRÜFEN: Berichte liegen im Issue‑Log; kein Scan wird als Zertifikat aufgezeichnet.
  4. 04

    Nur mit Tastatur verwenden

    Navigieren Sie Menüs, Dialoge, Formulare, Widgets, Fehler und Bestätigungen ohne Zeigegerät.

    ÜBERPRÜFEN: Fokus ist sichtbar, Reihenfolge logisch und keine erforderliche Aktion fängt die Nutzerin/den Nutzer ein.
  5. 05

    Bedeutung prüfen

    Überprüfen Sie Titel, Überschriften, Labels, Links, Bild‑Alternativen, Sprache und Nicht‑Farbhinweise.

    ÜBERPRÜFEN: Bedienelemente und Inhalte bleiben über ihre visuelle Darstellung hinaus verständlich.
  6. 06

    Anzeige anpassen

    Testen Sie Zoom, Textgröße, Kontrast, Fokus‑ und Fehlerzustände sowie Medienalternativen.

    ÜBERPRÜFEN: Kernaufgaben bleiben unter den getesteten Anpassungen lesbar und nutzbar.
  7. 07

    Wiederherstellung üben

    Senden Sie ungültige und gültige Formularinhalte; testen Sie Anmeldung, Zurücksetzen, Authentifizierung und irreversible Aktionen.

    ÜBERPRÜFEN: Fehler weisen einen Korrekturpfad, ohne vermeidbaren Verlust eingegebener Daten.
  8. 08

    Anbieter prüfen

    Folgen Sie eingebetteten oder weitergeleiteten Zahlungs‑ und Identitätserfahrungen wie eine Kundin/ein Kunde.

    ÜBERPRÜFEN: Offene Anbieterbarrieren haben Belege, einen Verantwortlichen und einen Eskalationspfad.
  9. 09

    Beheben und retesten

    Priorisieren Sie Blocker in wesentlichen Aufgaben, beheben Sie sie und retesten Sie im ursprünglichen Kontext.

    ÜBERPRÜFEN: Geschlossene Issues enthalten ein Retest‑Ergebnis; offene Einträge haben einen Verantwortlichen und ein Ziel‑Datum.
  10. 10

    Wiederholbarkeit sicherstellen

    Nehmen Sie die relevanten Prüfungen in Veröffentlichungs‑, QA‑ und Freigabeprozesse auf.

    ÜBERPRÜFEN: Der Release‑Eintrag benennt die durchgeführte Prüfung und die Änderungen.
DISKUSSIONSTHEMEN

Vergleichen Sie Kompromisse, nicht private Daten.

Nutzen Sie diese Fragen mit Ihrem Team oder der Website‑Betreiber‑Community. Teilen Sie Methoden und Erkenntnisse, aber fügen Sie niemals Zugangsdaten, Kundendaten oder nicht‑öffentliche Infrastrukturdaten ein.

  1. 01

    Welches Kunden‑Journey wäre für Tastaturbenutzer*innen am schädlichsten zu verlieren, und wer besitzt die nächste Überprüfung dafür?

  2. 02

    Welche Belege helfen Ihrem Team, einen nützlichen automatischen Befund von einer Aussage zu trennen, die eine manuelle oder Spezialistenprüfung erfordert?

  3. 03

    Wie können Design‑, Content‑, Engineering‑ und Anbieter‑Teams Barrieren teilen, ohne Kunden‑ oder sicherheitsrelevante Daten offenzulegen?

BELIEBTE / MASSGEBLICHE RESSOURCEN

Öffnen Sie das Quellmaterial.

World Wide Web Consortium (W3C)Web Content Accessibility Guidelines (WCAG) 2.2 ↗

Die normative Norm für Prinzipien, Erfolgskriterien, Ebenen und Umfang der Konformität.

Geprüft 2026-09-27
W3C Web Accessibility InitiativeEasy Checks – A First Review of Web Accessibility ↗

Ein praktischer Einstieg für Basisprüfungen und deren erklärte Grenzen.

Geprüft 2026-09-27
W3C Web Accessibility InitiativeEvaluating Web Accessibility Overview ↗

Erläutert, warum Tools menschliche, fachkundige Bewertung benötigen und verweist auf Evaluationsressourcen.

Geprüft 2026-09-27
W3C Web Accessibility InitiativeHow to Meet WCAG (Quick Reference) ↗

Filtert WCAG‑2.2‑Kriterien und Leitfäden nach Level, Technologie, Rolle und Thema.

Geprüft 2026-09-27
MDN Web DocsAccessibility tooling and assistive technology ↗

Praktischer Hintergrund zu Tools, Accessibility‑Trees, Screenreadern und Nutzertests.

Geprüft 2026-09-27

Quellenrichtlinie. Quellen wurden vor dem Verfassen gelesen. Dieser Artikel bevorzugt W3C/WAI‑Standards und Evaluationsleitfäden sowie MDN‑Implementationshinweise. SIU‑Links dienen der Navigation, nicht als Beleg. Formelle Aussagen zu Konformität, Recht, Sicherheit, Zahlung und vertraglichen Entscheidungen erfordern qualifizierte Prüfung.

KURZE KLARSTELLUNGEN

Häufige Fragen.

Reicht ein automatisierter Barrierefreiheits‑Scan aus, um zu sagen, eine Website sei zugänglich?

Nein. Er findet einige wiederholbare Probleme, kann aber viele kontextabhängige Barrieren nicht bestimmen. Kombinieren Sie Tools mit manuellen Tests und, wenn das Risiko es erfordert, mit qualifizierter Bewertung und informiertem Nutzerfeedback.

Sollte ein Eigentümer WCAG 2.2 AA als Ziel anstreben?

AA umfasst die Ebenen A und AA und ist ein nützliches Entscheidungsrahmenwerk, aber das Ziel hängt von anwendbaren Anforderungen, Verträgen, Zielgruppe und Service‑Risiko ab. Eine Teilprüfung rechtfertigt keine Konformitätsaussage; holen Sie qualifizierte Accessibility‑ und gegebenenfalls rechtliche Beratung ein, wenn eine solche Aussage nötig ist.

Wer ist verantwortlich, wenn ein eingebettetes Tool eines Anbieters unzugänglich ist?

Der Anbieter kontrolliert möglicherweise den Code, aber die Kundin/der Kunde erlebt die kombinierte Journey. Testen Sie die Übergabe, dokumentieren Sie Barrieren, fordern Sie Behebung an und erwägen Sie Alternativen oder Minderungsmaßnahmen. Anbieterdokumentation allein beweist nicht, dass die reale Journey nutzbar ist.

Status Is UP Editorial Team · Uptime Enablement Redaktion

Geprüft von Fachperson für Barrierefreiheit und Web‑Qualitätsprüfer. Veröffentlicht 2026-09-27; aktualisiert 2026-09-30.