Eingabemodalitäten: So wird Ihre Website für alle Eingaben nutzbar

Die WCAG 2.1 Richtlinie 2.5 „Eingabemodalitäten“ (Input Modalities) stellt sicher, dass Nutzer auf verschiedene Arten mit Inhalten interagieren können. Mit dem BFSG 2025 wird dies für deutsche Unternehmen zur rechtlichen Pflicht – denn nicht jeder bedient Websites mit Maus und Tastatur.

Stellen Sie sich vor, Sie möchten einen Button klicken, treffen ihn aber ständig nicht, weil er zu klein ist. Oder Sie wollen eine Geste auf dem Touchscreen ausführen, schaffen aber die komplexe Mehrfinger-Bewegung nicht. Solche Probleme erleben täglich Millionen von Menschen: Menschen mit motorischen Einschränkungen, die zitternde Hände haben, ältere Menschen mit eingeschränkter Feinmotorik, Nutzer von Sprachsteuerung oder Menschen, die mit nur einer Hand bedienen müssen. Wenn Ihre Website nur für perfekte Maus-Präzision optimiert ist, schließen Sie all diese Menschen aus.

Warum sind flexible Eingabemöglichkeiten wichtig?

Moderne Geräte bieten vielfältige Eingabemethoden: Touchscreens, Maus, Tastatur, Stift, Sprachsteuerung, Eye-Tracking und mehr. Menschen mit Behinderungen nutzen oft assistive Technologien, die diese Eingabemethoden simulieren oder kombinieren. Eine Website, die nur auf eine spezifische Eingabeart ausgelegt ist, schließt automatisch große Nutzergruppen aus.

Menschen mit Tremor oder anderen motorischen Einschränkungen haben Schwierigkeiten mit präzisen Bewegungen. Sie benötigen großzügige Klickbereiche und tolerante Interaktionen. Menschen, die nur eine Hand nutzen können, schaffen keine komplexen Mehrfinger-Gesten. Sprachsteuerungs-Nutzer müssen alle Funktionen auch ohne Zeigergerät aktivieren können. Diese Anforderungen klingen komplex, lassen sich aber mit durchdachtem Design und Entwicklung gut umsetzen.

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 von 2.5 Eingabemodalitäten

Zeigergesten (Level A)

Alle Funktionen, die Mehrpunkt- oder pfadbasierte Gesten erfordern, müssen auch mit Einzelpunkt-Gesten bedienbar sein – außer wenn die Mehrpunkt-Geste essentiell ist.

Problematische Gesten:

Pinch-to-Zoom ohne Alternative
Wischen mit mehreren Fingern
Komplexe Pfad-Gesten (Z-Form zeichnen)
Drag-and-Drop ohne Alternative

Gute Alternativen:

Zoom-Buttons zusätzlich zu Pinch-Gesten
Vor/Zurück-Buttons zusätzlich zum Wischen
Einfache Klicks oder Taps für alle Aktionen
Optionale Tastatureingabe statt Drag-and-Drop

Dies bedeutet nicht, dass Sie keine Gesten verwenden dürfen – aber es muss immer eine einfachere Alternative geben.

Abbruch oder Widerruf von Zeigereingaben (Level A)

Aktionen sollten erst beim Loslassen ausgelöst werden (up-Event), nicht beim Drücken (down-Event). Dies ermöglicht Nutzern, versehentlich begonnene Aktionen abzubrechen.

Sichere Implementierung:

Click-Event auf mouseup/touchend, nicht auf mousedown/touchstart
Möglichkeit, den Zeiger vor dem Loslassen wegzubewegen
Bestätigungsdialog bei kritischen Aktionen
Rückgängig-Funktion nach der Aktion

Ausnahme: Das down-Event ist essentiell (z.B. Klaviertasten-App, Zeichenprogramme) oder ein Mechanismus zum Abbrechen ist vorhanden.

Beschriftung im Namen (Level A)

Wenn eine Benutzeroberfläche Text oder Bilder als Label enthält, muss der programmatische Name (accessible name) diesen Text enthalten. Dies ist wichtig für Sprachsteuerungs-Nutzer.

Beispiele:

Sichtbarer Button-Text: „Jetzt kaufen“ → accessible name muss „Jetzt kaufen“ enthalten
Icon mit Text „Suche“ → accessible name muss „Suche“ enthalten
Nicht: sichtbar „Absenden“, programmatisch „Submit-Button“

Sprachsteuerungs-Nutzer sagen „Klick Jetzt kaufen“ – das funktioniert nur, wenn der sichtbare Text im programmatischen Namen enthalten ist.

Bewegungsaktivierung (Level A)

Funktionen, die durch Gerätebewegung (Schütteln, Kippen) oder Nutzerbewegung ausgelöst werden, müssen auch durch herkömmliche Benutzerschnittstellen bedienbar sein.

Anforderungen:

Bewegungsaktivierung kann deaktiviert werden
Alternative Bedienung über UI-Komponenten verfügbar
Ausnahme: Bewegung ist essentiell oder vom Betriebssystem unterstützt

Beispiele:

„Schütteln zum Zurücksetzen“ braucht auch einen Reset-Button
„Kippen zur Steuerung“ braucht Pfeiltasten oder Buttons
Schrittzähler-Apps dürfen Bewegung als primäre Funktion nutzen

Zielgröße (Minimum) – Level AA (Aktualisiert in WCAG 2.2)

Klick- oder Touch-Ziele sollten mindestens 24×24 CSS-Pixel groß sein, mit einigen Ausnahmen.

Anforderungen:

Mindestgröße 24×24 CSS-Pixel für Klickbereich
Oder: ausreichender Abstand zu anderen Zielen
Oder: Inline-Elemente in Fließtext (Links in Absätzen)
Oder: vom Betriebssystem kontrolliert
Oder: spezifische Darstellung ist essentiell

Dies ersetzt das strengere Level AAA Kriterium aus WCAG 2.1 (44×44 Pixel) mit einem pragmatischeren Ansatz.

Drag-Bewegungen (Level AA – Neu in WCAG 2.2)

Alle Drag-and-Drop-Funktionen müssen auch ohne Ziehen bedienbar sein – durch einfache Zeigereingaben wie Klicks.

Umsetzung:

Alternative Buttons: „Nach oben“, „Nach unten“, „Löschen“
Klick-basierte Auswahl und Positionierung
Copy-Paste als Alternative
Tastatursteuerung zusätzlich

Ausnahme: Das Ziehen ist essentiell oder die Funktion wird vom User Agent bestimmt (Browser-eigene Funktionen).

Praktische Umsetzung

Ausreichende Klickbereiche gestalten

Auch wenn ein Icon oder Text kleiner ist, sollte der klickbare Bereich mindestens 24×24 Pixel (besser 44×44) betragen.

CSS-Technik:

Padding hinzufügen, um Klickbereich zu vergrößern
::before oder ::after Pseudo-Elemente für unsichtbare Klickfläche
Mindestabstände zwischen interaktiven Elementen
Touch-Target-Größe in mobilen Designs besonders beachten

Gesten mit Alternativen anbieten

Image-Galerie Beispiel:

Wischen funktioniert für Touch-Nutzer
Zusätzlich: Vor/Zurück-Buttons für alle
Tastatursteuerung mit Pfeiltasten
Thumbnails zum direkten Ansteuern

Zoom-Funktionalität:

Pinch-to-Zoom auf Touch-Geräten
Plus/Minus-Buttons für alle Nutzer
Browser-Zoom unterstützen
Tastaturkürzel (Strg/Cmd + Plus/Minus)

Sichere Button-Implementierung

Click-Event richtig setzen:

Standard-Button-Elemente verwenden (<button>)
Click-Events werden automatisch auf „up“ gefeuert
Bei Custom-Implementations: mouseup/touchend verwenden
Visuelles Feedback beim Drücken (active-State)

Kritische Aktionen absichern:

Bestätigungsdialoge bei „Löschen“ oder „Kaufen“
Rückgängig-Funktion anbieten
Undo-Mechanismus für versehentliche Aktionen

Sprachsteuerungs-freundliche Labels

Wichtige Prinzipien:

Sichtbarer Text = Programmatischer Name
Bei Icons mit Text: Text im accessible name
Bei Icons ohne Text: eindeutiger aria-label
Konsistente Bezeichnungen über die Website

Beispiel:

Sichtbar: „Warenkorb“ → aria-label=“Warenkorb“ oder „Zum Warenkorb“
Nicht: Sichtbar „Warenkorb“ → aria-label=“Shopping Cart Button“

Drag-and-Drop alternativ gestalten

Listen sortieren:

Drag-Handles für visuelles Feedback
Zusätzlich: Hoch/Runter-Buttons bei jedem Element
Tastatur: Fokus + Pfeiltasten + Enter zum Verschieben
Visuelle Rückmeldung bei allen Methoden

Datei-Upload:

Drag-and-Drop-Bereich für schnelles Hochladen
Zusätzlich: „Datei auswählen“-Button
Tastatur-zugänglich über nativen Datei-Dialog
Multiple-File-Upload ermöglichen

Mobile-First-Ansatz

Touch-optimiertes Design:

Großzügige Touch-Targets (min. 44×44 Pixel)
Ausreichende Abstände zwischen Elementen
Vermeidung von Hover-abhängigen Funktionen
Testen auf echten Mobilgeräten

BFSG 2025 und rechtliche Konsequenzen

Eingabemodalitäten sind ein relativ neues, aber wichtiges Thema in der digitalen Barrierefreiheit. Mit der zunehmenden Verbreitung von Touch-Geräten, Sprachsteuerung und assistiven Technologien werden diese Anforderungen immer relevanter.

Besonders kritische Bereiche:

Mobile Apps und responsive Websites
Interaktive Tools und Konfiguratoren
Drag-and-Drop-Interfaces (Sortieren, Organisieren)
Gestenbasierte Navigation
Spiele und interaktive Anwendungen

Das BFSG macht flexible Eingabemöglichkeiten zur Pflicht. Websites, die nur auf Mauseingaben oder komplexe Gesten ausgelegt sind, diskriminieren Menschen mit motorischen Einschränkungen und verstoßen gegen geltendes Recht.

Vorteile guter Eingabemodalitäten:

Bessere mobile Nutzererfahrung für alle
Höhere Conversion-Rates durch weniger Abbrüche
Zukunftssicher für neue Eingabemethoden
Positive Markenwahrnehmung

BarriGo. unterstützt Sie bei der Umsetzung

BarriGo.Live Inspect hilft Ihnen dabei, Steuerelemente für verschiedene Eingabemethoden zugänglich zu gestalten. Das Tool prüft, ob der sichtbare Button-Text im zugänglichen Namen enthalten ist (wichtig für Sprachsteuerung), ob interaktive Elemente ausreichend groß und per Tastatur erreichbar sind und ob Bedienelemente technisch korrekt ausgezeichnet sind.

Für komplexe Zeigergesten oder Bewegungssteuerungen empfiehlt sich ergänzend ein manueller Test – am besten auf echten Geräten, um sicherzustellen, dass Tippen, Sprache und Tastatur gleichermaßen gut funktionieren.

Weiterführende Informationen finden Sie im offiziellen WCAG 2.2 Standard: WCAG 2.2 – Richtlinie 2.5 Eingabemodalitäten