Barrierefreie Formulare und Interaktionen

Barrierefreie Formulare und Interaktionen

0:00 Formulare sind die Stelle, an der Geld verloren geht. Hier brechen Menschen ab, hier entstehen Support-Anfragen, hier scheitert die Buchung. Und hier wird fast jedes Kriterium, das wir in Modul sieben besprochen haben, ganz praktisch. Der Leitsatz dieses Moduls ist der häufigste Einzelfehler in Formularen überhaupt: Platzhaltertext ist kein Label.

0:20 Er verschwindet genau dann, wenn man ihn braucht — nämlich sobald man anfängt zu tippen. Das ist so verbreitet, dass es fast als Entwurfsmuster durchgeht. Wir schauen uns in diesem Modul acht Themen an, und jedes einzelne senkt messbar Ihre Abbruchquote.

Barrierefreie Formulare und Interaktionen

0:36 Neun Kapitel. Wir beginnen bei Labels und Hilfetexten, gehen über Gruppierung zur Validierung und zu den Statusmeldungen — das ist die technische Mitte des Moduls. Dann kommen drei Themen, die direkt aus Version 2.2 stammen: zugängliche Anmeldung, Eingabezwecke und Ziehbewegungen. Dazwischen die Zeitlimits, ein unterschätztes Ausschlusskriterium.

0:57 Und am Ende bringen Sie ein Formular mit sieben eingebauten Mängeln in Ordnung — mit Tastatur und Screenreader, und ohne das Aussehen zu verändern.

Labels, Hilfetexte und Pflichtfelder

1:06 Fangen wir bei der Beschriftung an. Das klingt trivial und ist der häufigste Fehler in Formularen — weil eine sehr verbreitete Gestaltungsmode genau hier ansetzt. Jedes Eingabefeld braucht eine dauerhaft sichtbare, programmatisch verknüpfte Beschriftung. Beide Eigenschaften sind wichtig. Und jetzt zum Platzhaltertext, der so gern als Beschriftung dient: Er hat drei Probleme auf einmal.

1:29 Er verschwindet beim Tippen — genau in dem Moment, in dem Sie prüfen wollen, ob Sie im richtigen Feld sind. Er hat schwachen Kontrast, weil er ja zurückhaltend wirken soll. Und er geht bei manchen assistiven Techniken ganz verloren. Hilfetexte binden Sie über ein Verweis-Attribut an, die Pflicht meldet das native Attribut.

1:49 Das ist alles Handwerk, und es ist in fünf Minuten erledigt. Oben die verbreitete Kurzfassung: Beschriftung und Formathinweis stecken beide im Platzhalter. Sobald jemand tippt, ist beides weg — und wenn er sich beim Format nicht sicher ist, muss er das Feld leeren, um wieder nachzulesen. Das ist absurd und passiert täglich.

2:08 Unten dieselbe Information richtig verteilt: eine verknüpfte Beschriftung, das Pflicht-Attribut, ein angebundener Hilfetext mit Beispiel. Und beachten Sie die Fußzeile — das Sternchen für Pflichtfelder ist reine Optik. Gemeldet wird die Pflicht über das Attribut. Wenn Sie nur ein Sternchen setzen, existiert die Information für einen Teil Ihrer Nutzer nicht.

2:30 Der erste Stolperstein ist der Leitsatz des Moduls: Platzhaltertext als einzige Beschriftung. Der zweite ist eine technische Feinheit, die oft übersehen wird: das Label per Umschließung lösen, aber die explizite Verknüpfung weglassen — oder gar nur nebeneinander stellen und hoffen. Verbinden Sie ausdrücklich über die Id; das ist unmissverständlich und funktioniert überall.

2:52 Und der dritte ist ein Erklärungsproblem: Pflichtfelder nur mit einem Sternchen markieren und nirgends erklären, was das Sternchen bedeutet. Es ist Konvention, ja — aber es ist eine gelernte Konvention, und sie steht nirgends. Eine Zeile Legende kostet nichts.

Gruppierung zusammengehöriger Eingaben

3:08 Jetzt zu einem Fall, den man mit der Maus nie bemerkt. Bei Optionsgruppen fehlt regelmäßig etwas Entscheidendes: die Frage. Man hört die Antworten, aber nicht, worauf sie antworten. Stellen Sie sich vor, jemand liest Ihnen nur die Antwortmöglichkeiten vor: „Einfach. Rückfahrt." Ohne die Frage. Genau das passiert, wenn Optionsgruppen keine gemeinsame Beschriftung haben — der Screenreader nennt die Einzeloptionen, die Frage bleibt offen.

3:36 Sehende lesen die Überschrift daneben mit; für alle anderen existiert der Bezug nicht. Das native Gruppierungselement mit seiner Beschriftung löst das ohne jeden Kunstgriff. Bei Fahrtwind betrifft das die Wahl zwischen Hin- und Rückfahrt genauso wie die Ermäßigungsart. Und wie so oft in diesem Seminar: Es ist kein Aufwand, es ist eine Kenntnisfrage.

3:58 Oben zwei Optionsfelder mit Text daneben. Optisch völlig klar, semantisch zwei zusammenhanglose Auswahlmöglichkeiten. Unten dieselben zwei Optionen in einer Gruppe mit Beschriftung. Jetzt wird beim Erreichen der Gruppe die Frage angesagt und danach die Option — „Fahrtart, Einfach, ausgewählt, eins von zwei". Beachten Sie auch die Umschließung der Optionen mit ihrer eigenen Beschriftung; dadurch wird die Trefferfläche größer, was der Zielgröße aus Modul fünf zugutekommt.

4:26 Zwei Verbesserungen in einem Umbau. Die Fußzeile fasst es zusammen: Ohne die Gruppenbeschriftung wird nur „Einfach" angesagt — wozu, bleibt offen. Der erste Stolperstein ist die naheliegende Halblösung: die Gruppenfrage nur als Überschrift daneben setzen. Optisch identisch, semantisch unverbunden. Der zweite ist Übereifer in die andere Richtung: eine Gruppe für jedes einzelne Feld verwenden.

4:51 Dann wird bei jedem Textfeld eine Gruppe angesagt, und die Struktur, die eigentlich helfen sollte, wird zu Lärm. Gruppen sind für Gruppen. Und der dritte ist der visuelle Kurzschluss: die Gruppe rahmen, ohne sie semantisch zu bilden. Ein Rahmen ist eine Linie. Er trägt keine Bedeutung, wie wir schon in Modul fünf gesehen haben.

Validierung, Fehlermeldung und Korrektur

5:11 Jetzt zum Kern der Abbruchproblematik. Fehlermeldungen entscheiden darüber, ob jemand einen Fehler korrigiert oder aufgibt. Und der wichtigste Punkt liegt vor dem Fehler. Zum Zeitpunkt zuerst: Validierung sollte beim Verlassen des Feldes greifen. Nicht bei jedem Tastendruck — dann meckert die Anwendung, während man noch tippt, was besonders bei langsamer Eingabe zermürbend ist.

5:34 Und nicht erst nach dem Absenden, weil man dann zehn Felder gleichzeitig repariert. Ein guter Fehler leistet drei Dinge: Er nennt das betroffene Feld, beschreibt das Problem in Worten und schlägt die Korrektur vor. Und er steht dort, wo das Feld ist, ist mit ihm verknüpft und zusätzlich über eine Zusammenfassung erreichbar.

5:53 Aber der wichtigste Punkt bleibt: Die Regel sollte vorher bekannt sein — als Hilfetext, wie im ersten Kapitel. Oben eine Fehlerklasse am Feld. Der Rahmen wird rot, sonst passiert nichts. Für jemanden, der die Farbe nicht sieht oder das Feld nicht sieht, existiert der Fehler nicht — er sendet ab und wundert sich. Unten dieselbe Situation richtig: Das Feld meldet über ein Attribut, dass es ungültig ist, es verweist auf den Fehlertext, und der Fehlertext hat die Rolle einer dringenden Meldung, wird also angesagt.

6:23 Und schauen Sie auf den Text selbst: Er nennt die Ursache und die Korrektur in zwei Sätzen. Das ist die Beschriftungsregel aus Modul vier, angewandt auf Fehler. Der erste Stolperstein ist der eben gezeigte: Fehler nur farblich markieren und den Text nicht verknüpfen. Das ist die Farbregel aus Modul fünf — Farbe trägt Bedeutung nie allein.

6:43 Der zweite ist ein Zeitpunktfehler mit hohem Nervfaktor: bei jedem Tastendruck validieren. Man bekommt dann eine Fehlermeldung, bevor man mit dem Eintippen fertig ist, und bei Screenreader-Nutzung wird das zur Dauerbeschallung. Und der dritte ist eine sehr verbreitete Halbheit: eine Fehlerzusammenfassung setzen, ohne den Fokus dorthin zu führen.

7:03 Die Zusammenfassung steht dann oben auf der Seite, und wer unten am Absendeknopf steht, erfährt nie davon.

Statusmeldungen und Live Regions

7:10 Damit zu einem Mechanismus, den moderne Anwendungen dringend brauchen. Alles, was sich ändert, ohne dass der Fokus wechselt, ist für assistive Technik unsichtbar — es sei denn, Sie sagen es ausdrücklich an. Denken Sie an eine Durchsage im Bahnhof. Sie stehen am Gleis, schauen woandershin, und trotzdem erreicht Sie die Information. Genau das leisten Live Regions.

7:33 „Vier Fahrten gefunden." „Reservierung läuft in zwei Minuten ab." Ohne diese Ansage passiert für die assistive Technik nichts — die Trefferliste ändert sich still. Zwei Dinge sind dabei technisch wichtig. Erstens: Der Bereich muss im Dokument stehen, bevor sich sein Inhalt ändert; nachträglich eingefügte Bereiche werden oft nicht gelesen.

7:55 Und zweitens: Sie vertragen keine Dauerbeschallung. Wer alles ansagt, sagt am Ende nichts, weil die Leute abschalten. Zwei Rollen, und der Unterschied ist die Frage nach der Unterbrechung. Die Statusrolle wartet ab, bis die Sprachausgabe einen Moment Ruhe hat — passend für Trefferzahlen und Erfolgsmeldungen. Die Warnrolle unterbricht sofort — passend für ablaufende Reservierungen und Fehler. Diese Wahl ist eine Höflichkeitsentscheidung: Wie dringend ist das wirklich?

8:23 Und die dritte Zeile ist die Erinnerung daran, dass nicht alles einen Live-Bereich braucht. Wenn eine Änderung mit einem Fokuswechsel einhergeht — der Fokus wandert auf das neue Element —, wird sie ohnehin angesagt. Dann ist ein Live-Bereich doppelt und stört. Der erste Stolperstein ist der technische Klassiker, und er kostet viele Stunden Fehlersuche: die Live Region gleichzeitig mit dem Text einfügen.

8:48 Die Technik registriert den Bereich erst und bemerkt die Änderung dann nicht mehr — es funktioniert scheinbar zufällig. Legen Sie den leeren Bereich von Anfang an ins Dokument. Der zweite ist eine Dringlichkeitsinflation: die Warnrolle für alles verwenden. Dann unterbricht die Anwendung ständig, und Nutzende schalten sie ab — womit auch die echten Warnungen verloren sind.

9:09 Und der dritte: dieselbe Meldung wiederholt setzen, ohne dass sich etwas geändert hat. Das erzeugt Rauschen ohne Information.

Barrierefreie Authentifizierung

9:17 Jetzt eines der neuen Kriterien aus Version 2.2 — und dasjenige, das Bestandssysteme am häufigsten verletzen. Es geht um die Anmeldung und um die Frage, ob sie an Ihrem Gedächtnis scheitern darf. Die Anforderung klingt zunächst überraschend: Eine Anmeldung darf nicht an einem Gedächtnistest scheitern. Praktisch bedeutet das drei Dinge.

9:38 Das Einfügen aus dem Passwortmanager muss erlaubt sein. Keine Zeichenrätsel, bei denen man verzerrte Buchstaben abtippt. Und keine Rechenaufgaben. Alle drei sind für Menschen mit kognitiven Einschränkungen, mit Sehbehinderung oder mit motorischen Einschränkungen echte Hürden. Bei Fahrtwind ersetzt ein Einmallink per Mail die klassische Hürde vollständig — Sie klicken einen Link und sind angemeldet, ohne irgendetwas zu erinnern.

10:02 Das ist nebenbei auch für alle anderen bequemer, was in diesem Feld die Regel und nicht die Ausnahme ist. Die rechte Spalte erklärt jeweils den Grund, und das lohnt sich zu verstehen. Passwort mit Einfügen ist zulässig, weil der Passwortmanager das Merken übernimmt — die kognitive Last liegt bei der Software, nicht beim Menschen.

10:22 Der Einmallink ist zulässig, weil gar nichts erinnert werden muss. Das Zeichenrätsel ist unzulässig, weil es gleichzeitig ein Gedächtnis- und ein Sehtest ist. Und die Rechenaufgabe ist eine kognitive Hürde ohne Alternative. Wenn Sie unsicher sind, ob ein Verfahren zulässig ist, stellen Sie diese eine Frage: Muss ein Mensch sich hier etwas merken oder etwas erkennen, das über die reine Übertragung hinausgeht?

10:47 Der erste Stolperstein ist gut gemeint und sicherheitstechnisch längst überholt: das Einfügen ins Passwortfeld sperren. Das war nie eine wirksame Schutzmaßnahme und führt in der Praxis dazu, dass Menschen einfachere Passwörter wählen, die sie tippen können. Es macht die Sache also unsicherer. Der zweite ist ein Fristproblem: Zeitcodes ohne ausreichende Frist zum Eintippen verlangen. Dreißig Sekunden sind für viele Menschen zu wenig, besonders mit Vergrößerungssoftware.

11:14 Und der dritte ist eine Zugangsfrage: die zweite Stufe nur über eine App anbieten. Nicht jeder hat ein aktuelles Smartphone, und nicht jede App ist selbst zugänglich.

Autocomplete und Eingabezwecke

11:24 Jetzt kommt die Maßnahme mit dem besten Verhältnis von Aufwand zu Nutzen in diesem ganzen Seminar. Sie kostet ein Attribut pro Feld und spart bestimmten Menschen jede einzelne Eingabe. Ein einziges Attribut sagt dem Browser und assistiven Werkzeugen, welche Art von Angabe ein Feld erwartet — Vorname, Postleitzahl, E-Mail-Adresse.

11:43 Der Effekt: Die Felder füllen sich automatisch. Für jemanden mit motorischer Einschränkung ist das der Unterschied zwischen einer Minute und zehn Minuten. Für Menschen mit kognitiven Einschränkungen können darauf aufbauend personalisierte Darstellungen greifen, etwa mit Symbolen. Der Aufwand ist ein Attribut pro Feld, also vielleicht zehn Minuten für ein ganzes Formular.

12:04 Ich kenne keine andere Maßnahme in diesem Feld mit einem so günstigen Verhältnis — und trotzdem fehlt sie in den meisten Formularen. Oben Felder mit nichtssagenden Namen. Der Browser rät dann anhand von Heuristiken, mal richtig, mal nicht. Unten dieselben Felder mit ausdrücklich benanntem Zweck — Vorname, Nachname, E-Mail, Postleitzahl. Jetzt ist es keine Vermutung mehr, sondern eine Angabe.

12:29 Wichtig ist die Fußzeile: Die Werte sind standardisiert. Es gibt eine feste Liste, und eigene Bezeichnungen wirken nicht. Wenn Sie also „vorname" statt der standardisierten Bezeichnung schreiben, sieht es im Code richtig aus und tut gar nichts. Das ist übrigens ein guter Kandidat für eine Prüfung im Code-Review — es fällt sonst nie auf.

12:51 Der erste Stolperstein ist eine Nebenwirkung eigener Ambitionen: die automatische Vervollständigung pauschal abschalten, um eigene Vorschläge zu zeigen. Ihre Vorschläge sind aber nicht die gespeicherten Daten des Nutzers — Sie ersetzen etwas Persönliches durch etwas Generisches. Der zweite ist der eben genannte: eigene Werte erfinden statt der standardisierten. Sieht aus wie Sorgfalt, wirkt nicht.

13:13 Und der dritte ist ein Vollständigkeitsproblem: das Attribut nur im Anmeldeformular setzen und in der Buchung vergessen. Ausgerechnet in der Buchungsstrecke sind die meisten Adressfelder — dort bringt es den größten Gewinn.

Zeitlimits und Sitzungsverhalten

13:27 Ein unterschätztes Thema mit harten Folgen. Fristen sind für schnell bedienende Menschen unsichtbar und für langsam bedienende ein Ausschlusskriterium. Und die meisten Fristen sind gar nicht nötig. Reservierungen laufen ab, Sitzungen enden — das hat oft gute fachliche Gründe. Wer solche Fristen setzt, schuldet aber drei Dinge: ankündigen, verlängern lassen, den Stand erhalten.

13:50 Und der harte Satz dazu: Ein Ablauf, der zehn Minuten Eingabe stillschweigend verwirft, ist für langsam bedienende Menschen ein Ausschlusskriterium. Nicht ärgerlich — ausschließend. Denn wer für das Formular strukturell länger braucht, schafft es nie. Das kann bedeuten, dass eine ganze Nutzergruppe Ihre Anwendung faktisch nicht verwenden kann, ohne dass Sie es je aus den Daten erfahren würden.

14:13 In der Statistik sieht das aus wie Desinteresse. Fünf Schritte, und Schritt eins löst erfahrungsgemäß die meisten Fälle: Ist die Frist fachlich nötig oder nur bequem? Sitzungszeitüberschreitungen sind oft eine Voreinstellung, die niemand je hinterfragt hat. Wenn sie nötig ist, machen Sie die verbleibende Zeit sichtbar und geben sie als Statusmeldung aus — dafür haben wir gerade die Live Regions gelernt.

14:38 Warnen Sie rechtzeitig vorher, nicht danach. Bieten Sie das Verlängern an, ohne den Vorgang zu verlassen — ein Dialog, kein neuer Seitenaufruf. Und wenn die Frist doch abläuft: den eingegebenen Stand erhalten und beim Zurückkommen anbieten. Das ist der Zustandserhalt aus Modul zehn. Der erste Stolperstein ist eine halbe Lösung: nur einen Countdown anzeigen und ihn nirgends ansagen. Sichtbar tickt es, hörbar passiert nichts.

15:04 Der zweite klingt komisch und passiert wirklich: die Warnung genau zum Ablaufzeitpunkt ausgeben. Dann ist die Warnung eine Mitteilung über etwas Vergangenes. Warnen Sie so früh, dass jemand mit langsamer Bedienung noch reagieren kann — zwei Minuten sind ein vernünftiger Richtwert. Und der dritte ist der teuerste: nach Ablauf zurück zum Anfang schicken und die Eingaben verwerfen.

15:25 Das ist der Moment, in dem Menschen die Anwendung schließen und nicht wiederkommen.

Drag-and-drop und zugängliche Alternativen

15:31 Das letzte inhaltliche Kapitel, wieder ein Kriterium aus Version 2.2. Ziehen ist eine Präzisionsgeste — und für alles, was per Ziehen geht, braucht es einen zweiten Weg. Ziehen verlangt gleichzeitig Präzision, Ausdauer und Koordination: gedrückt halten, exakt bewegen, an der richtigen Stelle loslassen. Für Menschen mit Tremor, mit eingeschränkter Feinmotorik oder mit Schaltersteuerung ist das nicht machbar.

15:56 Deshalb verlangt Version 2.2 für alles, was per Ziehen geht, einen Weg mit einfachem Zeigen — eine Schaltfläche, ein Menü, eine Tastenkombination. Bei der Sitzplatzvergabe von Fahrtwind ist die Alternative denkbar einfach: eine schlichte Auswahlliste. Mehr braucht es nicht. Und wie Sie gleich sehen werden, ersetzt sie das Ziehen nicht — sie steht daneben und ist für alle nutzbar.

16:19 Oben ein ziehbarer Sitzplatz, mehr nicht. Unten derselbe ziehbare Sitzplatz — und daneben eine Auswahlliste mit denselben Plätzen, samt Lage und Verfügbarkeit im Text, wie wir es in Modul sechs spezifiziert haben. Achten Sie auf die Fußzeile, denn das ist der springende Punkt: Die Alternative ersetzt das Ziehen nicht, sie steht daneben. Wer mit der Maus zieht, zieht weiter.

16:41 Wer nicht ziehen kann, wählt aus. Und interessanterweise nutzen viele Menschen ohne jede Einschränkung dann auch die Liste, weil sie schneller ist. Das ist das Muster, das uns durch das ganze Seminar begleitet. Der erste Stolperstein ist eine falsche Zuordnung: die Alternative nur auf Touchgeräten anbieten. Die Frage ist nicht das Gerät, sondern die Fähigkeit zur Präzisionsgeste — und die hängt nicht am Formfaktor.

17:06 Der zweite ist der Ausgangsfall: Ziehen als einzigen Weg für Sortierung und Auswahl. Denken Sie besonders an Sortierlisten in Verwaltungsoberflächen; dort ist Ziehen fast Standard und eine Alternative fast nie vorhanden. Und der dritte ist ein Zirkelschluss, den ich tatsächlich schon gesehen habe: die Alternative hinter einem Menü verstecken, das selbst Ziehen erfordert.

17:27 Prüfen Sie den Weg zur Alternative mit, nicht nur die Alternative selbst.

Übung — ein Formular vollständig zugänglich machen

17:32 In der Übung bringen Sie ein Formular mit sieben Mängeln in Ordnung. Sechs davon werden Sie finden. Der siebte ist der, über den wir im Validierungskapitel schon gesprochen haben. Sie bringen das Formular für Reisendendaten in Ordnung. Geübt wird das Erkennen von Formularbarrieren und ihre Behebung mit nativen Mitteln — ohne das Aussehen zu verändern, wie schon in Modul neun.

17:55 Erfolgreich sind Sie, wenn alle sieben Mängel behoben sind, jedes Feld Label und Eingabezweck hat und Fehler verknüpft, angesagt und aus der Zusammenfassung erreichbar sind. Der siebte Mangel wird selten gefunden: Die Fehlerzusammenfassung steht da, führt den Fokus aber nirgendwohin. Sie sieht also korrekt aus und leistet nichts.

18:13 Wer früh fertig ist, ergänzt die Zeitbegrenzung der Reservierung samt Warnung und Verlängerung. Fünf Schritte in aufsteigender Tiefe. Zuerst das Formular mit der Tastatur ausfüllen und jede Hürde notieren — wieder erst sammeln, dann reparieren. Dann Labels verbinden und Platzhalter als Beschriftung entfernen. Dann zusammengehörige Felder gruppieren. Dann die Fehlerbehandlung, das ist der aufwendigste Teil.

18:38 Und zum Schluss die Eingabezwecke ergänzen und mit dem Screenreader gegenprüfen. Beachten Sie die Regel in der Fußzeile, sie ist die Fortsetzung von Modul neun: Kein ARIA, wo ein natives Attribut reicht. Das Pflicht-Attribut und die Label-Verknüpfung schlagen jede nachträgliche Ergänzung — sie sind kürzer und sie funktionieren zuverlässiger.

18:59 Der erste Stolperstein ist die ARIA-Übererfüllung, vor der die Fußzeile warnt: Fehler mit einem Live-Attribut nachrüsten, wo die Warnrolle am Fehlertext genügt. Weniger ist hier tatsächlich mehr. Der zweite ist eine Ausweichbewegung: Labels visuell verstecken, statt sie sichtbar zu setzen. Das ist gelegentlich vertretbar, aber es sollte die Ausnahme sein — sichtbare Beschriftungen helfen allen, besonders bei kognitiven Einschränkungen.

19:25 Und der dritte ist der siebte Mangel selbst: die Zusammenfassung ergänzen, ohne den Fokus dorthin zu führen. Das ist die häufigste halb fertige Fehlerbehandlung im Netz. Vier Punkte. Platzhaltertext ist kein Label — er verschwindet genau dann, wenn er gebraucht wird. Gruppen brauchen eine Frage, und zwar semantisch, nicht als Überschrift daneben.

19:46 Fehler müssen verknüpft, benannt und mit Korrekturvorschlag versehen sein; rot allein ist keine Meldung. Und Ziehen braucht immer einen Weg mit einfachem Zeigen daneben. Bemerkenswert an diesem Modul: Drei Neuerungen aus Version 2.2 sind hier praktisch geworden — Anmeldung, doppelte Eingabe und Ziehbewegungen. Sie sehen, wie nah der Rechtsrahmen aus Modul sieben an Ihrem Formularcode liegt. Als Nächstes nehmen wir uns die komplexen Komponenten vor.