Start / Seminare / Modern UI und UX Engineering für Webanwendungen

Modul

Menschen, Nutzungssituationen und assistive Technologien

6 Kapitel in diesem Modul-Video · Laufzeit

Vertonung mit synthetischer Stimme · Inhalte redaktionell verantwortet · © 2026 HECKER CONSULTING, alle Rechte vorbehalten

Transkript

Der gesprochene Text dieses Moduls zum Mitlesen, Überfliegen und Durchsuchen. Ein Klick auf einen Zeitstempel springt an die Stelle im Video.

Menschen und assistive Technologien

0:00 Im letzten Modul ging es um Regeln. Jetzt geht es um die Menschen, für die diese Regeln gemacht sind — und um die Technik, mit der sie arbeiten. Das ist mehr als Sensibilisierung: Dieses Modul erklärt, warum die technischen Lösungen ab dem nächsten Kapitel so aussehen, wie sie aussehen. Der Leitsatz lautet: Assistive Technik liest nicht den Bildschirm, sondern die Struktur dahinter.

0:22 Wer das einmal verstanden hat, für den ist semantisches HTML keine Formalie mehr, sondern die Schnittstelle zu einer ganzen Nutzergruppe. Und am Ende dieses Moduls probieren Sie es selbst aus — ohne Maus und ohne Bildschirm.

Menschen, Nutzungssituationen und assistive Technologien

0:35 Sechs Kapitel. Wir schauen zuerst auf Sehen, Hören und motorische Bedienung, dann auf Kognition und Alter — die größte betroffene Gruppe und die am seltensten mitgedachte. Danach kommt ein Modell, das in einem Satz erklärt, warum Barrierefreiheit keine Randgruppenfrage ist. Dann geht es zu den assistiven Technologien selbst und zu ihrem gemeinsamen Nenner.

0:56 Und schließlich zum Accessibility Tree — dem technischen Fundament, auf dem der ganze Rest von Tag zwei und drei steht.

Sehen, Hören und motorische Bedienung

1:04 Fangen wir bei den Gruppen an, an die man zuerst denkt. Und gleich mit einer Unterscheidung, die viele überrascht — denn sehbehindert und blind sind nicht dieselbe Anforderung, sondern zwei verschiedene. Diese Unterscheidung ist der wichtigste Punkt des Kapitels. Wer stark vergrößert — und das sind sehr viele Menschen — braucht Reflow ohne horizontales Scrollen und hohe Kontraste.

1:26 Er sieht die Oberfläche, nur eben ausschnittweise. Wer nichts sieht, braucht dagegen etwas völlig anderes: vollständige Semantik und eine sinnvolle Reihenfolge; Kontraste sind irrelevant. Motorische Einschränkungen verlangen große Ziele und keine Präzisionsgesten. Und bei Hörbehinderungen geht es um Untertitel, Transkripte und eine sichtbare Entsprechung für jedes akustische Signal.

1:49 Eine gute Oberfläche muss all das gleichzeitig können — nicht abwechselnd, und nicht in getrennten Fassungen. In der rechten Spalte sehen Sie, woran es bei Fahrtwind jeweils bricht — und das sind vier völlig verschiedene Baustellen. Die feste Breite der Ergebnisliste trifft die Vergrößerer. Icon-Schaltflächen ohne Beschriftung treffen blinde Nutzende. Die Sitzplatzwahl per Ziehen trifft die Motorik.

2:12 Und der Ablaufton der Reservierung trifft Menschen, die ihn nicht hören — die Reservierung läuft ab, und sie erfahren es nicht. Beachten Sie: Kein einziger dieser Fehler fällt bei einer normalen Sichtprüfung auf. Alle vier sehen auf dem Bildschirm völlig in Ordnung aus. Genau deshalb braucht es die Prüfverfahren aus Modul fünfzehn.

2:32 Der erste Stolperstein ist der eben besprochene: Sehbehinderung und Blindheit als dieselbe Anforderung behandeln. Wer nur an Screenreader denkt, vergisst Reflow und Kontrast; wer nur an Kontrast denkt, vergisst die Semantik. Der zweite: Zeitfenster setzen, ohne an langsamere Bedienung zu denken. Eine Reservierung, die nach fünf Minuten verfällt, ist für jemanden mit Schaltersteuerung schlicht nicht schaffbar.

2:55 Und der dritte ist ein Klassiker aus der Entwicklung: akustische Rückmeldungen ohne sichtbare Entsprechung. Ein Signalton beim Fehler ist nett — aber er darf nicht der einzige Hinweis sein, sonst existiert der Fehler für einen Teil Ihrer Nutzer nicht.

Kognition, Verständlichkeit und Alter

3:10 Jetzt zur größten betroffenen Gruppe überhaupt — und zu der, die am seltensten mitgedacht wird. Das hat einen Grund, und der ist zugleich das Problem: Diese Menschen melden sich nicht. Bei kognitiven Einschränkungen geht es nicht um Technik, sondern um Entwurf: verständliche Sprache, gleichbleibende Abläufe, wenig gleichzeitige Information, keine unerwarteten Kontextwechsel und die Möglichkeit, Fehler zu korrigieren.

3:35 Das klingt nach guter Gestaltung — und genau das ist es. Und dann kommt das Alter dazu. Mit dem Alter treten mehrere leichte Einschränkungen gleichzeitig auf: etwas geringere Sehschärfe, etwas weniger Feinmotorik, etwas langsamere Verarbeitung. Jede für sich unauffällig, zusammen aber deutlich spürbar. Diese Bündelung ist der Grund, warum Alter die wirtschaftlich wichtigste Kategorie in diesem ganzen Seminar ist.

4:00 Vier Argumente, die auch in einer Vorstandssitzung tragen. Die Bevölkerung altert — das ist keine Prognose mehr, sondern Gegenwart —, und Alter bündelt mehrere leichte Einschränkungen. Der zweite Punkt ist der entscheidende: Betroffene bezeichnen sich selbst nicht als behindert und melden sich deshalb nicht. Sie schreiben kein Ticket, sie brechen ab.

4:20 Die Maßnahmen verbessern die Bedienbarkeit für alle spürbar, sind also nie verlorene Investition. Und der vierte Punkt ist der unangenehme: Abbrüche dieser Gruppe erscheinen in Ihrer Statistik als Desinteresse. Sie sehen eine Absprungrate und interpretieren sie als fehlende Kaufabsicht — dabei war es eine Bedienbarkeitshürde.

4:40 Der erste Stolperstein ist ein verbreitetes Missverständnis: Verständlichkeit als Vereinfachung lesen und Inhalte weglassen. Verständlich heißt klar formuliert und gut strukturiert, nicht inhaltsarm. Erwachsene Menschen mit kognitiven Einschränkungen wollen dieselbe Information, nur zugänglich aufbereitet. Der zweite trifft besonders ältere Nutzende: Abläufe zwischen Releases umstellen, ohne den Wechsel anzukündigen. Was mühsam gelernt wurde, ist dann über Nacht weg.

5:08 Und der dritte ist ein Zuständigkeitsfehler: kognitive Anforderungen an das Marketing delegieren. Verständliche Sprache entsteht nicht im Textbaustein am Ende, sondern im Entwurf des Ablaufs.

Permanente, temporäre und situative Einschränkungen

5:20 Jetzt kommt ein Denkmodell, das ich für das wirksamste Argument im ganzen Seminar halte. Es passt in einen Satz und beendet die Randgruppendiskussion zuverlässiger als jede Statistik. Das Modell stammt aus dem Inclusive Design und geht so: einarmig dauerhaft, mit Gipsarm vorübergehend, mit Kind auf dem Arm situativ. Drei völlig verschiedene Lebenslagen — und die Anforderung an Ihre Oberfläche ist in allen drei Fällen exakt dieselbe. Alles muss einhändig erreichbar sein.

5:48 Das ist der ganze Gedanke, und er wirkt in Diskussionen erstaunlich gut, weil jeder im Raum die dritte Kategorie aus eigener Erfahrung kennt. Barrierefreiheit ist damit keine Frage einer kleinen Gruppe, sondern eine Frage der Robustheit gegenüber Situationen, in die jeder gerät. Genau das macht sie zum Qualitätsmerkmal.

6:07 Sehen Sie sich die rechte Spalte an: dreimal dieselbe Anforderung, nur die Dauer unterscheidet sich. Einige Jahre, einige Wochen, einige Minuten. Das ist der ganze Unterschied. Und wenn Sie die Häufigkeiten überschlagen, kippt das Bild vollends: Die permanente Gruppe ist eine Minderheit, die temporäre schon größer, und die situative betrifft praktisch jeden Menschen regelmäßig.

6:29 Wenn Sie also die Anforderung erfüllen, weil eine Minderheit sie braucht, bedienen Sie damit nebenbei eine Mehrheit in bestimmten Momenten. Die Rechnung geht ökonomisch fast immer auf — sie wird nur selten aufgemacht. Beim Umgang mit diesem Modell gibt es drei Fallen, und alle drei betreffen die Rhetorik. Erstens: aus dem Modell schließen, Barrierefreiheit sei nur Bequemlichkeit für alle.

6:53 Für die permanente Gruppe geht es nicht um Komfort, sondern um Teilhabe — das ist ein qualitativer Unterschied. Zweitens, und das ist die verwandte Falle: situative Fälle als Argument benutzen und die permanenten dabei übergehen. Das Modell soll erklären, nicht ersetzen. Und drittens die Falle in die andere Richtung: die Häufigkeit situativer Fälle unterschätzen.

7:15 Sonnenlicht, Lärm, ein Kind auf dem Arm, ein Handschuh im Winter — das ist der Alltag, nicht die Ausnahme.

Assistive Technologien und die Tastatur als gemeinsamer Nenner

7:22 Jetzt zur Technik selbst. Es gibt eine gute Nachricht darin, und sie ist der wirksamste einzelne Test, den ein Team einführen kann — er dauert Minuten und kostet nichts. Vier Technikfamilien, ein gemeinsamer Kern. Ein Screenreader spricht Rollen, Namen und Zustände. Eine Sprachsteuerung braucht sichtbare Beschriftungen, die zum zugänglichen Namen passen — der Fall aus Modul fünf.

7:45 Eine Schaltersteuerung, mit der Menschen mit schwerer motorischer Einschränkung arbeiten, durchläuft exakt dieselbe Fokusreihenfolge wie die Tastatur. Und daraus folgt die praktisch nützlichste Erkenntnis dieses Moduls: Was per Tastatur bedienbar ist, ist meist auch per Schalter, Sprache und Screenreader bedienbar. Die Tastatur ist der gemeinsame Nenner. Ein Tastaturdurchlauf ist damit der billigste sinnvolle Test, den es gibt.

8:11 Lesen Sie die rechte Spalte als Fehlerkatalog. Screenreader scheitern an Elementen ohne Rolle und Namen — unser Container-Knopf aus Modul eins. Vergrößerungssoftware scheitert an fester Breite und an Text, der in Grafiken eingebacken ist; der lässt sich nicht umbrechen und nicht vorlesen. Sprachsteuerung scheitert, wenn der zugängliche Name von der sichtbaren Beschriftung abweicht.

8:34 Und Schaltersteuerung scheitert an Bedienelementen, die gar nicht erst fokussierbar sind. Vier Zeilen, und drei davon haben dieselbe Wurzel: fehlende oder falsche Semantik. Genau deshalb ist das nächste Modul dem semantischen HTML gewidmet. Der erste Stolperstein ist ein weit verbreitetes Missverständnis: Screenreader für Vorlesewerkzeuge halten. Sie lesen nicht von oben nach unten vor — sie navigieren strukturiert.

9:00 Geübte Nutzende springen von Überschrift zu Überschrift, rufen Listen aller Links auf, wechseln zwischen Landmark-Bereichen. Deshalb ist Struktur so wichtig: Sie ist das Navigationsgerüst. Der zweite ist der Sprachsteuerungsfall, der uns nun zum dritten Mal begegnet — ein zugänglicher Name, der von der sichtbaren Beschriftung abweicht.

9:20 Und der dritte ist der ärgerlichste: den Tastaturtest überspringen, weil er zu einfach wirkt. Er ist einfach. Deshalb ist er so gut.

Accessibility Tree und Plattform-APIs

9:29 Damit zum technischen Fundament. Dieses Kapitel trägt das ganze nächste Modul — und es kommt in Modul zwanzig noch einmal zurück, wenn Browser-Agenten denselben Baum lesen. Hier ist die Erklärung für den Leitsatz dieses Moduls. Der Browser erzeugt aus dem DOM einen zweiten Baum — den Accessibility Tree. Der enthält keine Farben und keine Positionen, sondern Rollen, Namen, Zustände und Werte.

9:53 Diesen Baum reicht er über Schnittstellen des Betriebssystems an assistive Technologien weiter. Das heißt: Ein Screenreader sieht Ihre Seite nie. Er liest diesen Baum. Und daraus folgt der Satz, der alles Weitere trägt: Was dort nicht ankommt, existiert für einen Screenreader nicht — völlig unabhängig davon, wie es aussieht, wie schön es gestaltet ist und wie gut es funktioniert.

10:16 Ein Beispiel, das Sie in fast jedem Projekt finden: eine Symbolschaltfläche zum Entfernen. Oben die verbreitete Variante — ein Container mit einem Symbol darin. Im Accessibility Tree kommt davon nichts Brauchbares an: keine Rolle, kein Name, nicht fokussierbar. Unten dieselbe Optik, richtig gebaut. Drei Dinge passieren dort.

10:37 Das Element ist eine echte Schaltfläche, bringt Rolle und Tastatur also mit. Das Symbol wird für die assistive Technik ausgeblendet, weil es nichts beiträgt. Und der Name kommt aus einem Text, der visuell verborgen, für den Baum aber vorhanden ist. Sichtbar bleibt allein das Symbol — die Gestaltung ändert sich nicht. Der erste Stolperstein ist eine unterlassene Gewohnheit: den Accessibility Tree nie ansehen und Semantik nur aus dem Markup vermuten.

11:05 Jeder Browser zeigt ihn in den Entwicklerwerkzeugen an — schauen Sie hin, das dauert zehn Sekunden und beendet viele Diskussionen. Der zweite ist eine fehlerhafte Kombination: ein Element für assistive Technik ausblenden, das weiterhin fokussierbar ist. Der Fokus landet dann auf etwas, das aus Sicht der Technik nicht existiert — das ist besonders verwirrend.

11:26 Und der dritte ist ein Nebeneffekt, den viele nicht kennen: sichtbaren Text vollständig verstecken und damit auch den zugänglichen Namen entfernen. Verstecken ist nicht gleich verstecken.

Übung — eine Buchung ohne Maus und ohne Bildschirm

11:37 Jetzt kommt der Teil, der erfahrungsgemäß mehr bewirkt als alle Folien davor. Sie führen dieselbe Buchung zweimal durch — einmal ohne Maus, einmal ohne Bildschirm. Und Sie werden zweimal etwas völlig Verschiedenes erleben. Sie führen die Fahrtwind-Buchung zweimal durch: mit der Tastatur und mit einem Screenreader bei ausgeschaltetem Bildschirm.

11:58 Geübt wird das Identifizieren von Barrieren am eigenen Erleben — und deren Zuordnung zu einer Nutzungssituation aus diesem Modul. Erfolgreich sind Sie, wenn beide Durchläufe abgeschlossen oder begründet abgebrochen sind und jede Hürde einer Technik und einer Personengruppe zugeordnet ist. Ein wichtiger Hinweis vorab: Der Screenreader-Durchlauf verunsichert regelmäßig, und das gehört dazu.

12:20 Nur verwechseln Sie Ihre eigene Ungeübtheit nicht mit einem Produktfehler — kennzeichnen Sie im Zweifel beides getrennt. Wer früh fertig ist, wiederholt den Tastaturlauf bei vierhundert Prozent Zoom. Fünf Schritte, und einer davon ist eine Disziplinfrage. Zuerst der Tastaturdurchlauf ohne Maus daneben — die Fußzeile sagt es deutlich: Nicht abkürzen.

12:41 Wer zwischendurch zur Maus greift, verliert genau den Befund, um den es geht. Notieren Sie jede Stelle, an der Sie nicht weiterkommen oder raten müssen; das Raten ist übrigens ein eigener, sehr wertvoller Befund. Dann Bildschirm aus und derselbe Vorgang mit Screenreader. Je Hürde halten Sie fest, welche Technik betroffen ist und wer darauf angewiesen ist.

13:02 Und dann der Vergleich: Was nur in einer der beiden Listen auftaucht, ist besonders lehrreich — es zeigt, dass ein Test allein nicht reicht. Der erste Stolperstein macht den zweiten Durchlauf wertlos: den Screenreader-Lauf mit eingeschaltetem Bildschirm machen. Ihr Auge korrigiert dann still alles, was die Sprachausgabe nicht hergibt, und Sie merken es nicht einmal.

13:24 Der zweite ist der methodisch wichtige: eigene Ungeübtheit als Produktfehler notieren, ohne sie zu kennzeichnen. Ein geübter Screenreader-Nutzer arbeitet in einem Tempo, bei dem Sie kaum folgen können — manches, was Ihnen unmöglich vorkommt, ist für ihn Routine. Und der dritte ist ein Abbruchfehler: nur bis zur ersten Hürde gehen. Die interessanten Befunde liegen oft weiter hinten, im Zahlungsschritt und in der Bestätigung.

13:49 Vier Punkte. Sehbehinderung und Blindheit brauchen verschiedene Maßnahmen — Reflow und Kontrast auf der einen Seite, Semantik und Reihenfolge auf der anderen. Alter bündelt mehrere leichte Einschränkungen und ist damit die größte betroffene Gruppe, die sich nie als solche meldet. Die Tastatur ist der gemeinsame Nenner fast aller assistiven Techniken — deshalb ist der Tastaturtest der beste Einstieg.

14:12 Und der Satz, den Sie ins nächste Modul mitnehmen: Was im Accessibility Tree fehlt, existiert für assistive Technik nicht. Genau dieser Baum trägt jetzt Modul neun, wenn wir über semantisches HTML sprechen. Und er kommt in Modul zwanzig als Schnittstelle für Agenten zurück.

Lieber mit Trainer? Dieses Modul ist Teil unserer Team-Schulungen — mit Übungen, Ihrem eigenen Code und Fragen, die ein Video nicht beantwortet. Mehr erfahren →