Beta

Barrierefreiheit WCAG Checkliste

Verwende diese interaktive Checkliste, um sicherzustellen, dass deine Website die wichtigsten Barrierefreiheitsanforderungen erfüllt.

Diese Checkliste ist ein Hilfsmittel und keine vollständige WCAG-Konformitätsprüfung.

Keine Ergebnisse gefunden

Setze deine Filter zurück oder versuche eine neue Eingabe.

Grafiken

Farben & Kontraste

Text & Sprache

Links und Interaktionen

  • WCAG AA

    WCAG Kriterium: 2.5.7 Ziehbewegungen

    Wenn Nutzer Elemente ziehen müssen (z.B. Dateien hochladen), biete eine Alternative ohne Ziehen an – zum Beispiel einen „Datei auswählen“-Button oder Pfeiltasten zum Sortieren.

    • Bedienbar
    • Design
    • Entwicklung
  • WCAG A

    WCAG Kriterium: 2.5.1 Zeigergesten

    Funktionen, die Wischen, Mehrfinger-Gesten oder andere komplexe Bewegungen benötigen, brauchen eine Alternative – zum Beispiel Buttons zum Vor- und Zurückblättern statt Swipe-Gesten.

    • Bedienbar
    • Entwicklung
  • WCAG A

    WCAG Kriterium: 2.5.3 Label im Namen

    Menschen mit motorischen Einschränkungen nutzen oft Sprachsteuerung mit Befehlen wie „Klicke auf Speichern“. Damit das funktioniert, muss der sichtbare Text (z.B. auf Buttons oder Links) auch im Code als Name hinterlegt sein. Wenn im Code etwas anderes steht als sichtbar ist, erkennt die Sprachsteuerung den Befehl nicht.

    • Bedienbar
    • Entwicklung
    • Redaktion
    Lernartikel über dieses Thema:
  • WCAG A

    WCAG Kriterium: 2.5.2 Zeigeraufhebung

    Wenn jemand aus Versehen auf einen Button drückt, kann er den Finger wegziehen ohne dass etwas passiert. Die Aktion wird erst ausgelöst, wenn man loslässt – nicht schon beim ersten Berühren.

    • Bedienbar
    • Entwicklung
  • WCAG AA

    WCAG Kriterium: 1.4.13 Inhalt bei Hover oder Fokus

    Wenn sich Tooltips oder Infofenster öffnen (beim Drüberfahren mit der Maus), müssen Nutzer sie wieder schließen können. Sie dürfen auch nicht andere wichtige Inhalte verdecken.

    • Bedienbar
    • Entwicklung
  • WCAG AA

    WCAG Kriterium: 2.5.5 Zielgröße

    Alle klickbaren Elemente (Links, Buttons, Eingabefelder) sind mindestens 24x24px groß für präzise Bedienung mit Maus, Touch und anderen Zeigegeräten.

    • Bedienbar
    • Design
    • Entwicklung
    Lernartikel über dieses Thema:
  • WCAG A

    WCAG Kriterium: 2.4.4 Linkzweck (im Kontext)

    Links müssen klar benennen, wohin sie führen oder was passiert. Statt „hier klicken“ also besser: „Mehr über unser Team erfahren“. So können alle Nutzer – auch mit Screenreader – den Link sinnvoll einordnen.

    • Bedienbar
    • Entwicklung
    • Redaktion
    Lernartikel über dieses Thema:

Navigation

  • WCAG AA

    WCAG Kriterium: 3.2.3 Konsistente Navigation

    Die Navigation bleibt auf allen Seiten an der gleichen Stelle – das erleichtert die Orientierung. Auch Breadcrumbs und Suchfelder sollten konsistent platziert sein.

    • Verständlich
    • Design
  • WCAG AA

    WCAG Kriterium: 2.4.5 Mehrere Wege

    Man kann das Kriterium erfüllen, indem man z.B. eine Sitemap oder eine Suchfunktion anbietet.

    • Bedienbar
    • Design
    • Entwicklung
    Lernartikel über dieses Thema:
  • WCAG A

    WCAG Kriterium: 2.4.1 Blöcke umgehen

    Ein „Skip to Content“-Link ermöglicht es Nutzern, direkt zum Hauptinhalt zu springen – ohne sich durch Navigation oder Wiederholungen zu tabben. Das spart Zeit und erleichtert besonders Screenreader- und Tastaturnutzern die Orientierung.

    • Bedienbar
    • Design
    • Entwicklung
    Lernartikel über dieses Thema:

Multimedia & Animationen

  • WCAG A

    WCAG Kriterium: 1.4.2 Audio-Kontrolle

    Wenn Audio automatisch länger als 3 Sekunden abgespielt wird, muss es einen gut sichtbaren Button zum Stoppen oder Stummschalten geben – damit Screenreader-Nutzer nicht gestört werden.

    • wahrnehmbar
    • Entwicklung
  • WCAG A

    WCAG Kriterium: 2.2.1 Timing anpassbar

    Nutzer müssen genug Zeit haben, um Inhalte zu lesen oder Eingaben zu machen – ohne Zeitdruck. Automatische Abläufe (z. B. Sicherheits-Logout-Timer, automatischer Slider-Wechsel) sollten entweder vermieden werden oder sich pausieren bzw. verlängern lassen.

    • Bedienbar
    • Design
    • Entwicklung
  • WCAG A

    WCAG Kriterium: 2.3.1 “2.3.1 Drei-Flashes oder unter Schwelle

    Inhalte dürfen nicht mehr als drei Mal pro Sekunde blinken oder aufblitzen, da sie epileptische Anfälle auslösen können.

    • Bedienbar
    • Design
    • Entwicklung
  • WCAG A

    WCAG Kriterium: 2.2.2 Pause, Stop, Ausblenden

    Videos oder Animationen, die automatisch starten und länger als 5 Sekunden dauern, müssen pausierbar, stoppbar oder ausblendbar sein.

    • Bedienbar
    • Entwicklung
    Lernartikel über dieses Thema:
  • WCAG A

    WCAG Kriterium: 1.2.2 Untertitel (aufgezeichnet)

    Alle gesprochenen Inhalte im Video sollten durch Untertitel ergänzt werden – damit auch Menschen mit Hörbehinderung dem Inhalt folgen können. Die Untertitel sollten gut lesbar und synchron zum Gesprochenen sein.

    • wahrnehmbar
    • Redaktion
    Lernartikel über dieses Thema:
  • WCAG AA

    WCAG Kriterium: 1.2.5 Audiodeskription (vorab aufgezeichnet)

    Wichtige visuelle Informationen im Video (z. B. Gestik, Szenenwechsel, Text-Einblendungen) sollten zusätzlich als Audiodeskription eingesprochen werden. So können auch blinde oder sehbehinderte Menschen den Inhalt vollständig erfassen

    • wahrnehmbar
    • Redaktion
    Lernartikel über dieses Thema:
  • WCAG AA

    WCAG Kriterium: 1.2.4 Untertitel (Live)

    Bei Live-Videos oder Livestreams sollten Echtzeit-Untertitel bereitgestellt werden – etwa durch automatische Systeme oder menschliche Schriftdolmetscher. So können auch gehörlose oder schwerhörige Nutzerinnen folgen.

    • wahrnehmbar
    • Entwicklung
    • Redaktion
    Lernartikel über dieses Thema:
  • WCAG A

    WCAG Kriterium: Audio- und Video-Inhalte (vorab aufgezeichnet)

    Audioinhalte wie Podcasts oder Interviews sollten als vollständiger Text (Transkript) verfügbar sein. Das hilft Menschen mit Hörbehinderung – und ist auch für Suchmaschinen und leises Mitlesen praktisch.

    • wahrnehmbar
    • Redaktion
    Lernartikel über dieses Thema:

Tastatur & Bedienung

  • WCAG A

    WCAG Kriterium: 2.1.4 Tastenkürzel

    Wenn deine Website Tastenkürzel mit einzelnen Zeichen nutzt (z.B. „S“ für Suche), müssen Nutzer diese ausschalten oder anpassen können – sonst kollidieren sie mit Screenreader-Befehlen.

    • Bedienbar
    • Entwicklung
  • WCAG AA

    WCAG Kriterium: 2.4.11 Fokus nicht verdeckt (Minimum)

    Wenn ein Element den Tastaturfokus erhält, darf es nicht durch andere Inhalte (z.B. Sticky Header, Cookie-Banner) verdeckt werden. Mindestens ein Teil des fokussierten Elements muss sichtbar bleiben.

    • Bedienbar
    • Entwicklung
  • WCAG AA

    WCAG Kriterium: 2.4.7 Fokus sichtbar

    Wenn Nutzer mit der Tastatur navigieren, muss immer klar erkennbar sein, welches Element gerade aktiv ist (z. B. durch einen sichtbaren Rahmen). Die Reihenfolge der Fokusstationen sollte der logischen Struktur der Seite folgen.

    • Bedienbar
    • Entwicklung
  • WCAG A

    WCAG Kriterium: 2.1.2 Keine Tastaturfalle

    Alle interaktiven Elemente müssen vollständig mit der Tastatur bedienbar sein – und zwar ohne „Fallen“. Das bedeutet: Man darf nicht irgendwo hängen bleiben, ohne wieder herauszukommen (z. B. in einem Modal oder Dropdown).

    • Bedienbar
    • Entwicklung
  • WCAG A

    WCAG Kriterium: 2.1.1 Tastatur

    Alle interaktiven Elemente können ohne Maus bedient werden.

    • Bedienbar
    • Entwicklung

Formulare

  • WCAG AA

    WCAG Kriterium: 1.3.5 Eingabezweck identifizieren

    Formularfelder für persönliche Daten haben entsprechende autocomplete-Attribute.

    • Verständlich
    • Entwicklung
    Lernartikel über dieses Thema:
  • WCAG A

    WCAG Kriterium: 1.1.1 Nicht-Text-Inhalte

    Wenn ein CAPTCHA verwendet wird (z. B. „Ich bin kein Roboter“), muss es eine barrierefreie Alternative geben – etwa eine einfache Rechenaufgabe oder ein Audio-CAPTCHA für sehbehinderte Menschen.

    • Verständlich
    • Entwicklung
    Lernartikel über dieses Thema:
  • WCAG AA

    WCAG Kriterium: 3.3.4 Fehlervermeidung (rechtlich, finanzielle, Daten)

    Aktionen wie das Löschen eines Kontos oder das Absenden eines Formulars sollten rückgängig gemacht oder bestätigt werden können – zum Beispiel durch eine „Rückgängig“-Funktion oder eine Sicherheitsabfrage.

    • Verständlich
    • Entwicklung
  • WCAG AA

    WCAG Kriterium: 3.3.3 Fehlervorschlag

    Bei Fehlern werden konkrete Korrekturvorschläge gemacht.

    • Verständlich
    • Entwicklung
  • WCAG A

    WCAG Kriterium: 3.3.1 Fehleridentifikation

    Validierungsfehler werden klar identifiziert und beschrieben.

    • Verständlich
    • Design
    • Entwicklung
  • WCAG A

    WCAG Kriterium: 1.3.1 Info und Beziehungen

    Jedes Eingabefeld braucht ein sichtbares Label, das erklärt, was dort eingegeben werden soll – zum Beispiel „E-Mail-Adresse“ oder „Vorname“. So können auch Screenreader-Nutzer das Formular korrekt ausfüllen.

    • Verständlich
    • Entwicklung
    Lernartikel über dieses Thema:

Semantik & Code

  • WCAG A

    WCAG Kriterium: 1.3.1 Info und Beziehungen

    Längere Zitate oder Testimonials, die alleinstehend auf der Seite präsentiert werden, sollten mit <blockquote> ausgezeichnet sein. So erkennen Screenreader die Struktur.

    • wahrnehmbar
    • Entwicklung
    • Redaktion
  • WCAG A

    WCAG Kriterium: 1.3.1 Info und Beziehungen

    Datentabellen nutzen <table>, <th> für Überschriften und <td> für Zellen. Komplexe Tabellen mit mehreren Überschriftenebenen benötigen das scope-Attribut (z.B. scope="col" oder scope="row").

    • wahrnehmbar
    • Entwicklung
    • Redaktion
  • WCAG A

    WCAG Kriterium: 1.3.1 Info und Beziehungen

    Für Absätze wird <p> verwendet, für Betonungen <strong> oder <em>. Abstände werden nicht durch doppelte Zeilenumbrüche (<br><br>) erzeugt, sondern durch CSS-Margins.

    • wahrnehmbar
    • Entwicklung
    • Redaktion
    Lernartikel über dieses Thema:
  • WCAG A

    WCAG Kriterium: 1.3.1 Info und Beziehungen

    Inhalte, die optisch wie Listen aussehen, müssen im Code auch als Listen ausgezeichnet sein. Nutze <ul> für unsortierte Listen, <ol> für nummerierte Listen.

    • wahrnehmbar
    • Entwicklung
    • Redaktion
    Lernartikel über dieses Thema:
  • WCAG A

    WCAG Kriterium: 4.1.2 Name, Rolle, Wert

    Akkordeons, Drop-downs oder andere ausklappbare Bereiche müssen auch mit der Tastatur und Screenreadern bedienbar sein. Nutzer sollen erkennen können, was eingeklappt ist – und es gezielt öffnen und schließen können.

    • Robust
    • Entwicklung
    Lernartikel über dieses Thema:
  • WCAG A

    WCAG Kriterium: 4.1.3 Statusmeldungen

    Wenn sich Inhalte auf einer Seite automatisch ändern (z. B. durch AJAX oder Live-Updates), müssen Screenreader über diese Änderungen informiert werden. Das geschieht durch sogenannte ARIA-Live-Regionen, die neue Inhalte automatisch ansagen lassen.

    • Robust
    • Entwicklung
    Lernartikel über dieses Thema:
  • WCAG AA

    WCAG Kriterium: 1.3.1 Info und Beziehungen

    Eine klare, semantische HTML-Struktur hilft Screenreadern und anderen Hilfsmitteln, den Seitenaufbau zu verstehen. Verwende z. B. <header>, <main>, <nav> und <footer> statt nur <div>-Containern. So wird der Inhalt logisch gegliedert und besser zugänglich.

    • Robust
    • Entwicklung
    Lernartikel über dieses Thema:
  • WCAG A

    WCAG Kriterium: 4.1.1 Parsing

    Der HTML-Code sollte fehlerfrei und valide sein. Fehlerhafte Struktur kann die Interpretation durch Hilfsmittel behindern.

    • Robust
    • Entwicklung

Responsive & Mobile

  • WCAG AA

    WCAG Kriterium: 1.3.4 Orientierung

    Inhalte funktionieren sowohl im Hoch- als auch Querformat.

    • wahrnehmbar
    • Design
    • Entwicklung
  • WCAG AA

    WCAG Kriterium: 1.4.10 Reflow

    Der Inhalt muss sich bis auf 320 CSS-Pixel (bzw. 400 % Zoom eines 1280-px-Desktops) ohne horizontales Scrollen und ohne Funktions- oder Informationsverlust umfließen lassen.

    • wahrnehmbar
    • Design
    • Entwicklung
    Lernartikel über dieses Thema: