Barrierefreiheit, UI-Bausteine und Internationalisierung

Barrierefreiheit und UI-Bausteine

0:00 Ein Dialog, den man nur mit der Maus schließen kann, ist kein Dialog. Er ist eine Falle. Und das ist kein Randthema für eine kleine Minderheit: In einer Werkstatt arbeiten Menschen mit Handschuhen, an schlechten Bildschirmen, im Stehen, mit einer Hand am Fahrzeug. Tastaturbedienung ist dort keine Barrierefreiheitsmaßnahme, sondern Arbeitsgeschwindigkeit.

0:20 In diesem Modul prüfen wir eine Oberfläche ohne Maus, beheben die Befunde und schauen uns an, welche Bausteine Angular dafür anbietet.

Qualität, Tests und zugängliche Oberflächen

0:29 Das ist das letzte Modul des vierten Tages. Vormittags Tests, jetzt die andere Hälfte von Qualität — die, die man nicht automatisch messen kann und die deshalb regelmäßig untergeht.

Semantisches HTML, Tastatur und Fokus

0:40 Beginnen wir mit dem Fundament. Und die gute Nachricht ist: Die halbe Arbeit macht das richtige HTML-Element ganz von allein. Ein Knopf, der als Knopf ausgezeichnet ist, ist fokussierbar, mit Leer- und Eingabetaste bedienbar und wird als Knopf angesagt. Ein Container mit einem Klick-Ereignis ist nichts davon — er sieht nur genauso aus. Barrierefreiheit beginnt also bei der Wahl des Elements und setzt sich in der Fokusführung fort.

1:07 Zwei Fragen, die man sich bei jedem Dialog stellen sollte: Wo steht der Fokus beim Öffnen, und wohin kehrt er beim Schließen zurück? Die zweite wird fast immer vergessen. Vier Punkte, und der zweite ist der, den ich in fast jedem Projekt beanstande: Der Fokus muss jederzeit sichtbar sein, nicht nur vorhanden. Der Rahmen wird gern entfernt, weil er nicht ins Design passt — und damit ist die Tastaturbedienung theoretisch möglich und praktisch unbenutzbar, weil niemand sieht, wo er gerade ist.

1:36 Der dritte und vierte gehören zusammen: In einem Dialog bleibt der Fokus drin, und beim Schließen kehrt er auf das auslösende Element zurück. Sonst beginnt der Benutzer jedes Mal wieder ganz vorn. Fünf Schritte, und die Fußzeile ist mir die wichtigste Aussage dieses Moduls: Zehn Minuten ohne Maus finden mehr als jedes automatische Prüfwerkzeug.

1:56 Automatische Werkzeuge finden fehlende Beschriftungen und Kontrastprobleme — nützlich, aber das ist die leichte Hälfte. Ob ein Ablauf bedienbar ist, ob der Fokus sinnvoll läuft, ob man sich verirrt: Das merkt nur, wer es versucht. Und Schritt fünf ist Disziplin: Befunde notieren statt sofort zu beheben, sonst finden Sie die letzten drei nie.

2:17 Der erste Punkt ist der Ursprung der meisten Befunde: Ein Container mit Klick-Ereignis ersetzt einen Knopf. Das passiert nicht aus Nachlässigkeit, sondern weil ein Knopf Standardstile mitbringt, die jemand wegräumen müsste. Der zweite ist der eben besprochene entfernte Fokusrahmen. Und der dritte ist der Klassiker, der beim Prüfen sofort auffällt und den vorher niemand bemerkt: Nach dem Schließen eines Dialogs beginnt der Fokus wieder ganz vorn — und der Benutzer tabbt sich durch die halbe Seite zurück.

Angular Aria für interaktive Muster

2:45 Jetzt zu einem Paket, das in Angular 22 stabil geworden ist und das genau diese Arbeit abnimmt. Angular Aria liefert Direktiven ohne eigene Gestaltung, die verbreitete Zugänglichkeitsmuster umsetzen. Es übernimmt die Tastaturbedienung, die ARIA-Attribute, die Fokusverwaltung, die Unterstützung für Screenreader und für Sprachen, die von rechts nach links laufen.

3:09 HTML-Struktur, CSS und Fachlogik bleiben bei Ihnen. Denken Sie an ein Getriebe ohne Karosserie: Die Mechanik ist fertig und erprobt, wie das Auto aussieht, entscheiden Sie. In Angular 22 ist das Paket stabil. Zwölf Muster in vier Gruppen — und das sind genau die, bei denen man sich selbst verhebt. Eine Auswahlliste mit Tastaturnavigation korrekt umzusetzen, mit Pfeiltasten, Typeahead, Bildlauf und den richtigen Attributen, ist ein Tagewerk. Ein Menü mit Untermenüs ebenso.

3:39 Wenn Sie in dieser Tabelle das finden, was Sie bauen wollten: Nehmen Sie es. Der Reiz, es selbst zu machen, endet erfahrungsgemäß bei der Frage, was die Pos1-Taste in einem aufgeklappten Untermenü tun soll. Der Import erfolgt je Muster aus einem eigenen Unterpfad — das hält die Auslieferung klein, Sie holen sich nur, was Sie benutzen.

4:01 Worauf es ankommt: In diesem Beispiel steht keine einzige Zeile Tastaturbehandlung und kein einziges ARIA-Attribut, das Sie selbst setzen müssten. Das macht die Direktive. Ihre Aufgabe ist das HTML drumherum und das CSS. Und die Fußzeile nennt den einen Satz, der beim ersten Einsatz Verwirrung stiftet: Die Gestaltung bleibt vollständig beim Projekt.

4:23 Der erste Punkt ist der, der mich am meisten ärgert: Das Muster wird eingebaut und die Prüfung ohne Maus dennoch übersprungen. Das Paket erledigt seinen Teil — es weiß aber nichts über Ihr CSS, Ihren Fokusrahmen oder Ihre Beschriftungen. Der zweite ist ein technischer: Eigene ARIA-Attribute überschreiben die der Direktive, und dann ist es schlechter als vorher.

4:44 Und der dritte ist ein Missverständnis: Die fehlende Gestaltung wird als Fehler des Pakets gelesen.

CDK und Material zum Designsystem wählen

4:51 Damit zur Entscheidung, die dahintersteht: Welche Bausteine nehmen Sie überhaupt? Angular bietet drei Stufen an, und die Wahl hat Folgen. Angular Material liefert fertig gestaltete Komponenten. Angular Aria liefert das Verhalten ohne Gestaltung. Das CDK liefert einzelne Bausteine — Überlagerungen, Listen, Fokusverwaltung.

5:12 Die Wahl hängt an einer einzigen Frage: Gibt es ein eigenes Designsystem, oder ist ein fertiges Erscheinungsbild erwünscht? Und ein Satz zur Warnung: Ein nachträglicher Wechsel ist ein Umbau der Oberfläche, kein Austausch einer Abhängigkeit. Vier Felder, und das vierte ist das, vor dem ich warnen möchte: Material anpassen.

5:33 Das geht, und es ist regelmäßig teurer als gedacht — man kämpft gegen ein Designsystem an, das seine eigenen Vorstellungen hat. Bei Falkenhorst war die Entscheidung einfach, weil ein Designsystem existiert: Farben, Abstände und Typografie liegen fest. Also Angular Aria. Hätte es keines gegeben, wäre Material die schnellere Wahl gewesen — und völlig in Ordnung. Falsch ist nur, das eine zu wählen und dann das andere zu wollen.

6:00 Der erste Punkt ist genau dieses vierte Feld: Material wird eingeführt und dann gegen das Designsystem umgestaltet. Der zweite ist die andere Richtung, die Zeit kostet: Ein eigenes Menü entsteht, obwohl das Muster fertig vorliegt. Und der dritte ist ein organisatorischer, der sich im Ergebnis sehr sichtbar niederschlägt: Die Wahl fällt je Feature, und die Oberfläche wird uneinheitlich — hier ein Material-Dialog, dort ein eigener, und der Benutzer merkt den Unterschied.

Internationalisierung vorbereiten

6:27 Zum Abschluss ein Thema, das die meisten Projekte vertagen — und bei dem sich das Vertagen besonders rächt. Angular i18n zeichnet Texte im Template mit einem Attribut aus, ein Befehl zieht sie in eine Übersetzungsdatei, und je Sprache entsteht ein eigener Build. Datum, Zahl und Währung formatieren die mitgelieferten Pipes anhand der eingestellten Sprachregion. Das Vorbereiten kostet fast nichts: Attribute setzen, Texte aus dem Code halten.

6:53 Das Nachrüsten kostet viel, weil man dann durch die ganze Anwendung geht und jede Zeichenkette sucht — auch die im TypeScript-Code, die keine Extraktion je findet. Fünf Schritte, und die Fußzeile nennt den teuersten Teil einer späten Umstellung: Texte im TypeScript-Code. Die werden von der Extraktion nicht erfasst, also muss jemand sie von Hand finden. Schritt zwei ist die eigentliche Vorbereitung und kostet je Text fünf Sekunden.

7:19 Schritt fünf ist der, den man aus Gewohnheit falsch macht: Datums- und Zahlenformate über die Pipes ausgeben statt selbst zusammenzusetzen. Ein selbstgebautes Datumsformat ist beim nächsten Land falsch. Der erste Punkt ist der, den ich eben genannt habe und der die meiste Nacharbeit erzeugt: Texte stehen im Code statt im Template.

7:39 Der zweite ist derselbe Gedanke bei Formaten: Datumsformate werden selbst zusammengesetzt statt über eine Pipe — funktioniert und ist beim ersten fremden Markt falsch. Und der dritte ist ein halber Weg: Die Übersetzung wird begonnen, der Build je Sprache aber nie eingerichtet. Dann liegen Übersetzungsdateien im Projekt, die niemand benutzt und die veralten.

Übung

7:59 Nehmen wir uns den Statusdialog von Spurweite vor. Zehn Minuten ohne Maus — und ich verspreche Ihnen, Sie werden etwas finden. In Spurweite ändert ein Dialog den Status eines Auftrags. Er wird über einen Knopf in der Auftragskarte geöffnet, enthält eine Auswahl und ein Notizfeld. In der jetzigen Fassung lässt er sich mit der Tastatur öffnen, aber nicht zuverlässig schließen — das war der Befund, mit dem eine Monteurin sich gemeldet hat.

8:26 Sie arbeitet mit Handschuhen und benutzt die Maus ungern. Solche Rückmeldungen bekommt man selten, und wenn, dann sollte man sie ernst nehmen. Das Lernziel hat drei Teile, und der mittlere ist der ungewohnte: Befunde benennen. Nicht nur beheben — benennen, damit jemand anders sie nachvollziehen kann. Das Erfolgskriterium verlangt vollständige Tastaturbedienbarkeit, den Rücksprung des Fokus und einen kurzen Review, der die behobenen Befunde festhält.

8:53 Wer früh fertig ist, markiert die Texte für eine spätere Übersetzung. Das ist die Gelegenheit — der Dialog ist ohnehin gerade offen. Der erste Schritt ist der, den ich Ihnen ans Herz lege: zehn Minuten ohne Maus. Schieben Sie sie wirklich weg. Schritt zwei ordnet je Befund eine Ursache zu — falsches Element, fehlender Fokus, fehlende Ansage. Diese drei Kategorien decken fast alles ab.

9:18 Schritt drei setzt das passende Muster ein. Schritt vier überarbeitet Beschriftung und Fehlerrückmeldung des Notizfelds, also den Teil aus Modul zwölf. Und Schritt fünf hält das Ergebnis fest — mit den offenen Punkten, nicht nur den erledigten. Der erste Punkt ist der, der am häufigsten passiert und am wenigsten hilft: Der Befund wird mit einem ARIA-Attribut überdeckt statt behoben.

9:41 Ein Container, der sich als Knopf ausgibt, ist immer noch kein Knopf. Der zweite ist der, der die ganze Übung wertlos macht: Die Prüfung erfolgt mit der Maus in der Hand. Und der dritte betrifft die Ehrlichkeit des Reviews: Er nennt die Befunde, nicht aber die offen gebliebenen. Morgen geht es um Rendering, Performance und Sicherheit — die Themen, bei denen Messen wichtiger ist als Meinen.