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.
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.
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:
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.*
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.
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.
Welcher Alt-Text ist am besten für ein Bild von Professorin Müller, das im Team-Bereich einer Website gezeigt wird?
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.
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.
Ein Icon-Button ohne sichtbaren Text braucht keine zusätzliche Beschriftung, solange das Symbol verständlich ist.
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.
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.
Welche Beschreibung macht ein Video für blinde Nutzer:innen verständlicher?
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.
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.
Für welches der folgenden Bilder sollte am ehesten Alt-Text vergeben werden?
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.
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.
Welche CAPTCHA-Variante ist barrierearm und für möglichst viele Nutzer:innen zugänglich?
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.
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.
<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).
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.
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.
<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.
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.
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.
Welche Aussage über Audiodeskriptionen ist korrekt?
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.
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.
Welche HTML-Struktur ist semantisch korrekt, um eine Kontaktadresse auszuzeichnen?
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.
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.
Welche HTML-Struktur ist semantisch korrekt für ein Formularfeld mit Beschriftung?
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.
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.
<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.
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.
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.
Welches Text-Beispiel hat wahrscheinlich den besten Farbkontrast?
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.
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.
Was verbessert die Zugänglichkeit einer farblich gekennzeichneten Fehlermeldung am besten?
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.
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.
<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.
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.
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.
Wie lässt sich sicherstellen, dass automatisch startendes Audio barrierefrei bleibt?
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.
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.
Welches Element ist standardmäßig NICHT per Tab-Taste erreichbar?
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.
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!
<style> button:focus { outline: none; } </style> <button>Absenden</button> Dieser Code erfüllt die WCAG-Anforderung 2.4.7 für sichtbaren Tastaturfokus.
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".
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).
Welches dieser Elemente ist NICHT korrekt für eine interaktive Schaltfläche?
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.
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.
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.
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.
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.
Welcher Effekt kann potenziell epileptische Anfälle auslösen und sollte laut WCAG 2.3.1 vermieden werden?
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.
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.
Ein Sprunglink hilft dabei, sich schneller zurechtzufinden
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.
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.
Welche Kombination entspricht den Anforderungen an eine sinnvolle Seitenstruktur nach WCAG 2.4.6?
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.
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.
Warum ist der Linktext 'Mehr erfahren' problematisch im Sinne der Barrierefreiheit?
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.
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.
Wenn eine Funktion sowohl per Drag-and-Drop als auch über Schaltflächen bedient werden kann, profitieren davon auch Nutzer:innen ohne Einschränkungen.
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.
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.
Welche Formulierung ist am besten geeignet, um möglichst viele Nutzer:innen zu erreichen?
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.
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.
Warum ist es wichtig, Fremdwörter wie 'Login' oder 'Zoom' im Code mit der richtigen Sprache zu markieren?
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.
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.
Ein Hinweis auf die Bedeutung einer Abkürzung, der beim Überfahren mit der Maus erscheint, ist barrierefrei.
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.
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.
Wenn ein Link 'Kontakt' heißt, aber beim Klicken ein PDF herunterlädt, kann das für viele Nutzer:innen verwirrend sein.
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.
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.
Was trägt am meisten zur Barrierefreiheit bei, wenn ein Formularfehler auftritt?
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.
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.
Wenn Pflichtfelder nur durch eine rote Umrandung gekennzeichnet sind, ist das für alle Nutzer:innen barrierefrei zugänglich.
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.
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.
Welche Lösung hilft am meisten, damit Nutzer:innen ein Datumsfeld korrekt ausfüllen?
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.
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).
Damit die Autovervollständigung funktioniert, muss das entsprechende Eingabefeld mit einem passenden autocomplete-Wert ausgezeichnet sein.
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.
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.
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.
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 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.
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/