Zum Hauptinhalt springen

Checkliste: Barrierefreiheit nach BFSG/BITV 2.0 (WCAG 2.1 AA)

Diese ausführliche Checkliste hilft dabei, Websites gemäß dem deutschen Barrierefreiheitsstärkungsgesetz (BFSG) barrierefrei zu gestalten. Sie orientiert sich an den gesetzlichen Vorgaben der Barrierefreie-Informationstechnik-Verordnung (BITV 2.0) und den Web Content Accessibility Guidelines (WCAG) 2.1 Konformitätsstufe AA. Die Prüfpunkte sind nach den vier Prinzipien der Barrierefreiheit gegliedert – Wahrnehmbarkeit, Bedienbarkeit, Verständlichkeit und Robustheit – und können als praktische abhakbare Liste genutzt werden.

Wahrnehmbarkeit (Perceivability)

Textalternativen

  • Bilder und Grafiken: Alle informativen Bilder, Icons und Grafiken haben aussagekräftige Alternativtexte (alt-Attribut), die den Inhalt oder Zweck beschreiben. Reine Dekorationen tragen entweder ein leeres alt="" oder werden per CSS eingebunden, damit sie von Screenreadern ignoriert werden.

  • CAPTCHAs: Falls visuelle CAPTCHAs eingesetzt werden, sind barrierefreie Alternativen vorhanden – z. B. ein Audiocaptcha oder eine andere Verifizierungsmethode –, damit auch Nutzer mit Behinderung den Test lösen können.

Zeitbasierte Medien (Audio/Video)

  • Videos: Für eingebundene Videos mit Ton stehen Untertitel (Captions) zur Verfügung, damit auch hörbehinderte Nutzer alle Informationen erfassen können. Wichtige visuelle Inhalte in Videos werden entweder durch Audiodeskriptionen oder alternative Text-Beschreibungen vermittelt, um sie für blinde Nutzer wahrnehmbar zu machen. (Beispiel: Ein erklärendes Video auf der Startseite enthält Untertitel und eine Audiodeskription für visuelle Elemente.)

  • Audio: Reine Audio-Inhalte (z. B. Podcasts) werden durch ein Transkript oder eine gleichwertige textliche Zusammenfassung ergänzt, sodass die Informationen auch ohne Gehör aufgenommen werden können.

Struktur und Anpassbarkeit

  • Semantische Struktur: Inhalte sind logisch und semantisch strukturiert. Überschriften sind in der richtigen Hierarchie ausgezeichnet (<h1> … <h2> etc.), Listen als <ul>/<ol> umgesetzt, Tabellen mit <th>-Headern versehen usw., damit Zusammenhänge und Informationen für alle Nutzer erkennbar sind. Formularelemente besitzen zugehörige <label>-Beschriftungen, und generell werden Beziehungen im Layout nicht nur visuell, sondern auch im Code vermittelt (WCAG 2.1 Erfolgskriterium 1.3.1).

  • Ausrichtung des Bildschirms: Die Website unterstützt verschiedene Bildschirm-Orienta­tionen. Inhalte sind sowohl im Hochformat (Portrait) als auch im Querformat (Landscape) gut nutzbar, ohne dass eine bestimmte Ausrichtung erzwungen wird (z.B. Apps/Seiten lassen sich nicht nur im Querformat anzeigen).

  • Vergrößerung und Zoom: Benutzer können die Darstellung bis auf 200 % vergrößern, ohne dass Inhalte oder Funktionen verloren gehen. Es entsteht kein horizontales Scrollen bei 200 %-Zoom auf gängigen Bildschirmgrößen; das Layout passt sich an (Reflow). Texte bleiben bei Vergrößerung lesbar und überlappen sich nicht oder werden nicht abgeschnitten. Die Website funktioniert zuverlässig mit den Browser-Zoomfunktionen (Strg/⌘+Plus) und erfordert keine spezielle Schriftgrößen-Umschaltfunktion.

Visuelles Design

  • Farben und Kontraste: Informationen werden nie ausschließlich durch Farbe vermittelt – es gibt immer auch eine textliche oder grafische Kennzeichnung. (Beispiel: Fehler werden nicht nur durch rote Umrandung markiert, sondern zusätzlich durch eine Fehlermeldung im Text.) Alle Texte und Bedienelemente weisen zudem ausreichende Kontraste auf. Für Fließtext in normaler Größe beträgt das Kontrastverhältnis mindestens 4,5:1 (für große Schrift ab 18pt bzw. 14pt fett mindestens 3:1). Ebenso haben grafische UI-Elemente und Icons einen Kontrast von mindestens 3:1 zum Hintergrund. (Ausnahmen gelten nur für unwesentliche Dekorationen, Logos o. ä..)

  • Audio ohne Zwang: Es wird kein Audio oder Video automatisch abgespielt, sobald eine Seite lädt, oder der Nutzer kann autostartende Medien sofort pausieren bzw. stummschalten. Insbesondere Hintergrundmusik oder -videos dürfen nicht ungefragt und endlos laufen (WCAG 2.1 Erfolgskriterium 1.4.2 verlangt, dass Medien, die länger als 3 Sekunden automatisch laufen, eine Pausen-/Stopp-Funktion haben).

  • Kein Text als Bild: Auf reinen Text in Grafikform wird verzichtet. Texte (z. B. Überschriften, Beschriftungen) werden als echte Web-Texte umgesetzt und nicht in Bildern eingebettet, außer es ist unvermeidbar (etwa bei Logos oder Branding). Falls doch ausnahmsweise ein Text als Teil einer Grafik vorliegt, enthält der Alternativtext die entsprechende Information.

  • Inhalt bei Hover oder Fokus: Wenn Inhalte bei Hover oder Fokus erscheinen (z. B. Tooltips, Dropdown-Menüs), sind diese für den Nutzer zugänglich: Sie versperren nicht den Blick auf andere Inhalte, bleiben so lange sichtbar, wie der Mauszeiger oder Tastaturfokus darauf bleibt, und können vom Nutzer auch manuell geschlossen werden. (Beispiel: Ein Tooltip, der beim Fokussieren einer Schaltfläche erscheint, lässt sich durch Drücken der Esc-Taste schließen.)

  • Gebärdensprache (BITV-Anforderung): Für wesentliche Inhalte, insbesondere auf der Startseite, wird eine Erklärung in Deutscher Gebärdensprache (DGS) angeboten (z. B. als Video). Darin werden die Hauptinhalte der Website sowie Hinweise zur Navigation verständlich in Gebärdensprache vermittelt.

  • Leichte Sprache (BITV-Anforderung): Es wird ein Bereich in Leichter Sprache bereitgestellt, der die wesentlichen Inhalte der Website und die Navigation in sehr einfacher, leicht verständlicher Sprache zusammenfasst. Diese Inhalte in Leichter Sprache sind von der Startseite aus leicht erreichbar.

Bedienbarkeit (Operability)

Tastatur-Navigation und Fokus

  • Tastaturbedienung: Alle Funktionen der Website sind vollständig mit der Tastatur bedienbar. Das heißt, jeder interaktive Inhalt (Links, Buttons, Formularelemente, Menüs usw.) kann über die Tabulator-Taste oder andere Tastatureingaben erreicht und aktiviert werden, ohne Maus oder Touchscreen.

  • Keine Tastaturfalle: Es gibt keine Tastaturfallen. Der Fokus lässt sich jederzeit weiterbewegen und auch wieder vom Element lösen – der Nutzer kann z.B. ein eingebettetes Widget oder Dialogfeld per Tastatur betreten und es anschließend wieder verlassen, ohne steckenzubleiben.

  • Sichtbarer Fokus: Der Tastaturfokus ist visuell hervorgehoben, sodass stets erkennbar ist, welches Element aktuell fokussiert ist. (Zum Beispiel wird der fokussierte Link oder Button durch einen gut sichtbaren Rahmen oder Hintergrundfarbmarkierung angezeigt.)

  • Logische Fokus-Reihenfolge: Die Reihenfolge, in der man per Tastatur durch die Seite navigiert, ist sinnvoll und logisch. Sie folgt dem visuellen Aufbau der Seite und den logischen Abläufen (z.B. bei Formularen), damit die Bedienung vorhersehbar bleibt. Beim Öffnen von Dialogen oder Overlays erhält das Dialogfeld den Fokus, und beim Schließen springt der Fokus zurück an eine sinnvolle Stelle.

Navigation und Orientierung

  • Seitentitel: Jede Seite besitzt einen aussagekräftigen Titel im HTML-<title>-Element, der ihren Inhalt oder Zweck eindeutig beschreibt (z. B. "Produktkatalog – Unternehmen XYZ" anstelle von generischen Titeln).

  • Bereiche überspringen: Es existiert eine Möglichkeit, wiederkehrende Seitenelemente zu überspringen – z. B. ein “Zum Inhalt springen”-Link am Seitenanfang, der direkt zum Hauptinhalt führt. (Alternativ können auch ARIA-Landmark-Rollen für Hauptbereiche genutzt werden, sofern Screenreader-Nutzer so effektiv navigieren können.)

  • Mehrere Zugangswege: Für umfangreichere Websites werden alternative Navigationswege angeboten, um Inhalte leichter zu finden. Beispielsweise können Nutzer eine Suchfunktion, eine Sitemap oder ein Inhaltsverzeichnis nutzen, zusätzlich zur normalen Menü-Navigation.

  • Beschreibende Linktexte: Links und Schaltflächen sind so benannt, dass ihr Zweck klar erkennbar ist. Vermeiden Sie nichtssagende Beschriftungen wie “Hier klicken”. Stattdessen macht der Linktext deutlich, was den Nutzer erwartet (z. B. “Produktbroschüre herunterladen (PDF, 2 MB)” statt “Hier klicken”).

Zeitlimits und Animationen

  • Zeitbegrenzungen: Falls es Funktionen mit Zeitlimit gibt (z. B. automatische Sitzungs-Timeouts oder zeitgesteuerte Formularabbruch), wird der Nutzer rechtzeitig gewarnt und hat die Möglichkeit, den Zeitraum bei Bedarf zu verlängern. Standardmäßig sind Zeitlimits ausreichend großzügig bemessen, sodass auch langsamere Nutzer alle Aufgaben erledigen können, ohne unter Zeitdruck zu geraten (WCAG 2.1 Erfolgskriterium 2.2.1).

  • Animationen anhalten: Bewegungseffekte oder automatisch ablaufende Animationen (z. B. Bilderkarussells, Auto-Scrolling-Inhalte) können vom Nutzer angehalten, gestoppt oder ausgeblendet werden. Es werden Bedienelemente (Pause/Stop) bereitgestellt, um bewegte Inhalte zu kontrollieren, sofern die Animation länger als 5 Sekunden läuft.

  • Kein gefährliches Flackern: Auf der Website gibt es keine stark flackernden Inhalte, um das Risiko von epileptischen Anfällen zu minimieren. Insbesondere werden keine Elemente eingesetzt, die mehr als drei Blitze pro Sekunde erzeugen (WCAG 2.1 Erfolgskriterium 2.3.1).

Eingabemodalitäten (Maus, Touch, Gesten)

  • Keine Einzeltasten-Kürzel: Die Bedienung der Website erfordert keine nicht anpassbaren Einzeltasten-Tastenkürzel (wie z.B. drücke allein “B” für Suche), die mit Screenreader- oder Browser-Shortcuts kollidieren könnten. Falls solche Tastenkürzel angeboten werden, kann der Nutzer sie deaktivieren oder anpassen, oder sie werden nur aktiv, wenn das zugehörige Element Fokus hat.

  • Alternativen für Zeigergesten: Funktionen, die eine komplexe Zeigergeste erfordern (z.B. Wischen, Ziehen mit Drag&Drop, Mehrfingergesten), sind auch anders nutzbar. Es existieren alternative Bedienelemente oder Methoden, die die gleiche Aktion auslösen – zum Beispiel zusätzliche Vor-/Zurück-Schaltflächen, wenn Inhalte durch Wischgesten gesteuert werden.

  • Pointer-Aktion bei Loslassen: Bei Maus- oder Touch-Bedienung werden Aktionen nicht sofort beim Drücken (Mouse-Down/Touch-Start) ausgeführt, sondern erst beim Loslassen (Mouse-Up/Touch-End). Dadurch können Nutzer eine Eingabe abbrechen, indem sie den Zeiger wegbewegen, und versehentliche Aktivierungen werden vermieden.

  • Beschriftung im Namen: Die sichtbare Bezeichnung eines Bedienelements (z.B. der Text auf einem Button) ist im programmatischen Namen enthalten. Das bedeutet: Screenreader geben dasselbe oder zumindest das enthaltene Wortlaut aus, das visuell auf dem Element steht. (Beispiel: Ein Button mit dem sichtbaren Text “Suche” sollte auch programmgesteuert als “Suche” benannt sein und nicht ein abweichendes aria-label wie “Absenden” besitzen.)

  • Gerätesensoren deaktivierbar: Funktionen, die durch Bewegung des Geräts oder durch Sensoren ausgelöst werden (z.B. Schütteln oder Neigen eines Smartphones, um eine Aktion auszuführen), sind auch über normale Bedienelemente auslösbar. Zudem kann die Bewegungserkennung deaktiviert werden, damit Nutzer nicht gezwungen sind, ihr Gerät zu schütteln oder zu kippen. (Dies stellt sicher, dass z.B. jemand mit motorischen Einschränkungen die Funktion trotzdem nutzen kann.)

Verständlichkeit (Understandability)

Sprache und Inhalt

  • Hauptsprache angegeben: Die Standardsprache der Webseite ist im HTML deklariert (z. B. <html lang="de"> für Deutsch). So wissen Browser und Hilfsmittel, in welcher Sprache der Inhalt verfasst ist.

  • Sprachwechsel markiert: Wenn innerhalb einer Seite die Sprache wechselt – etwa bei Zitaten, Fremdwörtern oder englischen Begriffen – ist dies im Code kenntlich gemacht (z. B. <span lang="en">...</span> für ein englisches Wort in einer deutschen Seite). Damit können Screenreader die Aussprache automatisch anpassen.

  • Klare, einfache Sprache: Die Texte sind möglichst verständlich und klar formuliert. Lange oder verschachtelte Sätze werden vermieden. Falls Fachbegriffe, Abkürzungen oder ungewöhnliche Wörter verwendet werden, werden diese bei der ersten Verwendung erklärt oder es wird eine einfachere Umschreibung angeboten. (Ziel: Auch Nutzer mit kognitiven Einschränkungen oder geringerer Lesekompetenz können den Inhalten folgen.)

Vorhersehbarkeit und Konsistenz

  • Keine unerwarteten Änderungen: Die Benutzeroberfläche verhält sich vorhersehbar. Weder das Fokussieren eines Elements noch eine Eingabeänderung (z. B. Auswählen einer Dropdown-Option) führen ohne Vorwarnung zu einem drastischen Kontextwechsel (wie z.B. automatisch auf eine andere Seite zu springen). Veränderungen der Seite erfolgen nur als bewusste Nutzeraktion (z.B. beim Klick auf einen Button) oder der Nutzer wird vorher darauf hingewiesen.

  • Konsistente Navigation: Wiederkehrende Navigationselemente und Menüstrukturen sind auf allen Seiten einheitlich angeordnet und beschriftet. Das Hauptmenü erscheint z.B. immer an derselben Stelle mit denselben Einträgen in gleicher Reihenfolge, sodass Nutzer sich nicht neu orientieren müssen.

  • Einheitliche Bezeichnungen: Elemente mit gleicher Funktion werden durchgängig konsistent benannt und dargestellt. Wenn z.B. auf verschiedenen Seiten ein Icon oder Button dieselbe Aktion auslöst, hat er überall denselben Text oder dasselbe Symbol. Dies hilft Nutzern, wiederkehrende Funktionen zuverlässig zu erkennen (WCAG 2.1 Erfolgskriterium 3.2.4).

Formulare und Fehlervermeidung

  • Eingabefelder beschriftet: Alle Formularfelder sind mit eindeutigen Labels versehen, die für Nutzer sichtbar oder zumindest für assistive Technologien erkennbar sind. Gegebenenfalls werden Eingabehilfen angeboten – etwa Platzhaltertexte oder Hinweise zum erwarteten Format (z.B. “TT.MM.JJJJ” bei einem Datum).

  • Fehlermeldungen: Falls ein Nutzer ein Formularfeld falsch ausfüllt oder einen anderen Fehler macht, wird dies deutlich kenntlich gemacht. Es erscheint eine verständliche Fehlermeldung, die das Problem beschreibt und nach Möglichkeit Hinweise zur Korrektur gibt (z. B. “Bitte geben Sie eine gültige E-Mail-Adresse ein.”). Fehlertexte sind so platziert (etwa in der Nähe des betreffenden Feldes), dass sie leicht wahrgenommen werden.

  • Fehlervermeidung bei wichtigen Transaktionen: Bei Vorgängen, die rechtliche oder finanzielle Auswirkungen haben oder wichtige Daten übermitteln (z.B. Online-Bestellungen, Formulare mit Vertragsabschlüssen), gibt es besondere Prüf- oder Bestätigungsschritte, um Fehler zu vermeiden. Nutzer erhalten die Möglichkeit, ihre Eingaben zu überprüfen und zu bestätigen, bevor die endgültige Aktion ausgelöst wird, oder sie können Vorgänge im Nachhinein rückgängig machen. (Beispiel: Vor dem endgültigen Absenden einer Bestellung wird eine Übersichtsseite mit allen Eingaben und Kosten angezeigt, mit der Option, Korrekturen vorzunehmen.)

Robustheit (Robustness)

Technische Umsetzung

  • Valides Markup: Der gesamte Code der Website entspricht den gängigen Webstandards. HTML und CSS sind valide (prüfen Sie z.B. mit dem W3C-Validator) und enthalten keine schwerwiegenden Syntaxfehler. Semantische HTML-Strukturen werden konsequent genutzt, um eine robuste Basis für verschiedenste Browser und Geräte zu bieten. (Tipp: Statt komplexe Eigenlösungen zu programmieren, nutzen Sie nach Möglichkeit standardisierte HTML-Elemente und -Steuerelemente, die von Haus aus barrierefrei sind.)

  • Skripte und ARIA: Interaktive Funktionen sind so implementiert, dass sie auch unter atypischen Bedingungen robust bleiben (z.B. verursacht deaktiviertes JavaScript keine vollständigen Funktionsausfälle). WAI-ARIA wird nur dort eingesetzt, wo es erforderlich ist, und dann korrekt angewendet. Das heißt, individuelle Widgets oder dynamische Inhalte wurden mit den passenden ARIA-Rollen, Zuständen und Eigenschaften versehen, ohne die native Semantik unnötig zu duplizieren oder zu überschatten.

Kompatibilität mit Hilfstechnologien

  • Name, Rolle, Wert: Alle interaktiven Bedienelemente stellen programmatisch ihren Namen, Rolle und Wert bereit. Insbesondere bei benutzerdefinierten Steuerelementen (z.B. selbstgebauten Dropdown-Menüs, Tabs, Slidern) wurde darauf geachtet, dass sie für Assistenztechnologien verständlich sind – etwa durch geeignete ARIA-Rollen (role="menu" etc.), Beschriftungen (aria-label oder verknüpfte <label>) und Zustandsangaben (aria-expanded="true" für aufgeklappte Elemente usw.).

  • Statusmeldungen: Dynamische Status- oder Hinweistexte (z.B. Ergebnis-Anzeigen, Bestätigungen, Ladeanzeigen) werden so umgesetzt, dass sie von Screenreadern automatisch erkannt und vorgelesen werden. Hierfür werden z.B. Live-Regionen genutzt (aria-live="polite" für weniger dringliche Meldungen oder role="alert" für wichtige sofortige Meldungen). Dadurch erhalten Nutzer mit Screenreader Rückmeldungen, auch wenn der Fokus nicht explizit auf die Meldung gesetzt wird.

  • Test mit Hilfstechnologien: Die Website wurde mit gängigen Hilfstechnologien geprüft, um sicherzustellen, dass alle Inhalte robust zugänglich sind. Dazu gehören Tests mit Screenreader-Software (z.B. NVDA, JAWS oder VoiceOver), Bildschirmvergrößerungen, Braillezeilen oder sprachgesteuerten Systemen. Ergebnis: Alle Funktionen können von diesen Technologien fehlerfrei genutzt und verstanden werden. (Empfehlung: Darüber hinaus regelmäßig manuelle Tests und Nutzerrückmeldungen einholen, um die Barrierefreiheit praxisnah zu überprüfen.)

Hinweis: Diese Checkliste fasst die wichtigsten Anforderungen der WCAG 2.1 (Level AA) und der BITV 2.0 zusammen. Sie ersetzt kein ausführliches Audit, bietet aber einen praktischen Leitfaden, um typische Barrieren zu erkennen und zu beheben. Durch konsequente Umsetzung der obigen Prüfpunkte wird sichergestellt, dass Ihre Website den gesetzlichen Vorgaben entspricht und für alle Nutzer – einschließlich Menschen mit Behinderungen – uneingeschränkt zugänglich ist.

Schlagwörter

Wichtige Beiträge

Populäre Beiträge