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.

Ganze Seite

  • WCAG A

    WCAG Kriterium: 2.4.2 Titel der Seite

    Der Seitentitel im Browser-Tab muss sowohl den Namen der aktuellen Seite als auch den Namen der Website enthalten. Screenreader-Nutzer hören ihn als erstes wenn sie die Seite öffnen.

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

    WCAG Kriterium: 3.1.1 Sprache der Seite

    Die Hauptsprache der Seite (z. B. Deutsch) muss im HTML-Code definiert sein. Das geschieht über das lang-Attribut am <html>-Element. Nur so wissen Screenreader, wie sie den Inhalt korrekt aussprechen sollen.

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

    WCAG Kriterium: 2.4.1 Bereiche überspringbar

    Ein „Zum Hauptinhalt springen“-Link ermöglicht Tastaturnutzern, die Hauptnavigation zu überspringen. Er darf beim Laden unsichtbar sein, muss aber bei Tab-Fokus erscheinen.

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

    WCAG Kriterium: 1.3.2 Sinnvolle Reihenfolge

    Seiteninhalte müssen unabhängig von der visuellen Darstellung im DOM in einer sinnvollen Reihenfolge stehen. Screenreader lesen den Quelltext linear vor — wenn CSS Inhalte visuell umordnet aber der DOM keine logische Lesefolge ergibt, entsteht Verwirrung.

    • wahrnehmbar
    • Entwicklung
  • WCAG A

    WCAG Kriterium: 3.2.6 Konsistente Hilfe

    Wenn eine Website Hilfe anbietet (Kontakt, Chat, FAQ, Telefon) muss diese auf allen Seiten an derselben Stelle im Layout erscheinen. Nutzer mit kognitiven Einschränkungen verlassen sich auf stabile Positionen.

    • Verständlich
    • Design
  • WCAG AA

    WCAG Kriterium: 3.2.4 Konsistente Erkennung

    Elemente die dieselbe Funktion haben müssen auf der gesamten Website gleich benannt und beschriftet sein. Ein Suche-Button darf nicht mal „Suchen“, mal „Los“ und mal „Finden“ heißen.

    • Verständlich
    • Design
    • Entwicklung
    • Redaktion
  • 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
    Lerninhalte über dieses Thema
    Lernartikel über dieses Thema:

Bilder & Grafiken

Farben & Kontraste

Text & Sprache

  • WCAG A

    WCAG Kriterium: 1.3.3 Sensorische Eigenschaften

    Beschreibe Elemente nicht nur durch Form, Farbe oder Position. Statt „Klicke auf den grünen Button rechts“ besser: „Klicke auf ‚Jetzt kaufen’“. Screenreader-Nutzer können Position und Farbe oft nicht wahrnehmen.

    • 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
    Lerninhalte über dieses Thema
    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
    Lerninhalte über dieses Thema
    Lernartikel über dieses Thema:
  • WCAG AA

    WCAG Kriterium: 3.1.2 Sprache von Teilen

    Wenn Inhalte auf einer anderssprachigen Seite in einer anderen Sprache stehen (z.B. ein englisches Zitat auf einer deutschen Seite), muss das entsprechende Element lang="en" haben.

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

Überrschriften

Links

  • WCAG A

    WCAG Kriterium: 1.4.1 Einsatz von Farbe

    Links im Fließtext dürfen nicht ausschließlich durch Farbe von normalem Text unterschieden werden. Eine Unterstreichung oder ein anderes visuelles Merkmal ist Pflicht.

    • wahrnehmbar
    • Design
  • WCAG A

    WCAG Kriterium: 2.4.7 Fokus sichtbar

    Wenn ein Link den Tastaturfokus erhält muss das visuell deutlich erkennbar sein. Der Fokus-Indikator muss ausreichend sichtbar sein (WCAG 2.2: mind. 3:1 Kontrast, Fokus-Fläche entspricht mindestens einem 2px Umriss).

    • Bedienbar
    • Design
    • Entwicklung
  • WCAG A

    WCAG Kriterium: 2.1.1 Tastatur

    Alle Links müssen per Tab-Taste erreichbar sein und per Enter aktiviert werden können. Links ohne href-Attribut oder mit JavaScript-only-Handling sind oft nicht per Tastatur erreichbar.

    • Bedienbar
    • Entwicklung
    Lerninhalte über dieses Thema
    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
    Lerninhalte über dieses Thema
    Lernartikel über dieses Thema:
  • WCAG A

    WCAG Kriterium: 2.5.3 Label im Namen

    Der zugängliche Name (aria-label) eines interaktiven Elements muss den sichtbaren Text enthalten. Wenn ein Button sichtbar „Jetzt kaufen“ zeigt, darf aria-label nicht „Produkt bestellen“ heißen — Sprachsteuerungs-Nutzer können das Element sonst nicht ansprechen

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

Buttons

  • WCAG A

    WCAG Kriterium: 2.1.1 Tastatur

    Alle Buttons müssen per Tab erreichbar und per Enter oder Leertaste aktivierbar sein. <button>-Elemente sind standardmäßig korrekt bedienbar. Wenn andere Elemente (<div>, <span>, <a>) als Button verwendet werden, müssen sie tabindex="0" und passende Tastatur-Handler besitzen. – Buttons ohne tabindex und Tastatur-Handler sind ein häufiger Fehler.

    • Bedienbar
    • Entwicklung
    Lerninhalte über dieses Thema
    Video über dieses Thema:
  • WCAG A

    WCAG Kriterium: 4.1.2 Name, Rolle, Wert

    Schaltflächen sollen als natives <button>-Element implementiert sein. Wenn andere Elemente (<div>, <span>, <a>) als Button fungieren, müssen sie role="button" und korrekte Tastaturunterstützung haben.

    • Robust
    • Entwicklung
    Lerninhalte über dieses Thema
    Video über dieses Thema:
  • WCAG AA

    WCAG Kriterium: 2.4.7 Fokus sichtbar

    Fokussierte Buttons müssen visuell klar erkennbar sein. Das gilt besonders für Buttons in Formularen, Modals und Navigationen.

    • Bedienbar
    • Design
    • Entwicklung
    Lerninhalte über dieses Thema
    Video über dieses Thema:
  • WCAG A

    WCAG Kriterium: 

    Buttons die nur aus einem Icon bestehen (Schließen-X, Hamburger, Teilen) brauchen ein aria-label das den Zweck beschreibt. Ohne aria-label sagt der Screenreader nur „Schaltfläche“

    • wahrnehmbar
    • Entwicklung
    Lerninhalte über dieses Thema
    Lernartikel über dieses Thema:
  • WCAG AA

    WCAG Kriterium: 2.5.8 Zielgröße (Minimum)

    Das anklickbare Ziel eines Buttons oder Links muss mindestens 24×24 CSS-Pixel groß sein (WCAG 2.2). Für AAA gilt 44x44px. Kleine Klickziele sind besonders für Nutzer mit motorischen Einschränkungen ein Problem.

    • Robust
    • Design
    Lerninhalte über dieses Thema
    Lernartikel über dieses Thema:
  • WCAG A

    WCAG Kriterium: 4.1.2 Name, Rolle, Wert

    Buttons die einen Zustand umschalten (Favorit, Stummschalten, Folgen) müssen aria-pressed="true/false" haben. So können Screenreader-Nutzer den aktuellen Zustand erkennen.

    • Robust
    • Entwicklung
  • WCAG A

    WCAG Kriterium: 2.5.3 Label im Namen

    Der zugängliche Name (aria-label) eines interaktiven Elements muss den sichtbaren Text enthalten. Wenn ein Button sichtbar „Jetzt kaufen“ zeigt, darf aria-label nicht „Produkt bestellen“ heißen — Sprachsteuerungs-Nutzer können das Element sonst nicht ansprechen

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

Navigation

  • WCAG A

    WCAG Kriterium: 2.1.1 Tastatur

    Jeder Navigationslink und jedes Dropdown-Menü muss ohne Maus erreichbar und aktivierbar sein. Tab zum Fokussieren, Enter/Leertaste zum Aktivieren, Escape zum Schließen.

    • Bedienbar
    • Entwicklung
  • WCAG A

    WCAG Kriterium: 2.1.1 Tastatur

    Dropdown-Menüs die per Klick oder Hover öffnen müssen per Escape-Taste schließbar sein. Beim Schließen muss der Fokus zum auslösenden Element zurückkehren.

    • Bedienbar
    • Entwicklung
  • WCAG A

    WCAG Kriterium: 4.1.2 Name, Rolle, Wert

    Der Link zur aktuell besuchten Seite muss aria-current=“page“ haben. Screenreader-Nutzer hören dann „Aktuelle Seite“ vor dem Link und wissen wo sie sich befinden.

    • Robust
    • Entwicklung
  • WCAG A

    WCAG Kriterium: 1.3.1 Info und Beziehungen

    Navigationsbereiche müssen als Landmark ausgezeichnet sein. Screenreader-Nutzer können direkt zu Landmarks springen (Taste D oder Liste aufrufen) und müssen nicht linear durch alles navigieren.

    • wahrnehmbar
    • Entwicklung
  • WCAG AA

    WCAG Kriterium: 2.4.11 Fokus nicht verdeckt

    Erhält ein interaktives Element den Tastaturfokus, darf es nicht vollständig durch eine fixierte Navigation, einen Sticky-Header oder ein Overlay verdeckt werden

    • Bedienbar
    • Design
    • Entwicklung
  • 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 A

    WCAG Kriterium: 1.3.1 Info und Beziehungen

    Wenn eine Seite mehrere

    • wahrnehmbar
    • Entwicklung
  • 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
    Lerninhalte über dieses Thema
    Lernartikel über dieses Thema:

Multimedia

  • 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.1.1 Tastatur

    Alle Steuerelemente des Medienplayers (Play, Pause, Lautstärke, Vollbild, Untertitel) müssen per Tastatur erreichbar und bedienbar sein.

    • Bedienbar
    • Entwicklung
  • 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
    Lerninhalte über dieses Thema
    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
    Lerninhalte über dieses Thema
    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
    Lerninhalte über dieses Thema
    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
    Lerninhalte über dieses Thema
    Lernartikel über dieses Thema:

Animationen

Tastatur & Bedienung

  • 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: 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
    Lerninhalte über dieses Thema
    Lernartikel über dieses Thema:
  • WCAG A

    WCAG Kriterium: 2.1.1 Tastatur

    Jede Funktion die mit der Maus ausgefuehrt werden kann muss auch per Tastatur möglich sein: Buttons, Links, Dropdowns, Slider, Datepicker — alles.

    • Bedienbar
    • Entwicklung
    Lerninhalte über dieses Thema
    Video über dieses Thema:
  • WCAG A

    WCAG Kriterium: 2.1.2 Keine Tastaturfalle

    Tastaturnutzer dürfen nicht in einem Element „gefangen“ sein. Sie müssen mit Tab oder Escape jederzeit weiterkommen — außer in geöffneten Modals (dort ist Fokus-Trap gewünscht).

    • Bedienbar
    • Entwicklung
    Lerninhalte über dieses Thema
    Video über dieses Thema:
  • 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.3 Fokus-Reihenfolge

    tabindex="1" oder hoehere Werte verändern die natürliche Tab-Reihenfolge und führen zu verwirrenden Fokus-Sprüngen. Erlaubt sind nur tabindex="0" und tabindex="-1".

    • 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: 1.4.11 Nicht-Text-Kontrast

    Tab-Navigation zeigt deutlich das aktive Element durch kontrastreiche Umrandung (mindestens 3:1 Verhältnis).

    • wahrnehmbar
    • Design
    • Entwicklung
    Lerninhalte über dieses Thema
    Lernartikel über dieses Thema:
  • 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 A

    WCAG Kriterium: 3.2.1 Kontextänderung bei Fokus

    Wenn ein Element den Tastaturfokus erhält darf das keine unerwartete Aktion auslösen (z.B. automatisch ein Formular absenden, eine neue Seite öffnen oder ein Modal starten).

    • Verständlich
    • Entwicklung

Formulare

  • 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
    Lerninhalte über dieses Thema
    Lernartikel über dieses Thema:
  • WCAG A

    WCAG Kriterium: 1.3.1 Info und Beziehungen

    Das <label>-Element muss über das for-Attribut mit der id des Eingabefeldes verknüpft sein. Nur so liest der Screenreader das Label vor, wenn das Feld fokussiert wird.

    • wahrnehmbar
    • Entwicklung
  • WCAG A

    WCAG Kriterium: 1.4.1 Einsatz von Farbe

    Pflichtfelder müssen durch Text oder Symbol (z.B. *) erkennbar sein, nicht nur durch Farbe. Die Bedeutung des Symbols muss erklärt werden (z.B. „* = Pflichtfeld“).

    • wahrnehmbar
    • Design
  • WCAG AA

    WCAG Kriterium: 1.3.5 Eingabezweck identifizieren

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

    • Verständlich
    • Entwicklung
    Lerninhalte über dieses Thema
    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
    Lerninhalte über dieses Thema
    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 AA

    WCAG Kriterium: 1.4.11 Nicht-Text-Kontrast

    Eingabefelder, Checkboxen, Radio-Buttons und ihre sichtbaren Umrandungen oder Flächen müssen einen ausreichenden Kontrast zur Umgebung aufweisen. Der Kontrast muss mindestens 3:1 betragen.

    • wahrnehmbar
    • Design
    • Entwicklung
  • WCAG A

    WCAG Kriterium: 3.3.7 Doppelte Eingabe

    Informationen die der Nutzer bereits in einem Prozess eingegeben hat müssen nicht nochmal eingegeben werden. Neues WCAG 2.2 Kriterium — hilft besonders Menschen mit kognitiven Einschränkungen.

    • Verständlich
    • Entwicklung

Landmarks & Seitenstruktur

  • 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
    Lerninhalte über dieses Thema
    Lernartikel über dieses Thema:
  • WCAG A

    WCAG Kriterium: 1.3.1 Info und Beziehungen

    Jede Seite darf nur einen <main>-Bereich haben. Screenreader-Nutzer springen direkt zum main-Landmark — mehrere main-Elemente verwirren.

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

    WCAG Kriterium: 1.3.1 Info und Beziehungen

    Wenn mehrere nav-, aside- oder section-Elemente auf einer Seite vorhanden sind, muss jedes per aria-label einen eigenen beschreibenden Namen haben.

    • wahrnehmbar
    • Entwicklung
  • 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

Darstellung & Mobil

  • 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

    Bei 320 CSS-Pixeln Breite (entspricht 400 % Zoom auf einem 1280-px-Desktop) muss sich der Inhalt ohne horizontales Scrollen und ohne Funktions- oder Informationsverlust umfließen lassen. Ausnahmen gelten für Tabellen, Karten und Diagramme.

    • wahrnehmbar
    • Design
    • Entwicklung
    Lerninhalte über dieses Thema
    Lernartikel über dieses Thema:
  • WCAG AA

    WCAG Kriterium: 1.4.12 Textabstand

    Viele Nutzer passen Textabstände über Browser-Erweiterungen oder eigene Stylesheets an. Die Seite muss mit folgenden Werten funktionieren: Zeilenabstand 1,5×, Absatzabstand 2× Schriftgröße, Buchstabenabstand 0,12× Schriftgröße, Wortabstand 0,16× Schriftgröße.

    • wahrnehmbar
    • Entwicklung
  • WCAG AA

    WCAG Kriterium: 1.4.4 Textgröße ändern

    user-scalable=no oder maximum-scale=1 im Viewport-Meta-Tag verhindert das Zoomen auf Mobilgeräten. Das ist ein barrierefreies No-Go.

    • wahrnehmbar
    • Design
    • Entwicklung
    Lerninhalte über dieses Thema
    Lernartikel über dieses Thema:
    Video über dieses Thema:
  • WCAG AA

    WCAG Kriterium: 1.4.4 Textgröße ändern

    Nutzer mit Sehbehinderungen zoomen häufig auf 200 % oder mehr. Texte und Inhalte dürfen dabei nicht abgeschnitten werden, überlappen oder unleserlich werden.

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

Dynamische Inhalte

  • WCAG A

    WCAG Kriterium: 2.4.3 Fokus-Reihenfolge

    Wenn ein „Mehr laden“-Button neue Inhalte lädt darf der Fokus nicht plötzlich an den Seitenanfang oder an eine andere unerwartete Stelle springen. Der Fokus bleibt idealerweise auf dem Button oder geht zum ersten neuen Element.

    • Bedienbar
    • Entwicklung
  • 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
    Lerninhalte über dieses Thema
    Lernartikel über dieses Thema:
    Video über dieses Thema:
  • 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

Drag & Drop

  • WCAG A

    WCAG Kriterium: 4.1.2 Name, Rolle, Wert

    Bereiche in denen Elemente abgelegt werden können (Drop Zones) müssen einen zugänglichen Namen haben. Bei aktivem Drag muss per aria-live oder aria-dropeffect kommuniziert werden was abgelegt werden kann.

    • Robust
    • Entwicklung
  • WCAG A

    WCAG Kriterium: 4.1.2 Name, Rolle, Wert

    Elemente die gezogen werden können müssen per aria-grabbed oder durch klare visuelle und textliche Hinweise als ziehbar erkennbar sein. Screenreader-Nutzer müssen wissen dass ein Element verschiebbar ist.

    • Robust
    • Entwicklung
  • WCAG AA

    WCAG Kriterium: 2.5.7 Ziehbewegungen

    Wenn ein Datei-Upload per Drag & Drop angeboten wird muss es auch einen klassischen Datei-Auswahl-Button geben. Nicht alle Nutzer können Dateien ziehen.

    • Bedienbar
    • Entwicklung
  • WCAG AA

    WCAG Kriterium: 2.5.7 Ziehbewegungen

    Alle Drag & Drop-Funktionen müssen auch ohne Ziehen bedienbar sein — z.B. per Buttons („Nach oben“, „Nach unten“), Kontextmenü oder Tastatureingabe. Reine Drag & Drop-Implementierungen schließen viele Nutzer aus.

    • Bedienbar
    • 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.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

Statusmeldungen & Alerts

  • WCAG AA

    WCAG Kriterium: 4.1.3 Statusmeldungen

    Wenn Inhalte geladen werden (Spinner, Skeleton-Screens) muss der Ladezustand per aria-live oder role="status" kommuniziert werden. Nach dem Laden sollte eine Meldung kommen.

    • Robust
    • Entwicklung
  • WCAG A

    WCAG Kriterium: 1.4.1 Einsatz von Farbe

    Erfolg (gruen) und Fehler (rot) dürfen nicht nur durch Farbe unterschieden werden. Ein Icon (Haekchen/X) oder zusätzlicher Text („Erfolg:“ / „Fehler:“) muss vorhanden sein.

    • wahrnehmbar
    • Design
  • WCAG A

    WCAG Kriterium: 2.2.1 Zeitbegrenzungen

    Toast-Nachrichten die automatisch verschwinden müssen lang genug sichtbar sein. Nutzer müssen die Zeit verlängern oder die Meldung schließen können.

    • Bedienbar
    • Design
    • Entwicklung
  • WCAG AA

    WCAG Kriterium: 4.1.3 Statusmeldungen

    Wichtige Fehlermeldungen (z.B. Formularfehler, Validierungsfehler) müssen den Screenreader sofort unterbrechen. Dafür gibt es zwei gleichwertige Wege: role="alert" (setzt automatisch aria-live="assertive" und aria-atomic="true") oder explizit aria-live="assertive". Beide Varianten sind korrekt — wichtig ist dass die Meldung sofort vorgelesen wird ohne dass der Nutzer erst hinnavigieren muss.

    • Robust
    • Entwicklung
  • WCAG AA

    WCAG Kriterium: 4.1.3 Statusmeldungen

    Meldungen die ohne Fokuswechsel erscheinen (z.B. „Gespeichert“, „3 Artikel in Warenkorb“, „Fehler beim Laden“) müssen über aria-live oder role="status"/role="alert" kommuniziert werden.

    • Robust
    • Entwicklung

Tabs

Akkordeons

Modals & Dialoge

  • WCAG A

    WCAG Kriterium: 4.1.2 Name, Rolle, Wert

    Empfohlen: das native <dialog>-Element (macht das automatisch) oder das inert-Attribut auf dem Hauptinhalt. Alternativ aria-hidden="true" auf dem Seitencontainer.

    • Robust
    • Entwicklung
  • WCAG A

    WCAG Kriterium: 4.1.2 Name, Rolle, Wert

    Wenn ein Modal geöffnet wird muss der Tastaturfokus automatisch in den Dialog wandern — zum ersten fokussierbaren Element oder zum Dialog-Titel. Sonst sind Tastatur-Nutzer weiter im Hintergrundinhalt.

    • Robust
    • Entwicklung
    Lerninhalte über dieses Thema
    Video über dieses Thema:
  • WCAG A

    WCAG Kriterium: 2.1.2 Keine Tastaturfalle

    Wenn ein Modal geöffnet ist darf der Fokus den Dialog nicht verlassen. Beim Tab nach dem letzten Element muss der Fokus zum ersten Element im Modal zurückkehren (Fokus-Schleife).

    • Bedienbar
    • Entwicklung
    Lerninhalte über dieses Thema
    Video über dieses Thema:
  • WCAG A

    WCAG Kriterium: 2.1.1 Tastatur

    Modale Dialoge müssen per Escape-Taste schließbar sein. Das ist eine etablierte Interaktionskonvention die alle Tastaturnutzer erwarten.

    • Bedienbar
    • Entwicklung
    Lerninhalte über dieses Thema
    Video über dieses Thema:
  • WCAG A

    WCAG Kriterium: 2.4.3 Fokus-Reihenfolge

    Nach dem Schließen eines Modals muss der Fokus zum Element zurückkehren das den Modal ausgelöst hat. Sonst verlieren Tastaturnutzer ihre Position auf der Seite.

    • Bedienbar
    • Entwicklung
    Lerninhalte über dieses Thema
    Video über dieses Thema:
  • WCAG A

    WCAG Kriterium: 4.1.2 Name, Rolle, Wert

    Das Modal-Element muss role="dialog" (oder das native <dialog>-Element) haben und einen zugänglichen Namen über aria-labelledby oder aria-label. Sonst weiß der Screenreader nicht, dass es ein Dialog ist.

    • Robust
    • Entwicklung
    Lerninhalte über dieses Thema
    Video über dieses Thema:

Cookie-Banner

  • WCAG A

    WCAG Kriterium: 4.1.2 Name, Rolle, Wert

    Cookie-Banner müssen als natives <dialog>-Element, role=“dialog“ oder role=“region“ mit einem beschreibenden aria-label ausgezeichnet sein, damit Screenreader-Nutzer wissen, was sie sehen, und es als zusammenhängenden Bereich wahrnehmen.

    • Robust
    • Entwicklung
    Lerninhalte über dieses Thema
    Video über dieses Thema:
  • WCAG A

    WCAG Kriterium: 4.1.2 Name, Rolle, Wert

    Wenn der Cookie-Banner erscheint sollte der Tastaturfokus automatisch in den Banner gesetzt werden. Sonst müssen Tastaturnutzer durch die gesamte Seite tabben bevor sie den Banner erreichen.

    • Robust
    • Entwicklung
  • WCAG A

    WCAG Kriterium: 4.1.2 Name, Rolle, Wert

    Wenn der Cookie-Banner erscheint sollte der Tastaturfokus automatisch in den Banner gesetzt werden. Sonst müssen Tastaturnutzer durch die gesamte Seite tabben bevor sie den Banner erreichen.

    • Robust
    • Entwicklung
  • WCAG A

    WCAG Kriterium: 1.3.1 Info und Beziehungen

    Checkboxen und Toggle-Schalter für einzelne Cookie-Kategorien müssen sichtbare, programmatisch verknüpfte Labels haben.

    • wahrnehmbar
    • Entwicklung
  • WCAG A

    WCAG Kriterium: 3.2.2 Kontextänderung bei Eingabe

    Ablehnen darf nicht versteckt oder schwieriger sein als Akzeptieren. Ein gut sichtbarer „Alle akzeptieren“-Button ohne gleichwertigen „Ablehnen“-Button ist eine manipulative Gestaltung und rechtlich problematisch.

    • Verständlich
    • Design
    • Entwicklung

Tabellen

  • WCAG A

    WCAG Kriterium: 1.3.1 Info und Beziehungen

    Spalten- und Zeilen-Überschriften in Datentabellen müssen als <th> ausgezeichnet sein, mit dem scope-Attribut (col oder row). So können Screenreader Zellen und Überschriften korrekt zuordnen.

    • wahrnehmbar
    • Entwicklung
  • WCAG A

    WCAG Kriterium: 1.3.1 Info und Beziehungen

    Jede Datentabelle sollte eine <caption> haben, die ihren Inhalt beschreibt. Screenreader kündigen den Tabellennamen an, bevor sie in die Tabelle eintreten.

    • wahrnehmbar
    • Entwicklung
  • WCAG A

    WCAG Kriterium: 1.3.1 Info und Beziehungen

    Bei einfachen Tabellen (eine Kopfzeile oben oder seitlich) reicht scope="col" oder scope="row" auf dem <th>. Bei komplexen Tabellen — mit mehreren Kopfzeilen oder verschachtelten Ebenen — braucht jedes <th> eine id, und jede <td>-Zelle ein headers-Attribut, das auf alle zugehörigen <th>-IDs verweist. Ohne diese Zuordnung kann ein Screenreader nicht ansagen, zu welchen Köpfen eine Zelle gehört.

    • wahrnehmbar
    • Entwicklung

Tooltips

  • WCAG AA

    WCAG Kriterium: 1.4.13 Eingeblendete Inhalte auf Hover und Fokus

    Nutzer die Mauszeiger-Vergroßerung verwenden oder langsam zielen müssen den Mauszeiger auf den Tooltip bewegen können ohne das er verschwindet.

    • wahrnehmbar
    • Entwicklung
  • WCAG AA

    WCAG Kriterium: 1.4.13 Eingeblendete Inhalte auf Hover und Fokus

    Tooltips die per Hover oder Fokus erscheinen müssen per Escape-Taste schließbar sein ohne den Fokus zu verschieben. Das ist ein Kriterium aus WCAG 2.1.

    • wahrnehmbar
    • Entwicklung
  • WCAG A

    WCAG Kriterium: 4.1.2 Name, Rolle, Wert

    Der Tooltip-Text muss programmatisch mit dem auslösenden Element verknüpft sein (z.B. aria-describedby). Screenreader-Nutzer müssen den Tooltip-Inhalt hören wenn das Element fokussiert wird.

    • Robust
    • Entwicklung
  • WCAG A

    WCAG Kriterium: 2.1.1 Tastatur

    Tooltips die nur per Hover erscheinen sind für Tastaturnutzer unsichtbar. Sie müssen auch erscheinen wenn das auslösende Element per Tab fokussiert wird.

    • Bedienbar
    • Entwicklung

Karussell / Slider

  • WCAG A

    WCAG Kriterium: 1.3.1 Info und Beziehungen

    Das Karussell-Element sollte role="region" und ein aria-label wie „Aktuelles“ oder „Bildergalerie“ haben, damit Screenreader-Nutzer es als eigenständigen Bereich identifizieren können.

    • wahrnehmbar
    • Entwicklung
  • WCAG A

    WCAG Kriterium: 4.1.2 Name, Rolle, Wert

    Vorwärts/Zurück-Buttons und Slide-Indikatoren (Punkte) müssen beschreibende aria-labels haben. „Button“ allein reicht nicht — Screenreader-Nutzer müssen wissen was die Schaltfläche tut.

    • Robust
    • Entwicklung
  • WCAG A

    WCAG Kriterium: 2.2.2 Pausieren, Stoppen, Ausblenden

    Wenn das Karussell automatisch wechselt muss es eine gut sichtbare und per Tastatur erreichbare Pause-Schaltfläche geben. Automatischer Wechsel ohne Pause-Option ist ein schwerer Fehler.

    • Bedienbar
    • Design
    • Entwicklung
  • WCAG A

    WCAG Kriterium: 2.1.1 Tastatur

    Alle Steuerelemente des Karussells (Vorwärts, Zurück, Pause, einzelne Slide-Indikatoren) müssen per Tab erreichbar und per Enter/Leertaste aktivierbar sein.

    • Bedienbar
    • Entwicklung
  • WCAG AA

    WCAG Kriterium: 4.1.3 Statusmeldungen

    Wenn eine neue Folie angezeigt wird sollten Screenreader-Nutzer das mitbekommen. Dies kann über aria-live="polite" auf dem Karussell-Bereich oder durch Fokus-Verschiebung geschehen.

    • Robust
    • Entwicklung

Pagination

  • WCAG A

    WCAG Kriterium: 2.1.1 Tastatur

    Alle Seiten-Links in der Pagination müssen per Tab erreichbar und per Enter aktivierbar sein. Keine Seite darf nur per Mausklick erreichbar sein.

    • Bedienbar
    • Entwicklung
  • WCAG A

    WCAG Kriterium: 2.4.4 Linktexte im Kontext

    Links wie „«“ oder „»“ müssen ein aria-label haben das den Zweck beschreibt („Vorherige Seite“, „Nächste Seite“). Nur ein Pfeil-Icon ohne Label ist nicht zugänglich.

    • Bedienbar
    • Entwicklung
    • Redaktion
  • WCAG A

    WCAG Kriterium: 1.3.1 Info und Beziehungen

    Die Pagination muss in einem <nav>-Element mit aria-label="Seitennavigation" oder „Pagination“ stehen, damit sie als eigener Landmark erkennbar ist.

    • wahrnehmbar
    • Entwicklung

Suche

  • WCAG A

    WCAG Kriterium: 1.3.1 Info und Beziehungen

    Der Suchbereich sollte als Search-Landmark ausgezeichnet sein, z.B. mit <form role=“search“> oder einem Container mit role="search". So erscheint er als eigener Landmark-Bereich in Screenreadern.

    • wahrnehmbar
    • Entwicklung
  • WCAG A

    WCAG Kriterium: 1.3.1 Info und Beziehungen

    Das Suchfeld muss einen zugänglichen Namen haben. Drei gleichwertige Wege: aria-label="Suche" direkt am Input, ein visuell verstecktes <label> (z.B. mit einer sr-only-Klasse) oder aria-labelledby. Ein sichtbares Label ist nicht nötig. Placeholder-Text allein reicht nicht. Empfehlung: <input type="search"> als Input-Typ verwenden.

    • wahrnehmbar
    • Entwicklung
  • WCAG A

    WCAG Kriterium: 2.1.1 Tastatur

    Wenn Suchvorschläge erscheinen müssen sie per Pfeiltasten erreichbar sein. Enter wählt einen Vorschlag aus. Escape schließt die Vorschlagsliste.

    • Bedienbar
    • Entwicklung
  • WCAG AA

    WCAG Kriterium: 4.1.3 Statusmeldungen

    Nach einer Suche muss die Anzahl der Ergebnisse (oder „keine Ergebnisse“) per aria-live oder Fokus-Verschiebung kommuniziert werden. Screenreader-Nutzer mussen wissen ob etwas gefunden wurde.

    • Robust
    • Entwicklung
  • WCAG AA

    WCAG Kriterium: 4.1.3 Statusmeldungen

    Wenn Suchvorschläge erscheinen muss das per aria-live oder role="combobox" dem Screenreader mitgeteilt werden. Nutzer müssen wissen dass Vorschläge verfügbar sind.

    • Robust
    • Entwicklung

Suchfilter & Facetten

  • WCAG A

    WCAG Kriterium: 1.3.1 Info und Beziehungen

    Alle Filter-Checkboxen, Dropdowns und Schaltflächen brauchen sichtbare Labels die programmatisch verknüpft sind. Nur visuelle Gruppierungen ohne Labels reichen nicht.

    • wahrnehmbar
    • Entwicklung
  • WCAG A

    WCAG Kriterium: 2.1.1 Tastatur

    Alle Filteroptionen müssen per Tab erreichbar und per Leertaste/Enter aktivierbar sein. Aufklappbare Filterbereiche müssen per Tastatur geöffnet und geschlossen werden können.

    • Bedienbar
    • Entwicklung
  • WCAG A

    WCAG Kriterium: 4.1.2 Name, Rolle, Wert

    Aktive Filter-Tags müssen programmatisch als aktiviert erkennbar sein und per Tastatur entfernbar sein. „Filter entfernen“-Buttons brauchen zugängliche Namen die den spezifischen Filter benennen.

    • Robust
    • Design
    • Entwicklung
  • WCAG AA

    WCAG Kriterium: 4.1.3 Statusmeldungen

    Wenn das Anwenden eines Filters die Ergebnisliste aktualisiert muss das per aria-live kommuniziert werden. „42 Ergebnisse gefunden“ muss vom Screenreader angesagt werden ohne Seitenneuladung.

    • Robust
    • Entwicklung
  • WCAG A

    WCAG Kriterium: 1.3.1 Info und Beziehungen

    Filtergruppen (z.B. „Preis“, „Farbe“, „Größe“) müssen mit <fieldset> und <legend> oder aria-group mit aria-labelledby ausgezeichnet sein.

    • wahrnehmbar
    • Entwicklung

Radio Buttons

  • WCAG A

    WCAG Kriterium: 2.1.1 Tastatur

    In einer Radio-Gruppe wird mit Tab in die Gruppe gewechselt. Innerhalb der Gruppe navigiert man per Pfeiltasten (Hoch/Runter oder Links/Rechts) zwischen den Optionen. Tab verlasst die Gruppe.

    • Bedienbar
    • Entwicklung
  • WCAG A

    WCAG Kriterium: 1.3.1 Info und Beziehungen

    Radio-Gruppen müssen mit <fieldset> und <legend> ausgezeichnet sein. Die Legend beschreibt die Frage oder den Kontext für alle Optionen der Gruppe.

    • wahrnehmbar
    • Entwicklung
  • WCAG A

    WCAG Kriterium: 4.1.2 Name, Rolle, Wert

    Der Zustand (ausgewählt/nicht ausgewählt) muss programmatisch übermittelt werden. Native <input type=“radio“> tut das automatisch. Benutzerdefinierte Radio-Buttons brauchen role="radio" und aria-checked.

    • Robust
    • Entwicklung
  • WCAG A

    WCAG Kriterium: 1.3.1 Info und Beziehungen

    Jede Radio-Option braucht ein sichtbares Label. Klick auf das Label soll den Radio-Button auswählen. Nur Icons ohne Text als Label sind nicht zulässig.

    • wahrnehmbar
    • Entwicklung
    • Redaktion

Toggle-Schalter

  • WCAG A

    WCAG Kriterium: 1.4.1 Einsatz von Farbe

    Der Ein/Aus-Zustand eines Toggles darf nicht ausschließlich durch Farbe (gruen/grau) erkennbar sein. Eine zusätzliche visuelle Unterscheidung (Position des Sliders, Icon, Text) ist nötig.

    • wahrnehmbar
    • Design
  • WCAG A

    WCAG Kriterium: 4.1.2 Name, Rolle, Wert

    Jeder Toggle-Schalter muss einen zugänglichen Namen haben der seine Funktion beschreibt. Nur „Ein/Aus“ als Text reicht nicht — es muss klar sein was ein- oder ausgeschaltet wird.

    • Robust
    • Entwicklung
  • WCAG A

    WCAG Kriterium: 4.1.2 Name, Rolle, Wert

    Der Zustand eines Toggle-Schalters muss per role="switch" und aria-checked="true/false" oder per role="button" und aria-pressed="true/false" kommuniziert werden.

    • Robust
    • Entwicklung
  • WCAG A

    WCAG Kriterium: 2.1.1 Tastatur

    Toggle-Schalter müssen per Tab erreichbar und per Leertaste oder Enter umschaltbar sein. Sie verhalten sich wie Buttons mit Zustand.

    • Bedienbar
    • Entwicklung

Komplett kostenlos

Starte deinen Weg zur digitalen Barrierefreiheit

Erhalte 5 Tage lang täglich eine E-Mail: Von den Grundlagen über die besten Testing-Tools bis zu häufigen Fehlern – dein perfekter Einstieg in digitale Barrierefreiheit.