Zugängliche UI-Komponenten

Zugängliche UI-Komponenten

0:00 In Modul neun haben wir gelernt, ARIA möglichst zu vermeiden. Jetzt kommt das Modul, in dem es tatsächlich nötig wird — und genau deshalb geht hier am häufigsten etwas schief. Zusammengesetzte Widgets haben kein natives Gegenstück: Es gibt kein Tab-Element und keine fertige Combobox mit Filterung. Hier müssen Sie Rollen und Zustände selbst setzen.

0:21 Und damit gilt der Satz, der dieses Modul zusammenfasst: Wer eine Rolle setzt, übernimmt damit ihr gesamtes erwartetes Verhalten. Hier landet auch das Material, das die Übungen in Modul neun und zehn ausdrücklich vertagt haben.

Zugängliche UI-Komponenten

0:35 Sieben Kapitel entlang der Komponenten, die in echten Projekten die meiste Mühe machen. Navigation und Menüs — und eine überraschende Erkenntnis darüber, was ein Menü technisch eigentlich ist. Dann Tabs und Akkordeons, die sich ähnlich sehen und grundverschieden verhalten. Dialoge, Comboboxen, und dann drei Muster, die häufig verlangt und selten zugänglich gebaut werden.

0:57 Danach Tabellen und Diagramme, und zum Schluss die Grundsatzentscheidung nativ gegen Eigenbau. In der Übung analysieren und reparieren Sie eine fehlerhafte Combobox — mit drei Prüfwegen, bevor Sie eine Zeile ändern.

Navigation und Menüs

1:10 Beginnen wir mit einer Erkenntnis, die viele überrascht. Die meisten Websitenavigationen sind gar keine Menüs im technischen Sinn — und sie sollten auch nicht so ausgezeichnet werden. Das Wort Menü führt in die Irre. Was Sie oben auf einer Website haben, ist in aller Regel eine Liste von Links — und die sollte auch genau so ausgezeichnet werden.

1:31 Die Menü-Rollen aus ARIA stammen nämlich aus einer anderen Welt: aus Anwendungsmenüs, wie Sie sie aus Textverarbeitungen kennen. Sie bringen ein bestimmtes Tastaturverhalten mit — Pfeiltasten statt Tabulator, ein einziger Tabstopp für das ganze Menü. Auf einer Website ist das unerwartet und irritiert geübte Nutzende. Was aufklappbare Bereiche dagegen wirklich brauchen, ist der Aufklappzustand als Attribut und eine Bedienung mit Escape.

1:56 Oben eine Linkliste mit Menü-Rollen. Das sieht nach Sorgfalt aus — jemand hat sich Gedanken gemacht. Und es ist ein Versprechen, das der Code nicht hält: Wer die Menü-Rolle setzt, schuldet Pfeiltasten, Escape und einen einzigen Tabstopp für die ganze Gruppe. Ist das nicht implementiert, verhält sich die Navigation anders als angesagt — und das ist schlimmer als gar keine Rolle.

2:19 Unten steht, was es wirklich ist: ein Navigationsbereich mit Label und einer Liste von Links. Das wird als Navigation angesagt, sagt die Anzahl der Einträge, und die Bedienung ist genau die erwartete. Weniger Code, mehr Wirkung. Der erste Stolperstein ist der eben gezeigte, und er ist das Grundmuster dieses Moduls: Rollen setzen und das zugehörige Tastaturverhalten schuldig bleiben.

2:43 Der zweite ist eine schlichte Lücke: Aufklappbereiche ohne Zustandsattribut. Dann weiß niemand, ob das Untermenü gerade offen oder geschlossen ist — und ob das Drücken etwas bewirkt hat. Und der dritte ist ein alter Bekannter, die Farbregel aus Modul fünf: die aktuelle Seite nur farblich markieren. Es gibt dafür ein eigenes Attribut, das genau diese Information trägt. Eine Zeile, und die Orientierung in der Navigation funktioniert für alle.

Tabs und Akkordeons

3:10 Jetzt zwei Muster, die sich zum Verwechseln ähnlich sehen und technisch grundverschieden sind. Wer sie vertauscht, erzeugt widersprüchliche Ansagen — die Komponente sagt das eine und tut das andere. Beide verstecken Inhalte hinter Schaltern, und optisch kann man sie kaum unterscheiden. Der Unterschied liegt im Verhalten.

3:29 Tabs sind eine Gruppe: Es ist genau ein Panel offen, man wechselt mit den Pfeiltasten, und die ganze Gruppe hat einen einzigen Tabstopp. Ein Akkordeon dagegen ist eine Folge unabhängiger Umschalter: Man kann alle öffnen, keinen oder drei, und jeder Schalter ist ein eigener Tabstopp. Wer das eine als das andere auszeichnet, erzeugt Ansagen, die nicht zum Verhalten passen — der Nutzer hört „Registerkarte, eins von vier" und drückt eine Pfeiltaste, und nichts passiert.

3:57 Die interessanteste Zeile ist die letzte, denn sie sagt, wann Sie was nehmen sollten. Tabs passen zu alternativen Ansichten desselben Gegenstands — Details, Bewertungen, Fahrplan. Es gibt einen sinnvollen Ausgangszustand, und man wechselt zwischen gleichrangigen Sichten. Ein Akkordeon passt zu einer langen Seite, die man abschnittsweise erschließt — häufige Fragen, Vertragsbedingungen.

4:20 Da will man vielleicht drei Abschnitte gleichzeitig offen haben. Wenn Sie unsicher sind, hilft eine einfache Frage: Soll man mehrere Bereiche gleichzeitig sehen können? Ja heißt Akkordeon, nein heißt Tabs. Das entscheidet dann auch alle anderen Zeilen dieser Tabelle mit. Der erste Stolperstein ist die Vertauschung: ein Akkordeon mit Tab-Rollen auszeichnen und die Pfeiltasten schuldig bleiben.

4:44 Das passiert häufig, weil Tab-Rollen nach der professionelleren Lösung aussehen. Der zweite ist der Tabstopp-Fehler aus Modul zehn: jedem Tab einen eigenen Tabstopp geben. Bei sechs Tabs sind das fünf unnötige Tastendrücke pro Durchlauf. Und der dritte ist ein subtiler und häufiger: Panels ausblenden, ohne sie aus dem Baum zu nehmen.

5:03 Sie sind dann unsichtbar und trotzdem vorhanden — der Screenreader liest alle vier Panels hintereinander vor, und niemand versteht, warum die Seite so lang ist.

Dialoge und Popover

5:13 Weiter zu Dialogen und Popovern. Wir haben in Modul zehn schon über Fokusverhalten gesprochen — hier geht es um die Unterscheidung selbst, und die hängt an einem Begriff: Modalität. Der Unterschied ist eine Frage der Verbindlichkeit. Ein modaler Dialog blockiert den Rest der Seite und fängt den Fokus — er sagt: Entscheiden Sie das jetzt.

5:34 Ein Popover tut das nicht; die Seite bleibt bedienbar, der Fokus bleibt frei. Es bietet Zusatzinformation an, ohne zu erzwingen. Beides gibt es inzwischen nativ, samt Fokusverhalten und Schließen per Escape — das ist eine der erfreulichsten Entwicklungen der letzten Jahre. Der Eigenbau lohnt sich nur noch bei sehr besonderen Anforderungen. Und dann übernimmt er die volle Wartungslast, wie wir in Modul sechs durchgerechnet haben.

6:00 Achten Sie auf die letzte Zeile, die den Zweck benennt — daran entscheiden Sie. Entscheidung erzwingen heißt modal: „Buchung wirklich stornieren?" Zusatzinformation anbieten heißt Popover: eine Erläuterung zum Tarif. Die Zeilen darüber sind dann Folgen, keine Wahlmöglichkeiten. Wenn Sie sich für modal entscheiden, gehört der inerte Hintergrund und der gefangene Fokus dazu — beides nicht optional.

6:25 Und umgekehrt: Ein Popover, das den Fokus fängt, ist eine Falle im Sinne von Modul zehn. Interessant ist, dass Escape in beiden Fällen schließt. Das ist die universelle Fluchttaste, und sie sollte überall funktionieren. Der erste Stolperstein ist eine Vermischung: einen Popover modal gestalten — mit abgedunkeltem Hintergrund — ohne diesen Hintergrund tatsächlich inert zu setzen.

6:49 Die Optik sagt blockiert, die Bedienung sagt frei, und der Fokus wandert in eine abgedunkelte Seite. Der zweite ist der Klassiker aus Modul zehn: beim Schließen den Fokus nicht an das auslösende Element zurückgeben. Und der dritte wird erst in großen Anwendungen relevant: Dialoge verschachteln und die Rückgabekette verlieren.

7:08 Wer aus Dialog A den Dialog B öffnet, muss beim Schließen von B zurück nach A — nicht auf die Seite. Führen Sie diese Kette bewusst, sie geht sonst verloren.

Comboboxen und Autocomplete

7:18 Jetzt die anspruchsvollste Komponente des ganzen Systems. Freihändig gebaute Comboboxen sind fast immer fehlerhaft — hier lohnt sich das dokumentierte Muster mehr als irgendwo sonst. Die Zielsuche von Fahrtwind vereint alles, was schwierig ist: ein Eingabefeld, eine gefilterte Liste, Tastaturnavigation zwischen Feld und Liste, eine Statusmeldung über die Trefferzahl und ein sinnvoller Zustand, wenn nichts passt.

7:42 Fünf Bestandteile, die alle zusammenspielen müssen. Genau deshalb ist die Combobox der Fall, bei dem sich das dokumentierte Muster am meisten lohnt — es ist über Jahre erprobt und deckt Fälle ab, an die Sie beim Bauen nicht denken. Und noch ein Hinweis aus Modul sechs: Wenn Sie eine Bibliothek prüfen, nehmen Sie die Combobox. Wer die kann, kann meistens den Rest.

8:04 Oben die naive Fassung: ein Eingabefeld, daneben eine Liste. Sichtbar zusammengehörig, technisch zwei unabhängige Dinge — der Screenreader-Nutzer tippt, und irgendwo daneben ändert sich still eine Liste, von der er nichts weiß. Unten die verbundene Fassung. Das Feld hat eine Beschriftung, meldet seine Rolle, seinen Aufklappzustand, den zugehörigen Listenbereich und die Art der Vervollständigung.

8:27 Und dann das Element, das am häufigsten fehlt: die Statuszeile mit der Trefferzahl. Ohne sie bleibt völlig unklar, ob die Eingabe zu vier Treffern oder zu keinem geführt hat. Sie ist der Unterschied zwischen bedienbar und benutzbar. Der erste Stolperstein ist der gerade genannte: die Trefferliste austauschen, ohne die Anzahl anzusagen.

8:48 Das ist die Live-Region-Regel aus Modul elf, angewandt auf die schwierigste Komponente. Der zweite ist ein Tastaturfehler mit hohem Nervfaktor: Pfeiltasten die Seite scrollen lassen, statt in der Liste zu navigieren. Sie müssen das Standardverhalten hier ausdrücklich abfangen. Und der dritte ist ein Zustandsfehler: den leeren Zustand als leere Liste ausliefern.

9:10 Für das Auge ist eine leere Liste eine Aussage. Für den Screenreader ist sie nichts — es wird schlicht nichts angesagt. Sagen Sie „keine Ziele gefunden", das ist die Aussage.

Anzeigemuster mit Fallstricken: Tooltip, Carousel, Toast

9:22 Drei Muster, die häufig verlangt und selten zugänglich gebaut werden. Bei allen dreien lautet die erste Frage aber nicht „wie baue ich das richtig", sondern: Braucht es das Muster überhaupt? Schauen wir uns an, was bei jedem schiefgeht. Tooltips erscheinen bei Mauskontakt, verschwinden zu schnell und sind auf Touch praktisch nicht erreichbar — ein Finger schwebt nicht, wie wir in Modul fünf gesehen haben.

9:45 Automatisch laufende Karussells bringen Bewegung ohne Pausemöglichkeit und wechselnden Inhalt ohne Ansage; für Menschen mit vestibulären Beschwerden und für langsam Lesende sind sie gleichermaßen ungeeignet. Und kurz eingeblendete Toasts sind für viele Menschen schlicht zu schnell. Was alle drei gemeinsam haben: Sie tragen oft Information, die einfach im Text stehen müsste.

10:06 Das ist meistens die richtige Antwort. Die Tabelle hat zwei Spalten, und die rechte ist die interessantere. „Mindestens nötig" sagt Ihnen, was Sie tun müssen, wenn das Muster gesetzt ist. „Besser" sagt Ihnen, was Sie tun sollten, wenn Sie noch Einfluss haben. Text sichtbar daneben statt Tooltip. Eine Liste statt eines Karussells — die Nutzer sehen dann alle Angebote statt eines rotierenden. Und eine Meldung, die nachlesbar bleibt, statt eines flüchtigen Einblenders.

10:34 Meine Erfahrung: In den meisten Fällen ist die rechte Spalte nicht nur zugänglicher, sondern auch schlicht besser. Karussells werden nachweislich kaum bedient — sie sind ein Kompromiss zwischen Abteilungen, kein Nutzerwunsch. Der erste Stolperstein hat unmittelbare Folgen: wichtige Information ausschließlich in einen Tooltip legen. Auf dem Telefon ist sie damit weg.

10:57 Ein Tooltip darf ergänzen, nie tragen. Der zweite ist der Klassiker beim Karussell: Folien ausblenden und sie fokussierbar lassen — der Tabulator wandert dann in unsichtbare Folien, und der Nutzer verschwindet gefühlt aus der Seite. Wir hatten das in Modul vier. Und der dritte betrifft die Toasts: sie als einzigen Ort für Bestätigungen verwenden.

11:18 „Ihre Buchung wurde gespeichert" für drei Sekunden — wer währenddessen woandershin sah oder langsamer liest, erfährt es nie.

Tabellen, Data Grids und Datenvisualisierung

11:26 Jetzt zu Daten. Drei verwandte Dinge mit drei verschiedenen Anforderungen — und einer Verwechslung, die besonders häufig ist. Drei Fälle, drei Aufgaben. Eine Datentabelle ist statisch und braucht saubere Kopfzellen — das haben wir in Modul neun behandelt. Ein Grid ist bedienbar: sortierbar, filterbar, mit fokussierbaren Zellen.

11:46 Es braucht deshalb ein eigenes Tastaturmodell, mit Pfeiltasten in vier Richtungen, wie in Modul zehn gesehen. Und ein Diagramm braucht gleich drei Zugänge: eine textliche Zusammenfassung, die zugrunde liegenden Daten in zugänglicher Form, und Farben, die nicht allein unterscheiden. Diese drei Zugänge sind übrigens auch für sehende Nutzende hilfreich — eine Zusammenfassung unter einem Diagramm liest fast jeder.

12:11 Ein kleines Beispiel mit großer Wirkung. Oben eine Sortierschaltfläche in der Kopfzelle. Man drückt sie, die Tabelle sortiert sich um — und für die assistive Technik passiert nichts Erkennbares. Der Nutzer weiß nicht, ob er gerade auf- oder absteigend sortiert hat und ob überhaupt etwas geschehen ist. Unten dieselbe Schaltfläche mit zwei Ergänzungen: das Sortier-Attribut an der Kopfzelle, das den aktuellen Zustand trägt, und eine Statusmeldung, die die Änderung erklärt.

12:38 Die Kombination ist wichtig — das Attribut beschreibt den Zustand für den, der die Zelle erreicht, die Statusmeldung informiert sofort über die Änderung. Der erste Stolperstein ist der eben gezeigte: Sortierschalter einbauen, ohne den Zustand zu melden. Das ist in Verwaltungsoberflächen fast der Normalfall. Der zweite ist eine Auslassung mit großer Wirkung: ein Diagramm ohne textliche Zusammenfassung und ohne Datentabelle ausliefern.

13:04 Ein Diagramm ist für einen Screenreader eine Grafik, mehr nicht — und selbst ein guter Alternativtext ersetzt keine Datenreihe. Und der dritte ist die eingangs erwähnte Verwechslung: ein Grid mit Tabellenrollen auszeichnen und das Tastaturmodell weglassen. Es ist dann eine Tabelle, die sich bedienen lässt, aber deren Bedienung niemand erreicht.

Eigene Komponenten gegen native Browserfunktionen

13:25 Das letzte inhaltliche Kapitel schließt den Bogen zu Modul neun. Es geht um die Abwägung — und vor allem darum, dass sie dokumentiert gehört und nicht dem Zufall überlassen wird. Vor jedem Eigenbau lohnt eine kurze Bilanz. Nativ bekommen Sie Tastaturbedienung, Semantik, Plattformkonventionen und künftige Verbesserungen — vier Dinge, für die Sie nichts tun.

13:46 Eigenbau bringt Gestaltungsfreiheit und eine dauerhafte Wartungspflicht. Das ist keine Wertung: Manchmal ist die Gestaltungsfreiheit die Anforderung, und dann ist der Eigenbau richtig. Der Punkt ist, dass diese Abwägung bewusst getroffen und aufgeschrieben werden sollte. Denn sie wird sonst in drei Jahren wieder geführt, von anderen Leuten, ohne das Wissen von heute — genau wie der Zielkonflikt aus Modul eins.

14:11 Fünf Schritte, und Schritt zwei ist der aufschlussreiche: Ist die Anforderung gestalterisch oder funktional? Die Fußzeile verrät das Ergebnis — die meisten Eigenbauten entstehen aus gestalterischen Gründen. Und dafür gibt es Schritt drei: erst das Native mit Stilmitteln ausreizen. Da hat sich in den letzten Jahren viel getan; vieles, was vor fünf Jahren unmöglich war, geht heute.

14:33 Bei tatsächlich funktionalen Gründen übernehmen Sie das dokumentierte Muster, statt eines zu erfinden. Und Schritt fünf: Entscheidung samt Begründung in die Komponentenseite schreiben. Das ist die Dokumentationsregel aus Modul sechs, angewandt auf eine Architekturentscheidung. Der erste Stolperstein ist der häufigste Anlass für Eigenbau überhaupt: ein natives Element ersetzen, weil eine Randgestaltung nicht ging.

14:58 Ein Pfeilsymbol, eine Ecke, eine Farbe im geöffneten Zustand — dafür wird eine ganze Komponente nachgebaut, inklusive aller Verhaltensweisen. Rechnen Sie das einmal gegeneinander auf. Der zweite ist Erfindungsreichtum am falschen Ort: ein Muster erfinden, für das ein dokumentiertes existiert. Und der dritte ist der Wissensverlust: die Entscheidung nicht festhalten.

15:19 Dann führt das nächste Team dieselbe Diskussion, kommt vielleicht zum anderen Ergebnis, und Sie haben zwei Lösungen für dasselbe Problem.

Übung — eine fehlerhafte Komponente analysieren und korrigieren

15:28 Zum Abschluss von Tag zwei nehmen Sie sich die schwierigste Komponente vor. Und beachten Sie die Reihenfolge: drei Prüfwege zuerst, dann erst die Korrektur. Sie analysieren die Combobox des Kompass-Systems und bringen sie in Ordnung. Geübt wird das systematische Aufdecken von Fehlern in einer zusammengesetzten Komponente — und die Behebung gegen das dokumentierte Muster, nicht nach eigenem Gutdünken.

15:51 Erfolgreich sind Sie, wenn jeder Befund mit dem verletzten Kriterium benannt ist und die korrigierte Combobox per Tastatur vollständig bedienbar ist sowie Trefferzahl und Auswahl meldet. Ein Hinweis: Die Trefferzahl wird fast immer vergessen — sie ist der Unterschied zwischen bedienbar und benutzbar. Wer früh fertig ist, prüft zusätzlich den leeren Zustand und den Fall, dass die Liste während der Eingabe neu lädt.

16:14 Drei Prüfwege, dann die Korrektur. Zuerst nur mit der Tastatur bedienen und jede Abweichung notieren. Dann im Accessibility Tree Rolle, Name und Zustände prüfen — das ist der Blick auf das, was gemeldet wird. Dann mit dem Screenreader hören, was beim Tippen und Auswählen tatsächlich ankommt; das ist noch einmal etwas anderes als der Baum.

16:35 Erst danach benennen Sie je Befund das verletzte Kriterium, und erst dann wird korrigiert — gegen das dokumentierte Muster, ohne Zutaten. Die Fußzeile begründet die Reihenfolge: Wer früher korrigiert, behebt das Sichtbare und übersieht den Rest. Der erste Stolperstein ist der Reihenfolgefehler: mit der Korrektur beginnen, bevor der Screenreader-Durchlauf gelaufen ist.

16:57 Gerade bei der Combobox liegen die interessanten Befunde in dem, was angesagt wird — und was nicht. Der zweite ist die Kernwarnung dieses Moduls: fehlendes Tastaturverhalten mit zusätzlichen ARIA-Attributen kaschieren. Mehr Attribute machen ein Widget nicht bedienbar, sie machen es nur ausführlicher falsch. Und der dritte ist ein Prüfumfangsfehler: den leeren Zustand und den Ladezustand auslassen.

17:21 Das sind genau die Zustände, die im Entwurf nie dargestellt sind — wie wir in Modul sechs gesehen haben. Vier Punkte, und damit endet Tag zwei. Die meisten Navigationen sind Linklisten — Menü-Rollen schulden ein Tastaturverhalten, das Sie dann auch liefern müssen. Tabs und Akkordeons sehen ähnlich aus und verhalten sich grundverschieden; entscheiden Sie über die Frage, ob mehreres gleichzeitig offen sein soll.

17:45 Eine Combobox ohne angesagte Trefferzahl ist bedienbar, aber nicht benutzbar. Und der Satz für alles: Wer eine Rolle setzt, übernimmt damit ihr gesamtes erwartetes Verhalten. Behalten Sie zum Schluss die Frage aus der Fußzeile im Kopf — bei jedem dieser Muster lautet die erste Frage, ob es die Komponente überhaupt braucht.