Fallablauf mit Screenreader: Hinweise und Hypothesen

Du öffnest den Fall des Tages mit eingeschaltetem Screenreader. Der Aufgabentext nennt Alter und Beschwerde. Danach springt der Fokus auf eine Schaltfläche ohne Namen, dann auf ein dekoratives Diagramm, und der "Hinweis 1" existiert nur als Farbe in der Ecke. Du formulierst eine Hypothese, aber das Suchfeld sagt nur "bearbeiten". Die Rückmeldung zur Nähe blinkt grün ohne Wort. Der Abschluss ist auf dem Bildschirm vorhanden und fehlt in der Sprachausgabe. Dieser Text durchläuft den Ablauf des spielbaren Falls mit Screenreader: Hinweise (bis zu sechs), Hypothesen, Abgabe, Nähe, Abschluss und was die Oberfläche in jeder Etappe ansagen und ordnen muss. Er unterscheidet sich vom Katalog visueller assistiver Technologie (Produkte und Screenreader) und von der WCAG-Karte zu digitaler Barrierefreiheit in medizinischer Software. Hier ist der Gegenstand der pädagogische Durchgang durch den Fall, nicht die Softwareliste.

Nichts in diesem Artikel behauptet die Wirksamkeit von NEXO. Wir beschreiben Gestaltungsprinzipien, öffentliche Kriterien (W3C, Leitlinien für barrierefreie Spiele) und Merkmale, die in der Erklärung zur Barrierefreiheit geprüft wurden. Fiktive Fälle mit echter klinischer Darstellung, mit bis zu sechs Hinweisen, lehren nur dann etwas, wenn jede Etappe des Ablaufs in der Barrierefreiheits-API lesbar ist, nicht nur im visuellen Layout.

Wichtigste Punkte

• Der Ablauf des Falls hat feste Etappen: Eröffnung, Hinweis, Hypothese, Abgabe, Nähe, nächster Hinweis oder Abschluss; der Screenreader braucht in jeder Etappe Namen, Reihenfolge und Landmarks.
• Die Fokusreihenfolge im DOM muss der pädagogischen Abfolge folgen, nicht dem Zufall des CSS; Kriterium 2.4.3 der WCAG behandelt genau das.
• Fortschreitende Hinweise (bis zu sechs) verlangen eine Beschriftung mit Nummer und Inhalt als echten Text; eine Offenlegung nur durch Animation oder Farbe scheitert in der Sprachausgabe und in Braille.
• Hypothesenfelder und Absende-Schaltflächen brauchen einen zugänglichen Namen, der die Aktion beschreibt; "bearbeiten" und "OK" genügen nicht.
• Nähe und Abschluss verlangen ein Wort über die Farbe hinaus; das Detail der langen Erklärung nach dem Abschluss ist ein anderer Moment des Zyklus (siehe nützliche Rückmeldung und die öffentliche Erklärung).
• Bei NEXO beschreibt die Seite /accessibility Beschriftungen bei Hinweisen und Rückmeldung, semantisches HTML und Unabhängigkeit von Farbe bei der Nähe; ohne Aussage über Lernergebnisse. Nutzungsgrenzen, soweit relevant, stehen unter /economia.

Ablaufkarte: von der Eröffnung bis zum Abschluss

In einem täglichen Diagnosespiel ist der Fall keine statische Seite. Er ist ein Weg: Du liest den Kontext, erhältst Hinweise auf Abruf, schlägst Hypothesen vor, erhältst die Nähe und kommst bei richtiger Antwort oder nach ausgeschöpften Versuchen zum Abschluss. Fallbasiertes Lernen ordnet diesen Zyklus um ein konkretes klinisches Problem (wie es funktioniert). Das Training der Differenzialdiagnose mit fortschreitenden Hinweisen stärkt das Gewicht jedes Befunds (mit Hinweisen trainieren). Mit Screenreader funktioniert derselbe Weg nur, wenn jede Zustandsänderung benannt und fokussierbar ist.

Fast 6% der Medizinstudierenden in den Vereinigten Staaten gaben 2021 eine Behinderung an, mehr als das Doppelte von 2015, und verlangen Nachteilsausgleiche, die digitalen Zugang einschließen (Huth et al., 2025; Prävalenz und Nachteilsausgleiche: Meeks et al., 2020). In Online-Kursen der Naturwissenschaften berichtete mehr als die Hälfte der Studierenden mit Behinderung nach der digitalen Umstellung von unzureichendem Nachteilsausgleich; Empfehlungen zur Inklusion müssen universell sein, nicht nur individuell (Gin et al., 2022). Interaktive Inhalte, die mit Screenreader getestet wurden, zeigen, dass viele Aktivitätstypen nur teilweise "funktionieren" und eine ausdrückliche Alternative verlangen (Böhm und Lux, 2025). Digitale Ressourcen für Sehbehinderung verlangen Beschreibung für den Screenreader, Tastaturnavigation und Einhaltung der W3C-Richtlinien (Almeida et al., 2020).

Man stelle sich einen fiktiven Fall mit echter klinischer Präsentation vor: ein junger Erwachsener mit Thoraxschmerz und Dyspnoe seit einigen Stunden, bis zu sechs Hinweise. Hinweis 1 spricht vom plötzlichen Beginn; Hinweis 2 von der Sättigung; Hinweis 3 von einem Untersuchungsbefund. Man steigt mit Hypothesen auf und ab (Embolie, koronares Syndrom, Pneumothorax, Angst). Jeder Schritt muss im Barrierefreiheitsbaum vorhanden sein: Es reicht nicht, im Rechteck auf dem Bildschirm zu erscheinen.

Leitlinien für barrierefreie Spiele verlangen eine vorhersehbare Struktur, aussagekräftige Landmarks, Fortschrittsanzeigen und Unterstützung für Screenreader in Menüs und Spielablauf (Game Accessibility Guidelines). Die WCAG behandelt Fokusreihenfolge, Namen, Beziehungen und Statusänderungen (W3C, Focus Order 2.4.3; Info and Relationships 1.3.1). Die mentale Karte des Ablaufs für alle, die die Oberfläche hören, lautet:

• Wo bin ich (Titel des Falls, Nummer des Hinweises, Status "laufend" oder "abgeschlossen").
• Was kann ich jetzt tun (Hinweis aufdecken, Hypothese bearbeiten, absenden, Problem melden).
• Was sich gerade geändert hat (neuer Hinweis, Nähe, Treffer, Netzwerkfehler).
• Wohin es als Nächstes geht (Erklärung, nächster Fall, beenden).

Kognitive Belastung in der Gesundheitslehre verlangt bereits, Störgeräusche zu reduzieren und das Arbeitsgedächtnis für das zu bewahren, was gelehrt wird (van Merriënboer und Sweller, 2010; Mayer, 2010). Einen Knopf ohne Namen zu suchen oder "Grafik" statt des Hinweises zu hören, ist reines Störgeräusch. Das passt zu Metakognition: Man überwacht das eigene Denken nur, wenn die Oberfläche nicht die ganze Aufmerksamkeit verbraucht.

In der Praxis behandelt man den Ablauf wie ein mentales Protokoll am Krankenbett: Anamnese (Fallschilderung), Untersuchung (Hinweise), Hypothesen, Test (Absenden), Ergebnis (Nähe) und Plan (Erklärung). Wer als Vorgesetzter das laute Denken beobachtet, macht etwas Ähnliches. Der Screenreader ist diese automatische laute Stimme: Wenn das Protokoll in der Oberfläche nicht benannt ist, bricht die Darstellung des Falls für sich selbst mittendrin ab. Deshalb sind Landmarks und Headings kein Ingenieursdetail; sie sind das Rückgrat des klinischen Denkens im digitalen Raum.

Vor dem ersten Hinweis: Seite, Landmarks und Fokus

Vor jedem Hinweis baut der Screenreader die Karte des Bildschirms auf. Landmarks (main, navigation, complementary) und ein Heading der Ebene 1 mit dem Titel des Falls erlauben, das Chrome der App zu überspringen. Ein Skip-Link zum Hauptinhalt verhindert endloses Tabben durch das Menü. Wenn der Titel des Browser-Tabs generisch ist ("App"), hilft die Fensterliste niemandem, der im Dienst die Aufgabe wechselt.

Die anfängliche Fokusreihenfolge ist wichtig. Beim Öffnen des Falls muss der Fokus auf dem Heading oder dem ersten Block der Fallschilderung liegen, nicht auf einem Werbebanner oder einem vergessenen Modal. Visuell verborgene, aber noch im Tab erreichbare fokussierbare Elemente erzeugen stille "Löcher". Die WCAG verlangt, dass die Reihenfolge Bedeutung und Bedienung bewahrt (Focus Order). In Spielen und Websimulationen orientieren eine konsistente Struktur und eine Beschreibung des Kontexts alle, die die Szene nicht sehen (Floe, Web Games and Simulations).

Die Tastatur ist der Begleiter des Screenreaders: Tab, Shift+Tab, Enter, Leertaste und Pfeiltasten. Ein sichtbarer Fokus muss für alle vorhanden sein, die teilweise sehen, und für alle, die lehren, indem sie auf einen fremden Bildschirm schauen. Der Beitrag zur digitalen Barrierefreiheit ordnet Tastatur und Namen in der klinischen Software ein; hier liegt der Fokus auf der Abfolge des spielbaren Falls.

Schneller Fünf-Minuten-Test beim Öffnen:

• Headings auflisten: Erscheint der Titel des Falls?
• Landmarks auflisten: Gibt es ein main mit der Fallschilderung?
• Von oben bis zum Knopf "Hinweis aufdecken" tabben, ohne in eine Falle zu geraten.
• Bestätigen, dass dekorative Bilder ein leeres alt haben und klinische Bilder ein nützliches alt.

Medizinische Bildungseinrichtungen kommunizieren Inklusion auf öffentlichen Seiten noch immer ungleich (Ikedionwu et al., 2025). Im Lernmaterial beginnt Inklusion weiter unten: im DOM des Falls. Rechenschaft gegenüber Studierenden mit Behinderung weist in dieselbe Richtung (Meeks, Stergiopoulos und Petersen, 2022). Offenlegungsbarrieren bei Assistenzärzten zeigen, dass viele zögern, eine Anpassung zu erbitten (Pereira-Lima et al., 2023); einen standardmäßig lesbaren Ablauf zu gestalten, verringert die Abhängigkeit von der Bitte, nur um "Hinweis 1 hören zu können".

Auch die Konsistenz zwischen Sitzungen zählt. Wenn gestern der Fokus im Aufgabentext begann und heute im Ranking, bricht das mentale Modell zusammen. Lesepräferenzen zu speichern (sofern das Produkt sie bietet) und die Hülle des Falls stabil zu halten, verringert die Last der Neuorientierung. Leitlinien für barrierefreie Spiele verlangen eine vorhersehbare Struktur und sichtbare Details zu Barrierefreiheitsfunktionen im Produkt und auf der Website (Game Accessibility Guidelines); die Erklärung unter /accessibility erfüllt den öffentlichen Teil dieser Forderung bei NEXO, ohne eine Wirksamkeit zu behaupten.

Schrittweise Hinweise: was die Leserin oder der Leser hören muss

Bis zu sechs schrittweise Hinweise sind das Herz des Verfahrens: Informationen kommen in Scheiben, und das Gewicht jedes Befunds verändert die Differenzialdiagnose. Für die Screenreader-Nutzung muss eine "Scheibe" ein benannter Block sein. Bezeichnungen wie "Hinweis 2 von 6" plus der vollständige klinische Text sind besser als "neuer Inhalt" ohne Kontext. Wenn der Hinweis nur eine farbige Karte mit Symbol ist, wird die Sprachausgabe zu "Schaltfläche" oder "Grafik".

Aufdeckung auf Abruf: die Steuerung "nächsten Hinweis anzeigen" braucht einen stabilen zugänglichen Namen, und beim Auslösen muss der Fokus zur Überschrift oder Region des neuen Hinweises springen. Vermeiden Sie es, den Text nur in einer aggressiven aria-live-Region einzufügen, die den ganzen Absatz ohne Kontrolle vorliest. Bevorzugen Sie den Fokus auf die Überschrift des Hinweises und das Vorlesen auf Befehl der Nutzerin oder des Nutzers; eine kurze Live-Meldung kann "Hinweis 2 verfügbar" ansagen. Die Dokumentation zu Live-Regionen empfiehlt polite in den meisten Fällen (APG Alert; MDN Live regions).

Klinische Bilder im Hinweis (Kurve, Foto, Befund) brauchen eine Textalternative des Befunds, auf den es ankommt, nicht den Dateinamen. Prinzipien der Multimedialität verlangen, Wörter und Bilder aufeinander abzustimmen (Mayer, 2010). Doppelte Kodierung hilft beim Lernen, wenn Text und Bild sich gegenseitig verstärken (duale Kodierung); wenn der wesentliche Befund nur in der Abbildung steht, fehlt der Hinweis für alle, die zuhören.

Abkürzungen ("RR", "HF", "SpO2") verwirren die Sprachsynthese. Das Ausschreiben bei der ersten Erwähnung im Hinweis verringert seltsames Buchstabieren. Kurze Listen innerhalb des Hinweises ("dafür", "dagegen") mit echten Überschriften oder ul-Elementen leiten besser als ein einziger Absatz mit acht Zeilen.

Sichtbarer Fortschritt ("3 von 6") braucht ein textliches Äquivalent. Ein rein visueller Balken versagt. Leitlinien für barrierefreie Spiele verlangen Fortschrittsanzeigen und Verstärkung nicht nur textlich, wenn die Anweisung kritisch ist (Game Accessibility Guidelines). In MOOCs, die mit WCAG und unter Berücksichtigung von Präferenzen gestaltet wurden, zeigten Screenreader-Nutzende eine positive Verbindung zu guter Leistung im Vergleich zu Personen ohne erklärte Präferenz; wer eine Sehbeeinträchtigung ohne geeigneten Screenreader hatte, war relativ benachteiligt (Rodriguez-Ascaso et al., 2024). Die Gestaltung des Hinweises ist Teil dieser Gleichung.

Eine diagnostische Pause im Denken (diagnostische Pause) passt zwischen die Hinweise: eine Steuerung "frühere Hinweise überprüfen" mit navigierbarer Liste verhindert, dass das Arbeitsgedächtnis alles allein tragen muss. Die Ethik des Bildungsdesigns verlangt bereits, Lernende nicht durch das Format zu benachteiligen (Ethik im Spieldesign).

Hypothesen und Abgabe: zugängliche Namen und Reihenfolge

Eine Hypothese zu formulieren ist der klinische Zug des Spiels: Name der Diagnose oder Code. Das Suchfeld oder die Combobox braucht ein sichtbares und zugeordnetes label ("Diagnostische Hypothese" oder "ICD-Code"), nicht nur einen Platzhalter, der beim Tippen verschwindet. Ergebnisse der Liste müssen Element für Element angesagt werden können, mit dem vollständigen Namen des Begriffs. Absende-Schaltfläche: "Hypothese senden", nicht "OK".

Reihenfolge im Formular: Label, Feld, kurze Hilfe ("Suche nach Name oder Code möglich"), dann senden. Fehlermeldungen ("kein Ergebnis", "Feld leer") als Text, der mit dem Feld verknüpft ist, mit Fokus auf den Fehler, wenn es sinnvoll ist. Vermeiden Sie es, nur über die Rahmenfarbe zu validieren.

Wenn es eine Liste kürzlicher oder bevorzugter Hypothesen gibt, braucht jedes Element einen eigenen Namen. "Schaltfläche", "Schaltfläche", "Schaltfläche" in der Liste der Steuerelemente ist ein klassischer Fehler. Dasselbe gilt für "Hypothese entfernen" gegenüber "senden".

Beschäftigte, die am Arbeitsplatz einen Screenreader verwenden, kombinieren häufig mehr als einen Screenreader und berichten von weniger Schwierigkeiten, wenn sie einen Ersatz haben (McDonnall et al., 2025). Das rechtfertigt hier keine Produktbewertung: Der Katalog und die offiziellen Seiten stehen im Beitrag zu visueller assistiver Technologie. In diesem Ablauf zählt, dass die Falloberfläche mit jedem gängigen Screenreader funktioniert: semantisches HTML, Namen und Fokus.

Kalibrierung des Vertrauens (Kalibrierung des Vertrauens) und Wissenslücke gegenüber Denklücke (Wissens- oder Denklücke) setzen voraus, dass Sie wissen, was Sie abgeschickt haben. Wenn der Screenreader die gewählte Hypothese vor dem Enter nicht bestätigt, wird der Fehler zu Rauschen. Eine Zusammenfassung "Sie senden: Lungenembolie" direkt vor dem Button verringert blindes Absenden.

In fiktiven Fällen mit realer klinischer Präsentation lehrt eine falsche Hypothese noch etwas, wenn der Zyklus aus Proximität und nächstem Hinweis hörbar bleibt. Wenn das Feld den gewählten Namen verschluckt oder der Senden-Button nach dem ersten Fehler aus dem Tab verschwindet, bricht der Studierende mit Screenreader den Fall nicht aus mangelndem Denken ab, sondern wegen eines Bedienfehlers. Das ähnelt dem motorischen Timeout in Lern-Apps: Die Hürde ist nicht klinisch. Das Formular bei jedem Versuch stabil zu gestalten (gleiche Namen, gleiche Reihenfolge, gleiche Meldungen) gehört zur pädagogischen Gestaltung, nicht nur zur Technik.

Vom Versuch bis zum Abschluss: Proximität und Erklärung

Bei jeder Hypothese geben viele Diagnosespiele eine Proximität zurück: gleiches Kapitel, nah, fern. Diese kurze Rückmeldung ist nicht die lange Erklärung des Abschlusses; sie ist das Navigationssignal im ICD-Raum. Unabhängigkeit von Farbe ist Pflicht: Angeborene Farbsehschwäche ist häufig genug, um in medizinischem Material eine textliche Kennzeichnung zu rechtfertigen (PMID 10562750; sichere Praxis: PMID 28731005). Die wissenschaftliche Kommunikation dokumentiert bereits den Missbrauch von Farbe als einzigem Kanal (PMID 33116149).

Für den Screenreader braucht die Proximität einen vollständigen zugänglichen Namen: "Proximität: Gleiches Kapitel" oder "Proximität: fern", nicht nur "Status" oder ein Symbol. Gibt es eine Animation, darf sie nicht der einzige Kanal sein; die Einstellung Bewegung reduzieren zu respektieren vermeidet Übelkeit und Ablenkung. Eine kurze, höfliche Live-Region kann die Proximität ansagen; sagen Sie sie nicht bei jedem stillen Re-Render erneut an.

Feedback in der klinischen Ausbildung ist Information über die Leistung mit der Absicht, den nächsten Zyklus zu verbessern (van de Ridder et al., 2008). Meta-Analysen zeigen, dass die Wirkung von Art und Form der Vermittlung abhängt (Wisniewski, Zierer und Hattie, 2019). Der Beitrag zu hilfreicher Erklärung vertieft Inhalt und Timing der pädagogischen Rückmeldung. Gamification kann Genauigkeit und Beständigkeit nutzen, ohne auf Konfetti ohne Beschriftung angewiesen zu sein (Evidenz zu Gamification). Formative Bewertung lebt von dieser Rückmeldung, die den nächsten Zyklus informiert (formative Bewertung).

Nach der Proximität muss der Fokus zu einem vorhersehbaren Punkt zurückkehren: dem Hypothesenfeld (für einen neuen Versuch) oder dem Button "nächster Hinweis". Den Fokus nach der Ansage im Nirgendwo zu lassen, ist einer der teuersten Fehler in der Lernzeit. Wer mit Screenreader spielt, rekonstruiert den Differenzialraum über die Abfolge der Ansagen; verschwindet die Proximität in der Stille, wird die nächste Hypothese zu einer Ohne Hypothese ohne Karte.

Den Fall abzuschließen (Treffer oder Ende der Versuche) ändert den Modus der Oberfläche. Der Screenreader braucht eine klare Statusansage ("Fall abgeschlossen: Zieldiagnose verfügbar") und eine Überschrift, die den Ergebnisbereich eröffnet. Den Fokus auf diese Überschrift zu setzen ist sicherer, als die ganze Erklärung in eine Live-Region zu schütten. Der Übergang vom Versuch zum Debrief ist der Punkt, an dem viele Apps die Accessibility-API "vergessen": Das Visuelle wechselt das Thema, Konfetti steigt auf, und der Accessibility-Baum bleibt ohne Überschrift oder mit im Modal gefangenem Fokus zurück.

Die ausführliche Erklärung nach dem Abschluss (Begründung, stützende Hinweise, Differenzialdiagnose) ist ein Problem der Dokumentstruktur: Überschriften, echter Text, benannte Links, Tabellen mit Kopfzeile. Diese pädagogische Achse des Nutzens der Rückmeldung steht unter hilfreiche Erklärung; der sorgsame Umgang mit assistiven Technologien im Text nach dem Fall steht im Dialog mit der Erklärung unter /accessibility und mit dem Leitfaden zu visueller assistiver Technologie, ohne einen Produktkatalog zu wiederholen. Hier liegt der Kern des Ablaufs im Übergang: vom Tipp zum Debrief, ohne dass die nutzende Person in Stille oder Werbespam verloren geht.

Steuerelemente nach dem Abschluss (Hinweise erneut öffnen, Zusammenfassung kopieren, Problem melden, zum nächsten Fall gehen) kommen in der Tab-Reihenfolge nach der Ergebnis-Überschrift. Beschreibende Namen. Gibt es ein Feiermodal, muss es per Tastatur schließbar sein, mit bewusst eingeschlossenem Fokus, der beim Schließen wiederhergestellt wird; sonst wird es zur Falle. Ein minimales QA-Skript mit eingeschaltetem Screenreader: falsche Hypothese senden, Nähe hören, Hinweis aufdecken, richtig treffen, "Fall abgeschlossen" hören, Tab bis zur "Erklärung" und die erste Überschrift der Begründung lesen.

Werkzeuge aus dem Ökosystem des Lernens nach dem Fall: Researcher, Closer, Curator und Creators, stets mit derselben Sorgfalt bei der Benennung, wenn sie auf dem Ergebnisbildschirm verlinkt sind. Dasselbe Muster von Name und Fokus, das beim Hinweis gilt, gilt auch beim Ausgangslink: "Researcher öffnen" sagt mehr als "mehr erfahren".

Tabelle: Schritt, Ankündigung und häufiger Fehler

Nutze die Tabelle bei der Prüfung des spielbaren Falls mit eingeschaltetem Screenreader. Die Kontraste sind technisch.

Schritt im Ablauf	Was die nutzende Person hören muss	Häufiger Fehler	Antwort des Designs
Öffnung des Falls	Titel des Falls; Landmark main; Aufgabenstellung	Fokus auf Banner; generischer Titel	h1 + main; Skip-Link; Fokus auf der Aufgabenstellung
Hinweis aufdecken	"Hinweis N von 6" + klinischer Text	Nur Farbe/Animation; Schaltfläche "Schaltfläche"	Name des Steuerelements; Fokus auf der Überschrift des Hinweises
Bild im Hinweis	Alt des relevanten Befunds	Leeres Alt oder Dateiname	Alt erst nach dem Ansehen des Bildes geschrieben
Feld für die Hypothese	Label + gewählter Wert	Nur Platzhalter; Liste ändert sich	zugeordnetes label; Bestätigung vor dem Senden
Senden	"Hypothese senden"	"OK" / Symbol ohne Namen	Name der Aktion
Nähe	Wort der Stufe (Kapitel, nah, fern)	Nur grün/gelb/rot	Text + benanntes Symbol; kurze Live-Meldung
Abschluss	Zustand "abgeschlossen" + Ergebnis-Überschrift	Gesamte Erklärung in aria-live	Fokus auf der Überschrift; stabiler Text
Nach dem Fall	Benannte Folgeaktionen	Modal ohne Escape; Fokus verloren	Tab-Reihenfolge; schließen und Fokus wiederherstellen

Frage nach der Tabelle: Wenn ich nur Überschriften, Landmarks und Namen von Schaltflächen höre, kann ich den Fall von der Aufgabenstellung bis zum Abschluss spielen? Ist die Antwort nein, ist der Ablauf noch nicht barrierefrei.

Wie NEXO hier hineinpasst

NEXO ist ein tägliches Diagnosespiel mit fiktiven Fällen mit echter klinischer Präsentation und bis zu sechs fortschreitenden Hinweisen. Die Seite /accessibility erklärt unter anderem beschreibende Bezeichnungen für interaktive Elemente, klinische Hinweise und Feedback des Spiels; semantisches HTML mit Überschriftenhierarchie auf der Website; Kontrast; Alt bei aussagekräftigen Bildern; keine Medien mit Autoplay; und Unabhängigkeit von Farbe bei den Nähestufen (Farbe mit Textbezeichnung). Dieselbe Seite nennt bekannte Einschränkungen, ohne daraus Marketing zu machen. Kein Satz hier behauptet, dass diese Merkmale die Merkfähigkeit, die Note oder die klinische Leistung verbessern. Es ist eine überprüfbare Beschreibung.

Wer die Plattform gerade kennenlernt, kann was NEXO ist lesen. Fallbasiertes Lernen ordnet die Methode ein (wie es funktioniert). Grenzen der Nutzung, wo relevant, stehen unter /economia. Der Blickwinkel dieses Beitrags ist der Walkthrough des Ablaufs mit Screenreader. Zum selben Thema siehe kognitive Barrierefreiheit, multimodales Feedback beim Tipp, Erklärung nach der Diagnose und wie man inklusive klinische Fälle schreibt.

Häufige Fragen

Ersetzt dieser Beitrag den Leitfaden zu visueller assistiver Technologie?

Nein. Produkte, Screenreader und klinische Praktiken der visuellen assistiven Technologie stehen unter visuelle assistive Technologie. Hier geht es um den Ablauf des Falls (Hinweise, Hypothesen, Abschluss) und darum, was die Oberfläche ankündigen muss.

Muss ich jeden Hinweis vollständig in aria-live ankündigen?

Im Allgemeinen nicht. Kurze Live-Meldung für "Hinweis verfügbar" oder die Nähe; Fokus auf der Überschrift; Lesen des Textes unter der Kontrolle der Person, die den Screenreader nutzt.

Kann die visuelle Reihenfolge von der Fokusreihenfolge abweichen?

Nur wenn die Reihenfolge noch Bedeutung und Bedienung bewahrt. Im spielbaren Fall muss der pädagogische Weg (Fallbeschreibung, Hinweis, Hypothese, Nähe, Abschluss) dem Weg der Tab-Taste und des linearen Lesens folgen (WCAG 2.4.3).

Reicht Nähe allein durch Farbe, wenn der Kontrast hoch ist?

Nein. Kontrast hilft denen, die sehen; er ersetzt weder ein Wort für Farbfehlsichtigkeit noch einen Screenreader. Farbe mit textlicher Bezeichnung und, falls vorhanden, einem benannten Symbol.

Wie hängt das mit der Erklärung nach der Diagnose zusammen?

Das sind verschiedene Momente: Nähe ist ein kurzes Signal im Zug; die Erklärung ist ein strukturiertes Debriefing. Nutzen der Rückmeldung: hilfreiche Erklärung. Umfassende digitale Barrierefreiheit: medizinische Software.

Lohnt es sich, nur mit einem Screenreader zu testen?

Besser ist es, den Ablauf nach Möglichkeit mit mehr als einer Kombination aus Screenreader und Browser zu testen; Studien mit blinden Arbeitnehmern legen Zurückhaltung bei den Werkzeugen nahe (McDonnall et al., 2025). Ohne Marken in diesem Text zu bewerten.

Abschließende Checkliste

• Einstieg: h1 des Falls, main-Landmark, Skip-Link, Anfangsfokus auf der Fallbeschreibung.
• Hinweise (bis zu sechs): benannte Steuerung; "Hinweis N von 6"; echter Text; klinischer Alt-Text; Fokus auf dem neuen Hinweis.
• Hypothese: zugeordnetes Label; Bestätigung des Begriffs; Schaltfläche "Hypothese senden".
• Nähe: Wort der Stufe; kurze Live-Region; vorhersehbarer Fokus danach.
• Abschluss: Statusmeldung; Überschrift des Ergebnisses; Erklärung außerhalb einer aufdringlichen Live-Region.
• Nach dem Fall: benannte Aktionen; schließbares Modal; keine Tastaturfalle.
• Keine Information nur in Farbe, nur in Animation oder nur im Bild.
• Erklärung unter /accessibility prüfen; Grenzen unter /economia.

Spiele den Fall des Tages.

Literatur

1. Almeida AMP, et al. Development of an online digital resource accessible for students with visual impairment or blindness. Work. 2020. PMID 32007977.
2. Böhm A, Lux T. Analyses of the Accessibility of Interactive Learning Content in H5P. Stud Health Technol Inform. 2025. PMID 40380646.
3. Gin LE, et al. New Online Accommodations Are Not Enough. CBE Life Sci Educ. 2022. PMID 35496702.
4. Huth K, et al. Accessible by design: a guide for health professions educators. 2025. PMID 39773717.
5. Ikedionwu I, et al. Evaluating Disability-Inclusive Content on U.S. Medical Schools Websites. Acad Med. 2025. PMID 40550114.
6. Mayer RE. Applying the science of learning to medical education. Med Educ. 2010. PMID 20604850.
7. McDonnall MC, et al. Screen reader use among legally blind workers. 2025. PMID 40614067.
8. Meeks LM, et al. National prevalence of disability and clinical accommodations in medical education. 2020. PMID 33178890.
9. Meeks LM, Stergiopoulos E, Petersen KH. Institutional accountability for students with disabilities. Acad Med. 2022. PMID 34670236.
10. Pereira-Lima K, et al. Barriers to disability disclosure in residency. 2023. PMID 37166801.
11. Rodriguez-Ascaso A, et al. Performance of students with different accessibility needs in Design for All MOOCs. 2024. PMID 38451899.
12. van de Ridder JM, et al. What is feedback in clinical education? Med Educ. 2008. PMID 18230092.
13. van Merriënboer JJ, Sweller J. Cognitive load theory in health professional education. Med Educ. 2010. PMID 20078759.
14. Wisniewski B, Zierer K, Hattie J. The Power of Feedback Revisited. Front Psychol. 2019. PMID 32038429.
15. Farbfehlsichtigkeit und Farbe als einziger Kanal: PMID 10562750; PMID 28731005; PMID 33116149.
16. W3C. WCAG 2.2 Understanding: Focus Order; Info and Relationships. Focus Order; 1.3.1.
17. W3C APG / MDN. Live regions and alert pattern. APG Alert; MDN.
18. Game Accessibility Guidelines. Full list. gameaccessibilityguidelines.com.
19. Floe Inclusive Learning Design Handbook. Web Games and Simulations. handbook.floeproject.org.