Barrierefreie
Programmierung
Code, der allen Menschen Zugang verschafft
Barrierefreie Programmierung bedeutet, digitale Inhalte so zu entwickeln, dass sie für möglichst viele Menschen unabhängig von individuellen Fähigkeiten oder technischen Voraussetzungen zugänglich sind. Dabei geht es nicht nur um HTML und CSS, sondern auch um strukturierten Code, semantische Auszeichnung, logische Fokusführung und die richtige Anwendung von WAI-ARIA-Attributen.
Anforderungen & technische Umsetzung
Die barrierefreie Webentwicklung richtet sich nach den Vorgaben der Web Content Accessibility Guidelines (WCAG) 2.2. Im Mittelpunkt stehen vier Prinzipien: Digitale Inhalte müssen wahrnehmbar, bedienbar, verständlich und robust sein. Nachfolgend finden Sie die Anforderungen der Konformitätsstufen A und AA, die für barrierefreie Websites relevant sind.
Richtlinie 1.1: Textalternativen
Textalternativen in Form von Nicht-Text (Großschrift, Braille, gesprochene Sprache, Symbole, einfachere Sprache)
| Elementtyp | Beispiele | Erklärung | HTML-Beispiel | Zusätzlicher WCAG-Bezug |
| Grafische Elemente | Fotos, Icons, Logos | Müssen inhaltlich beschrieben werden | <img src=“logo.png“ alt=“Logo der Agentur Sichtbar.“> | 1.1.1 (A) |
| Illustrationen, die Text ergänzen | Begleitende Bilder in Artikeln | Bildinhalt oder Bildaussage beschreiben | <img src=“familie.png“ alt=“Familie am Esstisch – Thema: Ernährung im Alltag“> | 1.1.1 (A) |
| Multimedia (Live) | Live-Video, Live-Audio | Textalternative mit Funktion und Inhalt anbieten (wo möglich) | <video src=“stream.mp4″ aria-label=“Live-Übertragung der Podiumsdiskussion zum Thema Inklusion“> | 1.1.1 (A), 1.2.4 (AA) |
| Infografiken / Diagramme | Statistiken, Balkendiagramme | Alternativtext + ausführliche Langbeschreibung nötig | <img src=“umsatz.png“ alt=“Umsatzentwicklung 2023. Details siehe Beschreibung unterhalb.“> | 1.1.1 (A), 1.3.1 (A) |
| Nicht-Text-Inhalte mit Sinneserfahrung | Kunstwerke, Soundeffekte | Deskriptive Beschreibung für visuelle/akustische Erfahrung | <img src=“kunstwerk.jpg“ alt=“Abstraktes Gemälde mit kräftigen Farben in Wellenform.“> | 1.1.1 (A) |
| Steuerelemente | Icon-Buttons, Play-Schaltflächen | aria-label oder sichtbarer Text muss Zweck beschreiben | <button aria-label=“Suche starten“><img src=“lupe.svg“ alt=““></button> | 1.1.1 (A), 4.1.2 (A) |
| Links (nur Bild oder Symbol) | Bildlink zu „Kontakt“ oder „Startseite“ | Linkziel und alt-/aria-label müssen übereinstimmen | <a href=“/kontakt“ aria-label=“Kontakt aufnehmen“><img src=“kontakt-icon.svg“ alt=““></a> | 1.1.1 (A), 2.4.4 (A) |
| Buttons & Widgets (nur grafisch) | Slider-Pfeile, Play-Button | Funktion verständlich benennen | <button aria-label=“Wiedergabe starten“><img src=“play.svg“ alt=““></button> | 1.1.1 (A), 4.1.2 (A) |
| CAPTCHA | Bild-/Audio-CAPTCHA | Alternative Möglichkeit + Erklärung notwendig | <img src=“captcha.jpg“ alt=“Sicherheitsabfrage: Bitte den Text eingeben“><p>Alternative: Rechenfrage: Was ist 3 + 4?</p> | 1.1.1 (A) |
Textlängen beachten
- Kurze Alternativtexte (unter ca. 80 Zeichen) gehören ins alt-Attribut.
- Längere Beschreibungen sollten mit aria-describedby, <details> oder einem Link umgesetzt werden.
Umgang mit Nicht-Text-Inhalten
- Tests und Übungen ohne sinnvolle textliche Entsprechung müssen inhaltlich beschrieben werden.
- Eingebettete Medien (z. Java, Flash) benötigen eine gleichwertige Textalternative.
Dekorative Grafiken
- Dekorative Bilder erhalten ein leeres alt=““ oder werden per CSS eingebunden.
- Dekorativer Nicht-Text sollte von Assistenztechnologien ignoriert werden können.
Ergänzende Bildbeschriftung
- Informative Bilder können zusätzlich mit <figcaption> versehen werden.
- Für SVG-Grafiken kann aria-label verwendet werden.
Barrierefreie CAPTCHA-Alternativen
- Unzugängliche CAPTCHAs vermeiden (z. verzerrte Zeichen oder klicklastige Bildrätsel).
- Empfohlene Lösungen:
- Logikfragen (screenreaderfreundlich)
- Tools wie Turnstile oder Friendly Captcha
- Honeypot + Zeitprüfung als erste Schutzmaßnahme
- Wichtig: Alternativen für verschiedene Sinneskanäle bereitstellen.
Richtlinie 1.2: Zeitbasierte Medien
Zeitbasierte Medien (Audio, Video oder kombiniert) müssen so aufbereitet sein, dass ihre wesentlichen Inhalte für alle zugänglich sind – z. B. in Form von Transkripten, Untertiteln oder Audiobeschreibungen.
| Elementtyp | Beispiele | Erklärung | HTML-Beispiel | WCAG-Bezug |
| Aufgezeichnetes Audio | Podcasts, Interviews | Texttranskript erforderlich | <audio controls aria-describedby=“transkript“> | 1.2.1 (A) |
| Aufgezeichnetes Video mit Ton | Tutorials, Vorträge | Synchronisierte Untertitel notwendig | <video controls><track kind=“subtitles“ src=“untertitel.vtt“ srclang=“de“></video> | 1.2.2 (A) |
| Synchronisierte Medien (Video + Audio) | Film mit visueller Handlung | Textalternative oder Audiodeskription erforderlich | <video aria-describedby=“beschreibung“></video> | 1.2.3 (A) |
| Live-Audio oder Live-Video | Livestream einer Veranstaltung | Live-Untertitel oder nachträgliche Bereitstellung empfohlen | <video aria-label=“Livestream der Pressekonferenz“ controls></video> | 1.2.4 (AA) |
| Aufgezeichnetes Video mit visueller Information | Schulungsvideo mit Handlungsanweisungen | Audiodeskription oder alternative Textbeschreibung | <video><track kind=“descriptions“ src=“beschreibung.vtt“ srclang=“de“></video> | 1.2.5 (AA) |
1. Untertitel und Transkripte bei Audioinhalten
- Untertitel für Audioinhalte, Podcasts (auch Geräusche, Weinen etc. muss berücksichtigt werden)
- Redaktionelle Prüfung der Untertitel
- Untertitel dürfen keine relevanten Informationen überdecken
- Kennzeichnung der Sprecher und nicht-sprachlicher Audioinhalte sowie Geräusche
2. Audiodeskription bei synchronisierten Medien
- Audiodeskription muss ggf. auch Handlungen, Darsteller, Szenenwechsel etc. enthalten
- Audiodeskription darf keine relevanten Audioinhalte überlagern
- Zeitabhängige Anweisungen berücksichtigen, z. Sprechpausen und Geräusche
3. Alternativen klar kennzeichnen
- Alternativen als solche kennzeichnen, z. Gebärdensprachfilme, Vorlesefunktion
- Videos ohne Tonspur müssen den Inhalt mit Text oder akustisch darstellen
4. Qualitätssicherung und Grenzen
- Fehlercheck durchführen
- Achtung: Es gibt aktuell keine standardisierten Verfahren für die Darstellung rein visueller Informationen in Text oder Audio – hier ist eine individuelle, redaktionelle Lösung gefragt
Richtlinie 1.3 Anpassbar
Inhalte müssen so strukturiert sein, dass sie in unterschiedlichen Darstellungsformen (z. B. per Screenreader, bei Vergrößerung oder auf mobilen Geräten) zugänglich bleiben, ohne dass dabei Informationen oder Bedeutungszusammenhänge verloren gehen.
| Elementtyp | Beispiele | Erläuterung | Programmierhinweise / Codebeispiele | WCAG-Bezug (Level) |
| Layoutelemente | Container, Grid, Flexbox, Positionierung | Struktur darf nicht ausschließlich durch visuelle Anordnung vermittelt werden | Semantische HTML5-Elemente wie <main>, <section>, <article> statt reinem <div>-Layout | 1.3.1 (A) |
| Strukturierende Elemente | Überschriften, Absätze, Listen, Tabellen | Müssen semantisch korrekt in HTML umgesetzt sein | <h1> bis <h6>, <p>, <ul>, <table> korrekt und in logischer Reihenfolge | 1.3.1 (A) |
| Formularfelder | Texteingaben, Checkboxen, Dropdowns | Müssen beschriftet sein (<label>) und idealerweise Autofill-Attribute verwenden | <label for=“email“>E-Mail</label><input id=“email“ autocomplete=“email“> | 1.3.1 (A), 1.3.5 (AA) |
| Software-Komponenten | Widgets, Java-/Flash-Elemente | Müssen alternativ zugänglich oder erklärt sein | Bei eigenen Komponenten: role, aria-label, Tastatursteuerung ergänzen; für Flash/Java Alternativen bereitstellen | 1.3.2 (A) |
| Responsive Inhalte | Webseiten, Web-Apps | Inhalte müssen in Hoch- und Querformat lesbar und bedienbar sein | Mit Media Queries und flexiblem Layout arbeiten: @media (orientation: portrait) { … } | 1.3.4 (AA) |
| Informations-vermittelnde Eigenschaften | Farbe, Ton, Größe, Form, Position | Dürfen nicht allein zur Bedeutungsvermittlung verwendet werden | Farbe mit Text oder Symbol kombinieren, z. B. nicht nur rot = Fehler, sondern auch mit aria-describedby=“error“ | 1.3.3 (A) |
Struktur in HTML korrekt abbilden
- Absätze mit <p>
- Listen mit <ul>/<ol>/<li>
- Tabellen mit <table>, <thead>, <th>, <td>
- Überschriftenhierarchie wahren: <h1> bis <h6> in logischer Reihenfolge
- HTML-Elemente nicht zweckentfremden (kein <div> als Button etc.)
Sinnvolle Reihenfolge und logische Zusammenhänge
- Inhaltliche Lesereihenfolge muss mit der Fokusreihenfolge übereinstimmen
- Wenn Reihenfolge eine Bedeutung hat, z. bei Anleitungen oder Zeitangaben, muss dies programmatisch erkennbar sein
- Screenreader sollen Zusammenhänge nachvollziehen können (z. Beschriftung + Eingabefeld)
Kein rein visuelles oder auditives Verständnis voraussetzen
- Formulierungen vermeiden wie: „Drücken Sie den roten Knopf links“
- Textbeschreibungen statt nur Farbe, Größe oder Ton zur Unterscheidung nutzen
- Sinnesmerkmale sollten immer ergänzt oder ersetzt werden (z. durch Text oder Symbol)
Orientierung & Layout-Anpassung (nur AA)
- Inhalte dürfen nicht auf eine bestimmte Bildschirmorientierung festgelegt werden (Portrait/Landscape) – außer bei funktionaler Notwendigkeit
- Inhalte müssen auch bei Zoom, Skalierung oder Umfluss (Responsivität) verständlich bleiben
- Komponenten müssen bei Vergrößerung von Screenreadern unterschieden und lokalisiert werden können.
Formulare barrierefrei gestalten
- Jedes Eingabefeld mit einem <label> verknüpfen
- autocomplete-Attribute nutzen, um Nutzer, Screenreader und Passwortmanager zu unterstützen
- autocomplete=“given-name“ für Vorname
- autocomplete=“email“ für E-Mail-Adresse
- Autofill-Werte bei Formularen: Mehrere Varianten für Namenseingabe möglich.
Komplexe Komponenten ergänzen oder erklären
- Programme mit eigener Oberfläche (wie Java oder Flash) haben keine eingebaute Verständlichkeit für Screenreader, man muss sie zusätzlich erklären – zum Beispiel durch Texte oder Alternativen
- Hervorhebungen, die nicht direkt mit HTML umgesetzt werden können, mit ARIA-Attributen beschreiben (aria-label, aria-describedby, aria-live), damit Screenreader die Bedeutung erfassen können
Richtlinie 1.4. Unterscheidbar
Inhalte müssen klar vom Hintergrund unterscheidbar, vergrößerbar und gestaltbar sein, ohne dass Funktion oder Inhalt verloren geht. Visuelle und auditive Informationen müssen so dargestellt sein, dass sie auch bei individuellen Anpassungen wahrnehmbar bleiben.
| Elementtyp | Beispiele | Erklärung | Programmierhinweise / Codebeispiele | WCAG-Bezug (Level) |
| Hervorhebungen | Farbiger Text, Markierungen | Farbliche Hervorhebungen müssen zusätzlich durch Text oder andere visuelle Merkmale unterstützt werden | Ergänze z. B. Icons oder Textlabel: <span class=“highlight“>Wichtig</span> + Symbol | 1.4.1 (A) |
| Kontraste – Text | Fließtext, Menüpunkte, Buttons | Kontrastverhältnis mind. 4,5:1 für normalen Text, 3:1 für großen Text | Nutze Tools wie contrast-ratio.comCSS z. B. color: #111; background: #fff; | 1.4.3 (AA) |
| Kontraste – UI-Elemente / Grafiken | Icons, Eingabefelder, Linien | Visuelle Merkmale (Rahmen, Linien) müssen sich mind. 3:1 vom Hintergrund abheben | Kontraste prüfen für Fokus-Rahmen, Pfeile, Icons etc. mit WCAG-Kontrastchecker | 1.4.11 (AA) |
| Temporäre Inhalte | Tooltips, Hover-Boxen, Dropdowns | Müssen dauerhaft sichtbar oder steuerbar sein, keine rein zeitbasierten Anzeigen | JS: Tooltip darf nur bei Fokus oder Hover erscheinen, nicht automatisch verschwinden | 1.4.13 (AA) |
| Bilder von Text | Banner mit eingebettetem Text | Nur zulässig, wenn nicht anders darstellbar oder visuell anpassbar | Verwende echten Text statt Bildtext: <h1>Sommerangebot</h1> statt <img src=“headline.jpg“> | 1.4.5 (AA) |
| Multimedia-Inhalte | Videos, Animationen, Bildslider | Inhalte dürfen nicht automatisch starten; Audio muss regelbar sein | <video autoplay controls muted> → besser: kein Autoplay, Lautstärkeregelung per UI | 1.4.2 (A) |
| Auditive Inhalte | Audiohinweise, gesprochene Texte | Lautstärke muss unabhängig von Systemlautstärke regelbar sein | Implementiere eigenen Volume-Slider für Web-Audio oder Video-Element | 1.4.2 (A) |
| Zoomfähigkeit | Texte, Bilder, Navigation | Inhalte müssen bis 200 % skalierbar sein, ohne Informationsverlust | Verwende relative Einheiten (em, rem, %) statt px für Layout und Schriftgrößen | 1.4.4 (AA) |
| Umfluss / Layout-Anpassung | Responsive Design, Spaltenlayouts | Kein Scrollen in zwei Richtungen bei 320 CSS-Pixel Breite | Media Queries verwenden: @media (max-width: 320px) + Flex/Grid-Systeme | 1.4.10 (AA) |
| Textabstand | Fließtext, Absätze, Headlines | Inhalte bleiben funktional & lesbar bei nutzerdefinierter Abstandsänderung | Teste mit Browser-Plugins für „Text Spacing Override“ oder line-height, margin, letter-spacing | 1.4.12 (AA) |
| Browser-Tooltips / Hovereffekte | Hinweise, Menüs, Interaktionen | Müssen per Tastatur & Maus erreichbar und steuerbar sein | Tooltips mit aria-describedby oder aria-label, Fokus- und Hover-Events kombinieren | 1.4.13 (AA) |
Farbliche Hervorhebung
- Farbige Hervorhebungen immer mit zusätzlichem Merkmal (z. Text, Muster, Rahmen) kombinieren
- In Grafiken können Schraffuren oder Symbole unterstützend eingesetzt werden
Kontraste
- Text: mindestens 4,5:1, große Schrift 3:1
- UI/Grafik: mindestens 3:1, wenn kein Text enthalten
- Logos, Marken und dekorative Elemente sind ausgenommen
Audio und Video
- Multimedia / Audio darf nicht unmittelbar starten
- Lautstärke / Audioinhalt unabhängig von Systemlautstärke regelbar
Steuerung
- Temporäre Inhalte (z. Tooltips, Einblendungen) müssen bei Hover oder Tastaturfokus:
- sichtbar bleiben, solange der Fokus oder der Hover bestehen (nicht automatisch verschwinden)
- durch den Nutzer ausgeblendet werden können (z. mit „Esc“)
- nicht durch Bewegung des Mauszeigers entfernt werden, z. beim Wechsel zwischen Trigger und Inhalt
- Inhalte müssen per Tastatur (Fokus) UND per Maus (Hover) erreichbar sein
- Ein- und Ausblenden darf keine zusätzliche Bewegung oder Präzision erfordern
Textgröße
- Inhalte bei 1280 px Bildschirmbreite ohne Assistenztechnologie bis zu 200 % vergrößerbar ohne Einbußen bei Inhalt oder Funktionalität, d. h. keine Textüberlagerungen, abgeschnittene Texte (Ausnahmen für Bilder, nebensächlichen Text, Untertitel)
Textabstand
- Wahrnehmbarkeit ohne Beeinträchtigung von Inhalt oder Funktionalität bei folgenden nutzerseitigen Anpassungen:
- Zeilenabstand auf mind. 1,5-faches der Schriftgröße
- Abstand nach Absätzen auf mind. 2-faches der Schriftgröße
- Laufweite Buchstaben auf mind. 0,12-faches der Schriftgröße
- Wortabstand auf mind. 0,16-faches der Schriftgröße
Bilder eines Textes
- Verwendung von Alt-Text, es sei denn, das Bild ist visuell an die Anforderungen des Benutzers anpassbar
- Wort-Bild-Marken sind unentbehrlich, sie müssen wahrnehmbar gestaltet sein
Umfluss
- Browserfenster: Vergrößerung darf nicht dazu führen, dass das Layout in zwei Richtungen gescrollt werden muss (Responsivität muss gegeben sein)
- Browserfenster: Inhalt darstellbar bei 320 CSS-Pixel (horizontaler Text), 256 CSS-Pixel (vertikaler Text), Ausnahmen für interaktive Inhalte, große Tabellen und Karten
Richtlinie 2.1 Per Tastatur zugänglich
Alle Funktionalitäten auf einer Website müssen vollständig per Tastatur oder Tastaturschnittstelle bedienbar sein – ohne Maus oder Touch. Dazu zählen auch interaktive Inhalte wie Formulare, Links und Widgets. Ein-Tasten-Befehle dürfen nicht unbeabsichtigt ausgelöst werden. Tastenkürzel, die durch Spracheingabe versehentlich ausgelöst werden können, müssen abschalt- oder veränderbar sein.
| Elementtyp | Beispiele | Erklärung | HTML-Beispiel | WCAG-Bezug |
| Links | Navigation, Sprungmarken | Müssen mit Tab-Fokus erreichbar und mit Enter auslösbar sein | <a href=“#kontakt“>Zum Kontaktformular</a> | 2.1.1 (A) |
| Steuerelemente | Buttons, Formularelemente, Widgets | Per Tab und Eingabe / Leertaste zu bedienen | <button>Absenden</button> | 2.1.1 (A) |
| Interaktive eingebettete Inhalte | Modale Fenster, Mediaviewer, iFrames | Müssen per Tastatur erreichbar und wieder verlassbar sein (keine Tastaturfalle!) | <iframe src=“…“> + Fokussteuerung via JS | 2.1.2 (A) |
| Ein-Tasten-Befehle | Tastenkürzel für Web-Apps | Müssen abschaltbar oder anpassbar sein, da sie unbeabsichtigt ausgelöst werden können (z. B. durch Spracheingabe) | JS mit anpassbarem Shortcut: if (key === ’s‘) … | 2.1.4 (A) |
Tastaturzugänglichkeit
- Alle Funktionen (Navigation, Eingaben, Aktionen) müssen ohne Maus ausführbar sein
- Standardbedienung: Tab für Navigation, Enter/Leertaste für Aktivierung
- Auch interaktive Inhalte wie modale Fenster oder Dialoge dürfen keine Tastaturfallen erzeugen – Nutzer müssen sie betreten und verlassen können
Fokus-Management
- Reihenfolge des Fokusflusses muss logisch nachvollziehbar sein
- Versteckte Elemente mit Fokus (tabindex=“-1″ bei nicht sichtbarem Content) vermeiden
Ein-Tasten-Shortcuts (z. B. „S“ für Suche)
- Zeichentastenbefehle = Ein-Tastenbefehle müssen abschaltbar oder personalisierbar sein, da sie in Konflikt mit Tastenbefehlen von Assistenztechnologien stehen können
- Beispiel: Statt onkeydown = ’s‘ → nutzerdefinierbare Steuerung oder kontextabhängige Aktivierung
- Wichtig für Nutzende von Sprachsteuerung oder Screenreadern
Richtlinie 2.2 Ausreichend Zeit
Nutzer müssen ausreichend Zeit zum Lesen, Hören und Reagieren haben. Zeitbegrenzungen dürfen die Zugänglichkeit nicht einschränken – außer in Ausnahmefällen.
| Elementtyp | Beispiele | Erklärung | Programmierhinweise / Codebeispiele | WCAG-Bezug (Level) |
| Eingabeaufforderungen mit Zeitbegrenzung | Formulare, Anmeldungen, Online-Tests | Zeitlimits müssen abschaltbar, erweiterbar oder anpassbar sein | JavaScript-Timer mit Pausen- oder Verlängerungsfunktion (setTimeout, clearTimeout)Beispiel: „Sitzung läuft ab in 30 Sek. – Jetzt verlängern“ | 2.2.1 (A) |
| Multimedia / bewegte Inhalte | Slideshow, automatische Bannerrotation, Live-Ticker | Inhalte, die automatisch starten und länger als 5 Sek. laufen, müssen pausierbar, stoppbar oder ausblendbar sein | Buttons wie „Anhalten“, „Pausieren“ programmierenBeispiel: <button onclick=“stopTicker()“>Ticker stoppen</button> | 2.2.2 (A) |
| Autoplay-Videos / -Audio |
Werbung, Hintergrundmedien | Nutzer müssen die Wiedergabe stoppen oder pausieren können | Verwende autoplay nur, wenn controls gesetzt sindAlternativ: JS zum Stoppen einbinden (pause() bei <video>) | 2.2.2 (A) |
| Nicht-interaktive Animationen während Ladezeit | Spinner, Ladeanimation | Ausgenommen, wenn keine Nutzerinteraktion stattfindet | CSS/JS-Spinner z. B. <div class=“spinner“ aria-hidden=“true“>Nach Ladezeit automatisch entfernen oder mit aria-busy markieren | 2.2.2 (A) |
| Zeitkritische Anwendungen mit Fokusverlust | z. B. Auto-Logout bei Inaktivität | Dürfen nicht ohne Warnung ausgelöst werden; Reaktion muss möglich sein | Zeige modales Dialogfenster vor Logout:„Ihre Sitzung läuft ab – Jetzt verlängern?“JavaScript mit Fokus auf Bestätigungs-Button setzen | 2.2.6 (AA) |
Zeitbegrenzungen anpassbar machen
- Zeitbegrenzungen (z. bei Formularen oder Tests) müssen mindestens eine dieser Optionen bieten:
- Abschalten der Zeitbegrenzung
- Zeitbegrenzung mind. 10 x erweiterbar
- Anpassung der Zeitspanne vor Beginn
- Warnung vor Ablauf erforderlich (z. 20 Sekunden vorher)
2. Bewegte, blinkende oder automatische Inhalte steuerbar machen
- Inhalte, die automatisch starten und sich bewegen, blinken oder aktualisieren,
- müssen pausiert, gestoppt oder ausgeblendet werden können
- gelten nur, wenn sie länger als 5 Sekunden sichtbar sind
- Nicht erforderlich, wenn Inhalt für Funktion erforderlich ist (z. Echtzeit-Ticker bei Börsendaten)
3. Kontrolle über automatisch startende Medien
- Audio-/Video-Inhalte dürfen nicht automatisch starten oder
- müssen leicht pausierbar oder stoppbar sein (z. klar beschrifteter Stopp-Button)
4. Keine unerwarteten Zeitüberschreitungen bei Reaktion
- Wenn Nutzer etwas beginnen (z. ein Formular ausfüllen), dürfen zeitkritische Unterbrechungen (z. B. Logout, Neuladen) nicht ohne Möglichkeit zur Reaktion erfolgen
⚠️ Ausnahmen
Zeitbegrenzungen sind zulässig, wenn:
- es sich um ein Echtzeitereignis handelt (z. Auktion, Live-Spielstand)
- eine Verlängerung die Handlung ungültig machen würde
- die Begrenzung mehr als 20 Stunden beträgt
- das Zeitlimit zur Wahrung der Sicherheit oder Validität notwendig ist
Richtlinie 2.3 Anfälle und physische Reaktionen
Inhalte dürfen keine Gestaltungen enthalten, die Anfälle oder physische Reaktionen auslösen können – insbesondere blitzende Inhalte, die für Menschen mit photosensitiver Epilepsie gefährlich sind.
| Elementtyp | Beispiele | Erklärung | Programmierhinweise / Codebeispiele | WCAG-Bezug (Level) |
| Animationen | Visuelle Effekte, Game-Elemente, animierte Hintergründe | Dürfen nicht mehr als 3 Blitze pro Sekunde enthalten | Schnelle Farbübergänge, schnelles Flackern oder Kontrastsprünge über JS/CSS-Animationen vermeiden, Test z. B. mit PEAT (Photosensitive Epilepsy Analysis Tool) | 2.3.1 (A) |
| Multimedia | Videos, Banner, Einblendungen mit Blitzlicht-Effekten | Müssen auf blitzende Sequenzen geprüft werden | Verwende Schnittsoftware oder Videoanalyse zur Prüfung auf visuell gefährliche SequenzenStroboskopeffekte vermeiden oder unter 3 Hz halten | 2.3.1 (A) |
Vermeidung gesundheitsschädlicher Effekte
- Inhalte dürfen nicht mehr als 3 Blitze innerhalb einer Sekunde enthalten
- Gilt insbesondere für weiße, helle und rote Blitzmuster
- Dies betrifft auch Effekte, die durch Kombination von Bildern/Frames entstehen
Grenzwerte einhalten
- Blitzinhalte dürfen nur verwendet werden, wenn sie die Reaktionsschwelle für Anfälle nicht überschreiten
- Rote Blitze sind besonders kritisch und sollten grundsätzlich nicht eingesetzt werden
Achtung: Hinweistexte reichen nicht aus!
- Es genügt nicht, nur eine Warnung wie „Dieses Video enthält Blitzlichter“ einzublenden
- Die Gefahr muss technisch ausgeschlossen sein
🛠 Empfohlenes Test-Tool
- PEAT – Photosensitive Epilepsy Analysis Tool
→ Ermöglicht die Analyse von blinkenden Inhalten in Videos und Animationen gemäß WCAG 2.3.1
Richtlinie 2.4 Navigierbar
Ziel ist es, sicherzustellen, dass Menschen mit verschiedenen Einschränkungen Inhalte leicht finden und sich sinnvoll durch Seiten bewegen können – z. B. mit Tastatur, Screenreader oder anderen Assistenzsystemen.
| Elementtyp | Beispiele | Erläuterung | Programmierhinweise / Codebeispiele | WCAG-Bezug (Level) |
| Navigationsleisten | Hauptmenü, Footer-Navigation | Müssen konsistent, auffindbar und per Tastatur zugänglich sein | <nav><ul><li><a href=“/“>Start</a></li></ul></nav>Verwende <nav> für semantische Navigation | 2.4.5 (AA) |
| Skiplinks | „Springe zum Inhalt“, „Zur Navigation“ | Erlauben das Überspringen wiederholter Inhalte | <a href=“#main-content“ class=“visually-hidden focusable“>Zum Inhalt springen</a>id=“main-content“ beim Zielbereich | 2.4.1 (A) |
| Seitentitel | <title> | Muss Inhalt oder Zweck der Seite klar beschreiben | <title>Kontakt – Agentur Sichtbar</title>Steht im <head> der HTML-Datei | 2.4.2 (A) |
| Abschnitts-überschriften | <h1> bis <h6> | Müssen logisch strukturiert und eindeutig sein | Keine Sprünge in Hierarchie<h1>, dann <h2>, <h3> usw. – nicht auslassen | 2.4.10 (AA) |
| Links | Textlinks, Kontextlinks, Bildlinks | Linkzweck muss erkennbar und nicht mehrfach gleichlautend sein | Keine Links wie „Hier klicken“, sondern z. B.: <a href=“/info“>Mehr zur Barrierefreiheit</a> | 2.4.4 (A) |
| Alternative Navigationswege | Suche, Sitemap, Breadcrumbs | Inhalte müssen auf mindestens zwei Wegen auffindbar sein | <nav aria-label=“Brotkrumen“>Start > Leistungen > SEO</nav><form role=“search“> für Suchfeld | 2.4.5 (AA) |
| Fokussteuerung | Tab-Index, sichtbarer Fokus, Fokus-Reihenfolge | Fokus muss klar erkennbar, logisch und nicht verdeckt sein | CSS: :focus { outline: 2px solid #000; }Kein tabindex=“-1″ bei wichtigen Elementen | 2.4.3 (A), 2.4.7 (AA) |
| Formularelemente | Texteingaben, Auswahlfelder | Müssen eindeutig beschriftet sein | <label for=“email“>E-Mail</label><input id=“email“ type=“email“>Verwende aria-labelledby bei komplexen Strukturen | 3.3.2 (A) |
| Widgets und wiederholte Links | Slider, Akkordeons, doppelte Links | Dürfen nicht doppelt oder mehrdeutig auftreten | Gleiche Linktexte mit unterschiedlichem ZielWidgets vermeiden mit role, aria-expanded, aria-controls | 2.4.4 (A) |
Blöcke & wiederholte Inhalte überspringbar machen
- Skiplinks für „Zum Inhalt“, „Zur Navigation“
- Navigation per Tastatur muss möglich sein
- Wichtig für Screenreader-Nutzer und Personen ohne Maus
Aussagekräftige Seitentitel
- <title> muss klar den Inhalt oder Zweck der Seite beschreiben
- Der Titel ist das erste Element, das Screenreader erfassen
Navigation & Auffindbarkeit
- Inhalte müssen über mindestens zwei Wege erreichbar sein: z. Navigation + Suche
- Sitemaps, Suchfunktionen oder Breadcrumbs sind ergänzend zu verwenden
Fokus-Reihenfolge und Sichtbarkeit
- Fokus-Indikatoren zeigen, welches Element ausgewählt ist, z. B. Links, Buttons und Formularelemente
- Tab-Reihenfolge muss logisch dem Inhalt folgen
- Fokus-Indikatoren (Outline) sollen sichtbar und nicht durch Banner oder Pop-ups verdeckt sein
- Fokus muss klar vom Hintergrund abgehoben sein
- Problematisch können Pop-ups, Banner und andere Inhalte sein
Verständlicher Linkzweck
- Links / Widgets müssen eindeutig formuliert und nur 1x enthalten sein
- Erkennbarer Linkzweck: z. nicht „Hier klicken“, sondern „Jetzt anmelden“
Formularelemente
- Jedes Feld muss eindeutig beschriftet sein (z. über <label>)
- Beschriftung muss auch programmatisch mit dem Feld verbunden sein
Überschriftenstruktur
- Überschriften sind besonders wichtig für die Seitenorientierung mit Screenreader
- Verwende übersichtliche, logisch gegliederte Überschriften von <h1> bis <h6>
- Keine leeren oder ausgelassenen Überschriften, da Screenreader diese dennoch vorlesen, was zur Verwirrung führen kann
- Keine fettgedruckten Texte als Ersatz für echte Überschriften
- Überschriften für lange Inhalte (ab drei Absätzen) verwenden
2.5 Eingabemodalitäten
Webinhalte müssen nicht nur über die Tastatur, sondern auch durch alternative Eingabearten wie Maus, Touch, Sprache, Joystick, Augensteuerung oder Bewegungssensoren bedienbar sein – ohne Einschränkung der Funktionalität.
| Elementtyp | Beispiele | Erläuterung | Programmierhinweise / Codebeispiele | WCAG-Bezug (Level) |
| Buttons | CTA, Formular-Submit | Per einfacher Zeigereingabe auslösbar | <button type=“submit“>Absenden</button>Per Tastatur und Maus auslösbar | 2.5.1 (A), 2.5.4 (A) |
| Links | Textlink, Symbol-Link | Muss klickbar und tastaturzugänglich sein | <a href=“/kontakt“>Kontakt</a>Vermeide <div onclick=““> ohne tabindex | 2.5.4 (A) |
| Formular-Schaltflächen | Absenden, Zurücksetzen | Assistive Technologien müssen Funktion erkennen | <input type=“submit“ value=“Speichern“><label for=“feld“> zur Beschriftung | 2.5.1 (A) |
| Menüeinträge | Navigationspunkte, Kontextmenüs | Mit Tastatur (Tab/Enter) und Maus bedienbar | <ul><li><a href=“#“>Menüpunkt</a></li></ul>Alternativ mit role=“menuitem“ | 2.5.1 (A), 2.5.2 (A) |
| Widgets | Slider, Akkordeon, Tabs | Müssen ohne komplexe Gesten funktionieren | Verwendung von role, aria-expanded, aria-controlsTastatursteuerung via JS (keydown-Handler) | 2.5.1 (A), 2.5.2 (A) |
| Touch-Gesten | Swipe, Pinch, Drag & Drop | Alternativen für Maus/Keyboard bereitstellen | JS-Events wie touchstart, mousedown, keydown kombinierenBeispiel: Drag via Button „Verschieben“ | 2.5.1 (A) |
| Bewegungsge-steuerte Elemente | Schütteln, Neigen | Alternative per Klick oder deaktivierbar | JS: DeviceMotionEvent, DeviceOrientationEvent + Umschalter<button onclick=“toggleMotion()“>Deaktivieren</button> | 2.5.4 (A) |
| Klickbare Ziele | Icons, Buttons, Touchflächen | Mindestgröße oder ausreichender Abstand | CSS: min-width: 24px; min-height: 24px;Alternativ: padding nutzen statt zu kleine Icons | 2.5.5 (AA) |
| Technik | Einsatz | Beispiel |
| aria-label | Unsichtbare, aber programmatisch lesbare Bezeichnung | <button aria-label=“Navigation öffnen“>☰</button> |
| aria-hidden=“true“ | Deko-Elemente aus Assistenztechniken ausblenden | <span aria-hidden=“true“>★</span> |
| tabindex=“0″ | Element in Tab-Reihenfolge aufnehmen | <div role=“button“ tabindex=“0″>Los</div> |
| event.preventDefault() | Verhindert ungewollte Aktivierungen (z. B. bei mousedown) | JS: element.addEventListener(„mousedown“, e => e.preventDefault()) |
| pointerup statt pointerdown | Aktionen erst beim Loslassen auslösen | JS: element.addEventListener(„pointerup“, callback) |
Alternativen zu komplexen Gesten
- Mehrpunktgesten wie Zweifinger-Zoom müssen auch per einfachem Klick oder Schaltfläche steuerbar sein
- Swipe-Funktionen müssen alternativ per Button oder Tastatur ausführbar sein
- Drag & Drop muss alternativ über Menüoptionen oder Tastenkombinationen funktionieren
- Zeichen- oder Pfadgesten sollen durch einfache Eingabemethoden ersetzt werden können
Barrierefreie Interaktionen ermöglichen
- Inhalte müssen mit Spracheingabe, Joystick, Augensteuerung oder anderen Technologien bedienbar sein
- Aktionen dürfen nicht mehrere Schritte gleichzeitig erfordern, z. B. Ziehen, Halten und Loslassen in Kombination
Unbeabsichtigte Aktionen vermeiden
- Aktionen dürfen nicht beim ersten Berühren (Down-Event), sondern erst beim Loslassen (Up-Event) ausgelöst werden
- Nutzer müssen versehentliche Aktionen rückgängig machen können
- Ausnahmen gelten bei Echtzeitanforderungen, z. B. bei einem virtuellen Klavier
Steuerung durch Bewegung ersetzbar machen
- Funktionen wie Schütteln oder Neigen dürfen nicht die einzige Möglichkeit zur Bedienung sein
- Diese Funktionen müssen deaktivierbar oder alternativ auslösbar sein (z. durch Klick)
Bedienung mit einfachem Zeiger sicherstellen
- Alle Funktionen müssen mit einfacher Point-and-Click-Interaktion nutzbar sein – etwa mit Maus, Touch, Stift oder assistiver Technologie
- Keine komplexen Gesten oder Eingabemuster als alleinige Bedienmöglichkeit
Zielgrößen für klickbare Elemente
- Interaktive Elemente wie Buttons, Links oder Icons sollen mindestens 24 x 24 CSS-Pixel groß sein
- Ausnahmen gelten, wenn
- ausreichend Abstand zu anderen Zielen besteht
- die Größe systembedingt ist (z. native Checkboxen)
- es sich um Hyperlinks im Fließtext handelt
- rechtliche oder gestalterische Vorgaben (z. Signaturfelder) eine Vergrößerung ausschließen
3.1 Lesbar
Informationen und Funktionen müssen in einer für die Nutzer verständlichen Sprache bereitgestellt und programmatisch erkennbar sein.
| Elementtyp | Beispiele | Erläuterung | Programmierhinweise / Codebeispiele | WCAG-Bezug (Level) |
| Haupttextinhalte | Fließtexte, Überschriften, Einleitung | Sprache muss programmatisch bestimmbar sein | <html lang=“de“> für Seitensprache | 3.1.1 (A) |
| Formulare und Labels | Eingabefelder, Checkboxen, Auswahllisten | Müssen in verständlicher Sprache formuliert sein | <label for=“name“>Name</label> – keine Fachbegriffe | 3.1.1 (A) |
| Navigationsmenüs | Hauptnavigation, Footer-Links | Einheitliche Sprache, eindeutig benannt | <nav lang=“de“> optional, wenn Sprache wechselt | 3.1.1 (A) |
| Button- und Linktexte | „Senden“, „Zurück“, „Mehr erfahren“ | Verständlich und sprachlich eindeutig | Kein Slang, z. B. nicht „Ab damit“ → besser: „Absenden“ | 3.1.1 (A) |
| Hinweistexte & Fehlermeldungen | „Bitte ausfüllen“, „Ungültige Eingabe“ | Klar formulierte, hilfreiche Rückmeldungen | Beispiel: „Bitte geben Sie eine gültige Telefonnummer ein.“ | 3.1.1 (A) |
| Mehrsprachige Inhalte | Zitate, Begriffe, Abschnitte in anderer Sprache | Müssen durch lang-Attribute gekennzeichnet sein | <span lang=“en“>Accessibility is important.</span> | 3.1.2 (AA) |
| Audio-/Videoinhalte mit Sprache | Podcasts, Erklärvideos | Sprache muss erkennbar und ggf. benannt sein | „Video in Englisch“ als Hinweistext oder Untertitel | 3.1.1 (A), 3.1.2 (AA) |
Sprachkennzeichnung bereitstellen
- Dokumentensprache mit <html lang=“…“> deklarieren
- Sprachwechsel im Text mit <span lang=“…“>…</span> kennzeichnen
- Einzelne Fremdwörter benötigen keine Kennzeichnung, längere Abschnitte schon
Verständlichkeit gewährleisten
- Klare, einfache Sprache verwenden (z. keine unnötigen Fachbegriffe oder Anglizismen ohne Erklärung)
- Links und Buttons sprachlich eindeutig und selbsterklärend benennen
- Fehlermeldungen und Hinweise so formulieren, dass sie verständlich und hilfreich sind
Audio- und Videoinhalte benennen
- Sprache der Tonspur benennen (z. „Video auf Englisch“)
- ergänzen durch Untertitel oder Transkript, um die Verständlichkeit zu unterstützen
3.2 Vorhersehbar
Interaktive Inhalte und Navigationselemente sollen sich konsistent verhalten und keine unerwarteten Änderungen auslösen, um die Bedienung vorhersehbar und benutzerfreundlich zu gestalten.
| Elementtyp | Beispiele | Erläuterung | Programmierhinweise / Codebeispiele | WCAG-Bezug (Level) |
| Buttons | „Senden“, „Weiter“, „Abbrechen“ | Aktion darf erst bei Aktivierung erfolgen, nicht beim Fokus | Kein JS in onfocus, stattdessen onclick oder submit verwenden | 3.2.1 (A) |
| Links | Navigationslinks, Textlinks | Kein automatischer Kontextwechsel bei Fokus oder Tastendruck | Keine JS-Weiterleitung in onfocus oder onchange | 3.2.1 (A) |
| Textfelder | Eingabefelder in Formularen | Fokus darf keine unerwartete Aktion auslösen | Kein automatischer Submit bei Eingabe ohne Bestätigung | 3.2.1 (A) |
| Checkboxen & Radiobuttons | Auswahlfelder | Auswahl darf keine sofortige Weiterleitung oder Veränderung bewirken | Kontextwechsel nur nach Button-Klick oder expliziter Aktion | 3.2.2 (A) |
| Dropdown-Menüs | Auswahllisten (z. B. Länderauswahl) | Kontextwechsel nur mit Ankündigung oder Bestätigung | JS: Hinweistext anzeigen („Wählen einer Option lädt die Seite neu“) | 3.2.2 (A) |
| Navigationselemente | Hauptmenü, Footer | Wiederkehrend an gleicher Position & Struktur | Konsistente HTML-Struktur und role=“navigation“ verwenden | 3.2.3 (AA) |
| Seitentitel | <title>-Element | Muss Thema oder Zweck der Seite beschreiben | <title>Kontakt – Agentur Sichtbar</title> | 3.2.2 (A) |
| Hilfefunktionen | Tooltips, Hilfesymbole, Chat | Gleichartige Funktionen gleich beschriften & platzieren | Z. B. Chat-Icon immer unten rechts, mit aria-label=“Hilfe öffnen“ | 3.2.4 (AA) |
| Dynamische Komponenten | Pop-ups, Slider, Tabs | Änderungen müssen kommuniziert werden | aria-live=“polite“ bei MeldungenJS mit Fokus-Handling ergänzen | 3.2.5 (AA) |
| Statusmeldungen | „Gespeichert“, „Fehler“ | Änderungen müssen screenreaderfreundlich kommuniziert werden | <div aria-live=“assertive“>Formular erfolgreich gesendet</div> | 3.2.5 (AA) |
| ARIA-Live- Bereiche |
Dynamische Inhalte wie Nachrichtenfelder | Wichtig für Aktualisierungen ohne Seitenreload | <div role=“status“ aria-live=“polite“>Neue Nachricht</div> | 3.2.5 (AA) |
| Kontakt- & Hilfeoptionen | „Support“, „Kontaktieren Sie uns“ | Einheitlich benennen und platzieren | Immer gleiche Bezeichnung und HTML-Struktur | 3.2.4 (AA) |
| Grafische Symbole mit Funktion | Icon-Buttons, z. B. Fragezeichen, Pluszeichen | Symbolfunktion muss konsistent sein | Gleiches Icon = gleiche Funktion auf allen Seiten | 3.2.4 (AA) |
Keine unerwarteten Änderungen bei Fokus oder Eingabe
- Fokus auf ein Textfeld darf nur Eingabe ermöglichen – keine automatische Navigation
- Buttons lösen Aktionen nur bei Aktivierung (z. per Klick oder Enter) aus, nicht beim Tab-Fokus
- Kein automatischer Seitenwechsel bei Auswahl eines Elements (z. bei <select>)
Änderungen durch Eingaben nur bei klarer Nutzeraktion
- Kontextwechsel (z. Weiterleitung, Seitenänderung) nur nach Bestätigung
- Dropdown-Menüs müssen Hinweise geben, wenn die Auswahl eine Änderung auslöst
- Formulare senden Daten erst nach explizitem Klick
Änderungen müssen kommuniziert werden
- Dynamische Inhalte oder Statusmeldungen müssen über aria-live an Screenreader weitergegeben werden
- Pop-ups oder Slidermeldungen benötigen zugängliche Benachrichtigungssysteme
Konsistente Navigation und Struktur
- Navigationselemente an gleicher Stelle und in gleicher Reihenfolge auf allen Seiten
- Auch im Quellcode muss die Reihenfolge gleich bleiben
- Unterschiede zwischen visuellem Aufbau und Screenreader-Reihenfolge vermeiden
Einheitliche Benennungen und Symbole
- Gleiche Funktion → gleiche Beschriftung oder Symbolik
- Icons (z. Lupe für Suche) nicht unterschiedlich einsetzen
- Hilfebuttons und Kontaktoptionen immer an derselben Stelle platzieren
Einheitliche Platzierung von Hilfeoptionen
- Kontaktmöglichkeiten und Hilfe-Optionen an der gleichen Stelle
- Positionierung und Organisation auf allen Seiten gleich
- Wichtig ist auch die richtige Reihenfolge im HTML-Code
3.3 Hilfestellung bei der Eingabe
Fehlerhafte Eingaben müssen leicht erkannt, erklärt und möglichst vermieden werden – insbesondere bei wichtigen Formularvorgängen.
| Elementtyp | Beispiele | Erläuterung | Programmierhinweise / Codebeispiele | WCAG-Bezug (Level) |
| Formularfelder | Name, E-Mail, Geburtsdatum | Müssen klar und verständlich beschriftet sein | <label for=“email“>E-Mail-Adresse</label> + Hinweistext <small>Format: name@domain.de</small> | 3.3.2 (A) |
| Pflichtfelder | z. B. „* Name“ | Müssen zusätzlich als „erforderlich“ gekennzeichnet werden | <label for=“name“>Name (erforderlich)</label> + required | 3.3.2 (A) |
| Formatvorgaben | Datum, Telefonnummer, IBAN | Nutzer müssen wissen, wie etwas einzugeben ist | <input type=“date“> oder <input pattern=“[0-9]{5}“> + Beschreibung | 3.3.2 (A) |
| Fehlermeldungen | „Eingabe ungültig“, „Feld leer“ | Fehler müssen klar benannt werden | <div class=“error“ aria-live=“assertive“>Bitte geben Sie eine gültige E-Mail ein.</div> | 3.3.1 (A) |
| Korrekturhilfen | Hinweis, wie der Fehler behoben werden kann | Gilt, wenn Sicherheit/Zweck nicht beeinträchtigt wird | Beispiel: „IBAN muss 22 Zeichen lang sein“ | 3.3.3 (AA) |
| Wichtige Aktionen | Absenden von Formularen, Zahlungen | Nutzer muss Eingaben prüfen oder rückgängig machen können | Bestätigungsschritt mit Übersicht<h2>Bitte prüfen Sie Ihre Angaben</h2> | 3.3.4 (AA) |
| Automatische Eingaben | Autofill von Name, E-Mail, Adresse | Nutzerfreundlich, wenn sicher und sinnvoll | autocomplete=“name“, email, postal-code etc. | 3.3.7 (AA) |
| Authentifizierung | Login-Masken, CAPTCHA | Muss ohne übermäßige kognitive Belastung möglich sein | Verzerrte Bilder vermeiden, einfache Rechenaufgaben nutzen oder Passwortmanager-Unterstützung | 3.3.6 (AA) |
Fehler vermeiden durch klare Beschriftungen und Hilfen
- Klare Labels und strukturierte Formularfelder, z. B.: Beschriftung des Textfeldes für Namenseingabe mit „Name“
- Pflichtfelder deutlich kennzeichnen. * (Sternchen) reicht alleine nicht aus. Stattdessen lieber eine textliche Erklärung verwenden. Achtung: Platzhaltertexte im Eingabefeld (Placeholder) werden nicht verlässlich von assistiven Technologien erkannt!
- Eindeutige Hinweise für Werteingaben, z. Format des Geburtsdatums
- Alleinstehende placeholder-Texte vermeiden – sie sind für viele Screenreader nicht zuverlässig
Fehler erkennen und erklären
- Fehlermeldungen müssen als Text ausgegeben werden
- Hinweis zur Korrektur, z. durch aria-describedby
- Live-Aktualisierung bei Fehlern mit aria-live=“polite“ oder assertive
Absicherung bei rechtlichen, finanziellen oder datenschutzrelevanten Aktionen (z. B. Bestellung, Anmeldung)
Mindestens eine der folgenden Optionen umsetzen:
- reversibel: Eingaben können zurückgenommen werden
- geprüft: System überprüft Eingaben und gibt Rückmeldung
- bestätigt: Übersicht zur finalen Bestätigung der Eingaben, die dann ggf. noch geändert werden können
Erleichterung durch Automatisierung
- Vorab bekannte Informationen automatisch ausfüllen (wenn sicher)
- autocomplete-Attribute korrekt nutzen
- Ausnahmen beachten bei sensiblen oder temporären Daten
Barrierearme Authentifizierung
- Keine schwer lösbaren CAPTCHAs
- Alternativen: biometrisches Login, Passwortmanager unterstützen, einfache Textaufgaben statt Bilderrätsel
4.1 Kompatibel
Inhalte müssen von Benutzeragenten und Assistenztechnologien interpretiert werden können.
| Elementtyp | Beispiele | Erläuterung | Programmierhinweise / Codebeispiele | WCAG-Bezug (Level) |
| HTML-Elemente | <div>, <button>, <input>, <label> | Müssen korrekt verschachtelt, geschlossen und validiert sein | HTML mit Validator überprüfen: validator.w3.org Beispiel: <label for=“email“>E-Mail</label><input id=“email“> | 4.1.1 (A) |
| Formularelemente | Textfelder, Checkboxen, Radiobuttons, Selects | Müssen programmatisch Name, Rolle und Wert übermitteln | <input type=“checkbox“ role=“checkbox“ aria-checked=“true“><select aria-label=“Land“> | 4.1.2 (A) |
| Interaktive Komponenten | Slider, Akkordeons, Tabs, modale Fenster | Müssen durch ARIA-Attribute semantisch beschrieben werden | Rolle & Zustand: <div role=“tablist“>, aria-selected=“true“ etc. | 4.1.2 (A) |
| ARIA-Attribute | aria-label, aria-labelledby, aria-checked, aria-expanded, aria-live | Müssen korrekt verwendet und gepflegt sein | <button aria-expanded=“false“>Menü</button><div aria-live=“polite“> | 4.1.2 (A) |
| Buttons und Links | Mit sichtbarem Namen oder ARIA-Beschriftung | Screenreader benötigen einen beschreibenden Namen | <a href=“/kontakt“ aria-label=“Kontakt aufnehmen“>📬</a> | 4.1.2 (A) |
| Statusmel-dungen | Erfolg, Warnung, Fehler (z. B. „Nachricht gesendet“) | Müssen per Screenreader ohne Fokusverlust erkennbar sein | <div role=“status“ aria-live=“polite“>Nachricht gesendet.</div> | 4.1.3 (AA) |
| Custom Controls | JavaScript-Komponenten, Dropdowns, Schieberegler | Müssen Rolle, Name & Status übermitteln | role=“slider“ aria-valuemin=“0″ aria-valuemax=“100″ aria-valuenow=“50″ | 4.1.2 (A) |
| Dynamische Inhalte | AJAX-Feedback, Ladeanzeigen, Formularrückmeldungen | Änderungen müssen programmatisch übermittelt werden | <div aria-live=“assertive“>Ladevorgang abgeschlossen</div> | 4.1.3 (AA) |
Name, Rolle, Wert – Verständliche Benutzeroberflächen für Assistenztechnologien
- Der Name beschreibt, was das Element ist oder tut, z. ein Button mit dem sichtbaren Text „Senden“. Dieser Name wird auch von Screenreadern vorgelesen. Beispiel: Button mit dem Text „Senden“.
- Die Rolle beschreibt die Funktion des Elements, z. Button, Checkbox, Slider, Schaltfläche. Sie wird über HTML oder ARIA korrekt zugewiesen. Beispiel: Eine Checkbox wird von Screenreadern als „Auswahlfeld“ erkannt.
- Der Wert zeigt den aktuellen Zustand oder Inhalt eines Elements an, z. ob eine Checkbox aktiviert ist oder welcher Wert in einem Schieberegler eingestellt ist. Beispiel: Ein Slider steht auf „50 %“.
Statusmeldungen – Änderungen ohne Fokusverlust vermitteln
- Statusmeldungen informieren über Erfolg, Fehler oder Hinweise, ohne dass der Nutzer etwas tun muss. Beispiele: „Ihre Nachricht wurde gesendet“, „Fehler: Bitte alle Felder ausfüllen.“
- Meldungen müssen für Assistenztechnologien zugänglich sein (z. über aria-live).
- Der Fokus darf nicht verändert werden – der Nutzer bleibt an der aktuellen Stelle.
🧪 Tools zur Unterstützung
- WAVE Accessibility Tool
- Axe DevTools (Browser-Erweiterung)
- NVDA / VoiceOver / JAWS (zum Test mit Screenreader)
- HTML Validator (W3C)
- Keyboard-only Test (ohne Maus bedienbar)
5. Konformitätsbedingungen
Die WCAG 2.2 (Web Content Accessibility Guidelines) geben klare Anforderungen vor, wie Inhalte auf Webseiten, in Dokumenten und in Software barrierefrei gestaltet werden müssen. Sie helfen dabei, sicherzustellen, dass alle Menschen – einschließlich Menschen mit Behinderungen – diese Inhalte problemlos nutzen können. Neben den Erfolgskriterien, die sich auf einzelne Inhalte und Funktionen beziehen, gibt es weitere Bedingungen, die im Folgenden dargestellt werden. Diese schaffen einen Rahmen, um die Barrierefreiheit einer Webseite insgesamt objektiv und einheitlich zu bewerten.
| Techniktyp | Beispiele | Erläuterung | WCAG-Bezug (Level) |
| HTML-Standard | <button>, <input>, <form> | Wird von Assistenztechnologien erkannt und korrekt verarbeitet | 4.1.2 (A) |
| ARIA-Attribute | aria-label, role=“button“ | Ermöglicht semantische Beschreibung benutzerdefinierter UI-Elemente | 4.1.2 (A) |
| Standardkonformes CSS | z. B. für Textvergrößerung | Unterstützt visuelle Anpassungen ohne Barriere | 1.4.4 (AA) |
| Unzugängliche Skripte | JS-Button ohne Rolle oder Label | Wird von Screenreadern nicht erkannt oder benutzbar gemacht | 4.1.2 (A) – nicht erfüllt |
| Flash | Interaktive Inhalte in Flash | Nicht mehr unterstützt, nicht zugänglich | generell nicht konform |
| Bilder ohne Alt-Text | <img src=“bild.jpg“> | Wird von Screenreadern ignoriert → keine Information | 1.1.1 (A) |
Gültigkeitsumfang
- Konformität gilt immer für die komplette Webseite, nicht nur für einzelne Seiten.
- Alle Seiten eines zusammenhängenden Prozesses (z. Warenkorb, Checkout) müssen vollständig konform sein.
- Ist Konformität nicht vollständig möglich, kann eine partielle Konformität deklariert werden.
Barrierefreiheit unterstützende Techniken verwenden
Eine Technik gilt als unterstützend, wenn sie:
- Assistenztechnologien wie Screenreader, Sprachsteuerung, Lupen unterstützt
- sich auf standardisierte Technologien stützt (HTML, CSS, WAI-ARIA)
- die Zugänglichkeit von Funktionen oder Inhalten sicherstellt
Anforderungen an nicht unterstützende oder nicht konforme Techniken
Keine Blockierung der Seite
- Wenn eine Technik nicht unterstützt wird (z. ein JS-Button), darf dies nicht die Funktionsfähigkeit der gesamten Seite beeinträchtigen
- Beispiel: Wenn ein Plugin ausfällt, muss die Seite weiter navigierbar und benutzbar sein
Technik muss ersetzbar oder alternativ sein
- Inhalte in Flash oder JS-only müssen durch barrierefreie Alternativen verfügbar sein
- : Flash-Video → statischer Text + Transkript
Benutzeragentenunabhängigkeit
- Die Seite muss auch funktionieren, wenn bestimmte Browser oder Geräte eine Technik nicht ausführen können
Erfolgskriterien, die immer erfüllt sein müssen (auch bei unzugänglicher Technik)
| Erfolgskriterium | Erläuterung | Level |
| 1.4.2 Audio-Steuerelemente | Audio darf nicht automatisch starten oder muss abschaltbar sein | A |
| 2.1.2 Keine Tastaturfalle | Nutzer dürfen mit Tastatur nicht in einem Bereich „gefangen“ sein | A |
| 2.2.2 Pausieren, beenden, ausblenden | Bewegte Inhalte müssen steuerbar sein | A |
| 2.3.1 Drei-Blitz-Grenze | Inhalte dürfen nicht öfter als 3×/Sekunde blinken | A |
Häufige Fragen zur barrierefreien Programmierung
Digitale Barrierefreiheit ermöglicht Teilhabe für alle – sie schließt Menschen mit Behinderung nicht aus und verbessert die Benutzerfreundlichkeit für alle Nutzer. Barrierefreies Webdesign bedeutet inklusives Design. Sehbehinderte oder Blinde profitieren von barrierefrei gestalteten Inhalten ebenso wie Menschen mit motorischen und kognitiven Einschränkungen.
In Deutschland gilt die Barrierefreie-Informationstechnik-Verordnung (BITV 2.0) für öffentliche Stellen. Für Unternehmen mit 10 oder mehr Personen, die sich mit ihren Leistungen und Produkten an Endkunden wenden, wird Barrierefreiheit ab dem 28. Juni 2025 durch das Barrierefreiheitsstärkungsgesetz (BFSG) verpflichtend – basierend auf der europäischen Accessibility-Richtlinie (EAA). Das Gesetz schreibt klare Anforderungen für digitale Angebote vor.
Grundlage für barrierefreie Programmierung sind die Web Content Accessibility Guidelines (WCAG) 2.2, insbesondere die Konformitätsstufen A und AA. Öffentliche Stellen müssen zusätzlich die Vorgaben der BITV 2.0 einhalten. Ein technischer Leitfaden hilft bei der Umsetzung der Standards.
Nicht nur Menschen mit Behinderung. Auch Nutzer mit temporären Einschränkungen, ältere Menschen, fremdsprachige Besucher oder Menschen mit langsamer Internetverbindung profitieren von einer barrierefreien, gut strukturierten Website.
Nein. Barrierefreies Webdesign ist eine interdisziplinäre Aufgabe. Neben Entwicklern sind auch Redakteure, Designer und Projektverantwortliche gefragt – z. B. bei der Auswahl von Farben, der Textgestaltung oder der alternativen Beschreibung von Bildern. Alle Aspekte der Barrierefreiheit müssen im Prozess berücksichtigt werden.
Es gibt viele Tools wie WAVE, axe DevTools oder Lighthouse, die automatisierte Prüfungen ermöglichen. Zusätzlich sind manuelle Tests (z. B. mit Tastatur oder Screenreader) notwendig, um reale Nutzungssituationen abzubilden – insbesondere für Blinde und Menschen mit motorischen Einschränkungen.
Typische Fehlerquellen sind:
- Fehlende Alternativtexte bei Bildern oder Icons
- Nicht erreichbare Elemente bei Tastaturnavigation
- Fehlende oder falsche ARIA-Attribute
- Unzureichende Farbkontraste oder Schriftgrößen
- Nicht beschriftete Formularfelder
- Fokusfalle bei modalen Fenstern oder dynamischen Komponenten
- Unverständliche Linktexte wie „Hier klicken“
- Verwendung rein visueller Hinweise (z. „Klicken Sie auf das rote Feld“)
Diese lassen sich durch frühzeitige Planung, Schulung und Tests gezielt vermeiden.
Ab 2025 drohen Unternehmen bei Verstößen gegen das BFSG rechtliche Konsequenzen. Darüber hinaus riskieren sie Imageverlust, Reichweiteneinbußen und Nutzerfrust – also auch wirtschaftliche Nachteile. Eine frühzeitige Umsetzung entsprechend dem Gesetz ist daher ratsam.
Starten Sie mit den WCAG-Grundlagen, analysieren Sie bestehende Barrieren und bauen Sie auf einem zugänglichen HTML-Grundgerüst auf. Wichtig ist ein bewusstes, inklusives Denken in jeder Projektphase. Ein strukturierter Leitfaden unterstützt dabei, alle relevanten Aspekte systematisch umzusetzen.
Kunden, die uns vertrauen
-
Haus am Kirschberg
-
Menschen-s-Kinder
-
Klinikum Fulda
-
My Way Betty Ford Klinik
-
Reha Bad Kötzingen
-
Gesunheitszentrum Main-Spessart
-
Engel Apotheke
-
Klinik am Hellweg
-
Klinik Lindenplatz
-
Praxis Contour
-
Dr. von Rosen
-
Dr. Al-Hami
-
Westfälisches Gesundheitszentrum
-
Elbe-Jeetzel-Klinik
Wir haben Ihr Interesse geweckt?
Jasmin Rothenbücher
+49 (0)661 410 955 – 43
j.rothenbuecher@re7consulting.com
Folge uns