Kompatible Website für assistive Technologien

Die WCAG 2.1 Richtlinie 4.1 „Kompatibel“ (Compatible) stellt sicher, dass Webinhalte mit aktuellen und zukünftigen Benutzeragenten und assistiven Technologien funktionieren. Mit dem BFSG 2025 wird dies für deutsche Unternehmen zur rechtlichen Pflicht – denn eine Website ist nur dann wirklich zugänglich, wenn sie mit allen Hilfsmitteln genutzt werden kann.

Stellen Sie sich vor, Sie haben eine perfekt gestaltete Website mit guten Kontrasten, klaren Texten und logischer Navigation. Aber ein Screenreader kann die Inhalte nicht richtig interpretieren, weil der Code fehlerhaft ist. Oder Formularfelder werden nicht erkannt, weil wichtige Attribute fehlen. Für die betroffenen Nutzer ist Ihre Website dann praktisch unbenutzbar – egal wie schön sie aussieht. Kompatibilität ist das technische Fundament, auf dem alle anderen Barrierefreiheits-Anforderungen aufbauen.

Warum ist Kompatibilität so wichtig?

Menschen mit Behinderungen nutzen eine Vielzahl assistiver Technologien: Screenreader, Sprachsteuerung, Bildschirmlupen, alternative Eingabegeräte und mehr. Diese Technologien müssen den Code Ihrer Website korrekt interpretieren können, um die Inhalte zugänglich zu machen.

Wenn Ihr HTML fehlerhaft ist, wichtige Attribute fehlen oder Elemente nicht richtig ausgezeichnet sind, können assistive Technologien die Inhalte nicht korrekt darstellen oder bedienen. Ein Screenreader erkennt vielleicht nicht, dass ein Element ein Button ist, oder ein Formularfeld wird nicht mit seinem Label verknüpft. Das Ergebnis: Frustration und Ausschluss.

Kompatibilität bedeutet auch Zukunftssicherheit. Technologien entwickeln sich weiter, neue Browser und Hilfsmittel kommen auf den Markt. Websites, die auf Standards basieren und sauberen, semantischen Code verwenden, funktionieren auch mit zukünftigen Technologien.

Geltungsbereich:

Gilt für alle Unternehmen, die mehr als 9 Beschäftigte haben oder deren Jahresumsatz 2 Millionen Euro übersteigt.

ONLINE -INTERAKTIONEN:

Webseiten, Plattformen, und Apps für den Austausch mit Kunden

Die wichtigsten Erfolgskriterien

Name, Rolle, Wert (Level A)

Für alle UI-Komponenten müssen Name, Rolle und Wert programmatisch bestimmbar sein. Dies ist essentiell, damit assistive Technologien verstehen, was ein Element ist und wie es funktioniert.

Name: Wie wird das Element bezeichnet? Zum Beispiel der Button-Text „Anmelden“, das Label „E-Mail-Adresse“ oder der Alt-Text eines Bildes.

Rolle: Was ist das Element? Ist es ein Button, Link, Eingabefeld, Checkbox oder eine Überschrift? Bei nativen HTML-Elementen ist dies automatisch vorhanden.

Wert: Was ist der aktuelle Zustand? Ist eine Checkbox aktiviert? Was steht im Eingabefeld? Ist ein aufklappbares Menü geöffnet oder geschlossen?

Praktische Beispiele:

Ein Button braucht einen erkennbaren Text oder eine Beschriftung
Ein Eingabefeld muss mit seinem Label verknüpft sein
Eine Checkbox muss ihren Zustand (aktiviert/deaktiviert) mitteilen
Ein aufklappbares Menü muss signalisieren, ob es offen oder geschlossen ist

Statusmeldungen (Level AA)

Statusmeldungen müssen programmatisch erkennbar sein, ohne dass der Fokus verschoben werden muss. Dies betrifft Erfolgsmeldungen, Fehlermeldungen, Fortschrittsanzeigen und andere dynamische Inhalte.

Beispiele für Statusmeldungen:

„Produkt wurde in den Warenkorb gelegt“
„Ihre Änderungen wurden gespeichert“
„5 Suchergebnisse gefunden“
„Formular wird gesendet…“
„Verbindung unterbrochen“

Diese Meldungen müssen so implementiert sein, dass Screenreader sie automatisch vorlesen, ohne dass der Nutzer den Fokus dorthin bewegen muss.

Praktische Umsetzung

Native HTML-Elemente verwenden

Die einfachste Art, Kompatibilität zu gewährleisten, ist die Verwendung der richtigen HTML-Elemente für ihre jeweiligen Zwecke. Echte Buttons, Links und Formularelemente haben bereits die richtige Semantik eingebaut.

Nutzen Sie die richtigen Elemente:

Echte Button-Elemente für Buttons
Link-Elemente für Links
Native Formularelemente für Eingaben
Semantische Strukturelemente für Bereiche

Vermeiden Sie:

DIV-Elemente, die als Buttons fungieren sollen
SPAN-Elemente als Links
Generische Elemente für interaktive Komponenten

Labels korrekt verknüpfen

Jedes Formularelement muss eindeutig beschriftet und verknüpft sein. Ein Screenreader muss wissen, welche Beschriftung zu welchem Eingabefeld gehört.

Wichtig:

Jedes Eingabefeld braucht ein sichtbares Label
Label und Feld müssen technisch miteinander verknüpft sein
Die Verknüpfung muss für assistive Technologien erkennbar sein

Dynamische Inhalte ankündigen

Wenn sich Inhalte ändern, ohne dass die Seite neu lädt, müssen Screenreader-Nutzer darüber informiert werden. Das betrifft zum Beispiel:

Produkte, die in den Warenkorb gelegt werden
Erfolgsmeldungen nach Speichern
Fehlermeldungen, die erscheinen
Suchergebnisse, die geladen werden

Zustände kommunizieren

Interaktive Elemente müssen ihren aktuellen Zustand mitteilen:

Ist ein Menü aufgeklappt oder zugeklappt?
Ist eine Option ausgewählt oder nicht?
Ist ein Toggle-Button aktiviert oder deaktiviert?
Lädt gerade etwas oder ist es fertig?

BFSG 2025 und rechtliche Konsequenzen

Fehlende Kompatibilität macht alle anderen Barrierefreiheits-Bemühungen zunichte. Eine schön gestaltete Website hilft niemandem, wenn assistive Technologien sie nicht interpretieren können.

Besonders kritische Bereiche:

Formulare ohne korrekte Labels
Custom-Komponenten ohne richtige Semantik
Dynamische Inhalte ohne Statusmeldungen
Interactive Elemente ohne Tastatur-Support
Fehlerhafte oder unvollständige technische Auszeichnung

Das BFSG macht technisch korrekte, kompatible Websites zur Pflicht. Websites, die mit assistiven Technologien nicht funktionieren, schließen Menschen mit Behinderungen vollständig aus und verstoßen gegen geltendes Recht.

BarriGo. unterstützt Sie bei der Umsetzung

Die Prüfung der technischen Kompatibilität einer Website ist anspruchsvoll – und viele Probleme bleiben ohne spezialisierte Werkzeuge unsichtbar. BarriGo.Live Inspect unterstützt Sie dabei, genau diese Barrieren sichtbar zu machen. Unsere Lösung zeigt technische Fehler in der Auszeichnung Ihrer Website auf, etwa fehlende oder fehlerhafte Semantik, unzureichende Kennzeichnungen von UI-Elementen, nicht verknüpfte Formular-Labels sowie Probleme bei interaktiven Komponenten.

Bestimmte Aspekte wie komplexe Zustandsänderungen oder spezifische dynamische Statusmeldungen erfordern zusätzlich eine manuelle Bewertung, doch BarriGo.Live Inspect liefert eine klare Grundlage dafür, technische Barrieren präzise zu erkennen und zielgerichtet zu beheben.

Mit BarriGo.Live Inspect stellen Sie sicher, dass assistive Technologien Ihre Website korrekt interpretieren können und stärken die technische Barrierefreiheit.

Weiterführende Informationen finden Sie im offiziellen WCAG 2.2 Standard: WCAG 2.2 – Richtlinie 4.1 Kompatibel