Ein Klick im modernen Web verbirgt eine Annahme: dass die Person, die klickt, eine Hand, ein Handgelenk und ein Zeigegerät hat, das sich auf zwei Achsen mit subpixelgenauer Präzision bewegt und über eine separate, zuverlässige Taste für den Klick verfügt. Fehlt auch nur eines davon, verändert sich die Begegnung. Für jemanden, der die Seite mit einem Eye-Tracker steuert, ist der „Cursor“ ein 1-Grad-Blickfeld-Kegel, der driftet und zittert. Für jemanden, der einen Head-Pointer benutzt, ist der Cursor ein per Webcam verfolgter Nasenspitzen-Tracker mit langsamem Dwell-to-Click. Für jemanden, der eine Single-Switch-Scan-Schnittstelle nutzt, gibt es gar keinen Cursor — nur eine wandernde Hervorhebung, die auf dem landet, was gerade fokussiert ist, wenn der Nutzer den Schalter drückt. Jede dieser Methoden ist eine reale Eingabemodalität, die heute, im Jahr 2026, von einer Bevölkerungsgruppe genutzt wird, die groß genug ist, dass das „moderne Web“ davon wissen sollte. Das tut es größtenteils nicht.
Dieser Beitrag ist ein Konzeptleitfaden zu den drei alternativen Eingabemodalitäten, auf die motorisch eingeschränkte Nutzer am häufigsten angewiesen sind — Eye-Tracking, Head-Pointing und Switch-Eingabe — und dazu, wie die Normenschicht (die WCAG-2.2-Erfolgskriterien, die W3C Pointer Events-Spezifikation) mit den Benutzeroberflächenmustern interagiert, die tatsächlich in Produktion erscheinen. Der Berichterstattungsrahmen ist redaktionell statt rechtsstreitigkeitsgetrieben: Es geht darum, was funktioniert, was nicht und was Designer morgen aufhören könnten zu tun.
Wer diese Eingaben nutzt — und warum
Die Bevölkerungsgruppe, die auf alternative Eingabemodalitäten angewiesen ist, ist nicht klein. Schätzungen des WHO-Global Report on Health Equity for Persons with Disabilities (2022, mit dem Monitoring-Update 2024) und des US-amerikanischen CDC-Disability and Health Data System beziffern den Anteil der Erwachsenen mit erheblicher Beeinträchtigung der oberen Extremitäten auf rund 8 % der Erwachsenenbevölkerung in Hocheinkommensländern und den Anteil der Erwachsenen, die zuverlässig keine Standard-Maus oder kein Trackpad bedienen können, auf rund 3–4 %. Innerhalb dieser 3–4 % gibt es mehrere distinkte Nutzergruppen, deren bevorzugte Eingabemodalität mehr durch ihre Physiologie als durch ihre Vorlieben bestimmt wird.
Die eindeutigste Gruppe sind Menschen mit amyotropher Lateralsklerose (ALS), die zunehmend die willkürliche Kontrolle über ihre Gliedmaßen und schließlich über ihre Gesichtsmuskulatur verlieren. Eye-Gaze-Tracking ist für viele Menschen mit fortgeschrittener ALS der einzige verbleibende Kanal für autonome Computernutzung. Die ALS Association schätzt, dass in den USA zu jedem Zeitpunkt ca. 30.000 Menschen mit ALS leben; das europäische ALS-Register legt eine ähnliche altersbereingte Prävalenz in der EU nahe. Die zweite Gruppe sind Menschen mit hochgradiger Rückenmarksverletzung — insbesondere C1-C4-Tetraplegie — für die Hände und Arme nicht verfügbar sind, Augen- und Kopfbewegungen aber erhalten bleiben. Die dritte Gruppe sind Kinder und Erwachsene mit Zerebralparese, bei denen die Eingabestrategie sehr individuell ist: Manche haben genug Fingerkontrolle für eine Switch-Schnittstelle, andere nutzen einen Head-Pointer, wieder andere einen kinngesteuerten Joystick. Die vierte Gruppe sind Menschen mit progressiven neuromuskulären Erkrankungen — Muskeldystrophie, Multiple Sklerose in späteren Stadien — die im Laufe der Zeit oft durch mehrere Eingabemodalitäten wechseln.
Über diese Gruppen hinweg lassen sich zwei Prinzipien erkennen, die die Variabilität durchschneiden. Erstens nutzt fast jeder, der eine alternative Eingabe verwendet, diese, weil die Standard-Maus-und-Tastatur-Kombination physisch unmöglich geworden ist — nicht weil eine neue Modalität bevorzugt wird. Zweitens ist die Eingabe in einem entscheidenden Sinne meist einachsig: eine einzelne Blickfixierung, eine einzelne Kopfzeigerichtung, ein einzelner Schalterdruck. Designs, die zwei koordinierte Kanäle voraussetzen — einen Zeiger plus eine Modifikator-Taste, eine Ziehbewegung plus ein präzises Ablageziel — versagen für diese Nutzergruppe am stärksten.
Die Hardware im Jahr 2026
Die Hardware-Landschaft hat sich in den letzten drei Jahren merklich verschoben. Was folgt, ist eine grobe Übersicht über das, was Nutzer tatsächlich verwenden — kein vollständiger Katalog.
Eye-Tracker
Tobii Dynavox bleibt der dominante klinische Eye-Gaze-Anbieter. Die aktuelle Generation — das PCEye und die I-Series — nutzt einen Infrarot-Sensor-Balken, der unter einem Monitor montiert oder in ein dediziertes Tablet integriert ist, und meldet die Blickposition als systemweiten Zeiger an das Host-Betriebssystem. Die Kalibrierung dauert ca. 30 Sekunden; die Präzision unter guten Bedingungen liegt bei ca. 0,5–1,0 Grad Sehwinkel, was bei einem typischen Betrachtungsabstand einem Blickfeldkegel von ca. 30–60 Pixeln entspricht. EyeGaze Edge (LC Technologies) und EyeTech VT3 sind klinische Alternativen. Auf der Verbraucherseite wird der Tobii Eye Tracker 5 hauptsächlich an Gamer verkauft, wird aber weitgehend als günstige Barrierefreiheits-Eingabe genutzt.
2024 brachte das erste Eye-Tracking für den Mainstream-Konsumenten, das in ein Allzweck-Computing-Gerät integriert ist: Die Apple Vision Pro wird mit Eye-Gaze als primärer Navigationsmodalität ausgeliefert, kombiniert mit einer Pinch-Geste zur Auswahl. visionOS stellt die Blickposition für systemweite Dwell-Auswahl-Barrierefreiheitsfunktionen bereit, und aus der Entwicklerperspektive wird eine Blickfixierung gefolgt von einem Pinch als Standard-Click-Ereignis gemeldet. Die Barrierefreiheitsbevölkerung hat visionOS aus dem vorhersehbaren Grund aufgenommen, aus dem sie 2008 das iPhone angenommen hat: eine eingebaute Modalität, die für den Mainstream konzipiert ist und zufällig auch den Barrierefreiheits-Anwendungsfall bedient. Der Preis der Vision Pro stellt sie für viele Nutzer außer Reichweite, aber der Präzedenzfall — Eye-Gaze als primäre Eingabe auf einem nicht-medizinischen Computer — ist der maßgebliche Präzedenzfall.
Head-Pointer
Head-Pointer-Software nutzt typischerweise die eingebaute Webcam des Geräts, um einen Fixpunkt zu verfolgen — oft die Nasenspitze oder einen kleinen reflektierenden Aufkleber auf der Stirn des Nutzers — und übersetzt Kopfrotation in Cursorbewegung. Camera Mouse (Boston College, kostenlos) ist die am längsten laufende Implementierung und wird weiterhin aktiv genutzt. Glassouse liefert einen tragbaren, kopfmontierten, gyroskopbasierten Controller, der sich mit dem Betriebssystem als Bluetooth-Maus koppelt. macOS enthält Head Pointer als eingebaute Barrierefreiheitsfunktion; Windows 11 hat äquivalente Funktionalität durch Eye Control in Verbindung mit kompatibler Hardware. Die Auswahl mit einem Head-Pointer ist fast immer dwell-basiert: Der Cursor verweilt für ein konfigurierbares Intervall auf einem Ziel — typischerweise 0,5 bis 2,5 Sekunden — und ein Click-Ereignis wird ausgelöst.
Switch-Eingabe
Switch-Eingabe ist die einfachste und variabelste der drei. Die Hardware ist ein einzelner Knopf — ein großer runder mechanischer Schalter, ein Saug-und-Puste-Schlauch, ein kinnbetätigter Hebel, ein Fußpedal, eine Brain-Computer-Schnittstelle im Spätstadium der Forschung — verkabelt mit einer standardisierten Schnittstelle (einem AbleNet Hook+, einem Pretorian J-Pad, einem Tecla Shield), die sich dem Betriebssystem als USB- oder Bluetooth-Tastatureingabe präsentiert. Die Software führt dann eine Scan-Schnittstelle aus: Ein Fokus-Indikator bewegt sich automatisch durch die verfügbaren Ziele auf dem Bildschirm, und der Nutzer drückt den Schalter, wenn der Fokus auf dem gewünschten Ziel landet. Single-Switch-Scanning bedeutet, dass ein Knopf alles steuert; Two-Switch-Scanning ordnet typischerweise einen Schalter „Weiter“ und den anderen „Auswählen“ zu. iOS enthält Switch Control als eingebaute Barrierefreiheitsfunktion; Android 14+ liefert Switch Access; macOS und Windows haben beide vergleichbare Funktionalität. Switch-Eingabe ist grundlegend seriell — der Nutzer kann nicht auf ein Ziel zeigen; er kann nur warten, bis der Scan es erreicht — und diese Tatsache prägt jedes Designmuster weiter unten.
Wie sie auf das Web treffen: die Normenschicht
Aus Browser-Perspektive sehen ein Eye-Tracker und ein Head-Pointer beide wie Standard-Zeigegeräte aus: Sie emittieren pointermove-, pointerdown- und pointerup-Ereignisse über die W3C Pointer Events-Spezifikation, die gleiche API, die eine Maus oder ein Touchscreen verwendet. Switch-Eingabe dagegen sieht für den Browser aus wie Tastatureingabe: Der Fokus traversiert tabulierbare Elemente, und der Schalterdruck löst ein keydown-Ereignis für Enter oder Space aus. Diese Divergenz ist das Erste, was ein Designer verinnerlichen muss — Eye-Gaze-Nutzer treffen die :hover-Zustände und Pointer-Event-Handler; Switch-Nutzer begegnen nur den per Tastatur fokussierbaren Elementen und der definierten Fokusreihenfolge.
WCAG 2.2 enthält mehrere Erfolgskriterien, die speziell darauf ausgelegt sind, diese Eingabemodalitäten funktionstüchtig zu halten. Drei davon tragen den Großteil des Gewichts.
SK 2.1.1 Tastatur (Stufe A) ist die grundlegende Anforderung: Jedes funktionale Element auf der Seite muss allein über eine Tastaturschnittstelle bedienbar sein. Switch-Nutzer sind absolut darauf angewiesen. Ein Element, das nur auf einen Mausklick reagiert — ein benutzerdefiniertes div mit einem click-Handler und ohne tabindex, ohne role, ohne keydown-Handler — ist für einen Switch-Nutzer unsichtbar. Es ist auch für viele Head-Pointer-Nutzer unsichtbar, die für Abschnitte der Seite, wo Dwell-Clicking zu langsam ist, auf Tastaturnavigation zurückgreifen.
SK 2.5.1 Zeigergesten (Stufe A) erfordert, dass jede Funktion, die per Mehrpunkt- oder pfadbasierter Geste betätigt wird, auch mit einer einzelnen Zeiger-Aktion bedienbar ist. Das Kriterium existiert, weil Eye-Gaze, Head-Pointer und viele alternative Eingaben keine Mehrfinger-Gesten oder präzise Ziehpfade zuverlässig ausführen können. Ein Pinch-to-Zoom ohne alternative Schaltfläche. Ein Wischen-zum-Löschen ohne On-Screen-Löschen-Steuerelement. Eine Ziehen-zum-Sortieren-Liste ohne Tastaturäquivalent. Jedes davon ist ein 2.5.1-Versagen, und jedes schneidet die Modalität ab, über die der Nutzer tatsächlich verfügt.
SK 2.5.2 Zeiger-Abbrechbarkeit (Stufe A) erfordert, dass für jede Single-Pointer-Aktivierung entweder die Aktion nicht beim Down-Ereignis ausgeführt wird (sie wird stattdessen beim Up-Ereignis ausgeführt) oder beim Down-Ereignis ausgeführt wird, aber dem Nutzer erlaubt, die Aktion durch Wegbewegen vor dem Up-Ereignis abzubrechen. Das Kriterium ist für Nutzer geschrieben, die das falsche Ziel durch ein Zittern oder eine Drift treffen, und es ist intensiv wichtig für dwell-basierte Head-Pointer- und Eye-Gaze-Schnittstellen: Ein Klick, der in dem Moment ausgelöst wird, in dem der Cursor landet, gibt dem Nutzer keine Chance, sich von einem Blick-Drift zu erholen. Schaltflächen, die ihren Handler an mousedown statt an click binden, verstoßen gegen dieses Kriterium.
SK 2.5.7 Ziehbewegungen (neu in WCAG 2.2) erweitert den Gestenschutz speziell auf Drag-and-Drop: Alles Ziehbare muss auch über eine Single-Pointer-Alternative erreichbar sein, typischerweise eine schaltflächengesteuerte Hoch/Runter-Verschiebung. SK 2.5.4 Bewegungsbetätigung (Stufe A) schützt Nutzer, die ihr Gerät nicht zuverlässig schütteln oder kippen können. Und SK 2.2.1 Zeitlimit einstellbar (Stufe A) und SK 2.2.2 Pausieren, Stoppen, Ausblenden (Stufe A) schützen alle vor Schnittstellen, die ablaufen, bevor eine Scan-Schnittstelle das relevante Steuerelement erreichen kann.
Diese Kriterien sind als ein einziger, integrierter Rahmen geschrieben: Der Nutzer hat nur eine Eingabeachse, die Eingabe ist langsam, und das Design darf nicht anders annehmen.
Häufige Fehler auf Produktionsseiten
Stellt man diese Kriterien dem gegenüber, was Produktionsseiten tatsächlich ausliefern, ergibt sich ein wiederkehrendes Muster von Fehlern. Keiner davon ist exotisch. Alle tauchen beim routinemäßigen Nutzertest mit Eye-Tracker-, Head-Pointer- und Switch-Nutzern auf.
Drag-and-Drop ohne Tastaturalternative. Ein verbreitetes Muster in Projektmanagement-Tools, Dateimanagern und Ranglisten-Schnittstellen: eine Karte von einer Spalte in eine andere ziehen. Für Switch-Nutzer ist die Aktion unmöglich — im Scanning gibt es kein Ziehen. Für Head-Pointer- und Eye-Gaze-Nutzer ist das Ziehen selbst ca. 4–5× langsamer als eine schaltflächengesteuerte Verschiebung und ist in der Regel nicht vollendbar, ohne das Element auf dem Weg fallen zu lassen. Die Lösung ist unkompliziert: Jedes Drag-and-Drop mit einer schaltflächengesteuerten Verschiebungsaktion koppeln, die in der Tastatur-Tab-Reihenfolge zugänglich ist. Das Trello-artige „Karte hoch / Karte runter / In eine andere Liste verschieben“-Menümuster ist die Referenzimplementierung.
Nur-Hover-Navigation. Dropdown-Menüs, Tooltips und Disclosure-Steuerelemente, die nur bei :hover erscheinen und verschwinden, wenn der Cursor das Element verlässt. Für einen Eye-Gaze-Nutzer driftet der Blickfeldkegel vom Menü-Trigger weg, sobald versucht wird, auf ein Unterelement zu blicken, und das Menü schließt sich, bevor es erreicht wird. Das WCAG-2.2-Kriterium dafür ist 1.4.13 Inhalt bei Hover oder Fokus (Stufe AA): Hover-ausgelöste Inhalte müssen schließbar, überfahrbar (der Nutzer kann hineinbewegen, ohne dass sie verschwinden) und persistent sein. Viele Produktionsmenüs versagen bei allen dreien.
Winzige Klickziele. SK 2.5.8 Zielgröße (Minimum) (Stufe AA, neu in WCAG 2.2) verlangt, dass interaktive Ziele mindestens 24×24 CSS-Pixel groß sind, mit Ausnahmen. Das Kriterium wurde für Touch und für zeigerpräzisionseingeschränkte Nutzer geschrieben — Eye-Gaze, Head-Pointer, Handzittern. Ein 16-Pixel-Schließen-Symbol in der Ecke eines Modals ist in der Praxis mit einem Eye-Tracker kaum zuverlässig zu treffen. Die Lösung ist mechanisch: Ziele größer machen oder dieselbe Aktion über ein größeres Steuerelement an anderer Stelle der Benutzeroberfläche zugänglich machen.
Zeitgebundene Klicks. Karussells, die alle 5 Sekunden automatisch weiterschalten, „Sie haben 30 Sekunden zur Bestätigung“-Dialoge, Sitzungs-Timeouts, die mitten in einer Aufgabe auslösen. Für einen Switch-Nutzer, der eine Scan-Schnittstelle mit einer 1,5-Sekunden-pro-Ziel-Scan-Rate navigiert, sind 30 Sekunden ca. 20 erreichbare Ziele — oft nicht genug, um den Bestätigungsknopf zu erreichen. SK 2.2.1 Zeitlimit einstellbar verlangt, dass jedes Zeitlimit verlängerbar, einstellbar oder abweisbar ist. Die meisten Produktions-Timeouts sind keines davon.
Gestennur-Bestätigung. Wischen-zum-Bestätigen-Schieberegler, Unterschriften-Pad-Bestätigungen, Captchas, die das Verfolgen eines Pfads erfordern. Jedes davon ist ein 2.5.1-Versagen, sofern keine Schaltflächenalternative vorhanden ist.
Aktion bei mousedown. Eine Schaltfläche, die ihren Handler bei mousedown statt beim Standard-click-Ereignis auslöst, lässt dem Nutzer keine Möglichkeit, eine Fehlbedienung abzubrechen. SK 2.5.2 Zeiger-Abbrechbarkeit ist das Kriterium; die Lösung besteht darin, an click oder pointerup mit expliziter Abbruchprüfung zu binden.
Benutzerdefinierte Steuerelemente ohne ARIA. Ein <div>, das visuell wie eine Schaltfläche aussieht, aber role=“button”, tabindex=“0” und einen keydown-Handler für Enter und Space fehlen lässt. Das Steuerelement ist für Switch und Tastatur-Fallback nicht erreichbar. SK 4.1.2 Name, Rolle, Wert (Stufe A) ist das Kriterium. Die Lösung ist das native <button>-Element überall wo möglich, und ein vollständiges ARIA-Muster wo nicht.
Designmuster, die funktionieren
Die Muster, die einen Eye-Tracker, einen Head-Pointer und einen Switch-Scan überleben, teilen eine kleine Anzahl struktureller Eigenschaften. Jedes ist im ARIA Authoring Practices Guide und in den WCAG-2.2-Verständnisdokumenten gut dokumentiert, und jedes ist im routinemäßigen Produktiveinsatz auf Sites, die für ein Mainstream-Publikum ausgeliefert werden, ohne dass es jemandem auffällt.
Native HTML-Elemente wo immer möglich. Der bei weitem zuverlässigste Barrierefreiheits-Schritt ist die Verwendung von <button>, <a>, <input>, <select> und <textarea> für ihre semantischen Zwecke. Native Elemente kommen mit der richtigen Tastaturverarbeitung, den richtigen ARIA-Rollen, dem richtigen Fokusverhalten und der richtigen Zeiger-Abbrechbarkeits-Semantik eingebaut. Die Komplexität, eine dieser Eigenschaften mit einem benutzerdefinierten <div> korrekt nachzubauen, beträgt ca. das 10-fache des Engineering-Aufwands für ein fast immer schlechteres Ergebnis.
Sichtbare Fokusindikatoren mit ausreichendem Kontrast. Für Switch-Nutzer ist der Fokusring der Cursor. Ein 2-Pixel-blauer Ring mit 4:1-Kontrast gegenüber dem umgebenden Hintergrund ist das Verfahrensminimum (SK 2.4.7 Fokus sichtbar, Stufe AA, und SK 2.4.11 Fokus nicht verdeckt, neu in WCAG 2.2). Sites, die den Standard-Browser-Fokusring entfernen, ohne ihn zu ersetzen, lassen Switch-Nutzer orientierungslos zurück.
Vorhersagbare Fokusreihenfolge. Ein Switch-Scan bewegt sich standardmäßig durch das DOM in Quellreihenfolge, modifiziert durch tabindex. Eine Scan-Reihenfolge, die auf der Seite herumspringt, macht die Schnittstelle unbenutzbar. SK 2.4.3 Fokusreihenfolge (Stufe A) ist das Kriterium; die praktische Implikation ist, dass visuelle Reihenfolge und DOM-Reihenfolge überall dort übereinstimmen sollten, wo der Nutzer eine Abfolge von Aktionen ausführt.
Großzügige Aktivierungsbereiche. Das 24-Pixel-Minimum von SK 2.5.8 ist der Boden, nicht das Ziel. Viele der Designsysteme, die seit 2022 barrierefreiheitsgetestete Muster veröffentlicht haben — Adobe Spectrum, IBM Carbon, GOV.UK Design System, das US Web Design System — verwenden standardmäßig 44-Pixel-Touch-Ziele, was für zeigerpräzisionseingeschränkte Nutzer gut funktioniert, ohne das visuelle Layout zu beeinträchtigen.
Bestätigungsabläufe mit expliziten Schaltflächen. Jede destruktive oder unwiderrufliche Aktion sollte eine explizite Bestätigungsschaltfläche erfordern — kein Wischen, kein langes Drücken, kein „Klicken Sie irgendwo außerhalb zum Schließen“. Das Muster funktioniert für alle und übersteht jede alternative Eingabe.
Großzügige Timeouts oder gar keine. Wenn ein Timeout aus Sicherheitsgründen erforderlich ist (Banking, Gesundheitswesen), muss der Nutzer es durch eine Single-Pointer-Aktion gut vor dem Auslösen verlängern können. Das Muster sieht vor, einen „Noch da?“-Hinweis bei 75 % des Timeout-Fensters einzublenden, mit einer einzigen großen Schaltfläche zur Verlängerung.
Skip-Links und Landmark-Navigation. Eine Scan-Schnittstelle, die das gesamte Navigationsmenü, den gesamten Hero-Bereich und den gesamten Anzeigenblock traversieren muss, bevor sie den Artikelkörper erreicht, ist unbenutzbar. Ein „Zum Inhalt springen“-Link als erstes fokussierbares Element der Seite ist das Minimum; Landmark-Regionen (<main>, <nav>, <aside>) ermöglichen Switch-Nutzern strukturelles statt lineares Springen.
Die Einstellung prefers-reduced-motion des Nutzers respektieren. Automatisch weiterschaltendes Karussell und ständig animierte Hintergründe machen es einem Eye-Tracker unmöglich, sich auf ein stabiles Ziel zu fixieren. CSS-Media-Queries (@media (prefers-reduced-motion: reduce)) ermöglichen dieselbe Schnittstelle für Nutzer, die die Bewegung abgeschaltet brauchen.
Was das für Designer, Entwickler und Produktteams bedeutet
Der Berichterstattungsstand zu alternativen Eingabemodalitäten führt zu einem Ergebnis, das jedem vertraut sein sollte, der andere Barrierefreiheits-Leitfäden dieser Site gelesen hat. Die Technologie hat sich weiterentwickelt. Die Normen haben sich weiterentwickelt. Die Nutzerbevölkerungen sind gut charakterisiert. Die verbleibende Arbeit liegt in Beschaffung, Schulung und der täglichen Gewohnheit, Schnittstellen zu bauen, die nicht stillschweigend zweiachsige, beidhändige, subsekundenlatente Eingabe voraussetzen.
Für Designer: mit der Tastatur prototypisieren. Wenn ein Design unter reiner Tastaturnavigation mit sichtbarem Fokusring funktioniert, funktioniert es für Switch-Nutzer; wenn nicht, hat das visuelle Design das Interaktionsmodell überholt. Der Gaze-plus-Pinch-Präzedenzfall der Apple Vision Pro rahmt alternative Eingabe als Design-Baseline statt als Nachbesserung. Designs, die Vision Pro überleben, überleben tendenziell auch Tobii.
Für Entwickler: an click statt an mousedown binden. Native HTML-Elemente verwenden. Die Tab-Reihenfolge testen. Die Seite vor der Auslieferung durch ein reines Tastatur-Audit laufen lassen. Die meisten oben beschriebenen Fehler sind Engineering-Konvention, keine Engineering-Schwierigkeit.
Für Produktteams: Nutzer alternativer Eingabemodalitäten in routinemäßige Nutzertests einbeziehen. Die oben beschriebenen Barrieren sind keine Randfälle; sie sind routinemäßige Fehler, die in 30 Minuten Testen mit einem Tobii-Balken oder einem iOS-Gerät mit aktiviertem Switch Control auftauchen. Die Kosten der Einbeziehung der Modalität in den Testplan sind gering. Die Nichteinbeziehung zeigt sich als die oben beschriebene Art von Fehlern, in großem Maßstab ausgeliefert an eine Bevölkerungsgruppe, deren Optionen bereits eng sind.
Das Web funktioniert, wenn es akzeptiert, dass der Klick kein universelles Verb ist. Die Nutzerin mit einem Tobii-Balken unter ihrem Monitor, der Nutzer mit einer Webcam, die seine Nasenspitze verfolgt, der Nutzer mit einem einzelnen mechanischen Schalter, der mit einer Ecke eines Schreibtischs verbunden ist — jeder von ihnen führt dieselbe Aktion aus wie ein Nutzer mit einem Trackpad. Die Normenschicht erkennt das an. Die obigen Designmuster ehren es. Die Arbeit besteht darin, weiterhin so zu bauen, als ob das wahr wäre.
Weitere Artikel von Disability World zu den WCAG-2.2-Erfolgskriterien, zum umfassenderen Berichterstattungsstand 2026 und zu unserer laufenden Berichterstattung zu assistiver Technologie.