🎯 Alles, was kein Text ist, braucht Text – oder wird bewusst ignoriert.

Was ist zu tun?

Textalternativen bereitstellen, für alles was kein Text ist (für visuelle und auditive Inhalte)

Textalternative erforderlich für:

📷 Bilder, Icons, Symbole → kurze Beschreibung (ca. 100 Zeichen)

📊 Komplexe Grafiken (z. B. Diagramme, Infografiken) → ausführliche Beschreibung (bis zu 200 Wörter), z. B. als Link oder direkt darunter

🖱️ Steuerelemente & Formulare (z. B. Buttons, Icons) → klare textuelle Funktion (z. B. aria-label=“Löschen“)

🎥 Zeitbasierte Medien (z. B. Videos, Livestreams, Audios) → kurze Beschreibung mit Zweck und Inhalt

🔐 CAPTCHAs → erklärender Text + barrierefreie Alternative (z. B. Audio-CAPTCHA)

Keine Textalternative (aber korrekt gekennzeichnet) für:

🖼️ Dekorative Inhalte → mit alt=““ oder nur via CSS einbinden

HTML/ARIA/Sonstiges-Beispiel – Kurz & Einfach:

Deep Link Understanding (english)

🎧🎞 Ohne Bild braucht’s Text, ohne Ton braucht’s Beschreibung.

Was ist zu tun?

Bereitstellung einer Textbeschreibung für ein aufgezeichnetes Video ohne Ton, Bereitstellung einer Textalternative für reine Audio-Dateien (z.B. Podcast)

Check- Detail
Nur-Audio-Inhalte (z. B. Podcasts):

• Es muss ein vollständiges Transkript vorhanden sein, das den gesamten Informationsgehalt wiedergibt.

Nur-Video-Inhalte (ohne Ton):

• Es muss entweder eine textliche Beschreibung oder ein zusätzlicher Audiotrack vorhanden sein, der die visuellen Inhalte erklärt.

HTML/ARIA/Sonstiges-Beispiel – Kurz & Einfach

• Bereitstellung eines Transkripts für Audioinhalte

Deep-Link Original WCAG Understanding: Understanding 1.2.1

Ausnahmen im Gesetz / der Richtlinie:

• Gemäß § 1 Abs. 4 Nr. 1 BFSG sind die zeitbasierte Medien, die vor dem 28. Juni 2025 veröffentlicht wurden, von den Barrierefreiheitsanforderungen ausgenommen.

💬 Wenn jemand spricht, muss man’s auch lesen können.

Was ist zu tun?
Hinzufügen von Untertiteln zu einem aufgezeichneten Video mit Ton

Check- Detail:

• Für vorab aufgezeichnete Audioinhalte in Videos (z.  Sprecher, Dialoge) müssen Untertitel vorhanden sein. Diese sollen alle gesprochenen Inhalte sowie relevante Soundeffekte (z. B. [Musik spielt], [Lachen]) abdecken.

Wie prüfen?

• Spiele das Video ohne Ton ab.
• Sind alle Informationen über die Untertitel verständlich übertragbar?

Beispiel

Ein E-Learning-Video mit Sprechertext und akustischem Feedback enthält synchronisierte, vollständige Untertitel.

Technik-Tipp

• 👉 Verwende das HTML5-Element <track kind=“subtitles“ src=“…“ srclang=“de“ label=“Deutsch“> innerhalb des <video>-Tags, um Untertitel technisch korrekt einzubinden.

HTML/ARIA/Sonstiges-Beispiel – Kurz & Einfach
Verwendung von <track>-Elementen für Untertitel in <video>

Deep-Link Original WCAG Understanding: Understanding 1.2.2

Ausnahmen im Gesetz / der Richtlinie:

Gemäß § 1 Abs. 4 Nr. 1 BFSG sind die zeitbasierte Medien, die vor dem 28. Juni 2025 veröffentlicht wurden, von den Barrierefreiheitsanforderungen ausgenommen.

👁️‍🗨️ Was wichtig ist, aber nicht gesagt wird – muss beschrieben oder transkribiert sein.

Was ist zu tun?

Bereitstellung einer Audiodeskription oder einer Textalternative  für ein aufgezeichnetes Video

Check- Detail:

• Für vorab aufgezeichnete Videos mit Ton, deren visuelle Inhalte wichtig für das Verständnis sind, muss eine Audio-Deskription oder eine vollständige Textalternative (Transkript) bereitgestellt werden.

Was ist eine Audio-Deskription?

Ein zusätzlicher gesprochener Kommentar, der beschreibt, was im Bild passiert, z. B. Handlungen, Gestik, Mimik, Szenenwechsel – besonders wenn diese Inhalte nicht durch den Originalton vermittelt werden.

Alternativ möglich:

Ein ausführliches Transkript, das alle gesprochenen Inhalte + visuelle Informationen (Handlungen, Gestik, Szenen etc.) kombiniert, gilt ebenfalls als konform.

Wie prüfen?

• Enthält das Video visuelle Inhalte, die für das Verständnis notwendig sind und nicht durch den Ton abgedeckt werden?
• Ist eine Audio-Deskription oder eine kombinierte Medienalternative (Transkript) vorhanden?

Beispiel

Ein Schulungsvideo zeigt eine Maschinenbedienung ohne Erklärung im Ton. Eine Audio-Deskription oder ein Transkript beschreibt die visuellen Schritte der Bedienung.

Technik-Tipp

• 👉 Audio-Deskription kann als separate Tonspur oder in das Video eingebettet vorliegen. Für Textalternativen kann eine zusätzliche Seite oder ein Link direkt unter dem Video angeboten werden.

HTML/ARIA/Sonstiges-Beispiel – Kurz & Einfach

Bereitstellung einer separaten Audiodatei mit Beschreibungen

Deep-Link Original WCAG Understanding: Understanding 1.2.3

Ausnahmen im Gesetz / der Richtlinie

Gemäß § 1 Abs. 4 Nr. 1 BFSG sind die zeitbasierte Medien, die vor dem 28. Juni 2025 veröffentlicht wurden, von den Barrierefreiheitsanforderungen ausgenommen.

📡 Live verstehen – Untertitel an!

Was ist zu tun?

Bereitstellung von Untertiteln für einen Live-Webcast

Check- Detail

• Live-Übertragungen mit Ton (z.  Webinare, Streams) müssen Live-Untertitel bereitstellen.

Prüfen

• Unterstützt das eingesetzte Tool Live-Untertitel? (z.  Zoom, MS Teams, YouTube Live)

Beispiel
Ein Livestream nutzt automatische Untertitel oder einen Live-Schriftdolmetscher.

HTML/ARIA/Sonstiges-Beispiel – Kurz & Einfach
Echtzeit-Untertitelungsdienste für Live-Events einsetzen

Deep-Link Original WCAG Understanding: Understanding 1.2.4

🎥 Wenn Bilder mehr erzählen als Worte, braucht’s eine Beschreibung im Ton.

Was ist zu tun?
Hinzufügen einer Audiodeskription zu einem aufgezeichneten Video

Check- Detail:

• Für vorab aufgezeichnete Videos mit Ton muss eine eingefügte Audio-Deskription vorhanden sein, wenn wichtige visuelle Informationen nicht im Originalton vermittelt werden.

Prüfen

• Wird im Video z.  eine Handlung gezeigt, aber nicht erklärt?
• Gibt es eine zusätzliche Tonspur oder Version mit integrierter Audio-Deskription?

Beispiel
Ein Schulungsvideo zeigt Abläufe, ohne dass sie im Sprechertext erklärt werden – die Audio-Deskription beschreibt diese Abläufe zusätzlich im Ton.

Hinweis zur Technik
👉 Audio-Deskription kann als separate Spur oder in einer alternativen Videoversion mit eingebetteter Beschreibung angeboten werden.

HTML/ARIA/Sonstiges-Beispiel – Kurz & Einfach
Integration von Audiodeskriptionen in die Videodatei

Deep-Link Original WCAG Understanding: Understanding 1.2.5

Ausnahmen im Gesetz / der Richtlinie
Gemäß § 1 Abs. 4 Nr. 1 BFSG sind die zeitbasierte Medien, die vor dem 28. Juni 2025 veröffentlicht wurden, von den Barrierefreiheitsanforderungen ausgenommen

🧩 Was zusammengehört, muss auch im Code auch zusammengehören.

Was ist zu tun?
Verwendung von Tags zur Strukturierung von Inhalten

Check- Detail

• Strukturelle und inhaltliche Beziehungen müssen programmatisch erkennbar sein – also auch für Screenreader und andere Hilfsmittel verständlich.

Was heißt das konkret?

• Überschriften, Listen, Tabellen, Formulare, ARIA-Rollen müssen korrekt im Code ausgezeichnet sein.
• Visuelle Beziehungen (z.  durch Layout oder Farbe) müssen auch semantisch abgebildet werden.

Prüfen

• ✅ Nutze Screenreader oder Tools wie WAVE, um zu prüfen, ob Inhalte korrekt strukturiert sind.
• ✅ Teste: Werden z.  Feldbeschriftungen vorgelesen? Ist die Überschriftenhierarchie sauber?

Beispiele

• Eine visuell hervorgehobene Zwischenüberschrift muss ein echtes <h2> sein nicht nur fett.
• Formularfelder brauchen ein zugeordnetes <label>.
• Tabellen müssen th für Überschriftenzellen verwenden.

Technik-Tipp
👉 Verwende sauberes HTML (z. B. <ul>, <h1>–<h6>, <label>, <table>, ARIA-Attribute), um Strukturen und Beziehungen korrekt abzubilden.

HTML/ARIA/Sonstiges-Beispiel – Kurz & Einfach <h1>Hauptüberschrift</h1><h2>Unterüberschrift</h2>

🔧 Optionaler Hinweis für Fortgeschrittene:
Zusätzlich zur Verwendung von HTML-Strukturelementen kannst du mit ARIA-Rollen wie role=“form“, role=“region“ oder role=“complementary“ semantische Beziehungen weiter präzisieren. Das unterstützt Screenreader dabei, die Struktur der Seite besser zu vermitteln – insbesondere bei dynamischen Inhalten oder komplexeren Layouts.

Deep-Link Original WCAG Understanding: Understanding 1.3.1

🔄 Wie’s aussieht, so soll’s auch vorgelesen werden.

Was ist zu tun?
Sicherstellung, dass der Inhalt in einer sinnvollen Reihenfolge präsentiert, wird

Check- Detail

• Der Inhalt muss in einer sinnvollen Reihenfolge im Code stehen, sodass er auch beim Navigieren mit Tastatur oder Screenreader logisch verständlich bleibt.

Was heißt das konkret?

• Die visuelle Reihenfolge der Inhalte muss sich auch im Quellcode oder DOM widerspiegeln.
• Keine Layout-Tricks (z.  CSS-Positionierung oder Tabindex-Manipulation), die den Lesefluss verwirren.

Prüfen

✅ Navigiere mit der Tab-Taste oder einem Screenreader durch die Seite:

• Kommt der Text in der erwarteten Reihenfolge?
• Sind Navigation, Inhalte, Formulare logisch aufgebaut?

Beispiele

• Zwei Spalten im Layout: Visuell links = zuerst im Code.
• In einem Formular folgt das Eingabefeld direkt nach der zugehörigen Beschriftung.
• Keine Sprünge im Fokus durch unlogisches tabindex.

Technik-Tipp
👉 Halte die Struktur im HTML so nah wie möglich an der visuellen Darstellung. Nutze keine CSS-Tricks, die die Reihenfolge im Quelltext verändern.

HTML/ARIA/Sonstiges-Beispiel – Kurz & Einfach
Verwendung von <div> und CSS anstelle von Tabellen für Layouts

Deep-Link Original WCAG Understanding: Understanding 1.3.2

🧠 Form, Farbe oder Position allein reichen nicht – beschreib, was gemeint ist!

Was ist zu tun?
Vermeidung von Anweisungen, die sich ausschließlich auf sensorische Merkmale beziehen (z. B. „Klicken Sie auf den grünen Knopf“)

Check- Detail

• Anleitungen oder Hinweise dürfen nicht nur auf sensorische Merkmale wie Farbe, Form, Position, Größe oder Klang verweisen.
• Es muss eine ergänzende textliche Beschreibung geben, die für alle Nutzer verständlich ist – unabhängig von ihrer Wahrnehmung.

Was heißt das konkret?
❌ „Klicken Sie auf den roten Button“

✅ „Klicken Sie auf den roten Button mit der Aufschrift ‚Absenden‘“

❌ „Felder mit Stern markieren Pflichtangaben“

✅ „Pflichtfelder sind mit * gekennzeichnet (alle Pflichtfelder sind: Name, E-Mail …)“

Prüfen

• Kommen in Anleitungen ausschließlich visuelle oder auditive Hinweise vor?
• Ist die Bedeutung auch ohne Wahrnehmung dieser Merkmale klar?

Technik-Tipp
👉 Ergänze sensorische Hinweise immer durch eindeutigen Text oder semantische Markierungen (z. B. aria-label, title, sichtbare Beschriftung).

HTML/ARIA/Sonstiges-Beispiel – Kurz & Einfach
Anweisungen wie „Klicken Sie auf die Schaltfläche ‚Senden'“ verwenden

Deep-Link Original WCAG Understanding: Understanding 1.3.3

📱 Dreh mich, wenn du willst – nicht, weil du musst.

Was ist zu tun?
Unterstützung sowohl von Hoch- als auch Querformat auf mobilen Geräten.

Check- Detail

• Die Seiteninhalte müssen auch in anderer Ausrichtung (z.  Hoch- oder Querformat) nutzbar sein – ohne dass die Funktionalität verloren geht oder Nutzer gezwungen werden, das Gerät zu drehen.

Prüfen

• Funktioniert die Seite sowohl im Hoch- als auch im Querformat?
• Wird der Nutzer nicht gezwungen, das Gerät in eine bestimmte Richtung zu halten?

Ausnahme
Inhalte mit fester Ausrichtung aus funktionalen Gründen (z. B. digitale Wasserwaage, Spielkonsole) sind ausgenommen.

HTML/ARIA/Sonstiges-Beispiel – Kurz & Einfach
Vermeidung von orientation-Lock in CSS oder JavaScript

Deep-Link Original WCAG Understanding: Understanding 1.3.4

📝 Wenn du weißt, was reinkommt – sag’s dem Code!

Was ist zu tun?
Kennzeichnung von Formularfeldern mit Autocomplete-Attributen

Check- Detail

• Bei Formularfeldern muss der Zweck der Eingabe programmatisch erkennbar sein, wenn es sich um personenbezogene Daten handelt (z.  Name, E-Mail, Adresse, Telefonnummer).
• Damit können Browser und assistive Technologien Autovervollständigung oder personalisierte Eingabehilfen bereitstellen.

Technik-Tipp
👉 Nutze autocomplete-Attribute gemäß HTML-Standard (z. B. autocomplete=“email“, autocomplete=“given-name“).

Prüfen

• Sind Formularfelder für Name, E-Mail, Adresse usw. korrekt mit autocomplete versehen?
• Funktioniert Autovervollständigung in modernen Browsern?

HTML/ARIA/Sonstiges-Beispiel – Kurz & Einfach
<input type=“text“ name=“vorname“ autocomplete=“given-name“>

Deep-Link Original WCAG Understanding: Understanding 1.3.5

🎨 Farbe ist schön – aber nicht allein verständlich!

Was ist zu tun?
Sicherstellen, dass Informationen nicht ausschließlich durch Farbe vermittelt werden

Check- Detail

• Informationen dürfen nicht ausschließlich durch Farbe vermittelt werden.
• Es muss eine zusätzliche Kennzeichnung geben, z.  durch Text, Symbole oder Muster.

Was heißt das konkret?
❌ „Felder mit rotem Rand sind Pflichtfelder“

✅ „Pflichtfelder sind rot markiert und mit * gekennzeichnet“

❌ „Klicke auf die grüne Schaltfläche, um fortzufahren“

✅ „Klicke auf die grüne Schaltfläche mit dem Text ‚Weiter‘“

Prüfen

• Werden Inhalte auch ohne Farbe verständlich?
• Simuliere Farbblindheit oder drucke in Graustufen.

Technik-Tipp
👉 Ergänze farbliche Hinweise mit Text, Icons oder ARIA-Labels.

HTML/ARIA/Sonstiges-Beispiel – Kurz & Einfach
Wenn ein Fehler in einem Formularfeld rot markiert wird, füge eine Fehlermeldung oder ein Symbol (z. B. ein rotes Ausrufezeichen) hinzu.

Deep-Link Original WCAG Understanding: Understanding 1.4.1

🔊 Wenn’s klingt, muss man’s stoppen können.

Was ist zu tun?
Automatisch abgespielte Audiodatei, die länger als 3 Sekunden dauert, sollte eine Pause- oder Stopp-Funktion bieten.

Check- Detail

• Wenn Audio automatisch länger als 3 Sekunden abgespielt wird, muss der Nutzer es anhalten, pausieren oder die Lautstärke regeln können – unabhängig von der Systemlautstärke.

Was heißt das konkret?

❌ Eine Website startet Musik beim Laden – ohne Stoppmöglichkeit

✅ Ein eingebetteter Audio-Player bietet Pause/Stopp-Button

Prüfen

• Läuft irgendwo automatisch Audio ab?
• Gibt es Steuerelemente, um es zu stoppen oder leiser zu stellen?

Technik-Tipp
👉 Vermeide Autoplay bei Audio oder nutze standardkonforme Player mit Steuerungselementen.

HTML/ARIA/Sonstiges-Beispiel – Kurz & Einfach
<audio src=“audio.mp3″ controls></audio>

Deep-Link Original WCAG Understanding: Understanding 1.4.2

🌗 Wenn man’s kaum lesen kann, ist es nicht barrierefrei.

Was ist zu tun?
Text auf Hintergrund hat ein Kontrastverhältnis von mindestens 4,5:1.

Check- Detail
Text (inkl. Text in Bildern) muss einen ausreichenden Kontrast zum Hintergrund haben:

• Normaler Text: mindestens 4,5:1
• Großer Text (ab 18pt oder 14pt fett): mindestens 3:1

Ausnahmen

• Logos oder rein dekorative Texte

Prüfen

Nutze Tools wie:

• Silktide Accessibility Checker

Technik-Tipp
👉 Achte auf gute Lesbarkeit bei allen Lichtverhältnissen. Nutze CSS color und background-color mit hohem Kontrast.

HTML/ARIA/Sonstiges-Beispiel – Kurz & Einfach
CSS: color: #000000; background-color: #FFFFFF;

Deep-Link Original WCAG Understanding: Understanding 1.4.3

Ausnahmen im Gesetz / der Richtlinie
Gemäß Erfolgskriterien des WCAG Standards: Logos oder dekorative Texte fallen nicht unter diese Regelung!

👓 Wer größer liest, soll nicht stolpern.

Was ist zu tun?
Text kann um bis zu 200 % vergrößert werden, ohne dass Inhalte oder Funktionen verloren gehen.

Check- Detail

• Text muss ohne Funktionsverlust auf bis zu 200 % vergrößert werden können – ohne horizontales Scrollen (bei Fließtext) und ohne Inhalte oder Funktionen zu verlieren.

Prüfen

• Vergrößere den Text in den Browsereinstellungen oder mit Strg + / Cmd +
• Bleibt alles lesbar und benutzbar?

Ausnahme
Nur wenn Layoutbedingt unvermeidbar (z. B. interaktive Tabellen oder Karten mit begrenztem Platz)

Technik-Tipp
👉 Verwende relative Einheiten wie em, rem oder % für Schriftgrößen in CSS, statt feste Pixelangaben (px).

HTML/ARIA/Sonstiges-Beispiel – Kurz & Einfach
Verwende relative Einheiten wie em oder % für Schriftgrößen in CSS.

Deep-Link Original WCAG Understanding: Understanding 1.4.4

🖋️ Wenn du’s lesen kannst, mach’s als Schrift – nicht als Bild.

Was ist zu tun?
Vermeidung der Verwendung von Bildern anstelle von Text, um Informationen zu vermitteln.

Check- Detail

• Vermeide Text in Bildern, wenn der gleiche visuelle Effekt auch mit echtem Text und CSS erreicht werden kann.

Warum?
👉 Bilder von Text können nicht skaliert, vorgelesen oder angepasst werden – echter Text schon.

Ausnahmen

• Logos / Markennamen
• Gestalterisch notwendige Fälle, z.  bei bestimmten dekorativen Schriften, die nicht über CSS darstellbar sind

Prüfen

• Wird Text als Bild eingebunden, obwohl er auch als HTML/CSS darstellbar wäre?
• Skaliert oder verhält sich der Text wie „echter“ Text?

Beispiel
❌ Ein Button ist ein PNG mit Text

✅ Der Button ist HTML mit CSS-gestyltem Text

Technik-Tipp
👉 Nutze Webfonts & CSS-Effekte statt statischer Textgrafiken.

HTML/ARIA/Sonstiges-Beispiel – Kurz & Einfach
Statt eines Bildes mit Text: <h1>Überschrift</h1> mit CSS für Stil.

Deep-Link Original WCAG Understanding: Understanding 1.4.5

📱 Wenn’s aufs Handy passt, passt’s auch zur WCAG.

Was ist zu tun?
Inhalte sind bei einer Bildschirmbreite von 320 CSS-Pixeln ohne horizontales Scrollen lesbar.

Check- Detail

• Inhalte müssen bei Viewport-Breite von 320 px (z.  Smartphone) ohne horizontales Scrollen nutzbar sein.
• Kein Verlust von Informationen oder Funktionen beim Umbruch auf kleinen Bildschirmen.

Was heißt das konkret?

• Layout muss responsiv sein
• Inhalte sollen sich umschichten oder umbrechen, nicht abgeschnitten werden
• Scrollen vertikal ist okay, horizontal (bei Fließtext) nicht

Prüfen

• Browserfenster auf Mobilbreite verkleinern (320 × 256 px)
• Ist alles lesbar, bedienbar, ohne zur Seite scrollen zu müssen?

Technik-Tipp
👉 Nutze responsive CSS (Media Queries, Flexbox, Grid)
👉 Vermeide feste Breiten in Pixeln (width: 1200px)
👉 Verwende relative Einheiten (%, em, rem)

HTML/ARIA/Sonstiges-Beispiel – Kurz & Einfach
Verwende responsive Design-Techniken wie flexibles Layout und Medienabfragen.

Deep-Link Original WCAG Understanding: Understanding 1.4.10

🎯 Auch was kein Text ist, muss sichtbar sein.

Was ist zu tun?
Bedienelemente und grafische Objekte haben ein Kontrastverhältnis von mindestens 3:1 gegenüber angrenzenden Farben.

Check- Detail

• Grafische Bedienelemente und visuelle Indikatoren (z.  Icons, Umrandungen, Fokusrahmen) müssen einen Mindestkontrast von 3:1 zum angrenzenden Hintergrund haben.

Was ist betroffen?

• Icons (z.  Suchlupe, Papierkorb)
• Umrandungen von Formularfeldern, Buttons
• Fokusindikatoren (z.  sichtbarer Rahmen beim Tab-Fokus)
• Diagramm-Linien, Legenden, Statusanzeigen

Was ist nicht betroffen?

• Dekorative Elemente
• Text selbst (das regelt 1.4.3)

Prüfen

• Hat das Icon/Element mindestens 3:1 Kontrast zum Hintergrund?
• Tools wie Silktide, WAVE, WebAIM Contrast Checker oder axe DevTools helfen bei der Analyse.

Technik-Tipp
👉 Achte bei SVGs, Icons, Borders und Buttons auf Farbwahl & Kontrastwerte
👉 Fokusrahmen in CSS: outline-color, outline-width und :focus-visible clever nutzen

HTML/ARIA/Sonstiges-Beispiel – Kurz & Einfach
CSS: border: 2px solid #000000; für Schaltflächenrahmen.

Deep-Link Original WCAG Understanding: Understanding 1.4.11

🧑‍🎨 Typografie ist nur barrierefrei, wenn sie sich entfalten darf.

Was ist zu tun?
Benutzer können Zeilenhöhe, Absatzabstand, Zeichenabstand und Wortabstand anpassen, ohne dass Inhalte unlesbar werden.

Check- Detail
Text muss lesbar und funktionsfähig bleiben, wenn der Nutzer die folgenden Abstände verändert:

• Zeilenhöhe (line-height): mind. 1.5 × Schriftgröße
• Absatzabstand: mind. 2 × Schriftgröße
• Buchstabenabstand (letter-spacing): mind. 0.12 × Schriftgröße
• Wortabstand (word-spacing): mind. 0.16 × Schriftgröße

Was heißt das konkret?

• Wenn der Nutzer per CSS/Browser die Abstände verändert, darf nichts überlappen, verschwinden oder unbenutzbar werden.

Prüfen

• Mit benutzerdefiniertem CSS-Stil testen, z.  über den Browser-Inspektor oder eine Testdatei mit obigen Werten
• Text bleibt vollständig lesbar und verschiebt keine UI-Elemente

Technik-Tipp
👉 Vermeide feste Höhen oder harte overflow: hidden-Regeln
👉 Teste mit echten Nutzer-Stylesheets oder Accessibility-Tools

HTML/ARIA/Sonstiges-Beispiel – Kurz & Einfach
CSS sollte Anpassungen wie line-height: 1.5; und letter-spacing: 0.12em; unterstützen.

Deep-Link Original WCAG Understanding: Understanding 1.4.12

🖱️ Was aufklappt, bleibt – bis der Nutzer es schließt.

Was ist zu tun?
Zusätzliche Inhalte, die bei Hover oder Fokus erscheinen, sind entfernbar, hoverbar und persistent.

Check- Detail
Wenn beim Hover (Maus) oder Fokus (Tastatur) zusätzlicher Inhalt erscheint (z. B. Tooltip, Hilfetext, Dropdown), dann muss dieser:

• Einblendbar sein – durch Hover oder Fokus
• Entfernbar sein – z.  durch ESC, Klick außerhalb oder Fokuswechsel
• Stabil bleiben, solange er gebraucht wird – nicht plötzlich verschwinden

Beispiele für betroffene Inhalte

• Tooltips
• Hilfe-Overlays
• eingeblendete Formulartipps
• Mouseover-Menüs oder Dropdowns

Prüfen

• Bleibt der Zusatzinhalt sichtbar, solange der Fokus da ist?
• Kann der Inhalt ohne Maus und ohne Stress wieder geschlossen werden?

Technik-Tipp
👉 Achte auf zugängliche Tooltip-Komponenten (aria-describedby, ESC-Funktion, Fokussteuerung)
👉 Vermeide, dass Inhalte sofort verschwinden, sobald die Maus sich leicht bewegt

HTML/ARIA/Sonstiges-Beispiel – Kurz & Einfach
Verwende JavaScript + ARIA, um Tooltips barrierefrei zu gestalten.

Deep-Link Original WCAG Understanding: Understanding 1.4.13

⌨️ Wenn du’s nicht mit Tab erreichst, erreichen es nicht alle.

Was ist zu tun?
Alle Funktionen einer Website sind über die Tastatur erreichbar.

Check- Detail

• Alle Funktionen müssen vollständig mit der Tastatur bedienbar sein – ohne Maus oder Touch.

Prüfen

• Ist alles mit Tab, Enter, Pfeiltasten erreichbar und nutzbar?

Typische Fehlerquellen
❌ Buttons, die nur auf Mausklick reagieren
❌ Individuelle Komponenten ohne Tastaturfokus 

Technik-Tipp
👉 Verwende semantische HTML-Elemente (<button>, <a>, <input>)
👉 Achte auf sichtbaren Fokus und Tastatur-Events (keydown, keypress)

HTML/ARIA/Sonstiges-Beispiel – Kurz & Einfach
Verwende tabindex=“0″, um nicht-standardisierte HTML-Elemente (z. B. <div>, <span>) in die natürliche Tab-Reihenfolge aufzunehmen.

Deep-Link Original WCAG Understanding: Understanding 2.1.1

🚪 Wer ein Feld betritt, muss es auch wieder verlassen können.

Was ist zu tun?
Ein Benutzer kann mit der Tabulatortaste in ein Formularfeld gelangen und es mit Shift+Tab wieder verlassen.

Check- Detail
Nutzer müssen mit der Tastatur aus jedem Element oder Bereich wieder heraus navigieren können – es darf keine „Falle“ entstehen, in der man stecken bleibt.

Was heißt das konkret?

• Fokus darf nicht in einem Element hängen bleiben (z.  Modal, Custom Widget)
• Der Nutzer muss jederzeit mit Tab oder ESC weiter navigieren oder schließen können

Prüfen

• Kannst du mit Tab/Shift+Tab in alle Richtungen navigieren – rein und wieder raus?
• Bei Overlays: Lässt sich der Fokus gezielt wieder verlassen?

Typische Fehlerquellen
❌ Modale Dialoge ohne Fokussteuerung
❌ Eingebettete Widgets ohne Escape-Mechanismus

Technik-Tipp
👉 Verwende tabindex=“0″ für Custom-Komponenten
👉 Implementiere Fokus-Fallen kontrolliert, z. B. bei Modals – aber mit ESC oder Close-Button

HTML/ARIA/Sonstiges-Beispiel – Kurz & Einfach
Sicherstellen, dass keine Elemente den Fokus dauerhaft belegen.

Deep-Link Original WCAG Understanding: Understanding 2.1.2

🕹️ Einzeltasten brauchen Absicht – nicht nur Berührung.

 Was ist zu tun?
Ein Schaltfläche kann durch Drücken der Enter-Taste aktiviert werden.

Check- Detail
Funktionen, die durch eine einzelne Taste oder Berührung ausgelöst werden (z. B. Tastenkürzel, Sprachsteuerung, Touch), müssen absichtlich bedienbar sein – durch eine dieser Möglichkeiten:

• Abschaltbar
• Anpassbar (z.  andere Taste wählbar)
• Zweifach-Bestätigung nötig (z.  durch Halten oder Doppeltippen)

Warum?

➡️ Schutz vor versehentlichem Auslösen, z. B. durch Sprachsoftware, motorische Einschränkungen oder Fehleingaben

Prüfen

• Löst eine einzelne Taste (z.  „Z“) sofort eine Aktion aus?
• Gibt es eine Möglichkeit, das zu deaktivieren oder absichern?

Typische Fälle
❌  keydown = delete() ohne Nachfrage
✅  Halten von „Löschen“-Taste für 1 Sekunde, bevor Aktion erfolgt

Technik-Tipp:
👉 Vermeide direkte Aktionen auf keydown für einzelne Buchstaben oder Ziffern
👉 Nutze Modifier (z. B. Ctrl + …) oder Nachfrage/Bestätigung 

HTML/ARIA/Sonstiges-Beispiel – Kurz & Einfach
Verwende sichere Tastenkombinationen mit Modifiern (z. B. Ctrl, Alt, Shift) oder frage bei Einzeltasten nach einer Bestätigung per Klick oder Halten. 

Deep-Link Original WCAG Understanding: Understanding 2.1.4

⏳ Zeit darf nicht gegen den Nutzer arbeiten.

Was ist zu tun?
Ein Benutzer kann die Zeit für das Ausfüllen eines Formulars verlängern.

Check- Detail
Wenn Nutzer*innen innerhalb einer Zeitspanne etwas tun müssen (z. B. Eingaben abschließen, bestätigen), muss mindestens eine der folgenden Optionen gegeben sein:

• Abschalten / Anpassen / Warnen + Verlängern

Was heißt das konkret?

• Bei Sitzungs-Timeouts, Quiz-Zeiten, Formularabläufen o. Ä. muss der Nutzer die Kontrolle behalten

Prüfen

• Gibt es ein Zeitlimit?
• Kann man es verlängern, anpassen oder abschalten?

Typische Fälle
❌ Ein Formular läuft nach 2 Minuten ab – ohne Warnung
✅ Ein Hinweis erscheint nach 1:30 min: „Benötigen Sie mehr Zeit?“

Technik-Tipp
👉 Verwende modale Dialoge mit Verlängerungsoption
👉 Vermeide starre Zeitlimits – oder gib Nutzer*innen Kontrolle darüber

HTML/ARIA/Sonstiges-Beispiel – Kurz & Einfach
Mechanismus bereitstellen, um Zeitlimits zu deaktivieren oder zu verlängern.

Deep-Link Original WCAG Understanding: Understanding 2.2.1

Ausnahmen im Gesetz / der Richtlinie
Gemäß WCAG Erfolgskriterien: „Tests mit zeitlichen Anforderungen sind zulässig, wenn das Zeitlimit zum Bewertungszweck gehört (z. B. Reaktion unter Zeitdruck, Wissensabfrage, Prüfungsbedingungen).“

🛑 Was sich bewegt, braucht auch mal ’ne Pause.

Was ist zu tun?
Ein automatisch abspielendes Karussell kann vom Benutzer angehalten werden.

Check- Detail
Für bewegte, blinkende oder automatisch aktualisierende Inhalte, die länger als 5 Sekunden sichtbar sind, muss der Nutzer sie:

• Pausieren, Anhalten (Stopp) oder Dauerhaft ausblenden können. 

Was ist betroffen?

• Automatische Karussells / Slider
• Scrollende Texte (z.  Marquee)
• Animationen oder blinkende Hinweise
• Echtzeit-Feeds mit Auto-Update

Prüfen

• Gibt es Inhalte, die sich ohne Interaktion bewegen?
• Gibt es eine Möglichkeit zum Pausieren, Anhalten oder Ausblenden?

Ausnahme
Wenn die Bewegung essenziell für die Funktion ist (z. B. Echtzeit-Spiel oder Live-Video), gilt die Regel nicht.

Technik-Tipp
👉 Stelle bei Karussells z. B. ein Pause-Button, Play/Stopp-Steuerung oder ein aria-live=“off“ bereit
👉 Vermeide unkontrollierbare Animationen in CSS (animation, marquee)

HTML/ARIA/Sonstiges-Beispiel – Kurz & Einfach
„Pause“- oder „Stopp“-Schaltflächen für bewegte Inhalte bereitstellen.

Deep-Link Original WCAG Understanding: Understanding 2.2.2

Ausnahmen im Gesetz / der Richtlinie
Gemäß WCAG Erfolgskriterien: „Wenn die Bewegung essenziell für die Funktion ist (z. B. Echtzeit-Spiel oder Live-Video), gilt die Regel nicht.“

⚡ Wenn’s blitzt, dann höchstens dreimal – und nie gefährlich.

Was ist zu tun?
Ein Video enthält keine schnell blinkenden Lichteffekte.

Check- Detail

• Kein Inhalt darf mehr als drei Blitze pro Sekunde enthalten, wenn das Blitzen hell/dunkel-Kontraste erzeugt und einen Bereich von mehr als 25 % der Bildschirmfläche betrifft. 

Warum?

• Um das Risiko von epileptischen Anfällen bei empfindlichen Nutzer*innen (z.  Photosensibilität) zu vermeiden.

Prüfen

• Gibt es blinkende, blitzende oder flackernde Inhalte?
• Ist die Frequenz unter 3x/Sekunde?

Typische Fehlerquellen
❌ Werbeanimationen, Ladeeffekte, Effekte auf Mouseover
✅ Leichte Hervorhebungen mit sanften Übergängen oder max. 3x blinken

Technik-Tipp
👉 Verwende CSS-Animationen mit sanften transition-Effekten statt flash, flicker, rapid toggle
👉 Simuliere Animationen im Prototyp mit Tools (z. B. Lighthouse, Accessibility Insights)

HTML/ARIA/Sonstiges-Beispiel – Kurz & Einfach
Vermeide Inhalte, die mehr als dreimal pro Sekunde blinken. 

Deep-Link Original WCAG Understanding: Understanding 2.3.1

⏩ Was sich wiederholt, darf übersprungen werden.

Was ist zu tun?
Ein „Zum Inhalt springen“-Link ermöglicht es Benutzern, die Navigation zu überspringen.

Check- Detail

• Nutzer*innen müssen wiederkehrende Inhalte wie Navigationsmenüs, Header oder Filterleisten überspringen können, um direkt zum Hauptinhalt zu gelangen.

Was heißt das konkret?

• Besonders für Tastaturnutzer wichtig, um nicht jedes Mal durch das gesamte Menü zu tabben.

Prüfen

• Gibt es einen sichtbaren oder unsichtbaren Link wie „Zum Inhalt springen“?
• Funktioniert dieser per Tastatur (Tab + Enter)?

Technik-Tipp
👉 Stelle sicher, dass der Skip-Link sichtbar wird beim Fokus (z. B. per :focus)
👉 Nutze ein semantisch korrektes <main>-Element oder id=“main-content“

HTML/ARIA/Sonstiges-Beispiel – Kurz & Einfach
<a href=“#main-content“ class=“skip-link“>Zum Inhalt springen</a>

Deep-Link Original WCAG Understanding: Understanding 2.4.1

📘 Yes, we do judge the page by its title.

Was ist zu tun?
Der Titel einer Seite beschreibt deren Inhalt eindeutig.

Check- Detail

• Jede Seite muss einen aussagekräftigen, eindeutigen Titel im <title>-Element haben, der den Inhalt oder Zweck der Seite beschreibt. 

Warum?

• Screenreader lesen den Titel als Erstes vor
• Er erscheint im Browsertab, in Lesezeichen und Suchergebnissen

Prüfen

• Ist im HTML <title>…</title> gesetzt?
• Beschreibt der Titel klar, worum es auf der Seite geht?

Beispiel
❌ <title>Start</title>
✅ <title>Produkte – einfach.barrierefrei</title>

Technik-Tipp
👉 Dynamisch generieren mit Templates oder JavaScript
👉 Struktur: [Seitenzweck] – [Markenname] ist bewährt

HTML/ARIA/Sonstiges-Beispiel – Kurz & Einfach <title>Seitenüberschrift – Website-Name</title> im <head>-Bereich verwenden.

Deep-Link Original WCAG Understanding: Understanding 2.4.2

🧭 Der Fokus soll führen, nicht verwirren. 

Was ist zu tun?
Die Tab-Reihenfolge folgt der logischen Reihenfolge der Inhalte.

Check- Detail

• Die Reihenfolge der Tastaturfokus-Navigation (z.  mit Tab) muss logisch und sinnvoll dem visuellen/inhaltlichen Aufbau der Seite entsprechen.

Was heißt das konkret?

• Der Fokus springt nicht chaotisch durch die Seite
• Der Nutzer kann einem sinnvollen Lesefluss folgen – Navigation → Hauptinhalt → Footer etc.

Prüfen

• Tab-Taste durch die Seite → folgt der Fokus der sichtbaren Struktur?
• Keine Sprünge in versteckte Bereiche oder irrelevante Inhalte?

Typische Fehlerquellen
❌ Manuelles tabindex-Chaos (tabindex=“99″)
❌ Fokus springt in ausgeblendete Elemente oder Modal ohne Steuerung 

Technik-Tipp
👉 Nutze tabindex=“0″ für Custom-Elemente, aber vermeide positive Werte (tabindex=“1″ und höher)
👉 Verwende HTML in der richtigen Reihenfolge, nicht nur visuell sortiert per CSS

HTML/ARIA/Sonstiges-Beispiel – Kurz & Einfach

• Nutze tabindex=“0″, um benutzerdefinierte Elemente (z.  Dialoge, Widgets) in die Tastaturnavigation einzubinden.
• Verzichte auf positive tabindex-Werte – sie unterbrechen die logische Fokusreihenfolge.

Deep-Link Original WCAG Understanding: Understanding 2.4.3

🔗 Ein guter Link verrät, wohin er führt – auch alleinstehend.

Was ist zu tun?
Ein Link mit dem Text „Mehr erfahren“ wird durch umgebenden Text oder aria-label näher erläutert.

Check- Detail

• Der Zweck eines Links muss erkennbar sein, entweder durch den Linktext selbst oder durch den umgebenden Kontext (z.  in Listen, Sätzen oder Tabellen).

Was heißt das konkret?

• Links wie „hier klicken“ oder „mehr“ sind nicht ausreichend, außer der Kontext macht den Zweck eindeutig.

Prüfen

• Würde ein Screenreader-Nutzer nur die Links durchgehen (Linkliste) – wäre der Zweck klar?

Typische Fehlerquellen
❌ „Hier klicken“
❌ „Mehr erfahren“ ohne Bezug
✅ „Mehr erfahren über unser Barrierefreiheits-Angebot“

Technik-Tipp
👉 Nutze klare Linktexte oder ergänze per aria-label oder title
👉 Vermeide identische Linktexte bei unterschiedlichem Ziel

HTML/ARIA/Sonstiges-Beispiel – Kurz & Einfach
aria-label=“Details zum Thema Barrierefreiheit“ für Links verwenden. 

Deep-Link Original WCAG Understanding: Understanding 2.4.4

🧭 Gib dem Nutzer mehr als einen Weg – nicht nur eine Tür.

Was ist zu tun?
Eine Website bietet sowohl eine Suchfunktion als auch eine Sitemap zur Navigation an.

Check- Detail

• Es muss mehr als einen Weg geben, um eine bestimmte Seite oder Funktion zu erreichen – z.  über Navigation, Suche oder Sitemap.

Was heißt das konkret?

• Nutzer sollen Inhalte nicht nur über ein einziges Menü finden müssen
• Hilfreich bei Orientierung, besonders für Nutzer mit kognitiven Einschränkungen

Prüfen

• Gibt es eine Suche, eine Sitemap, eine strukturierte Navigation oder interne Verlinkung, um Inhalte mehrfach auffindbar zu machen?

Typische Wege

• Hauptnavigation, Suche, Sitemap, Breadcrumbs, Kontextverlinkungen im Fließtext

Technik-Tipp
👉 Biete eine interne Suchfunktion oder strukturierte Navigationshilfe
👉 Stelle sicher, dass alle Hauptseiten auch über die Navigation erreichbar sind

HTML/ARIA/Sonstiges-Beispiel – Kurz & Einfach
Zusätzliche Navigationsmethoden wie Breadcrumbs oder Filter bereitstellen.

Deep-Link Original WCAG Understanding: Understanding 2.4.5

Ausnahmen im Gesetz / der Richtlinie
Gemäß WCAG Erfolgskriterien:
Bei Web-Apps mit nur einer Seite (z. B. ein Formularprozess) ist keine zusätzliche Navigation nötig.

🏷️ Sag klar, worum es geht – mit Überschrift und Label. 

Was ist zu tun?
Formularelemente sind mit klaren Labels versehen.

 Check- Detail

• Überschriften und Labels (Beschriftungen) müssen den Inhalt oder Zweck klar beschreiben.
• Sie sollen verständlich, präzise und aussagekräftig sein – ohne unnötige Kürzel oder leere Phrasen.

 Was heißt das konkret?

• Überschriften gliedern Inhalte sinnvoll und verständlich
• Formulareingaben haben klar benannte Labels
• Keine vagen Begriffe wie „Abschnitt 1“ oder „Formularfeld“

 Prüfen

• Sind alle Überschriften informativ und strukturell sinnvoll?
• Versteht man bei einem Feld-Label sofort, was eingegeben werden soll?

 Typische Fehlerquellen
❌ „Abschnitt A“ ohne Inhaltshinweis
❌ Eingabefeld ohne sichtbares oder zugeordnetes Label
✅ „E-Mail-Adresse“ statt „Feld 1“

Technik-Tipp
👉 Nutze semantisch korrekte <h1>–<h6> und <label for=“…“>
👉 Stelle sicher, dass Labels auch programmatisch verknüpft sind

HTML/ARIA/Sonstiges-Beispiel – Kurz & Einfach
<label for=“email“>E-Mail-Adresse:</label> für Eingabefelder verwenden.

Deep-Link Original WCAG Understanding: Understanding 2.4.6

🎯 Fokus muss sichtbar sein – sonst findet ihn niemand. 

Was ist zu tun?
Der aktuell fokussierte Link ist durch eine sichtbare Umrandung hervorgehoben.

Check- Detail

• Wenn ein Element fokussiert wird (z.  per Tab), muss klar erkennbar sein, welches Element den Fokus hat – visuell sichtbar.

Was heißt das konkret?

• Der Fokus darf nicht unterdrückt oder „unsichtbar“ gemacht werden
• Der Nutzer muss jederzeit sehen, wo er sich befindet

Prüfen

• Tab-Taste durch die Seite: Siehst du deutlich, welches Element gerade aktiv ist?
• Wird z.  ein Button, Link oder Eingabefeld optisch hervorgehoben?

Typische Fehlerquellen
❌ outline: none ohne Ersatz
❌ Visuelle Fokusanzeige nur durch Farbänderung mit zu wenig Kontrast
✅ Klar sichtbare Umrandung, Schatten, Animation o. ä.

Technik-Tipp
👉 Vermeide outline: none oder ersetze es durch eine deutlich sichtbare Alternative
👉 Nutze z. B. :focus-visible mit kontraststarkem Rand oder Schatten

HTML/ARIA/Sonstiges-Beispiel – Kurz & Einfach
CSS verwenden: :focus { outline: 2px solid #000; }.

Deep-Link Original WCAG Understanding: Understanding 2.4.7

🫣 Wer den Fokus hat, darf nicht im Verborgenen liegen 

Was ist zu tun?
Der Fokus eines Elements wird nicht von einer fixierten Kopf- oder Fußzeile verdeckt.

Check- Detail

• Wenn ein Element den Tastaturfokus erhält (z.  beim Tabben), darf es nicht vollständig vom sichtbaren Bereich verdeckt sein – z. B. durch fixe Header, Sticky-Footer oder überlagernde UI-Elemente.

Was heißt das konkret?

• Mindestens ein Teil des fokussierten Elements muss auf dem Bildschirm sichtbar bleiben, damit Nutzer*innen es wahrnehmen und verstehen können.

Prüfen

• Tabbe durch die Seite: Wird der Fokus jemals vollständig verdeckt, z.  hinter Navigation, Popups oder modalen Overlays?

Typische Fehlerquellen
❌ Fokus springt auf ein Element unter einem Sticky-Header
❌ Popup erscheint über dem Fokus-Element
✅ Fokus bleibt sichtbar – z. B. durch automatisches Scrollen oder Puffer- Abstand

Technik-Tipp
👉 Verwende scroll-margin-top bei Fokuszielen unter fixen Elementen
👉 Teste mit :focus-visible und Tastaturnavigation, besonders auf mobilen Geräten 

HTML/ARIA/Sonstiges-Beispiel – Kurz & Einfach
Vermeide fixierte Elemente mit position: fixed, die den fokussierten Inhalt überlagern. Nutze stattdessen position: sticky, damit sich der Inhalt beim Scrollen besser mitbewegt.

Deep-Link Original WCAG Understanding: Understanding 2.4.11

👆 Wischen ist nett – aber Tippen ist Pflicht. 

Was ist zu tun?
Eine Wischgeste kann alternativ durch einfaches Tippen ausgelöst werden.

Check- Detail

• Funktionen, die mehr als einen Zeigereingabepunkt oder komplexe Gesten (z.  Wischen, Ziehen, Zusammenziehen) erfordern, müssen auch mit einem einfachen Klick oder Tippen bedienbar sein.

Was heißt das konkret?

• Nutzer dürfen nicht gezwungen sein, Drag & Drop, Mehr-Finger-Gesten oder Wischbewegungen zu verwenden.

Beispiele
❌ Inhalt kann nur durch Zweifinger-Zoom vergrößert werden
❌ Ein Element kann nur durch Drag & Drop verschoben werden
✅ Alternativ gibt es Buttons oder Kontextmenüs, die dieselbe Funktion bieten

Prüfen

• Gibt es für jede Geste auch eine einfache, klick- oder tippbare Alternative?
• Ist Drag & Drop auch über Tastatur oder Buttons bedienbar?

Technik-Tipp
👉 Ergänze Drag & Drop durch Greifen- und Ablegen-Buttons
👉 Vermeide Pflicht-Gesten für kritische Funktionen

HTML/ARIA/Sonstiges-Beispiel – Kurz & Einfach
Einfache Tipp-Alternativen für komplexe Gesten bereitstellen.

Deep-Link Original WCAG Understanding: Understanding 2.5.1

Ausnahmen im Gesetz / der Richtlinie
Gemäß Erfolgskriterien des WCAG Standards:
Wenn die komplexe Geste essenzieller Bestandteil der Funktion ist (z. B. in einem Malprogramm), gilt die Regel nicht.

🖱️ Erst loslassen, dann auslösen. 

Was ist zu tun?
Ein Drag-and-Drop-Vorgang kann durch Drücken der Escape-Taste abgebrochen werden.

Check- Detail

• Aktionen dürfen nicht sofort beim Drücken (Pointer Down) ausgeführt werden, sondern erst bei Loslassen (Pointer Up) – damit Nutzer*innen die Möglichkeit haben, die Aktion abzubrechen.

Was heißt das konkret?

• Bei Klick, Touch oder Drag-Aktionen darf die Funktion nicht schon beim ersten Antippen ausgelöst werden
• Der Nutzer muss durch Loslassen oder Wegbewegen (z.  Finger weggleiten) die Aktion verhindern können

Beispiele
❌ „Kaufen“-Button löst sofort beim Touch-Start die Bestellung aus
✅ Aktion wird erst ausgelöst, wenn der Finger wieder losgelassen wird

Prüfen

• Wird die Aktion erst bei „Pointer Up“ ausgelöst?
• Kann man den Finger oder Cursor wegbewegen, um den Vorgang abzubrechen?

Technik-Tipp
👉 Verwende mouseup, touchend oder click – nicht mousedown / touchstart
👉 Für Buttons: immer auf click reagieren, nicht auf pointerdown

HTML/ARIA/Sonstiges-Beispiel – Kurz & Einfach
Ereignisse bei pointerup statt pointerdown auslösen.

Deep-Link Original WCAG Understanding: Understanding 2.5.2

Ausnahmen im Gesetz / der Richtlinie
Gemäß Erfolgskriterien des WCAG Standards gibt es Ausnahmen:

• Wenn die Funktion nur durch Halten, Ziehen oder Bewegung ausgelöst wird (z.  Schieberegler)
• Wenn die Aktion nicht rückgängig gemacht werden muss

🗣️ Was man sieht, muss man auch sagen können. 

Was ist zu tun?
Ein Button mit sichtbarem Text „Senden“ hat auch den zugänglichen Namen „Senden“.

Check- Detail

• Wenn ein Element einen sichtbaren Text oder eine Beschriftung hat (z.  ein Button), dann muss dieser Text auch im zugänglichen Namen (z. B. aria-label) enthalten sein.

Was heißt das konkret?

• Sichtbarer Text und programmatischer Name müssen übereinstimmen oder sich überschneiden
• Wichtig für Nutzer:innen von Sprachsteuerung und Screenreadern 

Prüfen

• Ist der sichtbare Text Teil des aria-label, alt oder title?
• Kann der Nutzer das Element mit dem sichtbaren Begriff auch per Sprache aufrufen?

Typische Fehlerquellen
❌ aria-label=“Fortfahren“ bei Button mit sichtbarem Text „Weiter“
✅ aria-label=“Weiter zur nächsten Seite“ bei Button „Weiter“ 

Technik-Tipp
👉 Nutze aria-label oder aria-labelledby, die den sichtbaren Text nicht ersetzen, sondern erweitern
👉 Einheitliche Begriffe verbessern Usability + Sprachbedienung

HTML/ARIA/Sonstiges-Beispiel – Kurz & Einfach
aria-label=“Senden“ entsprechend dem sichtbaren Text setzen.

Deep-Link Original WCAG Understanding: Understanding 2.5.3

🌀 Bewegung darf eine Option sein – aber nie die einzige. 

Was ist zu tun?
Eine Funktion, die durch Schütteln des Geräts ausgelöst wird, kann alternativ über eine Schaltfläche aktiviert werden.

Check- Detail

• Wenn eine Funktion durch Bewegung des Geräts oder des Nutzers (z.  Neigen, Schütteln, Gesten) aktiviert wird, muss es auch eine alternative Bedienmöglichkeit ohne Bewegung geben.

Was heißt das konkret?

• Nutzer dürfen nicht auf Bewegungseingaben angewiesen sein – z.  bei Geräten mit Bewegungssensoren (Smartphones, Tablets)
• Funktionen müssen auch durch Tippen, Klicken oder andere Eingaben verfügbar sein

Prüfen

• Wird eine Funktion nur durch Neigen, Schütteln oder Drehen ausgelöst?
• Gibt es eine Alternative (z.  Button oder Schieberegler)?

Typische Fehlerquellen
❌ Formular wird durch Schütteln gelöscht – ohne Rückgängig-Button
❌ AR-Anwendung nur per Drehen steuerbar
✅ „Schütteln zum Löschen“ + Button „Löschen rückgängig machen“

Technik-Tipp
👉 Nutze motionEvent nur in Kombination mit Touch-/Click-Ersatz
👉 Erlaube die Deaktivierung von Bewegungseingaben in den Einstellungen

HTML/ARIA/Sonstiges-Beispiel – Kurz & Einfach
Bereitstellung einer Schaltfläche mit onclick-Event als Alternative zur Bewegungsgesteuerten Funktion.

Deep-Link Original WCAG Understanding: Understanding 2.5.4

Ausnahmen im Gesetz / der Richtlinie
Gemäß Erfolgskriterien des WCAG Standards gibt es Ausnahmen:
Wenn die Bewegung essenzieller Bestandteil der Funktion ist (z. B. Schrittzähler), ist keine Alternative nötig

🧲 Was du ziehen kannst, solltest du auch klicken können.

Was ist zu tun?
Eine Drag-and-Drop-Funktion bietet eine Alternative durch Tasten oder Klicks.

Check- Detail

• Wenn eine Funktion per Drag & Drop (Ziehen und Ablegen) ausgeführt wird, muss es auch eine Alternative ohne Ziehen geben – z.  per Klick, Tap oder Tastatur.

Was heißt das konkret?

• Nutzer dürfen nicht gezwungen sein zu ziehen, wenn es auch anders geht
• Das hilft Menschen mit motorischen Einschränkungen oder assistiven Technologien

Prüfen

• Ist eine Aktion nur durch Ziehen möglich?
• Gibt es auch eine klickbare oder schrittweise Alternative?

Typische Fehlerquellen
❌ Nur Drag & Drop zum Sortieren von Elementen
❌ Dateien lassen sich nur per Ziehen hochladen
✅ Zusätzliche Buttons: „Nach oben“, „Verschieben nach…“, „Datei auswählen“

Technik-Tipp
👉 Ergänze Drag & Drop durch bedienbare Alternativen
👉 Verwende aria-dropeffect, Tastatursteuerung oder einfache Schaltflächen

HTML/ARIA/Sonstiges-Beispiel – Kurz & Einfach
Füge eine „Klicken-um-zu-verschieben“-Alternative hinzu: <button onclick=“moveItem()“>Verschieben</button>

Deep-Link Original WCAG Understanding: Understanding 2.5.7

👆 Wer treffen soll, braucht Platz zum Zielen.

Was ist zu tun?
Interaktive Ziele wie Buttons und Links sind mindestens 24×24 CSS-Pixel groß.

Check- Detail

• Interaktive Elemente wie Buttons, Links oder Icons müssen mindestens 24 × 24 CSS-Pixel groß sein – oder ausreichend Abstand zu anderen Zielen haben.

Was heißt das konkret?

• Klick- und Touchziele dürfen nicht zu klein oder zu eng platziert sein
• Nutzer*innen müssen Ziele leicht treffen können, auch mit motorischen Einschränkungen

Prüfen

• Ist jedes interaktive Ziel mindestens 24×24 px groß oder 24 px von anderen Zielen entfernt?

Typische Fehlerquellen
❌ Kleine Icons direkt nebeneinander
❌ Textlinks im Fließtext ohne Abstand
✅ Buttons mit großzügigem Padding oder Abstand

Technik-Tipp
👉 Verwende ausreichend padding oder margin, um die Zielgröße zu erreichen
👉 Teste mit den Chrome DevTools: „Accessibility → Touch target size“

HTML/ARIA/Sonstiges-Beispiel – Kurz & Einfach
CSS: Stelle sicher, dass interaktive Elemente groß genug sind: button { min-width: 24px; min-height: 24px; }.

Deep-Link Original WCAG Understanding: Understanding 2.5.8

🗣️ Nur wer die Sprache kennt, liest auch richtig vor.

 Was ist zu tun?
Die Standardsprache einer Webseite ist im HTML-Tag angegeben.

Check- Detail: Anforderung

• Die Standardsprache der Seite muss im HTML-Element korrekt angegeben sein – z.  Deutsch, Englisch, Französisch usw.

Was heißt das konkret?

• Screenreader und andere Hilfsmittel erkennen so Aussprache, Betonung und Lesefluss
• Ohne korrekte Spracheinstellung werden Texte falsch vorgelesen

Prüfen

• Enthält das <html>-Element ein korrektes lang-Attribut?
• Entspricht es der tatsächlichen Sprache des Inhalts?

Typische Fehlerquellen
❌ lang=“en“ auf einer Seite mit deutschem Inhalt
❌ Kein lang-Attribut gesetzt
✅ <html lang=“de“> für eine deutschsprachige Seite

HTML/ARIA/Sonstiges-Beispiel – Kurz & Einfach
<html lang=“de“>

Deep-Link Original WCAG Understanding: Understanding 3.1.1

🌍 Sprache wechseln heißt auch: das HTML informieren. 

Was ist zu tun?
Absätze in einer anderen Sprache sind entsprechend gekennzeichnet. 

Check- Detail

• Wenn ein Textabschnitt in einer anderen Sprache als der Hauptsprache der Seite erscheint, muss diese Sprache programmgesteuert gekennzeichnet werden – z.  per lang-Attribut.

Was heißt das konkret?

• Screenreader wechseln sonst nicht in die korrekte Aussprache
• Besonders wichtig für Zitate, Begriffe, Menüpunkte oder Namen in Fremdsprachen

Prüfen

• Gibt es Wörter, Sätze oder Abschnitte in einer anderen Sprache?
• Wurde für diese Teile ein lang-Attribut gesetzt?

Typische Fehlerquellen
❌ „Click here“ in deutschem Fließtext ohne lang=“en“
❌ Zitat in Französisch ohne Sprachkennzeichnung
✅ <span lang=“en“>Save changes</span>

Technik-Tipp
👉 Nutze lang=“xx“ direkt im HTML-Element (z. B. span, div)
👉 lang=“en“, lang=“fr“, lang=“tr“ usw. – gemäß BCP 47 Sprachcodes 

HTML/ARIA/Sonstiges-Beispiel – Kurz & Einfach
 <p lang=“en“>This is an English paragraph.</p>

Deep-Link Original WCAG Understanding: Understanding 3.1.2

👁️ Fokus ist Orientierung – kein Auslöser.

Was ist zu tun?
Ein Formularfeld erhält den Fokus, ohne dass sich der Kontext ändert.

Check- Detail

• Wenn ein Element den Fokus erhält (z.  durch Tab), darf das nicht automatisch eine wesentliche Änderung auf der Seite auslösen – z. B. Navigation, Absenden, Öffnen eines Fensters.

Was heißt das konkret?

• Nutzer*innen sollen sich gefahrlos mit der Tastatur orientieren können
• Der Fokus darf keine Aktion erzwingen – das passiert erst beim Klick oder Bestätigen

Prüfen

• Führt der reine Fokus (z.  durch Tabben) zu keinem automatischen Wechsel 

Typische Fehlerquellen
❌ Dropdown-Menü springt sofort zur neuen Seite beim Fokus
❌ Formular wird beim Fokus auf ein Feld automatisch gesendet
✅ Aktionen werden erst bei aktivem Klick oder Enter ausgelöst

Technik-Tipp
👉 Verwende keine Event-Handler auf focus, die Inhalte verändern
👉 Nutze click, change, keydown – nicht onfocus für Aktionen

HTML/ARIA/Sonstiges-Beispiel – Kurz & Einfach
Vermeide automatische Kontextänderungen beim Fokussieren von Elementen.

Deep-Link Original WCAG Understanding: Understanding 3.2.1

📝 Eingabe darf nichts erzwingen – nur anbieten. 

Was ist zu tun?
Das Ändern einer Auswahl in einem Dropdown-Menü führt nicht automatisch zu einer Kontextänderung.

Check- Detail

• Wenn Nutzer*innen eine Eingabe tätigen (z.  ein Formularfeld ausfüllen, eine Auswahl treffen), darf das nicht automatisch zu einer wesentlichen Änderung der Seite führen – ohne Vorwarnung.

Was heißt das konkret

• Die Eingabe selbst darf nicht sofort Navigation, Absenden oder Umleitungen auslösen
• Es muss eine Bestätigungsmöglichkeit geben, bevor etwas passiert

Prüfen

• Wird bei Änderung eines Felds direkt eine neue Seite geladen oder etwas gesendet?
• Gibt es eine explizite Schaltfläche zur Bestätigung?

Typische Fehlerquellen
❌ Auswahl eines Dropdowns löst sofort Seitenwechsel aus
❌ Checkbox aktiviert sofort eine neue Ansicht
✅ Aktion erfolgt erst nach Klick auf „Weiter“ oder „Bestätigen“

Technik-Tipp
👉 Verwende onchange oder input nur für nicht-kritische Reaktionen
👉 Nutze für alles, was den Zustand der Seite verändert, einen Bestätigungs-Button

HTML/ARIA/Sonstiges-Beispiel – Kurz & Einfach
Verwende keine automatischen Formularübermittlungen bei Eingabeänderungen.

Deep-Link Original WCAG Understanding: Understanding 3.2.2

🧭 Was sich wiederholt, soll sich gleich verhalten.

Was ist zu tun?
Navigationsmenüs sind auf allen Seiten einer Website in derselben Reihenfolge angeordnet.

Check- Detail

• Wird eine Navigationskomponente (z.  Hauptmenü, Footer-Links) auf mehreren Seiten wiederholt, muss sie immer in der gleichen Reihenfolge und Struktur erscheinen.

Was heißt das konkret?

• Die Navigation soll vorhersehbar sein – keine Sprünge, Umstellungen oder wechselnde Menüelemente
• Hilft besonders Menschen mit kognitiven Einschränkungen und Screenreader-Nutzer*innen

Prüfen

• Bleiben Navigationselemente auf allen Seiten konsistent?
• Sind z.  Menüpositionen und Seitenstruktur gleich?

Typische Fehlerquellen
❌ Menüpunkt wechselt auf Unterseiten die Position
❌ Footer-Navigation zeigt plötzlich andere Links
✅ Einheitliche Navigation über alle Seiten hinweg

Technik-Tipp
👉 Arbeite mit Templates oder Komponenten, um Navigation wiederverwendbar und einheitlich zu halten
👉 Änderungen im Menü sollten klar begründet und bewusst gestaltet sein

HTML/ARIA/Sonstiges-Beispiel – Kurz & Einfach
Stelle sicher, dass die Navigationsstruktur auf allen Seiten konsistent ist.

Deep-Link Original WCAG Understanding: Understanding 3.2.3

🔁 Gleiche Funktion – gleicher Name. 

Was ist zu tun?
Schaltflächen mit derselben Funktion haben auf allen Seiten denselben Text.

Check- Detail

• Wenn eine Funktion mehrfach vorkommt (z.  Suchen, Teilen, Speichern), muss sie immer gleich benannt sein – unabhängig davon, wo sie erscheint.

Was heißt das konkret?

• Gleiche Funktionen brauchen gleiche Namen, Icons oder Beschriftungen
• Das erhöht Verlässlichkeit und Orientierung – besonders für Screenreader- und Sprachsteuerungs-Nutzer

Prüfen

• Wird dieselbe Aktion überall gleich bezeichnet?
• Gibt es widersprüchliche Beschriftungen für dieselbe Funktion?

Typische Fehlerquellen
❌ „Zur Kasse“ auf einer Seite, „Bezahlen“ auf einer anderen
❌ Zwei Buttons mit gleicher Funktion, aber unterschiedlichen Namen
✅ Einheitlich benannte Buttons und Links für wiederkehrende Funktionen

Technik-Tipp
👉 Arbeite mit komponentenbasierten Bezeichnungen (Designsystem, UI-Kits)
👉 Halte eine Sprachregelung für UI-Texte fest (z. B. „Speichern“ statt „Sichern“)

HTML/ARIA/Sonstiges-Beispiel – Kurz & Einfach
Verwende für wiederkehrende Funktionen konsistente Bezeichnungen.

Deep-Link Original WCAG Understanding: Understanding 3.2.4

🧩 Hilfe wirkt – wenn man sie findet.

Was ist zu tun?
Hilfefunktion wird an einer konsistenten Stelle platziert und überall gleich benannt.

Check- Detail

• Wenn auf mehreren Seiten eine Hilfefunktion angeboten wird, muss diese an einer konsistenten Stelle platziert und gleich benannt sein.

Was heißt das konkret?

• Nutzer*innen sollen Hilfe leicht finden, unabhängig davon, auf welcher Seite sie sich befinden
• Das umfasst z.  Kontakt-Links, Chat-Support, Tooltips, Hilfeboxen, FAQs

Prüfen

• Wird auf mehreren Seiten Hilfe angeboten?
• Ist die Hilfe immer an derselben Position (z.  im Footer)?
• Wird sie gleich bezeichnet?

Typische Fehlerquellen
❌ Auf Seite A: „Hilfe“ im Footer – auf Seite B: „Support“ im Men
❌ Auf einer Seite Live-Chat, auf der nächsten nur ein Kontaktformular
✅ Einheitlicher „Hilfe“-Link im Footer oder Header auf allen relevanten Seiten

Technik-Tipp
👉 Platziere Hilfeangebote über Templates oder Komponenten an einer festen Stelle
👉 Verwende konsistente Begriffe wie „Hilfe“, „Kontakt“ oder „Support“

HTML/ARIA/Sonstiges-Beispiel – Kurz & Einfach
Platziere Hilfeangebote über Templates oder Komponenten an einer festen Stelle

Deep-Link Original WCAG Understanding: Understanding 3.2.6

🚫 Ein Fehler ist nur halb so wild – wenn man ihn versteht.

Was ist zu tun?
Bei fehlerhafter Formulareingabe wird eine Textmeldung angezeigt, die den Fehler beschreibt. 

Check- Detail

• Wenn ein Eingabefehler auftritt (z.  Pflichtfeld vergessen, ungültige Eingabe), muss der Fehler klar beschrieben und identifiziert werden.

Was heißt das konkret?

• Nutzer*innen müssen verstehen, was falsch war – und wo
• Fehlerhinweise müssen in Textform erfolgen (nicht nur visuell)

Prüfen

• Werden Fehler beim Absenden erkannt und verständlich erklärt?
• Gibt es eine textliche Rückmeldung in der Nähe des Feldes?

Typische Fehlerquellen
❌ Nur rote Rahmen ohne Text
❌ Fehlermeldung ohne Bezug zum Feld
✅ Text wie: „Bitte geben Sie Ihre E-Mail-Adresse im Format name@domain.de ein“

Technik-Tipp
👉 Nutze aria-describedby oder aria-invalid für Screenreader-Unterstützung
👉 Stelle sicher, dass Fehlermeldungen sichtbar und fokussierbar sind

HTML/ARIA/Sonstiges-Beispiel – Kurz & Einfach
<span class=“error“>„Bitte geben Sie Ihre E-Mail-Adresse im Format name@domain.de ein“.</span> 

Deep-Link Original WCAG Understanding: Understanding 3.3.1

💬 Ein Feld ohne Beschriftung ist wie eine Frage ohne Fragezeichen.

Was ist zu tun?
Formularfelder sind mit klaren Labels versehen, die die erwartete Eingabe beschreiben.

Check- Detail

• Wenn Nutzer*innen Eingaben machen müssen, sollen sie klar erkennbare Beschriftungen oder Anleitungen erhalten, um die Eingabe korrekt vorzunehmen.

Was heißt das konkret?

• Eingabefelder müssen verständlich benannt sein
• Komplexere Eingaben brauchen ggf. eine Anleitung oder ein Beispiel

Prüfen

• Ist jedes Eingabefeld mit einem klaren Label versehen?
• Gibt es ggf. Hinweise zu Format, Pflichtfeldern oder erwarteten Angaben?

Typische Fehlerquellen
❌ Kein sichtbares Label oder nur Platzhaltertext
❌ Unklare Begriffe wie „Wert eingeben“
✅ „E-Mail-Adresse“ als Label + Hinweis: „Format: name@domain.de“

Technik-Tipp
👉 Verwende <label for=“…“> und stelle eine programmatische Verknüpfung zum Eingabefeld her
👉 Nutze aria-describedby für zusätzliche Anleitungen 

HTML/ARIA/Sonstiges-Beispiel – Kurz & Einfach
<label for=“email“>E-Mail-Adresse:</label><input type=“email“ id=“email“>

Deep-Link Original WCAG Understanding: Understanding 3.3.2

🧩 Nicht nur meckern, dass es falsch ist – auch zeigen wie’s richtig geht. 

Was ist zu tun?
Bei einer falschen Eingabe wird nicht nur der Fehler angezeigt, sondern auch eine Empfehlung zur Korrektur gegeben.

Check- Detail

• Wenn Nutzer*innen einen Eingabefehler machen und das System den Fehler erkennt, soll es einen Vorschlag machen, wie man den Fehler beheben kann.

Was heißt das konkret?

• Es reicht nicht aus zu sagen, dass etwas falsch ist
• Das System muss helfen, es richtig zu machen

Prüfen

• Werden konkrete Hinweise oder Korrekturvorschläge gegeben?

Typische Fehlerquellen
❌ „Ungültig“ ohne weiteren Kontext
❌ „Fehler in Eingabe“ ohne Hilfe
✅ „Bitte geben Sie eine gültige E-Mail-Adresse im Format name@domain.de ein“

Technik-Tipp
👉 Verwende klare Fehlermeldungen mit Formatvorgaben, Beispielen oder Eingabehilfen
👉 Kombiniere mit aria-describedby zur Anzeige ergänzender Hilfetexte

HTML/ARIA/Sonstiges-Beispiel – Kurz & Einfach
 <span class=“error“>Das Passwort muss mindestens 8 Zeichen lang sein und eine Zahl enthalten.</span>

Deep-Link Original WCAG Understanding: Understanding 3.3.3

📄 Wichtige Entscheidungen verdienen eine zweite Chance. 

Was ist zu tun?
Vor dem endgültigen Absenden eines Formulars wird eine Zusammenfassung zur Überprüfung angezeigt.

Check- Detail
Bei rechtlich verbindlichen, finanziellen oder datenschutzrelevanten Vorgängen muss eine der folgenden Möglichkeiten gegeben sein:

• Der Nutzer kann Eingaben überprüfen und korrigieren,
• oder erhält eine Bestätigungsmöglichkeit vor dem Absenden,
• oder es gibt eine Rückgängig-Funktion.

Was heißt das konkret?

• Schützt vor versehentlichen oder folgenschweren Aktionen, wie Kaufabschlüssen, Vertragsannahmen oder Datenübermittlungen.

Prüfen

• Gibt es einen Zwischenschritt zur Kontrolle oder Bestätigung?
• Können eingegebene Daten korrigiert oder die Aktion widerrufen werden?

Typische Fehlerquellen
❌ Abschluss eines Kaufs ohne Kontrollseite
❌ „Jetzt kaufen“ ohne Rückfrage oder Rückgängigmöglichkeit
✅ „Prüfen & Bestätigen“-Seite, „Bearbeiten“-Button, „Stornieren“-Option

Technik-Tipp
👉 Implementiere zusätzliche Schritte wie Vorschau, Zusammenfassung oder Prüfseite
👉 Biete Bearbeiten-/Zurück-/Abbrechen-Funktionen vor dem Absenden

HTML/ARIA/Sonstiges-Beispiel – Kurz & Einfach
Biete eine Bestätigungsseite an, auf der Nutzer ihre Eingaben überprüfen können, bevor sie diese absenden. 

Deep-Link Original WCAG Understanding: Understanding 3.3.4

🔁 Einmal reicht – was bekannt ist, muss man nicht nochmal eintippen.

Was ist zu tun?
Wenn du in einem mehrstufigen Formular bereits deine Adresse eingegeben hast, sollte das Formular diese Information in späteren Schritten automatisch ausfüllen oder dir die Möglichkeit bieten, die zuvor eingegebenen Daten zu bestätigen, anstatt sie erneut einzugeben.

Check- Detail

• Wenn Nutzer*innen Informationen bereits eingegeben oder zur Verfügung gestellt haben, müssen sie diese nicht erneut eingeben, sofern es technisch möglich ist, sie automatisch zu übernehmen oder auszuwählen.

Was heißt das konkret?

• Vermeide doppelte Eingabe derselben Information
• Verringere kognitive Belastung und Aufwand – besonders bei Formularen mit mehreren Schritten

Prüfen

• Werden bereits eingegebene Daten erneut abgefragt?
• Gibt es die Möglichkeit, frühere Eingaben automatisch zu übernehmen?

Typische Fehlerquellen
❌ Adresse muss mehrfach eingegeben werden (Lieferadresse = Rechnungsadresse)
❌ Gleiche Kontaktinformationen in zwei Schritten neu ausfüllen
✅ Vorausgefüllte Felder oder Auswahl: „Lieferadresse entspricht Rechnungsadresse“

Technik-Tipp
👉 Nutze lokale Zwischenspeicherung (z. B. Session oder DOM)
👉 Biete Checkboxen wie: „Gleiche wie oben“ oder wähle bereits bekannte Werte aus

HTML/ARIA/Sonstiges-Beispiel – Kurz & Einfach
Implementiere Mechanismen, die zuvor eingegebene Informationen speichern und in nachfolgenden Schritten automatisch einfügen.

Deep-Link Original WCAG Understanding: Understanding 3.3.7

🔓 Ein Login darf nicht zum Denkspiel werden.

Was ist zu tun?
Bei der Anmeldung auf einer Website sollte es alternative Methoden zur Passwort-Eingabe geben, die keine komplexen Anforderungen an das Erinnerungsvermögen stellen, wie z. B. die Möglichkeit, einen „Magic Link“ per E-Mail zu erhalten oder biometrische Authentifizierung zu nutzen.  Die Minimum Anforderung ist rein kognitive Prüfschritte zu vermeiden z.b. auch durch Support von Passwort Managern. 

Check- Detail

• Nutzer*innen dürfen nicht gezwungen werden, sich ausschließlich über kognitive Tests (z.  Puzzles, Bilderrätsel, Gedächtnisaufgaben) zu authentifizieren – es sei denn, eine alternative barrierefreie Methode ist verfügbar.

Was heißt das konkret?

• Authentifizierung muss ohne komplexe mentale Aufgaben möglich sein
• Login z.  über Passwort-Manager, Gerätekennung oder passwortlose Verfahren 

Prüfen

• Wird für den Login eine erinnerungsbasierte Aufgabe verlangt, z.  Passwort + zusätzliches Bilderrätsel?
• Gibt es eine Alternative, z.  „Login mit Gerät“, E-Mail-Code, biometrisch?

Typische Fehlerquellen
❌ Pflicht zur Eingabe eines Passworts, das nicht eingefügt werden kann
❌ Kein Zugang ohne CAPTCHA oder Bildervergleich
✅ Unterstützt Passwortmanager, Copy & Paste, Login-Links oder biometrische Verfahren

Technik-Tipp
👉 Erlaube Kopieren/Einfügen und Nutzung von Passwortmanagern
👉 Biete passwortlose Alternativen oder Zweitkanäle (z. B. Login-Link per E-Mail)

HTML/ARIA/Sonstiges-Beispiel – Kurz & Einfach
Biete alternative Authentifizierungsmethoden an, die keine komplexen Passwörter erfordern, wie z. B. Einmalcodes per E-Mail oder biometrische Verfahren.

Deep-Link Original WCAG Understanding: Understanding 3.3.8

🎛️ Name, Rolle, Wert – damit Technik weiß, was Sache ist. 

Was ist zu tun?
Buttons haben programmatisch definierte Rollen und Namen,
 z. B. <button aria-label=“Suche“>.

 Check- Detail

• Benutzeroberflächenelemente (z.  Formulare, Buttons, Widgets) müssen eine programmatisch erkennbare Bezeichnung (Name), Rolle und ggf. einen aktuellen Wert haben, die für assistive Technologien verfügbar sind.

Was heißt das konkret?
➡️ Screenreader & Co. müssen wissen:

• Was ist das? (z.  Rolle = Button)
• Wie heißt es? (z.  Name = „Suche“)
• Welcher Zustand gilt? (z.  aktiviert/deaktiviert, ausgewählt)

Prüfen

• Haben Custom-Komponenten passende role-Attribute?
• Ist ein Name (aria-label, label, alt etc.) vorhanden?
• Werden Zustände wie „ausgewählt“ korrekt übermittelt? 

Typische Fehlerquellen
❌ Eigene Steuerelemente ohne ARIA oder semantisches HTML
❌ Buttons als <div> ohne Rolle oder Name
✅ Verwendung von nativen HTML-Elementen oder korrekter ARIA-Spezifikation

Technik-Tipp
👉 Nutze möglichst semantisches HTML (<button>, <input>)
👉 Bei Custom-Widgets: role, aria-label, aria-checked, aria-expanded

HTML/ARIA/Sonstiges-Beispiel – Kurz & Einfach
Nutze ARIA-LiNutze ARIA-Attribute wie aria-label, aria-labelledby oder role, um interaktive Elemente für Screenreader programmatisch benennbar und verständlich zu machen.

Deep-Link Original WCAG Understanding: Understanding 4.1.2

📣 Was sich geändert hat, muss man auch hören können.

Was ist zu tun?
Statusänderungen (z. B. „Formular erfolgreich gesendet“) werden von Screenreadern erkannt, ohne dass der Fokus geändert wird.

Check- Detail

• Statusmeldungen, die ohne Fokuswechsel erscheinen (z.  „Erfolgreich gespeichert“), müssen automatisch von Screenreadern erkannt und vorgelesen werden.

Was heißt das konkret?

• Meldungen wie Bestätigungen, Fehler oder Infos müssen programmatisch zugänglich sein, auch wenn sie nur visuell erscheinen.

Prüfen

• Wird die Statusmeldung von Screenreadern automatisch vorgelesen?
• Wird kein Fokuswechsel nötig, um sie wahrzunehmen?

Typische Fehlerquellen
❌ „Erfolgreich gespeichert“-Meldung wird angezeigt, aber nicht vorgelesen
❌ Status erscheint im div, aber ohne aria-live
✅ Meldung liegt in einem Bereich mit role=““status““ oder aria-live=““polite““

Technik-Tipp
👉 Verwende aria-live=““polite““ oder role=““status““ für Statusmeldungen
👉 Ergänze bei Bedarf aria-atomic=““true““ für vollständige Vorlesung“
👉 Verwende ARIA-Live-Regionen (aria-live=“polite“ oder aria-live=“assertive“) für dynamische Statusmeldungen, die assistiven Technologien zugänglich gemacht werden sollen.

Deep-Link Original WCAG Understanding: Understanding 4.1.3