Ein Accessibility Overlay ist ein nachträglich eingebundenes Widget, das per JavaScript die Darstellung einer Website anpasst – etwa Schriftgröße, Kontraste oder eine Vorlesefunktion. Wichtig zu verstehen: Ein Overlay heilt keine Barrieren im Code, es legt nur eine Bedienoberfläche darüber. Anbieter, die ein Overlay als „1-Klick-Lösung für volle Konformität" verkaufen, sind in der Fachgemeinschaft zu Recht umstritten und haben Abmahnungen nicht verhindert. Wir setzen ein Overlay ausschließlich ehrlich ein: als deklarierte Übergangslösung, während die eigentliche Sanierung am Code läuft – nie als Ersatz dafür.

Der Accessibility Tree ist die Struktur, die assistive Technologien wie Screenreader tatsächlich auswerten. Er wird aus dem DOM abgeleitet und enthält nur die für die Bedienung relevanten Informationen: Rollen, Namen, Zustände. Ist dieser Baum fehlerhaft, bleiben Inhalte für blinde Nutzer unsichtbar, obwohl sie auf dem Bildschirm sichtbar sind. Hier liegt einer der häufigsten und am schwersten zu entdeckenden Fehler, weil ein automatischer Test ihn oft nicht erkennt.

Ein Alt-Text ist die textliche Beschreibung eines Bildes, die Screenreader vorlesen und die erscheint, wenn das Bild nicht lädt. Er beschreibt den Informationsgehalt des Bildes im Kontext, nicht jedes Detail. Verzichten Sie auf Floskeln wie „Bild von" und wiederholen Sie nicht die Bildunterschrift. Rein dekorative Bilder bekommen einen leeren Alt-Text, damit der Screenreader sie überspringt – auch das ist eine bewusste Entscheidung, kein Versäumnis.

ARIA (Accessible Rich Internet Applications, vollständig WAI-ARIA) ist ein Satz von HTML-Attributen, der komplexe Komponenten wie Dropdowns, Tabs, Slider oder Modale für Screenreader verständlich macht. ARIA ergänzt HTML, ersetzt es aber nicht. Die wichtigste Regel aus der Praxis: Kein ARIA ist besser als falsches ARIA. Ich sehe regelmäßig, dass gut gemeinte Attribute eine Komponente unbedienbar machen, weil ein natives HTML-Element die Aufgabe von Haus aus besser erfüllt hätte.

Die ATAG definieren, wie Redaktions- und Autorenwerkzeuge selbst barrierefrei sein müssen und wie sie ihre Nutzer beim Erstellen barrierefreier Inhalte unterstützen sollen. Relevant ist das vor allem für CMS, Shop-Systeme und E-Learning-Plattformen. Mein Praxishinweis: Ein Redaktionssystem, das es Ihrem Team unmöglich macht, einen Alt-Text einzutragen, produziert dauerhaft Barrieren – egal wie gut die Vorlage ist.

Ein Accessibility Audit ist die systematische Prüfung einer Website, App oder eines Dokuments gegen Standards wie die WCAG, BITV oder PDF/UA. Es kann automatisiert, manuell oder kombiniert erfolgen und liefert konkrete, priorisierte Empfehlungen. Der entscheidende Punkt: Ein rein automatisierter Scan deckt je nach Studie nur etwa ein Drittel der relevanten Kriterien ab. Wer ein Audit kauft, sollte genau fragen, wie viel davon eine Maschine und wie viel ein Mensch geprüft hat.

Automatisierte Testwerkzeuge wie axe-core oder Lighthouse scannen den Code einer Seite und melden technisch eindeutige Fehler, etwa fehlende Alt-Texte oder Kontrastmängel. Sie sind schnell, günstig und ein guter erster Filter. Ihre Grenze: Ob ein Alt-Text inhaltlich sinnvoll ist oder eine Tastaturreihenfolge logisch, kann kein Scanner beurteilen. Nutzen Sie diese Werkzeuge als Frühwarnsystem, nicht als Konformitätsnachweis.

Barrierefreie Authentifizierung bedeutet, dass sich Nutzer anmelden können, ohne einen kognitiven Funktionstest bestehen zu müssen – etwa das Abtippen verzerrter Zeichen oder das Lösen von Rätseln. Die WCAG 2.2 verlangen mit Kriterium 3.3.8, dass es immer eine zugängliche Alternative gibt, zum Beispiel das Einfügen aus dem Passwortmanager oder eine Bestätigung per Gerät. Viele Login- und Bezahlstrecken fallen genau hier durch, weil ihr CAPTCHA keinen barrierefreien Ausweg bietet.

Digitale Barrierefreiheit bedeutet, dass Websites, Apps und Dokumente von allen Menschen wahrnehmbar, bedienbar und verständlich genutzt werden können – unabhängig von körperlichen oder kognitiven Einschränkungen. Sie ist die Grundlage digitaler Teilhabe und seit 2025 für große Teile der Wirtschaft gesetzliche Pflicht. Wir sprechen bewusst von Barrierearmut statt von „100 Prozent barrierefrei": Eine seriöse Aussage über vollständige Freiheit von Barrieren kann niemand garantieren, weil Nutzungssituationen unendlich vielfältig sind.

Eine Barrierefreiheitserklärung ist eine öffentlich auffindbare Erklärung über den Stand der Barrierefreiheit eines digitalen Angebots, inklusive bekannter Mängel und einer Feedback-Möglichkeit. Für öffentliche Stellen ist sie seit Jahren Pflicht, für viele Unternehmen kommt diese Transparenzpflicht über das BFSG hinzu. Sie ist kein lästiges Formular, sondern ein juristisch relevantes Dokument: Wer hier ehrlich offene Punkte und einen Zeitplan nennt, dokumentiert seine Sorgfaltspflicht.

Das BFSG ist das deutsche Gesetz, das den European Accessibility Act in nationales Recht umsetzt und seit dem 28. Juni 2025 gilt. Es verpflichtet zahlreiche Unternehmen – darunter E-Commerce, Banken, Personenverkehr und viele Dienstleister –, ihre digitalen Produkte und Dienstleistungen barrierefrei anzubieten. Kleinstunternehmen im Dienstleistungsbereich sind unter bestimmten Schwellen ausgenommen, was in der Praxis aber seltener greift, als viele hoffen. Wer prüfen will, ob er betroffen ist, sollte das nicht aus dem Bauch entscheiden, sondern belastbar klären lassen.

Die BITV 2.0 regelt in Deutschland die Anforderungen an die Barrierefreiheit digitaler Angebote öffentlicher Stellen des Bundes. Sie verweist technisch auf die europäische Norm EN 301 549 und damit auf die WCAG. Während das BFSG die Privatwirtschaft adressiert, ist die BITV der maßgebliche Rahmen für Behörden, Ämter und öffentliche Einrichtungen.

Eine Braillezeile gibt digitale Inhalte taktil in Blindenschrift aus, indem sie Stifte zu Punktmustern anhebt. Sie ist für viele blinde Menschen, besonders für taubblinde Nutzer, das zentrale Ausgabegerät. Voraussetzung für ihre Funktion ist exakt derselbe semantisch saubere Code, der auch Screenreadern dient – Barrierefreiheit für die eine Technologie zahlt fast immer auf die andere ein.

Eine Breadcrumb-Navigation zeigt den Pfad an, auf dem sich ein Nutzer innerhalb der Seitenstruktur befindet, etwa Startseite, Produkte, Software. Damit sie für Screenreader funktioniert, muss sie als Navigationsbereich ausgezeichnet und der aktuelle Punkt korrekt markiert sein. Richtig umgesetzt verbessert sie zugleich Orientierung und SEO, weil Suchmaschinen die Struktur ebenfalls auslesen.

Ein CAPTCHA soll automatisierte Zugriffe abwehren, wird aber häufig selbst zur unüberwindbaren Barriere. Verzerrte Buchstaben sind für sehbehinderte Menschen unlösbar, rein visuelle Bildaufgaben für blinde Nutzer ohnehin. Barrierefreiere Alternativen sind unsichtbare, verhaltensbasierte Prüfungen oder logikbasierte Fragen mit zugänglicher Ausweichoption. Seit WCAG 2.2 ist das nicht mehr nur eine Empfehlung, sondern berührt das Kriterium zur barrierefreien Authentifizierung.

CI/CD steht für Continuous Integration und Continuous Deployment – also die automatisierte Pipeline, über die moderne Teams Code testen und ausspielen. Für Barrierefreiheit ist das ein Hebel, kein Detail: Wenn Sie Accessibility-Prüfungen direkt in die Pipeline einbauen, fällt ein Pull Request mit neuen Barrieren auf, bevor er live geht. Eine kurze Anmerkung, weil dieser Begriff oft verwechselt wird: Mit Corporate Identity oder Corporate Design hat CI/CD im technischen Kontext nichts zu tun. Wer Barrierefreiheit dauerhaft halten will, verankert sie hier – im Deployment-Prozess.

Closed Captions sind zuschaltbare Untertitel, die zusätzlich zu den gesprochenen Worten auch relevante Geräusche, Musik und Sprecherwechsel benennen. Sie richten sich an gehörlose und schwerhörige Menschen und gehen über reine Untertitel hinaus. Praktischer Nebeneffekt: In lauten Umgebungen oder beim stummen Abspielen in sozialen Netzwerken erhöhen Captions die Verweildauer erheblich.

Das Kontrastverhältnis beschreibt den Helligkeitsunterschied zwischen Text und Hintergrund und ist entscheidend für die Lesbarkeit, besonders bei Sehschwächen. Die WCAG fordern mindestens 4,5:1 für normalen Text und 3:1 für großen Text; auch grafische Bedienelemente brauchen mindestens 3:1. Hellgraue Schrift auf weißem Grund mag dezent wirken, fällt im Audit aber regelmäßig durch. Kontrast ist kein Designdetail, sondern eine harte Anforderung.

Corporate Design umfasst das visuelle Erscheinungsbild einer Marke – Farben, Schriften, Logos. Für die Barrierefreiheit ist es relevant, weil Markenfarben oft die Kontrastvorgaben verletzen. Mein Rat: Definieren Sie schon im Styleguide barrierefreie Farbpaarungen, statt nachträglich jede Seite zu korrigieren. So bleibt die Marke konsistent und konform zugleich.

Das DOM ist die strukturierte Repräsentation einer Webseite, die der Browser aus dem HTML aufbaut. Es ist die Grundlage, aus der der Accessibility Tree entsteht – und damit das, worauf jede assistive Technologie aufsetzt. Eine semantisch saubere DOM-Struktur, also richtige Überschriften, Listen und Schaltflächen statt generischer Container, ist die billigste und wirksamste Barrierefreiheitsmaßnahme überhaupt.

Der European Accessibility Act ist die EU-Richtlinie 2019/882, die einheitliche Barrierefreiheitsanforderungen für Produkte und Dienstleistungen im Binnenmarkt festlegt. Er ist die Wurzel, aus der das deutsche BFSG erwächst – und sorgt dafür, dass die Regeln in ganz Europa vergleichbar sind. Für international tätige Unternehmen bedeutet das: Es gibt nicht 27 Insellösungen, sondern einen gemeinsamen Nenner, an dem Sie sich orientieren können.

Die EN 301 549 ist die europäische Norm, die Barrierefreiheitsanforderungen an IKT – Websites, Software, Dokumente und Hardware – konkretisiert. Sie übersetzt die abstrakten Vorgaben der Gesetze in prüfbare technische Kriterien und übernimmt dafür die Erfolgskriterien der WCAG. Praktisch ist sie das Bindeglied: Wenn Sie nach WCAG 2.2 auf Stufe AA arbeiten, erfüllen Sie den Kern dessen, was die EN 301 549 für den Webbereich verlangt.

Erleichterte Sprache ist eine vereinfachte, klar strukturierte Ausdrucksweise, die leichter verständlich ist als Standardsprache, aber weniger streng reglementiert als Leichte Sprache. Sie verzichtet auf Schachtelsätze, Fachjargon und Fremdwörter, ohne ein festes Regelwerk einzuhalten. Für die meisten Unternehmensseiten ist sie der praktikablere Einstieg, weil sie sich ohne Zertifizierungsaufwand umsetzen lässt.

Barrierefreie Fehlermeldungen benennen klar, was schiefgelaufen ist, wo der Fehler liegt und wie er zu beheben ist – und werden vom Screenreader automatisch angekündigt. Ein rotes Rahmenfeld allein reicht nicht, denn Farbe ist kein Informationsträger für jeden. In Audits ist das fehlerhafte Formular der Klassiker: Der Nutzer weiß, dass etwas falsch ist, erfährt aber nie, was.

Der Focus Indicator ist die sichtbare Markierung, die zeigt, welches Element gerade per Tastatur aktiv ist – typischerweise ein deutlicher Rahmen. Ohne ihn ist Tastaturbedienung praktisch unmöglich, weil Nutzer im Blindflug navigieren. Ein häufiger Designfehler: Der Fokusrahmen wird aus ästhetischen Gründen per CSS entfernt und nicht ersetzt. Die WCAG 2.2 haben die Anforderungen an die Sichtbarkeit des Fokus mit zwei neuen Kriterien sogar verschärft.

Formularzugänglichkeit bedeutet, dass jedes Feld eindeutig beschriftet, vollständig per Tastatur erreichbar und sein Zweck verständlich ist. Beschriftungen müssen programmatisch mit dem Feld verknüpft sein, nicht nur visuell danebenstehen. Da über Formulare Käufe, Anträge und Logins laufen, entscheidet ihre Zugänglichkeit oft direkt über Umsatz – ein unbedienbares Checkout-Formular ist eine verlorene Conversion.

Eine Heading-Struktur ist die hierarchische Gliederung einer Seite über Überschriften der Ebenen H1 bis H6, logisch und ohne Sprünge. Screenreader-Nutzer springen über Überschriften durch die Seite, ähnlich wie Sehende einen Text überfliegen. Genau eine H1 pro Seite, danach saubere Verschachtelung – diese Disziplin hilft gleichzeitig der Barrierefreiheit und der Sichtbarkeit in Suchmaschinen und KI-Antworten.

Human-in-the-loop bezeichnet ein Prüfverfahren, das Software und KI mit echten menschlichen Testern kombiniert – idealerweise mit Menschen, die assistive Technologien täglich nutzen. Erst dieser Schritt deckt die 60 bis 70 Prozent der WCAG-Kriterien ab, die ein automatischer Scanner strukturell nicht erkennen kann. Aus meiner Erfahrung ist das der einzige Weg zu einem belastbaren Ergebnis: Ein blinder Tester, der Ihren Checkout in dreißig Sekunden als unbedienbar entlarvt, ist durch keine Software zu ersetzen.

Digitale Teilhabe beschreibt das Ziel, dass niemand vom digitalen Leben ausgeschlossen wird – sei es beim Online-Banking, beim Behördengang oder beim Einkauf. Barrierefreiheit ist das Mittel, Teilhabe das Ziel. In der EU leben rund 135 Millionen Menschen mit Behinderungen; das ist keine Randgruppe, sondern eine Zielgruppe mit erheblicher Kaufkraft, die viele Anbieter bis heute technisch aussperren.

Die WCAG kennen drei Konformitätsstufen: A als Basis, AA als gesetzlich relevanter Standard und AAA als höchste, oft nur punktuell erreichbare Anforderung. In Europa ist faktisch Stufe AA der Maßstab, an dem Behörden und Unternehmen gemessen werden. AAA sollten Sie dort anstreben, wo es sinnvoll ist, aber niemand erwartet eine vollständige AAA-Konformität über die gesamte Website – das ist bei manchen Kriterien schlicht nicht durchgängig umsetzbar.

Leichte Sprache ist eine stark vereinfachte Sprachform nach festem Regelwerk, gedacht für Menschen mit Lernschwierigkeiten, kognitiven Einschränkungen oder geringen Deutschkenntnissen. Typisch sind kurze Hauptsätze, große Schrift, erklärende Bilder und das Vermeiden von Metaphern. Wichtig zu wissen: Leichte Sprache ersetzt nicht die Standardversion, sie ergänzt sie. In Audits sehe ich oft, dass Behörden hier zu Recht streng geprüft werden, während die Privatwirtschaft den Bedarf unterschätzt.

Das Matterhorn-Protokoll ist der Prüfkatalog der PDF Association, der die Anforderungen des PDF/UA-Standards in konkrete, prüfbare Bedingungen übersetzt. Es listet die Fehlerarten auf, die ein PDF unzugänglich machen, und unterscheidet, was eine Maschine und was ein Mensch prüfen muss. Für die Validierung barrierefreier Dokumente ist es der maßgebliche Maßstab – wenn jemand seriös PDFs prüft, dann nach Matterhorn.

PDF/UA (Universal Accessibility, ISO 14289) ist der internationale Standard für barrierefreie PDF-Dokumente. Er regelt Tags, Lese-Reihenfolge, Alternativtexte, korrekte Tabellenauszeichnung und Navigation. Ein PDF sieht für das Auge oft tadellos aus und ist für einen Screenreader trotzdem völlig unbrauchbar. Genau diese Lücke unterschätzen Behörden und Konzerne mit großen Dokumentenbeständen am häufigsten – die wenigsten haben ihre Geschäftsberichte und Formulare je nach PDF/UA geprüft.

Ein Screenreader ist eine Software, die Bildschirminhalte vorliest oder an eine Braillezeile ausgibt und so blinden und stark sehbehinderten Menschen die Bedienung ermöglicht. Verbreitet sind JAWS und NVDA unter Windows, VoiceOver auf Apple-Geräten und TalkBack unter Android. Wichtig: Verschiedene Screenreader interpretieren denselben Code teils unterschiedlich. Deshalb prüfen wir nicht gegen einen einzigen, sondern gegen mehrere – was auf einem perfekt klingt, kann auf einem anderen scheitern.

Tastaturnavigation bedeutet, dass sich die gesamte Seite ohne Maus bedienen lässt – alle interaktiven Elemente sind erreichbar, die Reihenfolge ist logisch und es gibt keine Tastaturfallen, aus denen man nicht mehr herauskommt. Viele Menschen mit motorischen Einschränkungen, aber auch Power-User, navigieren ausschließlich per Tastatur. Mein Schnelltest für jede Seite: einmal mit der Tab-Taste komplett durchgehen, ohne die Maus anzufassen. Sie werden überrascht sein, was dabei hängenbleibt.

Tooltips liefern ergänzende Hinweise, wenn ein Element fokussiert oder überfahren wird. Damit sie barrierefrei sind, müssen sie auch per Tastatur auslösbar, vom Screenreader lesbar und lange genug sichtbar sein, um sie in Ruhe zu erfassen. Ein Tooltip, der nur bei Mausberührung erscheint und sofort wieder verschwindet, hilft niemandem, der auf die Tastatur angewiesen ist.

Ein Transkript ist die vollständige schriftliche Wiedergabe eines Audio- oder Videoinhalts. Es macht Podcasts, Interviews und Videos für gehörlose Menschen zugänglich und ist zugleich von Suchmaschinen lesbar. Ein gut aufbereitetes Transkript ist damit doppelt wertvoll: barrierefrei und ein SEO-Gewinn, weil gesprochene Inhalte sonst für Google unsichtbar bleiben.

Untertitel geben den gesprochenen Text eines Videos in Schriftform wieder, synchron zum Bild. Sie helfen Menschen mit Hörbehinderung, aber auch allen, die Videos ohne Ton ansehen. Automatisch generierte Untertitel sind ein Anfang, aber kein Freibrief – bei Fachbegriffen und Namen liegt die Spracherkennung oft daneben, und ein falscher Untertitel ist manchmal schlimmer als gar keiner.

Usability beschreibt, wie effizient, effektiv und zufriedenstellend Menschen ein System bedienen können. Barrierefreiheit und Usability sind keine Gegensätze, sondern verstärken sich: Eine klar strukturierte, tastaturbedienbare Seite ist für alle angenehmer, nicht nur für Menschen mit Behinderung. Genau hier liegt der oft übersehene Business-Case – bessere Bedienbarkeit senkt Absprünge und hebt Conversion-Raten.

Wahrnehmbarkeit ist das erste der vier WCAG-Grundprinzipien: Inhalte müssen so aufbereitet sein, dass sie über mindestens einen Sinneskanal erfassbar sind. Die vier Prinzipien zusammen ergeben das Kürzel POUR – Perceivable, Operable, Understandable, Robust (wahrnehmbar, bedienbar, verständlich, robust). Keine Information darf ausschließlich über Sehen oder ausschließlich über Hören vermittelt werden. Wer das verinnerlicht, hat den Kern der WCAG bereits verstanden.

Die WCAG 2.2 sind die aktuellen internationalen Richtlinien des W3C für digitale Barrierefreiheit und seit Oktober 2023 die maßgebliche Fassung. Sie strukturieren Anforderungen nach den vier Prinzipien wahrnehmbar, bedienbar, verständlich und robust. Version 2.2 brachte neun neue Erfolgskriterien, die in der Praxis oft übersehen werden: etwa eine sichtbare Mindestgröße für klickbare Ziele von 24 mal 24 Pixeln (2.5.8), der nicht verdeckte Tastaturfokus (2.4.11) und – besonders wichtig – die barrierefreie Authentifizierung (3.3.8), die reine Rätsel- und Merk-Tests bei Logins ausschließt. Wer noch nach WCAG 2.1 arbeitet, prüft veraltet.