Motorische Einschränkungen: Bedienung ohne Maus

Bei motorischen Einschränkungen ist nicht der Inhalt einer Website die Barriere, sondern der Weg dorthin: Die Maus verlangt ruhige Hände, präzise Zielbewegungen und schnelle Doppelklicks – genau das, was bei Tremor, Spastik, Lähmung oder Arthrose fehlt. Zugänglich wird eine Seite dadurch, dass jede Funktion ohne Maus erreichbar ist, Ziele groß genug sind, niemand unter Zeitdruck steht und ein danebengegangener Klick folgenlos bleibt.

Das Wichtigste in Kürze

• Von den rund 7,9 Millionen schwerbehinderten Menschen in Deutschland (Statistisches Bundesamt, Stand Ende 2023) ist bei 11 % die Funktion von Armen oder Beinen eingeschränkt, bei weiteren 10 % Wirbelsäule und Rumpf.
• Dazu kommen große Krankheitsgruppen: rund 400.000 Menschen mit Parkinson – bis 2040 werden 50 % mehr erwartet – und über 280.000 mit Multipler Sklerose (DMSG).
• Die Tastatur ist der gemeinsame Nenner: Mundmaus, Kopfmaus, Eye-Tracking, Taster und die meisten Sprachsteuerungen erzeugen darunter Fokus- und Aktivierungsereignisse.
• Pflicht ab Stufe A: alles per Tastatur bedienbar (2.1.1), keine Tastaturfalle (2.1.2), Aktion beim Loslassen statt beim Drücken (2.5.2).
• Neu in WCAG 2.2 und für diese Gruppe zentral: Zielgröße mindestens 24 × 24 CSS-Pixel (2.5.8) und Ziehbewegungen nur mit Alternative (2.5.7).
• Fitts’ Gesetz gilt für alle: Je kleiner und weiter entfernt ein Ziel, desto länger dauert der Weg dorthin – bei Tremor überproportional länger, weil jeder Fehlversuch eine neue Bewegung kostet.
• Zeit ist eine Barriere: Ein Session-Timeout mitten im Formular trifft genau die Menschen, die am längsten zum Ausfüllen brauchen (2.2.1).
• Der Selbsttest kostet nichts: Maus weglegen und den wichtigsten Ablauf nur mit Tab, Enter und Pfeiltasten durchspielen.

Wer betroffen ist – und wie viele

„Motorisch eingeschränkt“ klingt nach Rollstuhl. Fürs Web entscheidet aber die Feinmotorik der Hände, und die ist aus sehr unterschiedlichen Gründen beeinträchtigt:

• Tremor – bei Parkinson, essenziellem Tremor, als Nebenwirkung von Medikamenten oder schlicht altersbedingt. Der Zeiger zittert mit; kleine Ziele werden zum Glücksspiel.
• Spastik und Bewegungsstörungen – bei Cerebralparese, nach einem Schlaganfall, bei Multipler Sklerose. Bewegungen setzen verzögert ein oder schießen über das Ziel hinaus.
• Kraft- und Ausdauerverlust – bei Muskelerkrankungen, ALS, Rheuma. Nicht die einzelne Bewegung ist das Problem, sondern hundert Bewegungen hintereinander.
• Schmerz und Gelenksteife – Arthrose, Arthritis, Karpaltunnelsyndrom, Sehnenscheidenentzündung. Betrifft Millionen, wird selten als Behinderung eingeordnet und wirkt sich am Bildschirm trotzdem genauso aus.
• Lähmungen und Amputationen – hier entfällt die Maus vollständig, gearbeitet wird mit alternativer Hardware.

Zwei Dinge sind daran wichtig. Erstens ist der Übergang zur übrigen Nutzerschaft fließend: Situative Einschränkungen wie eine Hand am Haltegriff im Bus erzeugen dieselben Probleme. Zweitens steigt die Häufigkeit mit dem Alter steil an – und die Nutzerschaft der meisten Websites altert mit.

Wie Betroffene bedienen

Nur Tastatur. Wer nicht zielen kann, navigiert mit Tab, Umschalt+Tab, Enter, Leertaste und Pfeiltasten. Das ist präzise, weil jede Taste ein eindeutiges Ereignis auslöst – kein Millimeter dazwischen. Wie das im Detail abläuft, steht unter Tastatur- und Switch-Bedienung.

Sprachsteuerung. Dragon, Voice Control und Voice Access führen Klicks per Befehl aus. Dafür müssen sichtbare Beschriftung und technischer Name zusammenpassen – die Details stehen unter Sprachsteuerung.

Spezialhardware. Kopfmaus, Mundmaus, große Trackballs, Eye-Tracking, Taster. Fast alle verhalten sich gegenüber der Website wie Tastatur oder Zeiger – es gibt kein „Eye-Tracking-HTML“.

Touch mit Einschränkungen. Auf dem Smartphone wird mit dem Daumen, dem Handballen oder einem Stift getroffen: zittrig, ungenau, oft einhändig. Genau deshalb ist Zielgröße kein reines Desktop-Thema.

Ein Punkt, der dabei gern übersehen wird: Wer langsam zielt, trifft auch langsam – und trifft dann auf eine Seite, die noch mit dem Laden beschäftigt ist. Verzögerte Reaktionen auf Eingaben trifft die Gruppe doppelt, weil ein nicht quittierter Klick zum zweiten Klick verleitet. Gemessen wird das als INP; wie man es senkt, steht unter LCP & INP gezielt optimieren.

Fitts’ Gesetz: warum Zielgröße kein Detail ist

Fitts’ Gesetz beschreibt, wie lange eine Zeigebewegung dauert: Sie wächst mit der Entfernung und schrumpft mit der Zielgröße. Bei Tremor verschiebt sich diese Kurve dramatisch, weil jeder Fehlversuch eine komplett neue Bewegung verlangt – und die kostet wieder Zeit und Kraft.

Die gute Nachricht: Die Trefferfläche muss nicht so groß aussehen, wie sie ist. Ein kleines Symbol darf klein bleiben, solange der klickbare Bereich darum herum wächst.

/* Falsch: 16 × 16 px echte Trefferfläche, dicht an dicht */
.icon-btn { width: 16px; height: 16px; padding: 0; }

/* Richtig: Optik bleibt klein, die Trefferfläche wächst auf 44 × 44 px */
.icon-btn {
  position: relative;
  width: 16px;
  height: 16px;
  padding: 0;
}
.icon-btn::after {
  content: '';
  position: absolute;
  inset: -14px;                 /* 16 + 2 × 14 = 44 px */
}
.icon-btn + .icon-btn { margin-left: 12px; }   /* Ziele nicht verkleben */

Die Ausnahmen des Kriteriums – etwa Links im Fließtext – stehen unter 2.5.8 Zielgröße (Minimum).

Die Muster, die am häufigsten scheitern

Aktion beim Drücken statt beim Loslassen. Wer danebenklickt, muss den Fehler zurücknehmen können, indem er den Zeiger vor dem Loslassen wegzieht. Genau das verlangt 2.5.2 Zeiger-Abbruch.

// Falsch: löst schon beim Aufsetzen des Fingers aus – kein Zurück möglich
el.addEventListener('pointerdown', loeschen);

// Richtig: click feuert erst, wenn Drücken und Loslassen auf dem Element passieren
el.addEventListener('click', loeschen);

Ziehen ohne Alternative. Eine Liste umsortieren, einen Regler bewegen, eine Karte verschieben – jede Ziehbewegung braucht seit 2.5.7 einen zweiten Weg über einfache Zeigeraktionen.

<!-- Zusätzlich zum Ziehen: Schaltflächen, die dasselbe erledigen -->
<li>
  <span class="drag-handle" aria-hidden="true"></span>
  Kapitel 3: Formulare
  <button type="button" aria-label="Kapitel 3 nach oben verschieben">Hoch</button>
  <button type="button" aria-label="Kapitel 3 nach unten verschieben">Runter</button>
</li>

Menüs, die nur auf Hover reagieren. Ein Untermenü, das sich nur öffnet, solange der Zeiger ruhig darauf steht, ist bei Tremor unbedienbar. Menüs gehören auf Klick und Enter – Muster dazu stehen unter Menüs und Dropdowns.

Doppelklick als einziger Weg. Ein Doppelklick verlangt zwei Klicks in unter 500 Millisekunden auf demselben Punkt. Als einzige Möglichkeit, eine Funktion zu erreichen, schließt er aus.

Timeouts. Ein Warenkorb, der nach 15 Minuten leer ist, bestraft Langsamkeit. Die Verlängerung muss vor dem Ablauf angeboten werden, nicht danach.

Eingaben, die verloren gehen. Wenn ein Formular bei einem Fehler geleert wird, kostet das jemanden mit Tremor unter Umständen zwanzig Minuten Arbeit. Eingaben bleiben stehen – und was schon bekannt ist, wird nicht noch einmal abgefragt.

So testest du es

1. Maus weglegen und den wichtigsten Ablauf komplett mit Tab, Enter, Leertaste und Pfeiltasten durchspielen – Suche, Filter, Warenkorb, Formular.
2. Zielgrößen messen: In den DevTools ein Symbol auswählen und im Box-Modell prüfen, ob die klickbare Fläche mindestens 24 × 24 CSS-Pixel misst, Abstand zum Nachbarn eingerechnet.
3. Mit der anderen Hand bedienen. Klingt albern, wirkt sofort: Maus auf die andere Seite legen, dann die Seite benutzen. Jede zu kleine Fläche fällt in Sekunden auf.
4. Klick abbrechen: Auf einer Schaltfläche die Maustaste drücken, den Zeiger wegziehen, loslassen. Passiert trotzdem etwas, ist 2.5.2 verletzt.
5. Ziehen umgehen: Jede Drag-Funktion einmal ohne Ziehen erledigen. Geht es nicht, fehlt die Alternative.
6. Warten: Ein Formular öffnen, zwanzig Minuten liegen lassen, dann absenden. Sind die Eingaben noch da, oder war alles umsonst?

Häufiger Fehler in der Praxis

Zielgröße nur mobil geprüft. Viele Teams halten am Smartphone 44 Pixel ein und bauen am Desktop 16-Pixel-Symbole dicht an dicht. Für eine Kopfmaus oder eine zitternde Hand ist der Desktop aber der schwierigere Fall, nicht der leichtere.

Der Symbol-Teppich in Tabellen. Bearbeiten, Duplizieren, Löschen als drei winzige Zeichen ohne Abstand in jeder Zeile – und Löschen liegt direkt neben Bearbeiten. Wenn schon eng, dann wenigstens die zerstörerische Aktion räumlich trennen und bestätigen lassen.

outline: none im CSS-Reset. Ohne sichtbaren Fokus ist Tastaturbedienung Raten. Was stattdessen zu tun ist, steht unter Tastaturbedienung & sichtbarer Fokus.

Selbstgebaute Regler und Scrollbars. Beide setzen präzises Ziehen voraus und sind fast nie tastaturbedienbar. Der native <input type="range"> kann beides von Haus aus – siehe Slider und Karussells.

Nur mit der Maus getestet. Der häufigste Fehler überhaupt und der billigste zu beheben. Ich würd jede Abnahme mit fünf Minuten Tastaturbedienung beginnen lassen – danach diskutiert niemand mehr über Prioritäten.

Häufige Fragen

Ist Tastaturbedienung nicht ein Nischen-Feature?

Nein, sie ist der gemeinsame Nenner fast aller assistiven Technologien. Screenreader, Switch-Systeme, Kopfmäuse und viele Sprachsteuerungen setzen auf denselben Fokus- und Aktivierungsmechanismen auf. Wer den Tastatur-Durchlauf besteht, hat einen Großteil der motorischen Barrieren beseitigt – und nebenbei jede Power-Userin glücklich gemacht.

Reicht eine kleine Verzögerung, damit Hover-Menüs offen bleiben?

Sie hilft, ersetzt aber keine Klick-Bedienung. Ein Menü sollte per Klick beziehungsweise Enter öffnen und schließen; Hover darf Komfort obendrauf sein, nie Voraussetzung. Zusätzlich gilt für alles, was bei Hover erscheint, 1.4.13: Es muss wegdrückbar bleiben und stehen bleiben, wenn man mit dem Zeiger hineinfährt.

Was ist mit Touch-Gesten wie Wischen oder Zwei-Finger-Zoom?

Komplexe Gesten brauchen eine einfache Alternative – das regelt 2.5.1 Zeigergesten. Ein Karussell braucht sichtbare Vor- und Zurück-Schaltflächen, eine Karte Zoom-Schaltflächen neben der Pinch-Geste. Für Menschen, die nur einen Finger sicher aufsetzen können, ist alles andere unerreichbar.

Muss ich 24 × 24 Pixel einhalten oder 44 × 44?

Rechtlich reichen 24 × 24 CSS-Pixel, weil EN 301 549 auf die WCAG verweist und 2.5.8 dort auf Stufe AA steht; 44 × 44 ist die Empfehlung der Plattform-Richtlinien und die AAA-Variante. Meine Praxisregel: 24 als harte Grenze in dichten Werkzeugleisten, 44 überall dort, wo eine Aktion Geld, Daten oder Zeit kostet.

Hilft ein Barrierefreiheits-Overlay bei motorischen Einschränkungen?

Nein. Overlays vergrößern manchmal Zeiger oder Schrift, ändern aber nichts an Trefferflächen, Fokusreihenfolge oder Drag-Zwang – und sie kollidieren regelmäßig mit Sprachsteuerung und Switch-Systemen. Die Ursachen liegen im Markup, nicht in einer Zusatzschicht; warum ich davon abrate, steht unter Tools.

Verwandte Themen

• Tastatur- und Switch-Bedienung – wie Scanning funktioniert und welche Tastenkonventionen gelten
• Sprachsteuerung – bedienen mit der Stimme, wenn die Hände ausfallen
• Situative und temporäre Einschränkungen – dieselben Barrieren, deutlich mehr Betroffene
• Tastaturbedienung & sichtbarer Fokus – die Praxisseite mit CSS-Rezepten
• Buttons vs. Links – warum das richtige Element die halbe Arbeit spart
• WCAG 2.2 Kriterien – die neuen Kriterien zielen fast alle auf diese Gruppe

Quellen

• 7,9 Millionen schwerbehinderte Menschen leben in Deutschland (Statistisches Bundesamt – Verteilung nach Art der Behinderung, Stand Ende 2023)
• Was ist Multiple Sklerose? (DMSG – mehr als 280.000 Erkrankte in Deutschland)
• Understanding SC 2.5.8 Target Size (Minimum) (W3C – Herleitung der 24-CSS-Pixel-Grenze und ihre Ausnahmen)
• Understanding SC 2.5.2 Pointer Cancellation (W3C – warum Aktionen beim Loslassen ausgelöst werden)
• Tastaturbedienung (Bundesfachstelle Barrierefreiheit/BFIT-Bund – Handreichung für Webauftritte und Apps)