Tools

Im Folgenden werden dir zwei nützliche Werkzeuge vorgestellt, die dabei helfen können, Webseiten auf ihre Barrierefreiheit zu überprüfen. Beide Tools bieten unterschiedliche Funktionen und Herangehensweisen, um Probleme sichtbar zu machen und zu analysieren. Schau dir die Hilfsmittel gerne genauer an.

Dieses Werkzeug visualisiert Barrierefreiheitsprobleme direkt auf der Webseite und macht Fehler sowie Verbesserungspotenziale leicht erkennbar. Es bietet eine übersichtliche Darstellung von Warnungen, Fehlern und Hinweisen, die Entwickler:innen helfen, die Nutzungsfreundlichkeit für Menschen mit Behinderungen zu verbessern. Mit seiner intuitiven Oberfläche eignet es sich gut für schnelle Prüfungen und detaillierte Analysen. Durch Icons werden Fehler oder Verbesserungen markiert.

Dieses Tool analysiert Webseiten gründlich auf Barrierefreiheitsprobleme und zeigt Fehler sowie Verbesserungspotenziale strukturiert auf. Es erstellt verständliche Berichte mit konkreten Hinweisen, die Entwickler:innen helfen, bekannte Standards einzuhalten und Barrieren gezielt zu beheben. Mit seinem klaren Aufbau eignet es sich gut für detaillierte Auswertungen und die kontinuierliche Verbesserung digitaler Zugänglichkeit. Zusätzlich wird eine Bewertung des WCAG-Levels vorgenommen.

Unterschiede zwischen WAVE und AChecker

AChecker und WAVE sind zwei Werkzeuge zur Überprüfung der Barrierefreiheit von Webseiten, sie verfolgen jedoch unterschiedliche Ansätze. WAVE bietet eine visuelle Prüfung direkt auf der Seite und ist besonders benutzer:innen-freundlich, AChecker hingegen liefert eine detaillierte, technisch orientierte Analyse. Während WAVE automatisch erkannte Probleme farblich hervorhebt, gliedert AChecker seine Ergebnisse in überprüfbare Kategorien und erlaubt auch eine lokale Nutzung. Beide Tools ergänzen sich gut, um Webinhalte barrierefrei zu gestalten.

Tipps zur Umsetzung

Barrierefreiheit im digitalen Raum bedeutet, dass Webseiten und digitale Inhalte für alle Menschen nutzbar sind, unabhängig von körperlichen, sensorischen oder kognitiven Einschränkungen. Um das zu gewährleisten, gibt es die WCAG, die Web Content Accessibility Guidelines. Diese Richtlinien basieren auf dem sogenannten POUR-Prinzip, das vier zentrale Anforderungen an barrierefreie Inhalte definiert:

Pfür Perceivable (wahrnehmbar)
Ofür Operable (bedienbar)
Ufür Understandable (verständlich)
Rfür Robust (robust gegenüber Technik)

Hier findest du Tipps die nach den Richtlinien der WCAG geordnet sind. Pro Tipp erwartet dich eine Begründung, warum die Umsetzung sinnvoll ist, ein Tipp zum Umsetzen, ein Beispiel und eine kurze Quizfrage, um dein Verständnis zu prüfen. Viel Spaß beim Entdecken und Umsetzen.*

Wahrnehmbar
Textalternativen
Alt-Texte für aussagekräftige Bilder
Warum?

Menschen mit Sehbehinderungen können Bilder nicht visuell wahrnehmen. Durch alternative Texte können Screenreader den Bildinhalt in Worte fassen und so die Information für alle zugänglich machen. Ohne Alt-Texte bleibt der Inhalt für viele unsichtbar.

Was tun?

Verwende für jedes bedeutungsvolle Bild einen präzisen Alt-Text, der den Inhalt und die Funktion des Bildes beschreibt. Ist ein Bild rein dekorativ und trägt keine inhaltliche Bedeutung, sollte das Alt-Attribut leer sein (alt=""), damit es von Screenreadern ignoriert wird.

Beispiel:
<img src='klimawandel-grafik.png' alt='Grafik zeigt den Temperaturanstieg weltweit seit 1880.'>
Quiz:

Welcher Alt-Text ist am besten für ein Bild von Professorin Müller, das im Team-Bereich einer Website gezeigt wird?

  • Bild von Frau
  • Porträtfoto
  • Professorin Müller, Expertin für Barrierefreiheit
  • teamfoto.jpg
Funktion von Steuerelementen benennen
Warum?

Blinde oder sehbehinderte Nutzer:innen können die Funktion von Steuerelementen nur dann erfassen, wenn diese korrekt beschriftet sind. Ohne sinnvolle Textalternative, etwa ein aria-label oder ein sichtbarer Text, bleibt die Funktion unklar. Dadurch wird die Bedienung der Website erheblich erschwert oder unmöglich.

Was tun?

Stelle sicher, dass alle interaktiven Elemente, wie Buttons, Links oder Icons, mit einer klaren, beschreibenden Textalternative versehen sind. Verwende sichtbaren Text, ein aria-label, aria-labelledby oder ein title-Attribut, wenn kein sichtbarer Text vorhanden ist. Achte darauf, dass die Beschreibung die Funktion des Elements widerspiegelt, nicht nur sein Aussehen.

Beispiel:
<button aria-label='Suche starten'><img src='suche-icon.svg' alt=''></button>
Aussage:

Ein Icon-Button ohne sichtbaren Text braucht keine zusätzliche Beschriftung, solange das Symbol verständlich ist.

Medieninhalte kurz beschreiben
Warum?

Ohne eine kurze Beschreibung von Videos oder Audios wissen viele Nutzer:innen nicht, worum es im Medium geht. Menschen mit Sehbehinderung oder Screenreader sind darauf angewiesen, dass der Inhalt eines Mediums zumindest grob erläutert wird, sonst bleibt das Medium inhaltlich unsichtbar.

Was tun?

Füge bei Videos oder Audiodateien immer eine kurze Beschreibung hinzu, die den Inhalt oder Zweck zusammenfasst. Diese Beschreibung sollte nahe am Medium platziert sein, z.B. direkt darunter, und auch für Screenreader erfassbar sein. Bei komplexen Inhalten kann ein ausführlicheres Transkript oder eine separate Seite sinnvoll sein.

Beispiel:
<video controls> <source src='intro.mp4' type='video/mp4'> </video> <p>In diesem Video stellt sich das Entwicklungsteam des Projekts vor und erklärt die Ziele der Plattform.</p>
Quiz:

Welche Beschreibung macht ein Video für blinde Nutzer:innen verständlicher?

  • Video abspielen
  • Hier ist ein cooles Video!
  • In diesem Video erklärt eine Expertin barrierefreies Webdesign.
  • Ein Video mit Musik und Bildern
Dekoration ausblenden
Warum?

Dekorative Bilder tragen keine inhaltliche Bedeutung bei und können Menschen mit Screenreader unnötig ablenken. Wenn solche Bilder nicht korrekt ausgeblendet werden, müssen Nutzer:innen sich durch irrelevante Informationen navigieren, das stört den Lesefluss und erschwert die Nutzung.

Was tun?

Kennzeichne dekorative Bilder so, dass sie von Screenreadern ignoriert werden. Verwende dafür ein leeres Alt-Attribut (alt=""). So wird das Bild für Nutzer:innen ohne Sehvermögen übersprungen, ohne unnötige Ablenkung zu verursachen.

Beispiel:
<img src='linie.png' alt=''>
Quiz:

Für welches der folgenden Bilder sollte am ehesten Alt-Text vergeben werden?

  • Ein Zierelement (z.B. geschwungene Linie im Design)
  • Ein Firmenlogo in der Kopfzeile mit Link zur Startseite
  • Ein Symbolbild vor einer Überschrift, das deren Bedeutung ergänzt (z.B. Brief für "Kontakt")
Alternativen für CAPTCHA anbieten
Warum?

Viele CAPTCHAs stellen für Menschen mit Behinderungen ein großes Hindernis dar. Visuelle CAPTCHAs können von blinden oder sehbehinderten Personen nicht erkannt werden, während Audio-CAPTCHAs für gehörlose oder schwerhörige Nutzer:innen unzugänglich sind. Ohne barrierefreie Alternativen bleibt der Zugang zu geschützten Funktionen, wie Formularen oder Anmeldungen, verwehrt.

Was tun?

Vermeide CAPTCHAs, wenn möglich, sie stellen oft unnötige Barrieren dar. Wenn ein CAPTCHA erforderlich ist, stelle sicher, dass es mindestens zwei verschiedene Alternativen gibt: z.B. eine visuelle UND eine akustische Variante. Achte darauf, dass beide Varianten verständlich, kontrastreich und mit Screenreader bedienbar sind. Noch besser ist der Einsatz barrierefreier Alternativen wie Rechenaufgaben, einfache Logikfragen oder serverseitige Prüfungen.

Beispiel:
<label for='captcha'>Wie viel ist 3 plus 4?</label> <input type='text' id='captcha' name='captcha' aria-describedby='captcha-hinweis'> <p id='captcha-hinweis'>Bitte tragen Sie das Ergebnis als Zahl ein.</p>
Statt unzugänglichem Bild oder Audio wird eine einfache Rechenfrage gestellt. Textbasiert, also gut lesbar und screenreaderfreundlich. aria-describedby verbindet das Eingabefeld mit einer verständlichen Erklärung.
Quiz:

Welche CAPTCHA-Variante ist barrierearm und für möglichst viele Nutzer:innen zugänglich?

  • Ein Bild mit verzerrtem Text zum Abtippen
  • Eine Tonaufnahme mit schwer verständlichem Codewort
  • Eine Frage wie 'Welcher Buchstabe steht an zweiter Stelle im Wort „Barriere“?'
  • Ein Bild mit Verkehrsschildern, aus dem alle Stoppschilder ausgewählt werden müssen
Zeitbasierte Medien
Untertitel für Videos
Warum?

Videos mit gesprochener Sprache sind für viele Menschen ohne Untertitel nicht zugänglich, z.B. für gehörlose, schwerhörige oder Personen in lärmintensiven Umgebungen. Automatisch generierte Untertitel können helfen, enthalten aber häufig Fehler. Nur geprüfte Untertitel sorgen dafür, dass die Inhalte korrekt verstanden werden.

Was tun?

Stelle sicher, dass alle Videos mit Sprache gut lesbare, synchronisierte Untertitel enthalten. Wenn automatische Untertitel verwendet werden, überprüfe und korrigiere sie manuell. Die Untertitel sollen das Gesprochene vollständig wiedergeben, einschließlich relevanter Geräusche wie Musik oder Lachen.

Beispiel:
<video controls> <source src='erklärung.mp4' type='video/mp4'> <track src='untertitel.vtt' kind='subtitles' srclang='de' label='Deutsch' default> </video>
Das <track>-Element bindet eine Untertitelspur ein. Mit kind='subtitles' wird klargestellt, dass es sich um textliche Untertitel handelt. Die Attribute srclang, label und default sorgen dafür, dass die richtige Sprache verwendet und die Untertitel automatisch angezeigt werden.
Aussage:

<video controls> <source src='video.mp4' type='video/mp4'> </video> Dieser Code erfüllt die WCAG-Anforderung 1.2.2 (Untertitel für aufgezeichnete Medien).

Transkription für Audioinhalte
Warum?

Menschen, die nicht hören können, haben ohne Transkription keinen Zugang zu den Inhalten von Audiodateien. Auch in Situationen, in denen Ton nicht genutzt werden kann (z.B. im Zug oder Büro), hilft eine schriftliche Alternative. Nur so ist sichergestellt, dass alle Nutzer:innen den gleichen Informationszugang erhalten.

Was tun?

Stelle zu jeder reinen Audiodatei ein vollständiges Transkript zur Verfügung. Das Transkript sollte alle gesprochenen Inhalte sowie wichtige akustische Informationen (z.B. Musik, Lachen, Pausen) enthalten. Es kann direkt unter dem Audio eingebunden oder als separate Seite verlinkt werden.

Beispiel:
<audio controls> <source src='podcast.mp3' type='audio/mpeg'> </audio> <p> <a href='transkript.html'>Transkript anzeigen</a> </p>
Das <audio>-Element bindet eine Audiodatei ein. Direkt darunter befindet sich ein Link zum Transkript, der den gesamten gesprochenen Inhalt schriftlich zugänglich macht, so können auch gehörlose oder schwerhörige Nutzer:innen den Inhalt erfassen.
Aussage:

<audio controls> <source src='audio.mp3' type='audio/mpeg'> </audio> Die WCAG-Anforderung 1.2.1 ist erfüllt, wenn dieser Code allein auf der Seite steht.

Audiodeskription bei visuellen Medien
Warum?

Viele Videos enthalten wichtige visuelle Informationen, etwa Gesten, Szenenwechsel oder Texttafeln, die für blinde oder sehbehinderte Menschen nicht zugänglich sind, wenn sie nicht im Ton erwähnt werden. Audiodeskriptionen machen solche Inhalte verständlich, indem sie sie zwischen oder über die Dialoge einsprechen.

Was tun?

Wenn ein Video relevante visuelle Informationen enthält, die im Originalton nicht erklärt werden, musst du eine Audiodeskription bereitstellen. Diese kann entweder in das Video integriert oder als alternative Tonspur angeboten werden. Achte darauf, dass die Audiodeskription alle notwendigen visuellen Inhalte verständlich beschreibt.

Beispiel:
<video controls> <source src='video-mit-ad.mp4' type='video/mp4'> <track src='untertitel.vtt' kind='subtitles' srclang='de' label='Deutsch'> </video> <p>Diese Version enthält eine integrierte Audiodeskription im Originalvideo.</p>
Dieses Video verwendet eine Version mit integrierter Audiodeskription. Die visuellen Inhalte, die im Originalton fehlen (z.B. Gestik oder Szenen), werden zwischen den gesprochenen Passagen eingesprochen und so auch für blinde Nutzer:innen verständlich gemacht.
Quiz:

Welche Aussage über Audiodeskriptionen ist korrekt?

  • Audiodeskriptionen sind für Menschen, die keine Videos mögen.
  • Audiodeskriptionen erklären visuelle Inhalte in Videos.
  • Audiodeskriptionen sind automatisch generierte Untertitel.
  • Audiodeskriptionen ersetzen den Ton eines Videos.
Anpassbar/Inhalte verständlich strukturiert
Semantische HTML-Nutzung
Warum?

Nur mit semantischem HTML können assistive Technologien wie Screenreader erkennen, welche Funktion ein Element hat, z.B. ob es sich um eine Überschrift, einen Button oder einen Abschnitt handelt. Wenn stattdessen rein visuelle Gestaltung ohne semantische Struktur verwendet wird, geht diese Information verloren, und damit auch der barrierefreie Zugang.

Was tun?

Verwende HTML-Elemente entsprechend ihrer Bedeutung, z.B. <button> statt <div> für klickbare Elemente, <h1> bis <h6> für Überschriftenhierarchien und <nav>, <main>, <section> zur Gliederung der Seite. Vermeide es, Struktur oder Funktion nur mit CSS oder ARIA nachzubilden, wenn ein passendes HTML-Element vorhanden ist.

Beispiel:
<section> <h2>Kontakt</h2> <p>Hier finden Sie unsere Kontaktdaten und das Formular zur Anfrage.</p> <button>Senden</button> </section>
In diesem Beispiel wird ein Abschnitt sinnvoll mit <section> gekennzeichnet, die Überschrift mit <h2> und der klickbare Bereich als <button>. Dadurch können Screenreader und andere Hilfsmittel die Struktur und Funktion der Elemente korrekt erkennen und wiedergeben.
Quiz:

Welche HTML-Struktur ist semantisch korrekt, um eine Kontaktadresse auszuzeichnen?

  • <div class='adresse'>Musterstraße 12, 12345 Musterstadt</div>
  • <p>Musterstraße 12<br>12345 Musterstadt</p>
  • <span>Musterstraße 12 – 12345 Musterstadt</span>
  • <address>Musterstraße 12<br>12345 Musterstadt</address>
Formularstruktur
Warum?

Ohne semantisch korrekt ausgezeichnete Formulare können Screenreader-Nutzer:innen nicht erkennen, was in ein Feld eingegeben werden soll. Labels, Gruppen oder Hinweistexte müssen maschinenlesbar verknüpft sein, damit alle Nutzer:innen wissen, was von ihnen erwartet wird.

Was tun?

Nutze für Formulare die vorgesehenen HTML-Elemente wie <label>, <input>, <fieldset> und <legend>. Verknüpfe jedes Eingabefeld eindeutig mit einem sichtbaren und maschinenlesbaren Label. Gruppiere verwandte Felder logisch, z.B. bei Auswahlfragen oder Adressblöcken.

Beispiel:
<form> <fieldset> <legend>Kontaktinformationen</legend> <label for='email'>E-Mail:</label> <input type='email' id='email' name='email'> </fieldset> </form>
Dieses Beispiel zeigt ein semantisch korrektes Formular. Die Eingabe für die E-Mail-Adresse ist über das for-Attribut mit dem zugehörigen <label> verknüpft. Das <fieldset> gruppiert die Felder sinnvoll, und <legend> beschreibt den Abschnitt, so wird der Zusammenhang auch von assistiven Technologien erkannt.
Quiz:

Welche HTML-Struktur ist semantisch korrekt für ein Formularfeld mit Beschriftung?

  • <input type='text'> Name
  • <span>Name:</span><input type='text'>
  • <label for='name'>Name:</label><input type='text' id='name'>
  • <div>Name:<input type='text'></div>
Tabellenstruktur
Warum?

Screenreader lesen Tabellen nicht visuell, sondern linear. Nur wenn Überschriftenzellen (<th>) und Datenzellen (<td>) richtig ausgezeichnet sind, können Nutzer:innen verstehen, welche Werte zu welchen Überschriften gehören. Ohne semantische Struktur wird eine Tabelle schnell unverständlich, besonders bei mehreren Spalten oder Zeilen.

Was tun?

Verwende für Überschriften in Tabellen <th> statt <td> und gib, bei komplexeren Tabellen, scope-Attribute oder sogar headers-Beziehungen an. Nutze Tabellen ausschließlich für Daten, nicht für Layout. Gruppiere die Tabelle mit <table>, <thead>, <tbody>, und vermeide verschachtelte Tabellen.

Beispiel:
<table> <thead> <tr> <th scope='col'>Name</th> <th scope='col'>E-Mail</th> </tr> </thead> <tbody> <tr> <td>Anna Beispiel</td> <td>anna@example.com</td> </tr> </tbody> </table>
In dieser Tabelle sind die Spaltenüberschriften mit <th scope='col'> ausgezeichnet. Das erlaubt Screenreadern, die Überschrift mit der entsprechenden Zelle zu verknüpfen, auch bei mehreren Zeilen. Die Tabelle ist in <thead> und <tbody> unterteilt, was zusätzlich zur Barrierefreiheit beiträgt.
Aussage:

<table> <tr> <td>Name</td> <td>E-Mail</td> </tr> </table> Diese Tabelle ist korrekt ausgezeichnet, um die Spaltenüberschriften für Screenreader zugänglich zu machen.

Unterscheidbar
Farbkontrast
Warum?

Viele Menschen mit Sehbehinderungen oder Farbsehschwächen können Texte mit schwachem Kontrast kaum oder gar nicht lesen. Auch bei ungünstigen Lichtverhältnissen, z.B. auf dem Smartphone im Sonnenlicht, hilft ein guter Kontrast. Ein zu geringer Kontrast führt dazu, dass Informationen übersehen werden und die Seite unzugänglich bleibt.

Was tun?

Stelle sicher, dass der Kontrast zwischen Text und Hintergrund mindestens 4.5:1 beträgt (für normalen Text) bzw. 3:1 bei großem Text. Nutze dafür Kontrastprüfungs-Tools wie das WAVE-Tool, den Colour Contrast Analyser oder die DevTools in modernen Browsern. Verlasse dich nicht auf subjektives Empfinden.

Beispiel:
<p style='color: #999; background-color: #fff;'>Dieser Text ist schwer lesbar wegen zu geringem Kontrast.</p>
Der graue Text (#999) auf weißem Hintergrund hat einen Kontrastwert von nur etwa 3:1, das ist zu wenig für normalen Fließtext. Er verstößt gegen WCAG 1.4.3 und ist für viele Nutzer:innen mit eingeschränktem Sehvermögen schwer lesbar.
Quiz:

Welches Text-Beispiel hat wahrscheinlich den besten Farbkontrast?

  • Hellgrauer Text auf weißem Hintergrund
  • Gelber Text auf weißem Hintergrund
  • Dunkelgrauer Text auf weißem Hintergrund
  • Hellblauer Text auf hellgrauem Hintergrund
Farben nicht allein zur Information
Warum?

Nicht alle Menschen nehmen Farben gleich wahr, z.B. bei Farbenblindheit oder schlechter Bildschirmdarstellung. Wenn Informationen ausschließlich durch Farbe vermittelt werden (z.B. „rot = Fehler“), sind sie für viele nicht zugänglich. Nur wenn zusätzlich Symbole, Text oder Muster verwendet werden, ist die Bedeutung für alle erfassbar.

Was tun?

Verwende niemals Farbe als alleiniges Mittel, um Informationen zu vermitteln. Ergänze farbliche Hinweise immer durch Text, Symbole oder visuelle Muster. Beispiele: Ein Fehlerfeld sollte nicht nur rot sein, sondern zusätzlich ein Warnsymbol oder die Beschriftung "Fehler" enthalten.

Beispiel:
<p><span style='color: red;'>❗ Fehler:</span> Bitte füllen Sie alle Pflichtfelder aus.</p>
In diesem Beispiel wird die Farbinformation durch ein Warnsymbol (❗) und das Wort 'Fehler:' ergänzt. So bleibt die Bedeutung auch dann erhalten, wenn die Farbe nicht wahrgenommen werden kann, z.B. bei Farbenblindheit oder Schwarzweißdarstellung. Das erfüllt die WCAG-Anforderung, Farbe nicht als einziges Mittel zur Informationsvermittlung zu verwenden.
Quiz:

Was verbessert die Zugänglichkeit einer farblich gekennzeichneten Fehlermeldung am besten?

  • Eine kräftigere Farbe verwenden
  • Die Fehlermeldung blinken lassen
  • Ein Symbol oder erklärender Text ergänzen
  • Den Text ganz weglassen und nur Farbe verwenden
Text Skalierbarkeit
Warum?

Viele Nutzer:innen mit Sehbeeinträchtigung sind auf größere Schriftgrößen angewiesen. Wenn Text sich nicht flexibel vergrößern lässt, oder dabei Inhalte überlappen oder verschwinden , wird die Seite schnell unlesbar oder unbenutzbar. Gut skalierbarer Text sorgt für bessere Lesbarkeit und ermöglicht individuelle Anpassungen.

Was tun?

Verwende relative Einheiten wie em, rem oder % für Schriftgrößen, statt feste Pixelwerte. Stelle sicher, dass sich Layout und Komponenten bei vergrößerter Schrift nicht überlappen oder abschneiden. Teste die Seite mit Zoom auf 200% in Browsern, ohne horizontales Scrollen.

Beispiel:
<style> body { font-size: 1rem; } </style> <p>Dieser Text kann problemlos skaliert werden, da eine relative Einheit verwendet wird.</p>
Aussage:

<style> body { font-size: 1rem; } .info-box { width: 200px; height: 100px; overflow: hidden; } </style> <div class='info-box'> <p>Wichtige Information, die nicht abgeschnitten werden darf.</p> </div> Dieser Code ist barrierefrei skalierbar und erfüllt WCAG 1.4.4.

Audio-Steuerung
Warum?

Automatisch abspielender Ton kann für viele Nutzer:innen verwirrend, überfordernd oder störend sein, besonders für Menschen mit kognitiven Einschränkungen oder Screenreader-Nutzer:innen. Wenn sich Audio nicht stoppen lässt, überlagert es ggf. Sprachausgabe und macht die Seite unbenutzbar.

Was tun?

Vermeide es, Audio automatisch zu starten. Falls doch, stelle sicher, dass der Ton nach spätestens 3 Sekunden stoppt oder sich klar und einfach pausieren oder stummschalten lässt. Verwende möglichst <audio controls> oder benutzerfreundliche eigene Steuerelemente.

Beispiel:
<p>Klicken Sie auf den Play-Button, um das Interview anzuhören:</p> <audio controls> <source src='interview.mp3' type='audio/mpeg'> </audio>
Hier startet das Audio nicht automatisch. Nutzer:innen können selbst entscheiden, ob und wann sie den Ton abspielen. Zusätzlich wird der Zweck des Audios durch einen erklärenden Text klar gemacht. So wird die WCAG-Anforderung erfüllt, dass Audio nicht automatisch startet und vollständig steuerbar ist.
Quiz:

Wie lässt sich sicherstellen, dass automatisch startendes Audio barrierefrei bleibt?

  • Indem man die Lautstärke auf niedrig stellt
  • Indem man es kürzer als 3 Sekunden macht oder eine Stop-Möglichkeit bietet
  • Indem man den Ton mit visuellen Effekten kombiniert
  • Indem man es auf leisen Geräten testet
Bedienbar
Tastaturzugänglichkeit
Navigation per Tab
Warum?

Nicht alle Menschen können eine Maus benutzen, etwa aufgrund motorischer Einschränkungen oder weil sie Assistenztechnologien wie Sprach- oder Bildschirmtastaturen verwenden. Wenn Inhalte nicht per Tastatur erreichbar sind, bleiben sie für viele unzugänglich. Die Tabulatortaste (Tab) ist dabei die wichtigste Navigationsmöglichkeit.

Was tun?

Stelle sicher, dass alle interaktiven Elemente mit der Tab-Taste fokussierbar sind und eine sinnvolle Reihenfolge haben. Verwende echte HTML-Elemente wie <button>, <a> mit href, <input> usw., da diese standardmäßig tastaturbedienbar sind. Vermeide Konstruktionen mit <div> oder <span> + JavaScript, die nicht per Tab erreichbar sind.

Beispiel:
Versuche mit der Tabulatortaste auf dieser Seite den nächsten Tipp zu öffnen.
Quiz:

Welches Element ist standardmäßig NICHT per Tab-Taste erreichbar?

  • <a href='/start'>Start</a>
  • <button>OK</button>
  • <input type='email'>
  • <div onclick='senden()'>Absenden</div>
Fokus-Design
Warum?

Wer eine Webseite ohne Maus bedient, ist auf die Tastatur angewiesen. Dabei navigieren Nutzer:innen mit der Tab-Taste von Element zu Element. Ohne sichtbaren Fokusindikator wissen sie nicht, wo sie sich gerade befinden, was die Nutzung unmöglich oder extrem frustrierend macht.

Was tun?

Sorge dafür, dass alle fokussierbaren Elemente einen gut sichtbaren Fokuszustand haben. Verwende dafür z.B. outline, border, box-shadow oder farbliche Hintergründe. Entferne niemals den Standard-Fokus, ohne eine sichtbare Alternative zu definieren. Teste die Seite mit der Tab-Taste!

Beispiel:
<style> a:focus, button:focus { outline: 3px solid #005fcc; background-color: #e0f0ff; } </style> <a href='/weiter'>Weiter</a> <button>Absenden</button> Teste den Fokus-Outline auf dieser Website, wenn du willst.
Aussage:

<style> button:focus { outline: none; } </style> <button>Absenden</button> Dieser Code erfüllt die WCAG-Anforderung 2.4.7 für sichtbaren Tastaturfokus.

Interaktive Elemente
Warum?

Wenn interaktive Elemente falsch umgesetzt sind, z.B. als <div> statt <button>, sind sie für Tastaturnutzer:innen oder Screenreader oft nicht zugänglich. Die Bedienung funktioniert dann nur mit der Maus, und die Funktion (z.B. 'Senden') wird nicht korrekt erkannt oder vorgelesen. Das führt zu Barrieren, selbst wenn das Element visuell "gut aussieht".

Was tun?

Verwende ausschließlich echte HTML-Elemente für Interaktionen: <button> für Aktionen, <a href> für Navigation, <input> für Eingaben. Vermeide es, eigene Click-Flächen mit <div> oder <span> zu bauen, da diese weder fokussierbar noch verständlich für Screenreader sind, es sei denn, du ergänzt explizit role, tabindex, aria-label und Tastatursteuerung (was fehleranfällig ist).

Beispiel:
<button onclick='absenden()'>Absenden</button>
Dieses Beispiel verwendet das semantisch korrekte `<button>`-Element für eine Aktion. Es ist automatisch mit der Tastatur bedienbar und wird von Screenreadern als Schaltfläche erkannt, inklusive Rolle und Aktion. So erfüllt es die WCAG-Anforderungen für Bedienbarkeit und Barrierefreiheit.
Quiz:

Welches dieser Elemente ist NICHT korrekt für eine interaktive Schaltfläche?

  • <button onclick='start()'>Start</button>
  • <a href='/start'>Startseite</a>
  • <input type='submit' value='Senden'>
  • <div onclick='senden()'>Absenden</div>
genügend Zeit geben
Genügend Zeit lassen
Warum?

Nicht alle Nutzer:innen können Aufgaben in einem engen Zeitrahmen bewältigen, etwa Menschen mit kognitiven Einschränkungen, motorischen Einschränkungen oder beim Einsatz von Hilfstechnologien. Wenn Formulare oder Inhalte ohne Vorwarnung ablaufen oder verschwinden, entstehen Barrieren und Frust.

Was tun?

Vermeide zeitliche Beschränkungen, wenn möglich. Falls sie notwendig sind (z.B. aus Sicherheitsgründen), gib Nutzer:innen vor Ablauf der Zeit eine Möglichkeit, diese zu verlängern oder zu deaktivieren. Zeige einen deutlichen Hinweis oder Countdown an und ermögliche z.B. per Button die Verlängerung der Sitzung.

Aussage:

Eine Webseite leitet Nutzer:innen nach 20 Sekunden automatisch zur nächsten Seite weiter, ohne dass sie das beeinflussen können. Da die Weiterleitung Teil des beabsichtigten Workflows ist, ist das mit der WCAG 2.2.1 vereinbar.

Anfälle vermeiden
Anfälle vermeiden
Warum?

Blinkende oder schnell flackernde Inhalte können bei Menschen mit fotosensibler Epilepsie Anfälle auslösen. Besonders gefährlich sind visuelle Effekte mit starkem Kontrast, großem Bildbereich und schneller Frequenz. Selbst wenige Sekunden solcher Inhalte können gravierende Folgen haben.

Was tun?

Vermeide jegliche Inhalte mit mehr als drei Blitzen pro Sekunde, besonders in hellem Rot oder Weiß. Verwende Animationen und Übergänge sanft, mit langsamer Bewegung und ausreichendem Kontrast. Prüfe blinkende Inhalte mit Tools wie dem Photosensitive Epilepsy Analysis Tool (PEAT) oder achte auf die sogenannte Drei-Blitze-Grenze.

Quiz:

Welcher Effekt kann potenziell epileptische Anfälle auslösen und sollte laut WCAG 2.3.1 vermieden werden?

  • Ein Button wird beim Hovern langsam heller.
  • Ein Hinweis blendet sich sanft ein.
  • Ein Element blinkt rot-weiß zehnmal pro Sekunde.
  • Ein Akkordeon klappt Inhalte langsam aus.
Navigierbarkeit
Skip-Links/Sprunglinks
Warum?

Nutzer:innen mit Screenreadern oder Tastaturbedienung möchten nicht bei jedem Seitenaufruf alle Menüpunkte durchgehen müssen. Ein sogenannter Sprunglink (Skip Link) ermöglicht es, direkt zum Hauptinhalt zu springen. Das spart Zeit, reduziert Frustration und ist besonders für Menschen mit motorischen Einschränkungen oder Sehbehinderungen wichtig.

Was tun?

Füge zu Beginn der Seite einen sichtbaren Sprunglink hinzu, der beim Fokussieren (z.B. über Tab-Taste) erscheint. Er sollte mit href="#main" o.ä. auf das Haupt-Container-Element verweisen (z.B. <main id="main">). Stelle sicher, dass er für Tastatur und Screenreader zugänglich ist und sich beim Fokussieren visuell abhebt.

Beispiel:
<a href='#main' class='skip'>Zum Inhalt springen</a> <main id='main'>...</main>
Der Link springt direkt zum Hauptinhalt. Solche Sprunglinks helfen Tastatur- und Screenreader-Nutzer:innen, sich schneller zurechtzufinden.
Aussage:

Ein Sprunglink hilft dabei, sich schneller zurechtzufinden

Seitenstruktur
Warum?

Viele Nutzer:innen z.B. mit Screenreadern navigieren gezielt über Überschriften durch die Seite. Wenn die Struktur sinnvoll gegliedert und beschriftet ist, können sie schneller finden, was sie brauchen. Auch für sehende Nutzer:innen verbessert eine klare Hierarchie das Leseerlebnis und die Übersicht.

Was tun?

Verwende echte HTML-Überschriften wie <h1>, <h2>, <h3> usw., um die inhaltliche Struktur der Seite abzubilden. Beginne mit genau einer <h1>, die den Haupttitel der Seite markiert. Unterüberschriften folgen dann in sinnvoller Reihenfolge, z.B. <h2> für Hauptabschnitte, <h3> für Unterabschnitte usw. Achte darauf, keine Hierarchieebenen zu überspringen, also z.B. nicht direkt von einer <h2> zu einer <h4> springen. Visuelle Hervorhebungen allein (z.B. große Schrift mit <div> oder <p>) ersetzen keine korrekte semantische Gliederung.

Beispiel:
<h1>Studienberatung</h1> <h2>Für Studienanfänger:innen</h2> <h3>Sprechzeiten</h3> <h2>Internationale Studierende</h2>
Die Überschriften sind sauber strukturiert: eine <h1> als Hauptüberschrift, darunter logisch verschachtelte <h2> und <h3>. Das ermöglicht strukturierte Navigation mit Screenreadern und sorgt für Übersichtlichkeit.
Quiz:

Welche Kombination entspricht den Anforderungen an eine sinnvolle Seitenstruktur nach WCAG 2.4.6?

  • Eine Seite hat mehrere <h1> für visuell wichtige Abschnitte und nutzt <p> für Unterüberschriften.
  • Eine Seite beginnt mit einer <h1>, nutzt <h2> für Hauptabschnitte und <h3> für Unterpunkte.
  • Überschriften werden durch CSS formatiert, aber ohne semantische <h*>-Elemente.
  • Eine Seite verwendet nur <h4> und <h5>, weil sie kleiner dargestellt werden sollen.
Linkbeschreibungen
Warum?

Viele Nutzer:innen, besonders mit Screenreader, springen von Link zu Link, ohne den umliegenden Text zu hören oder zu sehen. Wenn Links nur 'Hier klicken' heißen, wissen sie nicht, wohin der Link führt. Das führt zu unnötigem Aufwand und kann zur Verwirrung führen.

Was tun?

Formuliere Linktexte so, dass sie auch für sich genommen verständlich sind. Nutze z.B. 'Informationen zur Studienberatung' statt 'Hier klicken'. Wenn der Linktext allein nicht reicht, kann der Zweck auch im direkten Kontext davor oder danach eindeutig erkennbar sein, z.B. in Tabellen oder Listen. Achte darauf, dass gleiche Links auch gleich benannt sind und unterschiedliche Links nicht denselben Text tragen.

Beispiel:
<p>Weitere Infos findest du unter <a href='/studienberatung'>Informationen zur Studienberatung</a>.</p>
Der Linktext ist eindeutig und beschreibt klar, wohin er führt. Auch ohne Kontext ist er verständlich.
Quiz:

Warum ist der Linktext 'Mehr erfahren' problematisch im Sinne der Barrierefreiheit?

  • Weil er zu lang ist.
  • Weil er bei mehreren Vorkommen nicht eindeutig ist, was den Linkzweck betrifft.
  • Weil Screenreader den Link nicht erkennen können.
  • Weil er nicht klickbar ist.
Eingabemethoden
Eingabemethoden
Warum?

Nicht alle Nutzer:innen können präzise wischen, ziehen oder tippen. Kleine Touchflächen oder rein gestenbasierte Interaktionen stellen für viele Menschen eine Barriere dar, z.B. bei eingeschränkter Feinmotorik, zittrigen Händen oder der Nutzung von Hilfsmitteln. Gute Bedienbarkeit heißt: Alternativen bereitstellen und ausreichend große, einfach erreichbare Ziele schaffen.

Was tun?

Sorge dafür, dass alle Touchziele groß genug sind, z.B. mindestens 44*44 Pixel. Wenn eine Funktion Drag-and-Drop oder bestimmte Gesten erfordert, biete zusätzlich eine alternative Möglichkeit per Button oder Tastatur an. Verzichte auf komplexe Eingaben wie Wischen mit drei Fingern oder langes Halten, wenn sie nicht durch einfachere Interaktionen ergänzt werden. So wird die Bedienung robuster und inklusiver.

Aussage:

Wenn eine Funktion sowohl per Drag-and-Drop als auch über Schaltflächen bedient werden kann, profitieren davon auch Nutzer:innen ohne Einschränkungen.

Verständlich
Lesbar
Einfache Sprache
Warum?

Viele Menschen haben Schwierigkeiten mit komplizierter Sprache, z.B. Menschen mit Lernschwierigkeiten, geringen Deutschkenntnissen, kognitiven Einschränkungen oder in stressigen Situationen. Wenn Inhalte zu verschachtelt, abstrakt oder fachlich sind, werden wichtige Informationen übersehen oder missverstanden. Einfache Sprache hilft allen, sich schneller zurechtzufinden, ohne Inhalte zu vereinfachen, sondern durch gute Verständlichkeit.

Was tun?

Vermeide Fachbegriffe, Fremdwörter und lange Schachtelsätze, besonders bei wichtigen Hinweisen. Erkläre, wenn nötig, Begriffe oder gib Beispiele. Verwende klare Verben und aktive Sprache. Gut strukturierte Texte mit Zwischenüberschriften, kurzen Absätzen und Listen helfen ebenfalls beim Verstehen. Besonders wichtige Inhalte kannst du zusätzlich in Leichter Sprache anbieten, das ist nicht verpflichtend, aber hilfreich.

Beispiel:
<p>Du brauchst Hilfe bei der Bewerbung? Wir erklären dir Schritt für Schritt, wie das geht.</p>
Der Text ist kurz, klar formuliert und verwendet keine Fachbegriffe. So verstehen ihn auch Menschen mit geringem Sprachniveau oder in Stresssituationen leicht.
Quiz:

Welche Formulierung ist am besten geeignet, um möglichst viele Nutzer:innen zu erreichen?

  • Bitte beachten Sie die aktuellen Regularien zur Antragstellung im Rahmen des §5 Abs. 3.
  • Zur Einreichung der Unterlagen kontaktieren Sie bitte das zuständige Referat.
  • Du willst etwas beantragen? Hier erklären wir dir, wie es geht.
  • Der Informationsprozess zur fristgerechten Antragstellung wurde aktualisiert.
Sprachauszeichnung
Warum?

Screenreader nutzen die Sprachauszeichnung, um den richtigen Sprachmodus zu aktivieren. Wenn z.B. ein englisches Wort nicht als Englisch gekennzeichnet ist, wird es im deutschen Sprachmodus oft unverständlich oder falsch ausgesprochen. Das betrifft nicht nur Fremdwörter, sondern auch Zitate, Eigennamen oder Textelemente wie Menüs in anderen Sprachen. Ohne diese Auszeichnung wird die Verständlichkeit erheblich beeinträchtigt.

Was tun?

Gib im <html>-Tag die Hauptsprache der Seite an, z.B. lang='de'. Wenn innerhalb des Inhalts Wörter oder Absätze in einer anderen Sprache vorkommen, markiere sie mit lang='', z.B. lang='en' für Englisch. Diese Markierung ist für Nutzer:innen nicht sichtbar, aber entscheidend für die korrekte Sprachausgabe von Screenreadern und anderen Hilfsmitteln.

Beispiel:
<p>Die Veranstaltung findet auf <span lang='en'>Zoom</span> statt.</p>
Das englische Wort 'Zoom' ist mit lang='en' ausgezeichnet. So kann ein Screenreader korrekt zwischen deutscher und englischer Aussprache wechseln.
Quiz:

Warum ist es wichtig, Fremdwörter wie 'Login' oder 'Zoom' im Code mit der richtigen Sprache zu markieren?

  • Weil sonst ein Übersetzungsfehler im Browser passiert.
  • Damit sie optisch hervorgehoben werden.
  • Damit Screenreader sie richtig aussprechen können.
  • Weil es ohne Markierung nicht klickbar ist.
Erklärungen für Abkürzungen
Warum?

Nicht alle Nutzer:innen verstehen Abkürzungen wie BAföG, LSF oder ZSB sofort, vor allem, wenn sie neu an der Hochschule sind, eine andere Muttersprache sprechen oder kognitive Einschränkungen haben. Unerklärte Kürzel können zu Missverständnissen oder Frust führen. Wer Inhalte wirklich barrierefrei gestalten möchte, sollte solche Hürden vermeiden.

Was tun?

Schreibe Abkürzungen beim ersten Vorkommen aus, z.B.: 'Zentrale Studienberatung (ZSB)'. Wiederholungen können dann abgekürzt erfolgen. Erklärungen sollten gut sichtbar im Fließtext stehen, nicht nur versteckt im title-Attribut oder Tooltip, da diese für viele Nutzer:innen nicht zugänglich sind. Falls du zusätzlich abbr oder Tooltips nutzt, dann nur als ergänzende Hilfe, nicht als alleinige Erklärung.

Beispiel:
<p>Die Zentrale Studienberatung (ZSB) hilft dir bei allen Fragen zum Studium.</p>
Die Abkürzung 'ZSB' wird im Text direkt erklärt. So verstehen alle Nutzer:innen sofort, was gemeint ist, unabhängig von Vorwissen oder Technik.
Aussage:

Ein Hinweis auf die Bedeutung einer Abkürzung, der beim Überfahren mit der Maus erscheint, ist barrierefrei.

Vorhersehbar
Vorhersehbarkeit
Warum?

Verlässlichkeit und Wiedererkennbarkeit sind entscheidend für eine gute Nutzendenerfahrung, besonders für Menschen mit kognitiven Einschränkungen, Lernschwierigkeiten oder Konzentrationsproblemen. Wenn sich z.B. Navigationselemente ständig ändern oder ein Link plötzlich ein Formular abschickt, führt das zu Unsicherheit oder Fehlbedienung. Konsistenz schafft Orientierung und reduziert Stress.

Was tun?

Strukturiere Menüs, Buttons und Seitenlayouts so, dass sie sich auf allen Unterseiten ähnlich verhalten und aussehen. Verwende für wiederkehrende Funktionen dieselben Begriffe, Icons und Platzierungen. Links sollten sich wie Links verhalten, also z.B. nicht plötzlich neue Fenster öffnen oder Inhalte ohne Hinweis verändern. Unerwartete Interaktionen (z.B. automatisches Absenden beim Fokussieren eines Felds) solltest du vermeiden oder klar ankündigen.

Aussage:

Wenn ein Link 'Kontakt' heißt, aber beim Klicken ein PDF herunterlädt, kann das für viele Nutzer:innen verwirrend sein.

Hilfen bei der Eingabe
Formularvalidierung
Warum?

Formulare sind eine häufige Stolperfalle: Wer versehentlich ein Pflichtfeld leer lässt oder ein falsches Datumsformat eingibt, braucht verständliche Hinweise, sonst kommt Frust oder sogar Abbruch. Menschen mit Lernschwierigkeiten, Sprachbarrieren oder wenig Technik-Erfahrung sind besonders darauf angewiesen, dass Rückmeldungen klar formuliert und hilfreich sind.

Was tun?

Stelle sicher, dass Fehler bei der Eingabe automatisch erkannt werden, z.B. durch HTML-Validierung oder serverseitige Prüfung. Zeige deutlich an, welches Feld betroffen ist und formuliere verständlich, was falsch war und wie man es korrigieren kann (z.B. 'Bitte gib ein Datum im Format TT.MM.JJJJ ein.'). Fehlermeldungen sollten gut sichtbar sein, am besten direkt beim jeweiligen Feld oder zusätzlich als Zusammenfassung am Seitenanfang.

Beispiel:
<label for='email'>E-Mail</label> <input id='email' type='email' required> <span class='error'>Bitte gib eine gültige E-Mail-Adresse ein.</span>
Wenn das Feld falsch ausgefüllt wird, erscheint eine klare Fehlermeldung in der Nähe des Felds. Nutzer:innen wissen so, was falsch ist und was erwartet wird.
Quiz:

Was trägt am meisten zur Barrierefreiheit bei, wenn ein Formularfehler auftritt?

  • Die Fehlermeldung wird oben auf der Seite eingeblendet.
  • Es erscheint ein rotes Ausrufezeichen neben dem Feld.
  • Das fehlerhafte Feld wird markiert und es steht direkt daneben, was korrigiert werden muss.
  • Das Formular wird einfach nicht abgeschickt, ohne Hinweis.
Pflichtfelder deutlich machen
Warum?

Wenn nicht klar ist, welche Felder verpflichtend sind, kommt es zu Irritationen: Nutzer:innen übersehen Eingaben, verstehen Fehlermeldungen nicht oder brechen das Formular ab. Für Menschen mit kognitiven Einschränkungen oder Sprachbarrieren ist eine eindeutige Kennzeichnung besonders wichtig, aber auch alle anderen profitieren davon.

Was tun?

Kennzeichne Pflichtfelder klar und konsistent, z.B. durch ein Sternchen (*) in der Beschriftung oder durch einen erklärenden Hinweis wie 'Alle mit * gekennzeichneten Felder sind Pflichtfelder'. Optionalfelder solltest du ggf. ebenfalls benennen, z.B. mit '(optional)'. Achte darauf, dass die Information nicht nur visuell (z.B. durch Farbe) vermittelt wird, sondern auch für Screenreader erkennbar ist.

Beispiel:
<label for='name'>Name *</label> <input id='name' required> <p>Felder mit * sind Pflichtfelder.</p>
Das Sternchen in der Beschriftung macht deutlich, dass das Feld verpflichtend ist. Der erklärende Hinweis sorgt für Klarheit, auch bei Screenreader-Nutzung.
Aussage:

Wenn Pflichtfelder nur durch eine rote Umrandung gekennzeichnet sind, ist das für alle Nutzer:innen barrierefrei zugänglich.

Hilfetexte/Beispiele
Warum?

Unklare Formulareingaben führen schnell zu Fehlern, zum Beispiel wenn ein Datum eingegeben werden soll, aber das gewünschte Format nicht angegeben ist. Für viele Nutzer:innen, insbesondere mit kognitiven Einschränkungen, Lernschwierigkeiten oder geringen Sprachkenntnissen, sind Hilfetexte oder Beispiele entscheidend, um Eingaben richtig zu machen und Frust zu vermeiden.

Was tun?

Gib bei Bedarf Hinweise direkt beim Feld, z.B. 'Format: TT.MM.JJJJ' bei einem Datumsfeld. Verwende Hilfetexte oberhalb, unterhalb oder innerhalb des Felds (z.B. als placeholder), aber achte darauf, dass wichtige Hinweise auch außerhalb von Platzhaltern stehen, da placeholder-Texte nicht dauerhaft sichtbar sind. Beispiele helfen, die erwartete Eingabeform zu verdeutlichen, ohne dass Nutzer:innen raten müssen.

Beispiel:
<label for='geburtstag'>Geburtsdatum</label> <input id='geburtstag' type='text'> <p>Format: TT.MM.JJJJ (z.B. 15.08.2001)</p>
Der Hinweis erklärt klar das erwartete Format für das Datum und gibt ein Beispiel. So sinkt die Wahrscheinlichkeit für Eingabefehler.
Quiz:

Welche Lösung hilft am meisten, damit Nutzer:innen ein Datumsfeld korrekt ausfüllen?

  • Ein Platzhalter mit dem Text 'TT.MM.JJJJ', der beim Klicken verschwindet.
  • Ein erklärender Text unter dem Feld mit 'Format: TT.MM.JJJJ (z.B. 01.09.2004)'.
  • Gar kein Hinweis, das Format ergibt sich von selbst.
Autovervollständigung aktivieren
Warum?

Viele Nutzer:innen, besonders mit motorischen Einschränkungen oder kognitiven Beeinträchtigungen, profitieren davon, wenn sie wiederkehrende Informationen nicht immer neu eingeben müssen. Autovervollständigung spart Zeit, reduziert Tippfehler und macht Formulare einfacher zugänglich. Damit das funktioniert, müssen Felder technisch korrekt mit autocomplete-Attributen versehen sein.

Was tun?

Nutze bei gängigen Formularfeldern passende autocomplete-Attribute, z.B. autocomplete='email', name, postal-code, tel, given-name, family-name, organization, address-line1 usw. Diese Angaben helfen nicht nur dem Browser, sondern auch unterstützenden Technologien wie Passwortmanagern oder Sprachsteuerung. Achte darauf, dass die Autovervollständigung nicht deaktiviert ist, außer in begründeten Ausnahmefällen (z.B. bei hochsensiblen Eingaben).

Beispiel:
<label for='email'>E-Mail</label> <input id='email' type='email' autocomplete='email'>
Das Feld ist mit autocomplete='email' ausgezeichnet. Browser und Hilfstechnologien können so passende Vorschläge machen und die Eingabe erleichtern.
Aussage:

Damit die Autovervollständigung funktioniert, muss das entsprechende Eingabefeld mit einem passenden autocomplete-Wert ausgezeichnet sein.

Robust
Kompatibilität
Valides HTML & CSS
Warum?

Assistive Technologien wie Screenreader sind darauf angewiesen, dass HTML und CSS fehlerfrei strukturiert sind. Wenn z.B. Tags nicht geschlossen, verschachtelt oder falsch geschrieben sind, kann es passieren, dass Inhalte gar nicht vorgelesen oder falsch interpretiert werden. Auch visuelle Darstellungen oder Formularfunktionen können dadurch unzugänglich werden. Valider Code ist die Grundlage für barrierefreie Technik.

Was tun?

Nutze standardkonformes HTML und CSS und prüfe deinen Code regelmäßig mit Validierungs-Tools wie dem W3C Validator. Achte besonders auf korrekt geschlossene Tags, eindeutige Attribute, gültige Rollen und saubere Struktur. Auch kleine Fehler können große Auswirkungen auf die Zugänglichkeit haben, insbesondere bei dynamischen Inhalten oder Formularen.

Semantik
Warum?

Semantische HTML-Elemente vermitteln Screenreadern, was ein Inhalt bedeutet, nicht nur wie er aussieht. Wenn z.B. ein Text optisch wie eine Überschrift formatiert ist, aber technisch nur ein <div> ist, erkennt ein Screenreader ihn nicht als solche. Auch Buttons, Links, Formulare oder Listen müssen korrekt ausgezeichnet sein, damit sie von Tastatur, Screenreader und anderen Hilfsmitteln zuverlässig erkannt und bedient werden können.

Was tun?

Verwende für Überschriften echte <h*>-Elemente, für Navigation <nav>, für Buttons <button>, für Listen <ul>/<ol> und für Formulareingaben passende <label>, <input> usw. Vermeide es, rein optisch zu gestalten, z.B. mit großem Text in einem <div> als Ersatz für eine echte Überschrift. Saubere Semantik verbessert nicht nur Barrierefreiheit, sondern auch Wartbarkeit.

ARIA korrekt anwenden
Warum?

ARIA kann die Zugänglichkeit verbessern, aber nur, wenn es korrekt und gezielt eingesetzt wird. Falsch oder überflüssig verwendete ARIA-Attribute führen schnell zu Problemen: Screenreader-Nutzer:innen hören verwirrende Rollen, wichtige Inhalte werden unsichtbar gemacht oder Interaktionen sind nicht mehr verständlich. Wer ARIA einfach überall verwendet, schadet oft mehr als es hilft. Gute Barrierefreiheit entsteht nicht durch möglichst viele ARIA-Attribute, sondern durch ihren sinnvollen Einsatz an den richtigen Stellen.

Was tun?

Nutze zuerst immer semantisch korrektes HTML. Setze ARIA nur ein, wenn es dafür einen echten Bedarf gibt, etwa bei selbstgebauten Komponenten wie aufklappbaren Menüs, Slidern oder Live-Meldungen. Verwende dann gezielt passende Attribute wie aria-expanded, aria-label, aria-live, aber achte auf die vollständige und korrekte Anwendung. Vermeide es, wahllos Rollen zu vergeben oder Inhalte mit aria-hidden zu verstecken, wenn sie zugänglich sein sollen.

* Die Quelle, die als Basis für die Tipps, sowie Struktur verwendet wurde sind die WCAG: https://www.w3.org/WAI/standards-guidelines/wcag/