Motorische Barrierefreiheit in klinischen Lern-Apps

Sie öffnen die Fall-App auf dem Tablet. Der nächste Hinweis verlangt eine Pinch-Geste zum Vergrößern des Bildes, dann ein langes Ziehen bis zum Hypothesenfeld und ein präzises Tippen auf ein 24-Pixel-Symbol neben einem fast identischen. Mit leichtem Händezittern oder eingeschränkter Kraft in einer Extremität scheitert der Versuch dreimal, bevor die Hypothese überhaupt gesendet wird. Das klinische Denken war bereit. Die Oberfläche verlangte feinmotorische Präzision. Das ist das Feld der motorischen Barrierefreiheit in Apps für klinisches Lernen und in Diagnosespielen.

Motorische Barrierefreiheit bedeutet, die Interaktion für Menschen nutzbar zu machen, die Tremor, eingeschränkte Extremitäten, reduzierte Kraft, geringere Tippgenauigkeit, Muskelermüdung haben oder mit Switch, Tastatur, Trackball, Controller oder Spracheingabe arbeiten. Sie gilt für Studierende und Ärztinnen und Ärzte mit dauerhafter körperlicher Behinderung und ebenso für Menschen mit Schiene, nach einem Eingriff, mit akutem Schmerz oder für alle, die das Gerät im Dienst mit einer Hand bedienen. Der Schwerpunkt dieses Textes liegt auf der Gestaltung von Apps und Lernplattformen: Touch-Ziele, Gesten, Zeit, Drag-and-drop und Eingabealternativen. Es ist keine nummerierte Checkliste technischer Normen für medizinische Software und kein Leitfaden zu Screenreadern (Thema eines anderen Beitrags der Reihe).

Wichtigste Punkte

• Motorische Barrieren in Apps für klinisches Lernen umfassen kleine Ziele, Gesten mit vorgeschriebenem Weg, Drag-and-drop ohne Alternative, kurze Timeouts und die Abhängigkeit von feinem Mauszeiger oder präzisem Tippen.
• Nützliche Prinzipien: große und gut verteilte Ziele, Bedienung mit einem einzigen Zeiger, flexible Zeit, vollständige Tastatur- und Switch-Bedienung, einfaches Rückgängigmachen und Gleichwertigkeit von Tippen, Tastatur und assistiver Eingabe.
• Studierende und Ärztinnen und Ärzte mit körperlicher Behinderung gibt es in der Ausbildung; funktionale technische Standards verlangen das klinische Ergebnis, nicht eine einzige Art des Zeigens auf dem Bildschirm.
• Zielgröße und Alternativen zu komplexen Gesten stützen sich auf Interaktionsforschung und internationale Leitlinien zur Barrierefreiheit im Web und auf Mobilgeräten.
• Bei NEXO verlangen fiktive Fälle mit realer klinischer Darstellung und bis zu sechs Hinweisen im Bildschirmablauf die Interaktion mit Hinweisen und Hypothesen; inklusive Gestaltung verringert motorische Reibung, ohne Wirksamkeit zu behaupten.

Was motorische Barrierefreiheit in Lern-Apps ist

Motorische Barrierefreiheit ist die Gesamtheit der Oberflächenentscheidungen, die es ermöglichen, eine App zu bedienen, ohne von feinen, schnellen oder komplexen Bewegungen abhängig zu sein. Im digitalen klinischen Lernen umfasst das das Antippen von Hinweisen, das Öffnen von Hypothesen, das Bestätigen des Sendens, das Navigieren in der Differenzialdiagnose und das Abschließen des Falls. Wenn der einzige Weg zum Weiterkommen eine Pinch-Geste gefolgt von einem präzisen Ziehen unter Zeitdruck ist, misst die App digitale Geschicklichkeit, nicht nur Denken.

Nicht zu verwechseln mit kognitiver Barrierefreiheit (Sprache, Belastung, Feedback) oder mit visueller Barrierefreiheit (Screenreader, Kontrast, Vergrößerung). Ein Fall kann kognitiv klar sein und dennoch für Menschen unzugänglich, die den Finger nicht stabil über einem winzigen Ziel halten können. Es ist auch nicht dieselbe Achse wie der Beitrag über digitale Barrierefreiheit in medizinischer Software, der auf allgemeinen Kriterien klinischer Software liegt, noch der über assistive Technologie für Ärztinnen und Ärzte mit Sehbehinderung. Hier ist das Problem motorisch: Tremor, Kraft, Bewegungsamplitude, Nutzung von Switch und Gleichwertigkeit der Eingabe.

In der medizinischen Ausbildung gibt es Studierende mit körperlichen und sensorischen Behinderungen, auch wenn die Bekanntmachung und die Anpassungen noch uneinheitlich sind. In einer nationalen Analyse technischer Standards medizinischer Fakultäten stützten nur wenige Dokumente ausdrücklich angemessene Anpassungen; viele waren mehrdeutig oder schwiegen zu Verantwortung und zur Nutzung von Hilfsmitteln (Zazove et al., 2016). Eine ethische Analyse argumentiert, dass "organische" Standards (das Organ oder die Geste ohne Hilfsmittel verlangen) fähige Kandidaten unter funktionalen Standards ausschließen, die das Ergebnis der Aufgabe mit Anpassung verlangen (McKee et al., 2016). Die Parallele zu Lern-Apps ist direkt: "präzises Tippen mit dem dominanten Daumen" zu verlangen ist ein organischer Standard der Oberfläche; "die Hypothese absenden" mit Tastatur, Switch oder vergrößertem Tippen zu verlangen ist ein funktionaler Standard.

Prävalenz und Verlauf sind auch für die Gestaltung von Bildungsprodukten wichtig. Daten zu Prävalenz und klinischen Anpassungen in der medizinischen Ausbildung zeigen, dass Behinderung an der medizinischen Fakultät keine Anekdote ist (Meeks et al., 2020). Kohortenstudien zur Leistung von Studierenden mit Behinderung bestätigen, dass sich der akademische Verlauf bei angemessenem Zugang an dem der Peers ausrichten kann; der Engpass ist meist eine Barriere der Umgebung, nicht eine allgemeine "fehlende Eignung" (Meeks et al., 2022). Aufrufe zum Handeln in der Literatur fordern, strukturelle Barrieren zu beseitigen und inklusive technische Standards einzuführen (Marzolf et al., 2022; Kezar et al., 2019; Stauffer et al., 2022).

Für Studierende lautet die praktische Frage: "Verlangt diese App von mir klinisches Denken oder verlangt sie von mir, einen Pixel zu treffen?". Für diejenigen, die Fälle und Spiele gestalten, lautet die Frage: "Hat jede kritische Steuerung einen bedienbaren Weg mit Tastatur, mit großem Tippen und mit menschlichem Zeitmaß?". Der Rest dieses Textes übersetzt das in Barrieren und konkrete Abhilfen, mit Bezug auf Arten von Spielen für Medizinstudierende und auf fallbasiertes Lernen.

Häufige motorische Barrieren in der Oberfläche

In Fall-Apps und Diagnosespielen wiederholen sich die motorischen Barrieren. Kleine und eng beieinanderliegende Ziele: Aktionssymbole nebeneinander ohne Abstand. Pflichtgesten mit Weg: Kneifen, Kurvenwischen, Multitouch. Ziehen und Ablegen ohne Alternative von Tippen-zum-Auswählen und Tippen-zum-Ablegen. Kurze Timeouts: der Bildschirm läuft ab, wenn der Finger zögert. Steuerungen nur in der oberen Ecke, mit einer Hand schwer erreichbar. Abhängigkeit von Maus-Hover in der Webversion. Destruktive Bestätigungen ohne Rückgängig. Textfelder, die eine virtuelle Tastatur öffnen und die Absendetaste verdecken.

Leitfäden zur Barrierefreiheit in Spielen (zum Beispiel die vollständige Liste der Game Accessibility Guidelines) fordern die Neuzuweisung von Steuerungen, das Vermeiden komplexer Pflichtgesten, flexible Zeit und alternative Eingabemodi. In der mobilen Bildung zeigen Analysen von Lernspielen für Android, dass Oberflächen, die nur auf Canvas basieren, dem Switch Access oft nur ein einziges Ziel in Bildschirmgröße bieten, was das Durchlaufen Element für Element verhindert. Der Punkt für die Medizin ist derselbe: Wenn die Barriere motorisch ist, "verfehlt" der Studierende den Fall, ohne das Differenzial verfehlt zu haben.

Objektive Liste der Barrieren, die in jedem spielbaren Fall zu prüfen sind:

• Kritische Schaltflächen kleiner als der bequeme Fingerbereich, ohne anklickbares Padding.
• Aktionen, die nur als Pflichtgeste existieren (freies Ziehen, Kneifen, Kreis).
• Zeitmesser oder Sitzungsablauf, der Zögern oder das Korrigieren eines Tippens bestraft.
• Ablauf, der in der Webversion nur mit Tastatur unmöglich ist (Tab, Enter, Pfeiltasten).
• Nicht fokussierbare Elemente für Switch Access (unterbrochene oder fehlende Fokusreihenfolge).
• Destruktive Ziele (Löschen, Hinweis überspringen) direkt neben dem Bestätigungsziel.

Diese Barrieren wirken ungleich. Wer zittert, kann den Nachbarn der richtigen Schaltfläche auslösen. Wer begrenzte Kraft hat, kann ein langes Ziehen nicht abschließen. Wer nur eine Hand nutzt, ermüdet bei beidhändigen Gesten. Wer mit Switch arbeitet, braucht jede Steuerung als diskreten Schritt im Durchlauf. Wer in Bewegung ist (Krankenwagen, Flur), erlebt denselben Effekt: die Hand zittert und das kleine Ziel wird zum Glücksspiel. Inklusives Design "bevorzugt" keine Gruppe; es erweitert, wer das trainieren kann, was der Fall messen soll.

Ein schneller Test für motorische Barrieren: Versuchen Sie, den Ablauf nur mit der Tastatur abzuschließen; dann nur mit grober Berührung (Knöchel oder dicker Stift); dann mit absichtlich langsamem Tempo. Wenn ein Weg abbricht, misst die Oberfläche Geschicklichkeit, nicht Denken. Korrigieren Sie Ziele, Gesten und Zeit, bevor Sie neue klinische Inhalte hinzufügen.

Ein weiteres Signal: Der Studierende formuliert die Hypothese laut und scheitert beim Eintragen in die App. Bei diesem Muster prüfen Sie Ziel, Geste und Timeout, bevor Sie auf eine Wissenslücke schließen. Der Beitrag über Wissens- oder Denklücke behandelt die pädagogische Diagnose; hier geht es bei der Hypothese um motorische Nutzbarkeit.

Touch-Ziele, Abstand und Präzision

Die Zielgröße ist das erste konkrete Mittel. Die internationale Orientierung für Web-Barrierefreiheit empfiehlt im erweiterten Kriterium zur Zielgröße mindestens 44 mal 44 CSS-Pixel für Zeigereingaben, mit Ausnahmen für Inline-Links und gleichwertige Steuerelemente (W3C, Target Size Enhanced). Es gibt außerdem ein Minimum von 24 mal 24 CSS-Pixeln im neuesten AA-Kriterium (W3C, Target Size Minimum). In nativen Apps sprechen Plattformleitfäden meist von etwa 44 Punkten (iOS) oder 48 dp (Android). Die genaue Zahl zählt weniger als die Faustregel: Ziele für klinische Aktionen (Hypothese senden, Hinweis öffnen, bestätigen) müssen groß genug sein für einen zitternden Finger oder eine Berührung mit der Handkante.

Klassische Forschung zur mobilen Interaktion mit dem Daumen einer Hand legte Ziele im Bereich von etwa 9 mm für diskrete und serielle Aufgaben nahe, ohne Fehler und Präferenz zu verschlechtern (Parhi, Karlson und Bederson, 2006). Technische Notizen der W3C zur Touch-Größe auf mobilen Geräten übersetzen physische Empfehlungen in der Größenordnung von 9 mm mal 9 mm, im Einklang mit dieser Evidenzlinie (W3C Mobile A11y TF, M002). Bei Nutzern mit schwerer motorischer Beeinträchtigung zeigen Studien zu taktilen Oberflächen, dass Präzision und Trefferquote je nach Bildschirmregion und Zielgröße variieren; Tippen wird bei angemessener Größe meist gegenüber Richtungsgesten bevorzugt (Guerreiro et al., 2010).

Der Abstand zählt ebenso wie die Größe. Zwei 44-Pixel-Schaltflächen ohne Rand aneinander erzeugen Nachbarfehler. Lassen Sie inaktiven Zwischenraum zwischen Bestätigen und Abbrechen; trennen Sie "Hypothese senden" von "Hinweis überspringen". In Listen von Hypothesen oder Codes erhöhen Sie die Höhe der anklickbaren Zeile, nicht nur den sichtbaren Text. Unsichtbares Padding zählt zur aktiven Fläche.

Zielpraktiken im spielbaren Fall:

• Primäre Schaltflächen mit großzügiger Mindestfläche (erweitertes Ziel von 44 CSS px als Zeichenreferenz).
• Klarer Abstand zwischen unwiderruflichen und routinemäßigen Aktionen.
• Symbole nur in der äußersten Bildschirmecke ohne barrierefreie Variante im Hauptablauf vermeiden.
• Im Web sicherstellen, dass der Tastaturfokus einen sichtbaren Rahmen auf demselben großzügigen Steuerelement zeichnet.
• Mit dem Daumen, mit einem dicken Stift und mit simuliertem Zittern testen (absichtlich ungenaue Berührung).

Das macht die klinische App nicht "kindisch". Große Ziele sind Standard eines reifen Produkts in der digitalen Gesundheit und bei Serious Games. Das Training der Differenzialdiagnose mit Hinweisen verlangt bereits, Befunde sorgfältig abzuwägen; aus motorischer Sicht gilt dieselbe Sorgfalt für die Schaltfläche, die das Gewicht der Hypothese erfasst.

Gesten, Drag-and-drop und ein einziger Zeiger

Weggesten und Multi-Touch sind klassische Barrieren. Das WCAG-Kriterium für Zeigergesten verlangt, dass Funktionalität auf Basis von Mehrpunkt- oder Weggesten mit einem einzigen Zeiger ohne Weggeste bedient werden kann, außer wenn die Geste wesentlich ist (W3C, Pointer Gestures). Übertragen auf das Diagnosespiel: Wenn das Vergrößern des Bildes nötig ist, bieten Sie Schaltflächen für mehr und weniger Zoom an; wenn das Ordnen von Hypothesen nötig ist, bieten Sie Pfeile oder ein Menü an, nicht nur das Ziehen von Karten.

Drag-and-drop erscheint in vielen Lern-Apps als "intuitive" Metapher. Für Menschen mit Zittern oder mit einem Switch ist Ziehen teuer: Es verlangt, Druck zu halten, einer Bahn zu folgen und am richtigen Ziel loszulassen. Die barrierefreie Alternative ist, mit einer Berührung auszuwählen und das Ziel mit einer weiteren Berührung (oder mit Enter auf der Tastatur) zu bestätigen. Das pädagogische Ergebnis ist dasselbe; die motorische Anforderung sinkt.

Nützliche Zuordnung von Gesten zu Alternativen:

• Pinch zum Zoomen: Schaltflächen + und −, oder ein Slider mit Tastatur.
• Wischen zum Aufdecken des Hinweises: Schaltfläche "Nächster Hinweis" mit klarer Beschriftung.
• Hypothese in den Sendebereich ziehen: Hypothese auswählen und Schaltfläche "Senden".
• Langes Drücken für das Menü: sichtbare Menüschaltfläche oder Tastenkürzel.
• Zwei Finger zum Drehen des Bildes: Schaltflächen für 90°-Drehung.

Die W3C-Richtlinie zur Barrierefreiheit mobiler Anwendungen erinnert daran, dass komplexe Gesten für einen Teil der Nutzer unmöglich sein können und dass das Design gleichwertige Optionen bieten muss (W3C, Mobile Accessibility Mapping). Bei Gamification in der medizinischen Ausbildung helfen Zeitdruck und "unterhaltsame" Gesten nur, solange sie keine Einstiegshürde werden. Unterhaltung, die Menschen mit zittriger Hand ausschließt, ist keine inklusive Unterhaltung.

Es gibt einen nützlichen Unterschied zwischen wünschenswerter Schwierigkeit und nutzloser Hürde. Eine Hypothese aus dem Gedächtnis abzurufen ist wünschenswerte Schwierigkeit (siehe auch den Beitrag über wünschenswerte Schwierigkeiten). Eine Pinzettengeste trotz Tremor zu treffen ist eine nutzlose Hürde. Motorische Barrierefreiheit beseitigt die zweite, ohne die erste zu verwischen.

Interaktionszeit und Timeouts

Starre Zeitvorgaben bringen eine Varianz ein, die keine klinische Kompetenz ist: Zielgeschwindigkeit, Tremor unter Anspannung, die Notwendigkeit, den Switch neu zu positionieren. In Lern-Apps bestrafen Sitzungs-Timeouts, Meldungen, die von selbst verschwinden, und Timer, die den Fall schließen, alle, die mehr motorische Zeit brauchen, nicht nur die, die langsamer denken.

Grundsätze im Einklang mit zeitlicher Barrierefreiheit: Zeitlimits verlängerbar, anpassbar oder abschaltbar machen, wenn der Inhalt keine formale synchronisierte Prüfung ist; vor dem Ablauf warnen; bereits Eingetipptes erhalten. Beim täglichen Training des Denkens sollte das eigene Tempo der Standard sein. Gibt es einen Zeitmodus, bieten Sie ihn als erweiterte Option an, angekündigt vor dem Start.

Gute Zeitpraxis im spielbaren Fall:

• Standardmodus ohne aggressiven Countdown in der Interaktion.
• Pause, die den Fall einfriert, ohne die Hypothese im Entwurf zu verlieren.
• Automatische oder konfigurierbare Zusatzzeit für alle, die assistive Eingabe nutzen.
• Zu schnelle Toasts als einziger Kanal für Feedback bei Fehlberührung vermeiden.
• Eine versehentliche Berührung korrigieren können, ohne den ganzen Fall neu zu starten.

Anspannung und motorische Eile verstärken sich gegenseitig: Der Finger irrt häufiger, wenn die rote Uhr blinkt. Es gibt einen Widerhall mit Diskussionen zur Prüfungsangst: Druck ohne pädagogischen Grund misst Stress, nicht nur Wissen. Beim formativen Lernen ist Großzügigkeit bei der Zeit eine Designentscheidung, keine "Faulheit".

Auch Metakognition kommt nach dem Fall ins Spiel: "Habe ich die Berührung verfehlt oder die Hypothese?". Beides zu trennen vermeidet, das Denken für einen Schnittstellenfehler verantwortlich zu machen. Der Beitrag über Metakognition in der Medizin vertieft die Gewohnheit; aus motorischer Sicht sollte die Frage nach dem Fall die Möglichkeit eines Zielfehlers einschließen.

Tastatur, Switch und alternative Eingabe

Eine vollständige Tastatur ist der Goldstandard der Bedienbarkeit. Wenn die Webversion der Lern-App kein Tab zwischen Bedienelementen erlaubt, kein Enter zum Auslösen, kein Escape zum Schließen und keine Pfeiltasten in Listen, bleibt draußen, wer eine physische Tastatur, eine vergrößerte Bildschirmtastatur, einen Mausemulator per Kopfsteuerung oder einen Switch nutzt. Das Tastaturkriterium der WCAG verlangt, dass jede Funktion per Tastatur bedienbar ist, ohne eine bestimmte Zeit pro Taste zu verlangen, außer bei wesentlichen Ausnahmen im Pfad (W3C, Keyboard). Vermeiden Sie Tastaturfallen: Der Fokus darf nicht in einem Widget festhängen.

Switch Access (lineares oder punktweises Scannen) hängt von fokussierbaren Elementen in logischer Reihenfolge ab. Oberflächen, die nur in Canvas mit einem einzigen anklickbaren Rechteck gestaltet sind, brechen das Scannen: Der Switch "sieht" den ganzen Bildschirm als einen Knopf. In Fall-Apps muss jeder Hinweis, jede Hypothese und jede Sendeaktion ein eigenständiges, benanntes Bedienelement sein. Testen Sie mit den nativen Switch-Werkzeugen des mobilen Betriebssystems, bevor Sie einen neuen Modus veröffentlichen.

Weitere alternative Eingaben aus der Praxis:

• Trackball und angepasste Maus: Sie brauchen einen einfachen Klick, kein fortlaufendes Ziehen.
• Controller oder Gamepad: nützlich, wenn physische Tasten größer sind als Berührungsziele.
• Spracheingabe für den Text der Hypothese: ergänzend, kein einziger Weg, wenn die Umgebung laut ist.
• Fußpedal oder externe Taste: zuweisbar auf "Nächster Hinweis" und "Senden", wenn das Betriebssystem es erlaubt.
• Berührungsannahme mit Verzögerung (Dwell): Die App darf den Fokus nicht abbrechen, wenn der Finger eine halbe Sekunde gezögert hat.

Die Wahrnehmung der Lernumgebung durch Studierende mit Behinderung verbessert sich, wenn das Zugangsprogramm sichtbar und verlässlich ist; strukturelle Barrieren und die Kultur der Bekanntmachung wiegen weiterhin schwer (Moreland et al., 2025). Im Bildungsprodukt ist das Gegenstück, Eingangswege (Tastatur, Switch, vergrößerte Berührung) so zu dokumentieren, dass sie ohne Schatzsuche gefunden werden. Die Seite zur Barrierefreiheit der Website ist der institutionelle Ort für die Orientierung; die App selbst muss erfüllen, was die Seite beschreibt, ohne den Beitrag in eine Prüfung der Erklärung zu verwandeln.

Praktische Prinzipien in einer Tabelle

Die folgende Tabelle fasst die Zuordnung von Barriere und Antwort zusammen. Nutze sie bei der Überprüfung einer App für klinisches Lehren, eines spielbaren Falls oder einer Tablet-Aktivität vor der Veröffentlichung.

Motorische Barriere	Was die Studierenden erleben	Antwort im Design
Kleines oder eng beieinanderliegendes Ziel	Trifft den Nachbarn; verfehlt das Senden	Breites Ziel; Abstand zwischen Aktionen
Pflichtgeste mit Weg	Vollendet weder Pinch noch Kurve	Schaltfläche oder gleichwertige Berührung
Nur Ziehen und Ablegen	Lässt an der falschen Stelle los	Auswählen und mit zwei Berührungen bestätigen
Kurzes Timeout	Verliert den Fortschritt beim Zögern	Eigenes Tempo; Hinweis vor dem Ablaufen
Keine vollständige Tastatur	Switch und Tastatur bleiben mittendrin stehen	Tab, Enter, Escape; Fokusreihenfolge
Canvas ohne diskrete Steuerelemente	Die Abtastung sieht nur einen einzigen Block	Benannte und fokussierbare Steuerelemente
Destruktive Aktion neben der Bestätigung	Löscht den Fall versehentlich	Trennen; Bestätigung verlangen; rückgängig machen

Diese Prinzipien entsprechen der W3C-Orientierung zu Ziel, Geste und Tastatur sowie Praktiken für barrierefreie Spiele. Sie ersetzen keinen Test mit Nutzenden, die Switch, Trackball oder nur eine Hand verwenden, vermeiden aber die teuersten Fehler vor dem ersten Playtest. Überprüfungen technischer Standards an neuen medizinischen Fakultäten zeigen, dass inklusive Sprache noch ungleich ist (Stauffer et al., 2022); dasselbe gilt für Apps: Die inklusive Absicht muss im konkreten Steuerelement erscheinen, nicht nur im institutionellen Text.

Das hilfreiche Feedback in klinischen Fällen hat auch einen motorischen Aspekt: Wenn die einzige Fehlerrückmeldung ein 200-ms-Blitz über einem winzigen Symbol ist, sieht selbst wer den Touch verfehlt hat das Kriterium nicht. Stabiles Feedback als Text, mit Zeit zum Lesen und einer breiten Schaltfläche "verstanden", schließt den Kreis ohne olympisches Zielen.

Wie NEXO hineinpasst

Bei NEXO zeigt der Ablauf des Falls des Tages fiktive Fälle mit echter klinischer Präsentation und bis zu sechs fortschreitenden Hinweisen. Die Interaktion mit Hinweisen und dem Hypothesenfeld ist das Herz der Übung. Aus motorischer Sicht bedeutet inklusives Design: bedienbare Ziele, Wege ohne Pflichtgeste des Pinch, Zeit, die Zögern nicht bestraft, und Gleichwertigkeit von Berührung und Tastatur im Web. Kein Satz hier behauptet Wirksamkeit; er beschreibt die Art der Interaktion, die ein tägliches Diagnosespiel barrierefrei zugänglich machen muss.

Ressourcen des Ökosystems rund um das Studium: NEXO Researcher zum Vertiefen von Themen; NEXO Closer, wenn der Fokus das Schließen von Lücken ist; Nutzungsgrenzen unter Wirtschaft. Die Seite zur Barrierefreiheit bündelt allgemeine Hinweise der Plattform. Der Text Was ist NEXO ordnet das Spiel in die Landkarte des klinischen Lehrens ein.

So nutzt du den Fall des Tages mit Blick auf motorische Barrierefreiheit (ohne Ergebnisversprechen):

• Bevorzuge ein Tablet mit Tastatur oder einen Desktop, wenn feine Berührung ermüdet; der Web-Ablauf muss per Tastatur bedienbar bleiben.
• Erhöhe den Zoom des Betriebssystems, wenn die Ziele klein erscheinen; prüfe, ob das Layout umbricht, ohne die Schaltfläche zum Senden zu verbergen.
• Wenn eine versehentliche Berührung einen Hinweis überspringt oder einen Dialog schließt, halte inne und nutze rückgängig oder öffne in Ruhe erneut; mache den motorischen Fehler nicht zu "kognitiver Eile".
• Formuliere die Hypothese in kurzem Text, bevor du auf Senden zielst, um Denken von Berührungspräzision zu trennen.
• Wenn Schmerz, Erschöpfung oder Ausgrenzung durch die Oberfläche stark sind, halte inne und suche die nötige Hilfe.

Ehrliche Vergleiche: NEXO bündelt Hinweise und das Senden der Hypothese in einem einzigen Ablauf; Simulatoren mit vielen 3D-Manipulationsgesten und Sammlungen mit Dutzenden Mikrozielen verlangen mehr motorische Präzision. Die Wahl des Tages hängt vom Ziel ab. Zum Trainieren der Differenzialdiagnose mit wenigen Hinweisen passt das knappe Format. Zum Trainieren manueller Fertigkeiten in einem Verfahren ist das Simulationslabor ein anderer Raum. Das gemeinsame Prinzip: Messe das Denken, nicht die Toleranz gegenüber winzigen Zielen.

Wer Fälle für Lerngruppen erstellt (Praxisanleiter, Tutorinnen und Tutoren, Lerngruppen), kann die obige Tabelle auch außerhalb der Plattform anwenden: große Schaltflächen in interaktiven Folien, Alternativen zum Ziehen, flexible Zeit in der formativen Aktivität und Rückmeldung nach festen Kriterien. NEXO zeigt einen Weg auf; der Standard für motorische Barrierefreiheit gilt für jeden spielbaren Fall auf dem Tablet.

Für Praxisanleiter, die den Fall des Tages in der Gruppe nutzen: Lassen Sie jede Studentin und jeden Studenten die Hypothese im eigenen Tempo und auf dem eigenen angepassten Gerät festhalten, und erst danach laut diskutieren. Vermeiden Sie eine einzige Station mit gemeinsam genutzter feiner Maus als einzigem Weg zur Teilnahme. Der klinische Inhalt bleibt; das Nutzungsprotokoll wird inklusiver.

Bevor Sie einen Fall unter dem Blickwinkel der motorischen Barrierefreiheit veröffentlichen oder spielen, gehen Sie diese Liste durch:

• Haben die kritischen Schaltflächen ein großes Ziel und Abstand zum Nachbarn?
• Hat jede Gestenaktion ein Äquivalent per einfachem Tippen oder Tastatur?
• Lässt sich der Web-Ablauf mit Tab und Enter vollständig durchlaufen, ohne Fokusfalle?
• Gibt es einen Modus ohne bestrafendes Timeout?
• Sind die Bedienelemente diskret und für Switch fokussierbar?
• Sind zerstörerische Aktionen getrennt und umkehrbar?
• Bleibt die Fehlerrückmeldung lange genug und in einem großen Bereich auf dem Bildschirm?
• Habe ich mit grober Berührung und nur mit Tastatur getestet?

Wenn ein Punkt scheitert, korrigieren Sie das Design, bevor Sie den Fehler der Studentin oder dem Studenten zuschreiben. Trainieren Sie danach mit einem vollständigen Fall im realen Ablauf.

Spielen Sie den Fall des Tages.

Häufige Fragen

Ist motorische Barrierefreiheit dasselbe wie WCAG?

Nicht ganz. WCAG liefert technische Kriterien (Ziel, Geste, Tastatur), die dieser Beitrag als Prinzipien nutzt. Der Fokus liegt hier auf Apps und Spielen für die klinische Lehre, nicht auf einem vollständigen normativen Leitfaden für medizinische Software.

Machen große Ziele die Oberfläche nicht "kindlich"?

Nein. Großzügige Ziele sind Standard in Gesundheitsprodukten und in barrierefreien Spielen. Sie ändern die aktive Fläche und den Abstand, nicht die klinische Strenge des Falls.

Kann Ziehen und Ablegen bleiben, wenn es eine Alternative gibt?

Ja. Behalten Sie das Ziehen bei Bedarf als optionale Abkürzung, solange Auswählen und Bestätigen per Tippen oder Tastatur dieselbe Aufgabe erfüllt.

Braucht Switch Access eine native App?

Nicht unbedingt. Es braucht fokussierbare Bedienelemente und eine logische Reihenfolge. Ein einzelnes Canvas scheitert oft; echte Schaltflächen und Felder funktionieren meist mit den Werkzeugen des Systems.

Ist das nur für Menschen mit dauerhafter Behinderung wichtig?

Nein. Schiene, Schmerz, Müdigkeit, einhändige Nutzung im Dienst und situatives Zittern erzeugen ähnliche Barrieren. Inklusives Design nützt der Mehrheit.

Wie passt NEXO hinein, ohne ein Ergebnisversprechen zu werden?

Als Übungsumgebung mit Hinweisen und Hypothese auf dem Bildschirm. Nutzen Sie es, um die Gewohnheit des Denkens in einem bedienbaren Format zu üben; nicht als Geschicklichkeitsprüfung und nicht als Behandlung.

Literatur

1. W3C. Understanding SC 2.5.5 Target Size (Enhanced). https://www.w3.org/WAI/WCAG22/Understanding/target-size-enhanced
2. W3C. Understanding SC 2.5.8 Target Size (Minimum). https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum
3. W3C. Understanding SC 2.5.1 Pointer Gestures. https://www.w3.org/WAI/WCAG22/Understanding/pointer-gestures
4. W3C. Understanding SC 2.1.1 Keyboard. https://www.w3.org/WAI/WCAG22/Understanding/keyboard
5. W3C. Mobile Accessibility: How WCAG 2.0 and Other W3C/WAI Guidelines Apply to Mobile. https://www.w3.org/TR/mobile-accessibility-mapping/
6. W3C Mobile Accessibility Task Force. M002 Providing adequate touch target size. https://w3c.github.io/Mobile-A11y-TF-Note/Techniques/M002
7. Parhi P, Karlson AK, Bederson BB. Target size study for one-handed thumb use on small touchscreen devices. MobileHCI. 2006. DOI 10.1145/1152215.1152260.
8. Guerreiro T, et al. Towards accessible touch interfaces. ASSETS. 2010. DOI 10.1145/1878803.1878809.
9. Zazove P, et al. U.S. Medical Schools' Compliance With the Americans With Disabilities Act: Findings From a National Study. Acad Med. 2016. PMID 26796093.
10. McKee M, et al. Medical Schools' Willingness to Accommodate Medical Students with Sensory and Physical Disabilities. AMA J Ethics. 2016. PMID 27780023.
11. Meeks LM, et al. National Prevalence of Disability and Clinical Accommodations in Medical Education. J Med Educ Curric Dev. 2020. PMID 33178890.
12. Meeks LM, et al. The Performance and Trajectory of Medical Students With Disabilities. Acad Med. 2022. PMID 34817411.
13. Marzolf BA, et al. Call to Action: Eliminate Barriers Faced by Medical Students With Disabilities. Ann Fam Med. 2022. PMID 35879081.
14. Kezar LB, et al. Leading Practices and Future Directions for Technical Standards in Medical Education. Acad Med. 2019. PMID 30398992.
15. Stauffer C, et al. Technical Standards from Newly Established Medical Schools: A Review of Disability Inclusive Practices. J Med Educ Curric Dev. 2022. PMID 35036566.
16. Moreland CJ, et al. Perceptions of the Learning Environment Among Medical Students With Disabilities and the Impact of Program Access. Acad Med. 2025. PMID 40344596.
17. Game Accessibility Guidelines. Full list. https://gameaccessibilityguidelines.com/full-list/