React v19 - Base UI für React

React v19+ — Base UI

0:00 Es gibt in der Oberflächenentwicklung einen alten Zielkonflikt. Fertige Komponenten-Bibliotheken nehmen einem viel Arbeit ab — aber sie bringen ein Aussehen mit, das man dann mühsam wieder wegkämpft, bis die eigene Marke durchkommt. Baut man dagegen alles selbst, hat man zwar volle Gestaltungsfreiheit, muss aber Dinge nachbauen, die überraschend schwer sind: Tastaturbedienung, Fokus-Führung, korrekte Auszeichnung für Screenreader.

0:24 Base UI schlägt einen dritten Weg vor. Es liefert das Verhalten und die Zugänglichkeit fertig und lässt das Aussehen vollständig offen. Genau diese Arbeitsteilung schauen wir uns heute an.

Unstyled UI mit Base UI

0:36 Der Weg führt von der ersten zusammengesetzten Komponente bis zu einem eigenen, barrierefreien Design-System. Wir klären zunächst die Einordnung — wo steht Base UI zwischen den bekannten Alternativen? Dann bauen wir Komponenten aus ihren Bausteinen, geben ihnen ein Aussehen, kümmern uns um Formulare und Overlays und schließen mit dem Thema, das den ganzen Ansatz erst rechtfertigt: Zugänglichkeit.

0:59 Sie werden sehen, dass "unstyled" nicht "unfertig" heißt — im Gegenteil. Kurze Runde vorweg, weil sie den heutigen Tag prägt. Wer schon mit Radix oder React Aria gearbeitet hat, wird vieles wiedererkennen und sich vor allem auf die Unterschiede konzentrieren. Wer aus der Welt der fertig gestalteten Bibliotheken kommt, muss sich zunächst umgewöhnen — dort bekommt man ein Ergebnis, hier bekommt man ein Fundament.

1:22 Und die mittlere Frage hat es in sich: Wer schon einmal ein Overlay mit korrekter Fokus-Führung selbst gebaut hat, weiß, wie viel Arbeit hinter der scheinbar einfachen Aussage "Verhalten ist fertig" steckt.

Einführung & Einordnung

1:34 Beginnen wir mit der Landkarte. Der Bereich der headless Komponenten ist in den letzten Jahren voller geworden, und die Namen klingen alle ähnlich. Klären wir also zuerst, was Base UI genau ist, woher es kommt und wie es sich von den Nachbarn unterscheidet. Diese Einordnung lohnt sich, bevor Sie eine Zeile schreiben — sie entscheidet nämlich darüber, was Sie von der Bibliothek erwarten dürfen.

1:56 Stellen Sie sich einen Rohbau vor, bei dem die gesamte Haustechnik schon verlegt ist — Leitungen, Anschlüsse, Statik. Was fehlt, sind Wandfarbe, Böden und Möbel. Genau das ist Base UI: Fünfunddreißig Komponenten, bei denen das Verhalten fertig ist, die Tastaturbedienung stimmt und die Auszeichnung für Screenreader sitzt — aber keine einzige Zeile Gestaltung mitgeliefert wird.

2:18 Interessant ist die Herkunft: Dahinter stehen die Leute, die Radix, Floating UI und MUI gebaut haben. Das ist geballte Erfahrung mit genau den Problemen, die man beim Selberbauen unterschätzt. Bei einer Bibliothek, auf die man sein gesamtes Design-System stellt, ist die Frage nach der Zukunft mindestens so wichtig wie die nach den Funktionen.

2:39 Deshalb verdienen die letzten beiden Punkte Beachtung. MUI steht mit einem langfristigen Bekenntnis dahinter — das ist eine Firma mit Geschäftsmodell, kein Nebenprojekt. Und dass shadcn/ui inzwischen auf Base UI als Standardschicht setzt, ist ein starkes Signal aus der Praxis: Sie treffen diese Wahl also nicht allein. Die freie Lizenz nimmt der Entscheidung zusätzlich das Risiko.

3:01 Die ersten beiden Schritte sind Denkarbeit, keine Tipparbeit — und die lohnt sich, bevor man ein Paket installiert. Schritt drei enthält eine praktische Stolperfalle: Das Paket wurde umbenannt. Im Netz kursieren noch viele Beispiele mit dem alten Namen, und wer den kopiert, installiert einen eingefrorenen Stand. Achten Sie darauf.

3:20 Die letzten beiden Punkte gehören ins Team-Gespräch: Welche React-Version ist bei Ihnen im Einsatz, und wie geht man mit Aktualisierungen um, wenn eine ganze Oberfläche darauf aufbaut? Hier sehen Sie das Grundmuster, das sich durch die gesamte Bibliothek zieht. Eine Komponente ist kein einzelnes Element mit dreißig Einstellungen, sondern ein Bausatz aus benannten Teilen: Es gibt eine Wurzel, die den Zustand hält, einen Auslöser, und den eigentlichen Inhalt.

3:46 Der Vorteil zeigt sich, sobald Sie etwas Ungewöhnliches wollen — Sie schieben ein eigenes Element dazwischen, statt nach einer passenden Einstellung zu suchen. Optisch passiert hier übrigens gar nichts: Ohne Ihre Gestaltung sehen Sie unformatierten Text. Das ist kein Fehler, das ist das Versprechen. Diese erste Aufgabe verlangt ausnahmsweise keinen Code, sondern eine klare Linie im Kopf.

4:09 Sie sollen benennen können, wo die Grenze verläuft: Was übernimmt die Bibliothek, und was bleibt bei Ihnen? Diese Grenze zu kennen, ist mehr wert als jedes Detailwissen — denn sie beantwortet später jede Frage der Form "Warum sieht das nicht aus wie erwartet?". Wer mag, geht danach in die Dokumentation und verfolgt den Bausatz einer Komponente nach. Sie werden feststellen, dass die Struktur überall dieselbe ist.

4:34 Der erste Punkt ist die Enttäuschung des ersten Tages: Man baut etwas, lädt die Seite und sieht rohen Text. Wer das erwartet, kommt gar nicht erst in diese Falle. Der zweite ist der Paketname, über den wir eben gesprochen haben. Der dritte ist die teuerste Verschwendung — man baut eine Tastatursteuerung nach, die längst mitgeliefert wird, und macht sie dabei schlechter.

4:56 Bevor Sie irgendetwas an Verhalten selbst schreiben: erst nachsehen, ob es nicht schon da ist. Meistens ist es das.

Setup & Architektur-Grundlagen

5:04 Jetzt gehen wir vom Überblick ins Handwerk. Drei Konzepte tragen alles, was folgt: der Bausatz aus Teilen, das Einschleusen eigener Elemente und die Frage, wer den Zustand hält. Wer diese drei verstanden hat, kann sich jede der fünfunddreißig Komponenten selbst erschließen. Nehmen Sie sich für dieses Kapitel Zeit; alles Weitere baut unmittelbar darauf auf.

5:25 Das zentrale Werkzeug ist hier das Render-Prop, und es löst ein Problem, das jeder kennt: Sie haben bereits eine eigene Schaltfläche, sorgfältig gestaltet, mit Ihren Abständen und Ihrer Schrift. Jetzt soll sie ein Menü öffnen. Ohne diesen Mechanismus bekämen Sie zwei ineinander verschachtelte Elemente, und die Gestaltung verrutscht.

5:45 Mit ihm reichen Sie Ihr Element hinein, und die Bibliothek verdrahtet ihr Verhalten damit — ein Element, keine zusätzliche Hülle. Wer von Radix kommt: Das ist der Nachfolger dessen, was dort anders hieß. Der Zweck ist identisch, die Schreibweise nicht. Der letzte Punkt verdient eine Einordnung, weil er ein Problem löst, das erfahrungsgemäß erst spät auffällt.

6:07 Ein Overlay, das innerhalb Ihres Layouts gerendert wird, wird von diesem Layout auch beschnitten — ein Container mit verborgenem Überlauf schneidet Ihr Dropdown einfach ab. Ein Portal hängt das Element stattdessen ganz oben im Dokument ein, außerhalb aller Container. Dieses Problem taucht typischerweise erst auf, wenn das Menü in einer scrollbaren Tabelle landet, und dann sucht man an der falschen Stelle. Gut, es vorher zu wissen.

6:32 Der erste Schritt betrifft nur Next.js-Projekte, ist dort aber die häufigste Ursache für einen abrupten Fehlschlag: Interaktive Komponenten brauchen die Kennzeichnung als Client-Code. Die Schritte zwei bis vier sind der eigentliche Bauplan. Bei der Zustandsfrage lohnt sich eine bewusste Entscheidung: Solange niemand außerhalb wissen muss, ob ein Dialog offen ist, überlassen Sie das ruhig der Komponente.

6:56 Sobald aber etwas anderes davon abhängt, übernehmen Sie die Kontrolle. Nur nicht beides gleichzeitig — dazu gleich mehr. Worauf es hier ankommt, ist unscheinbar, aber wichtig: Sie reichen ein fertiges Element hinein, kein Element wird um Ihres herumgebaut. Die Bibliothek nimmt Ihr Element und hängt daran alles an, was es braucht — die Klick-Behandlung, die Auszeichnung für Screenreader, die Fokus-Logik.

7:19 Im erzeugten Dokument steht am Ende genau Ihre Schaltfläche, nur eben verdrahtet. Das klingt nach einem Detail, entscheidet aber darüber, ob Ihre Abstände und Ihre Gestaltung greifen oder ob eine unsichtbare Hülle dazwischenfunkt. In dieser Übung setzen Sie die drei Konzepte zusammen. Bauen Sie einen Dialog aus seinen Teilen, hängen Sie Ihre eigene Schaltfläche als Auslöser ein und halten Sie den Zustand selbst.

7:43 Der Prüfstein ist einfach: Es soll funktionieren, und Ihre Schaltfläche soll dabei aussehen wie überall sonst. Die Zusatzaufgabe ist besonders lehrreich — stellen Sie danach auf die selbstverwaltete Variante um und formulieren Sie in einem Satz, was sich dadurch ändert. Diese Unterscheidung begegnet Ihnen bei jeder weiteren Komponente wieder.

8:03 Der dritte Punkt ist der, der die meiste Zeit kostet, weil das Symptom so verwirrend ist. Wenn Sie einen Wert vorgeben, aber nicht auf dessen Änderung reagieren, bleibt der Dialog scheinbar hängen — oder er springt beim nächsten Neuzeichnen zurück. Es sieht nach einem Fehler in der Bibliothek aus, ist aber eine halbe Zustandsverwaltung.

8:22 Entscheiden Sie sich: entweder ganz übernehmen, mit Wert und Änderungsbehandlung, oder ganz abgeben. Der erste und der letzte Punkt sind die beiden Umgebungsfallen, über die wir schon gesprochen haben.

Styling-Strategien

8:33 Kommen wir zu dem Teil, für den Sie sich diese Bibliothek überhaupt ausgesucht haben: der Gestaltung. Die spannende Frage dabei ist nicht, wie man Farben setzt, sondern wie man an die Zustände herankommt — an "gerade geöffnet", "ausgewählt", "deaktiviert". Und wir schauen uns an, wie man daraus ein eigenes Design-System macht statt einer Sammlung verstreuter Klassenlisten.

8:55 Der Ansatz ist elegant, weil er die Gestaltung dorthin verlagert, wo sie hingehört: ins Stylesheet. Die Komponente schreibt ihren jeweiligen Zustand als Datenattribut ins Dokument — geöffnet, angehakt, deaktiviert. Sie reagieren darauf mit ganz normalen CSS-Selektoren. Denken Sie an eine Ampel, die ihren Zustand selbst anzeigt, während Sie nur festlegen, welche Farbe wozu gehört.

9:19 Der große Vorteil: Kein JavaScript muss Klassen umschalten, keine Zustandsvariable muss doppelt gepflegt werden. Dazu kommen CSS-Variablen mit Layout-Werten — etwa der Breite des Auslösers für ein passgenaues Dropdown. Der letzte Punkt ist der wichtigste, und er wird oft zu spät beherzigt. Die Bibliothek gibt Ihnen Bausteine, kein Design-System — das entsteht erst, wenn Sie Ihre eigenen gestalteten Komponenten darum herumlegen.

9:46 Der Rest der Anwendung sollte nie direkt mit den rohen Teilen arbeiten, sondern immer mit Ihrer Schaltfläche, Ihrem Dialog. Sonst wandert dieselbe Klassenliste in vierzig Dateien, und die erste Designänderung wird zur Suchaktion. Diese Kapselung ist etwas Arbeit am Anfang und spart Wochen später. Der vierte Schritt verdient eine Erklärung, weil er nicht offensichtlich ist.

10:08 Wenn ein Overlay verschwindet, wird es normalerweise sofort aus dem Dokument entfernt — und damit ist auch keine Ausblendanimation mehr möglich, es gibt ja nichts mehr zu animieren. Die Einstellung zum Eingehängt-Bleiben löst genau das: Das Element bleibt kurz bestehen, bis die Animation durchgelaufen ist. Wer sich je gewundert hat, warum das Einblenden schön aussieht und das Ausblenden ruckartig abbricht — das ist die Antwort.

10:32 Hier sieht man den Ansatz in seiner kompaktesten Form. Eine Grundfarbe, und daneben eine Regel, die nur greift, wenn der Schalter aktiv ist. Kein Zustandshaken, keine Bedingung im Code, keine Klassenliste, die zusammengesetzt wird. Die Komponente sagt, wie es um sie steht, und das Stylesheet antwortet. Bemerkenswert ist, dass dieses Muster überall gleich funktioniert — bei geöffneten Menüs, deaktivierten Feldern, ausgewählten Einträgen.

11:00 Sie lernen es einmal und wenden es fünfunddreißig Mal an. Jetzt gestalten Sie drei Bausteine selbst — und zwar so, dass man ihre Zustände sieht. Der Prüfstein ist bewusst streng formuliert: Kein einziger Stil darf aus der Bibliothek kommen, denn sie liefert ja keinen. Alles, was Sie sehen, ist Ihr Werk. Nutzen Sie die Datenattribute konsequent und widerstehen Sie der Versuchung, Zustände im Code abzufragen.

11:25 Als Ergänzung dann eine Ein- und Ausblendanimation — und denken Sie an die Einstellung von eben, sonst fehlt Ihnen die halbe Bewegung. Der erste und der letzte Punkt sind die beiden großen. Zustände im Code umzuschalten funktioniert zwar, führt aber zu doppelter Wahrheit: Die Komponente weiß, dass sie offen ist, und Ihre Variable meint es auch zu wissen — bis die beiden auseinanderlaufen.

11:48 Und die Gestaltung direkt an den rohen Teilen zu platzieren, ist der Weg zu einem Design-System, das keines ist. Der zweite Punkt ist eine schöne Erinnerung: Für Positionsangaben gibt es fertige Werte. Wer die Breite eines Auslösers selbst misst, arbeitet gegen die Bibliothek.

Formulare & Eingabekomponenten

12:04 Formulare sind der Ort, an dem Zugänglichkeit am häufigsten scheitert — und zugleich der, an dem man es am leichtesten richtig machen kann. Schauen wir uns an, wie Base UI Beschriftung, Eingabe und Fehlermeldung zusammenbindet und was es an Eingabekomponenten mitbringt. Sie werden sehen, dass hier besonders viel Arbeit mitgeliefert wird, die man von Hand selten vollständig hinbekommt.

12:26 Die drei Strukturbausteine lösen ein Problem, das jeder unterschätzt: die korrekte Verknüpfung zwischen Beschriftung, Eingabefeld, Erklärungstext und Fehlermeldung. Von Hand bedeutet das eine Sammlung eindeutiger Kennungen, die man sorgfältig aufeinander verweisen lässt — und die beim ersten Umbau auseinanderfallen. Hier passiert das automatisch, sobald Sie die Teile ineinanderlegen.

12:48 Bemerkenswert ist außerdem die Auswahl mit Vorschlagsliste: Sie gilt als das Stück, das anderswo fehlt und das man selbst nachzubauen regelmäßig unterschätzt. Warum das mit der Vorschlagsliste so betont wird, versteht man erst, wenn man sie einmal selbst gebaut hat. Tippen filtert, Pfeiltasten wandern, die Vorlesesoftware muss ansagen, wie viele Treffer es gibt und welcher gerade aktiv ist — dazu die Frage, was passiert, wenn nichts passt.

13:13 Das sind mehrere Tage Arbeit für ein einziges Feld, und fertig ist es trotzdem selten. Der letzte Punkt ist die Beruhigung für bestehende Projekte: Die Zusammenarbeit mit den üblichen Formular- und Prüfbibliotheken funktioniert, Sie müssen nichts über Bord werfen. Wichtig an dieser Reihenfolge ist, dass die Struktur vor der Prüfung kommt. Erst stehen die Felder sauber gegliedert, dann kümmern wir uns darum, was gültig ist.

13:38 Der vierte Schritt nennt bewusst drei Ebenen — und die letzte davon ist keine Kür. Eine Prüfung im Browser ist Komfort für den Nutzer, keine Sicherheit; sie lässt sich in dreißig Sekunden umgehen. Was wirklich zählt, prüft der Server noch einmal. Der Browser sagt dem Nutzer freundlich, was fehlt — der Server sagt verbindlich, was gilt.

13:59 Vier Zeilen, in denen mehr steckt, als man sieht. Durch das bloße Ineinanderlegen entstehen die korrekten Verweise: Die Beschriftung zeigt auf das Feld, die Fehlermeldung wird als dessen Beschreibung angemeldet, und der ungültige Zustand wird gemeldet. Für einen sehenden Nutzer ändert das wenig. Für jemanden mit Vorlesesoftware ist es der Unterschied zwischen "Eingabefeld" und "E-Mail, Eingabefeld, ungültig, bitte gültige E-Mail".

14:25 Diese Verknüpfung von Hand hinzubekommen ist möglich — sie über den Umbau hinweg korrekt zu halten, gelingt selten. Bauen Sie ein vollständiges Formular mit Prüfung und Fehleranzeige. Und machen Sie unbedingt den Test, der im Erfolgskriterium steckt: Schalten Sie die Vorlesefunktion Ihres Betriebssystems ein und bedienen Sie das Formular nur mit der Tastatur.

14:46 Das ist für die meisten eine Erfahrung, die mehr hängen bleibt als jede Folie über Zugänglichkeit — vor allem, wenn man es danach einmal ohne die Strukturbausteine probiert. Als Ergänzung dann das Feld mit Vorschlagsliste, an dem Sie den ganzen Aufwand sehen, den Sie sich sparen. Der zweite Punkt ist der tückischste, weil das Ergebnis auf dem Bildschirm völlig in Ordnung aussieht.

15:07 Eine Fehlermeldung, die außerhalb des vorgesehenen Bausteins steht, ist optisch ein roter Text unter dem Feld — für die Vorlesesoftware aber ist sie unsichtbar, weil die Verknüpfung fehlt. Der Nutzer weiß dann nur, dass das Absenden nicht klappt, aber nicht warum. Der letzte Punkt wiederholt die Grenze von eben: Der Browser prüft für die Bequemlichkeit, der Server prüft für die Wahrheit.

Overlays & Popups

15:29 Overlays sind die Königsdisziplin. Alles, was über anderem Inhalt schwebt, wirft dieselben Fragen auf: Wo genau erscheint es, was passiert am Bildschirmrand, wo liegt der Fokus, und wie kommt man mit der Tastatur wieder heraus? Schauen wir uns an, wie diese Fragen hier einheitlich beantwortet werden. Wer solche Bausteine schon einmal selbst gebaut hat, wird dieses Kapitel besonders zu schätzen wissen.

15:52 Das gemeinsame Modell ist der eigentliche Gewinn. Ob Dialog, Sprechblase, Menü oder Kurzhinweis — dahinter steckt immer dieselbe Mechanik. Besonders sehenswert ist der Positionierer: Er verankert ein Element an seinem Auslöser und berücksichtigt dabei den Bildschirmrand. Stellen Sie sich ein Menü ganz unten am Fenster vor. Ohne diese Logik klappt es nach unten auf und ist zur Hälfte unsichtbar; mit ihr klappt es einfach nach oben.

16:17 Jeder kennt dieses Verhalten von guten Anwendungen, kaum jemand baut es freiwillig selbst nach. Der dritte Punkt ist der, für den man am dankbarsten ist. Fokus-Verwaltung bedeutet: Beim Öffnen springt der Fokus hinein, mit der Tabulatortaste kommt man nicht versehentlich in den Hintergrund, die Fluchttaste schließt, und beim Schließen landet der Fokus wieder dort, wo er herkam.

16:40 Verschachtelte Dialoge machen es noch komplizierter. Wer das schon einmal selbst versucht hat, kennt die Liste der Sonderfälle. Sie ist lang, sie ist unspektakulär, und sie ist genau der Grund, warum sich eine solche Bibliothek rechnet. Bei Schritt eins lohnt eine bewusste Entscheidung. Ein modaler Dialog sperrt alles dahinter — richtig für "Wollen Sie wirklich löschen?", falsch für einen Hilfetext, neben dem man weiterarbeiten möchte.

17:05 Wer alles modal macht, zwingt Nutzer zu unnötigen Klicks. Die Schritte zwei und drei bauen auf dem Positionierer auf. Und der letzte Punkt zahlt auf zwei Dinge ein: das Timing für Animationen, über das wir gesprochen haben, und die Geschwindigkeit — fünfzig Overlays, die alle im Voraus erzeugt werden, kosten spürbar. Diese Verschachtelung sollten Sie als Muster mitnehmen, denn sie kehrt bei jedem schwebenden Element wieder.

17:30 Ganz außen das Portal, das das Element aus Ihrem Layout heraushebt — dagegen hilft kein noch so hoher Stapelwert, wenn ein Container den Überlauf abschneidet. Darin der Positionierer, der die Verankerung und den Bildschirmrand regelt; hier legen Sie auch den Abstand zum Auslöser fest. Und ganz innen erst der sichtbare Inhalt, den Sie gestalten. Drei Ebenen, drei klar getrennte Aufgaben.

17:53 Ein Aktionsmenü ist die perfekte Übung, weil darin alles zusammenkommt. Testen Sie es bewusst hart: Legen Sie den Auslöser einmal ganz an den unteren Rand und schauen Sie zu, wie das Menü von selbst nach oben klappt. Bedienen Sie es ausschließlich mit der Tastatur — Pfeiltasten, Eingabetaste, Fluchttaste — und achten Sie darauf, wo der Fokus danach steht.

18:13 Wenn das alles funktioniert, ohne dass Sie eine Zeile dafür geschrieben haben, haben Sie den Wert dieses Kapitels verstanden. Der zweite Punkt ist der Klassiker mit dem verwirrendsten Symptom: Das Menü funktioniert wochenlang tadellos, und dann setzt jemand die Tabelle drumherum auf scrollbar — plötzlich ist es abgeschnitten.

18:32 Man sucht dann im Menü, obwohl die Ursache im Container liegt. Deshalb Portale von Anfang an. Der dritte Punkt ist die Mahnung, es nicht besser wissen zu wollen als eine Bibliothek, die genau dafür gebaut wurde. Fokus-Verwaltung selbst zu schreiben endet fast immer bei einer Falle, aus der die Tastatur nicht mehr herausfindet.

Accessibility & Best Practices

18:51 Zum Abschluss der ehrliche Teil. Über Zugänglichkeit wird oft geredet, als wäre sie ein Häkchen, das eine Bibliothek für einen setzt. Das stimmt zur Hälfte — und die andere Hälfte bleibt bei Ihnen. Klären wir, wo genau die Grenze verläuft. Diese Grenze zu kennen, ist mehr wert als jedes Detailwissen — sie sagt Ihnen, worauf Sie im eigenen Code achten müssen.

19:13 Die Aufteilung lässt sich gut merken: Die Bibliothek kümmert sich um alles, was mit Struktur und Bedienung zu tun hat — was ein Element ist, wo der Fokus liegt, was angesagt wird. Bei Ihnen bleibt alles, was mit Wahrnehmung zu tun hat. Ob Ihr Grauton auf Weiß lesbar ist, weiß keine Bibliothek. Ob Ihre Schaltfläche groß genug für einen Daumen ist, auch nicht.

19:34 Und ob Sie den Fokusrahmen sichtbar lassen, ist Ihre Entscheidung — eine, die täglich falsch getroffen wird, weil der Rahmen als hässlich gilt. Zum dritten Punkt eine Einordnung, die viele überrascht. Reduzierte Bewegung ist keine Geschmacksfrage. Für Menschen mit vestibulären Störungen können große Bewegungen auf dem Bildschirm echte Übelkeit auslösen — das Betriebssystem hat dafür einen Schalter, und Ihre Anwendung sollte ihn respektieren.

20:00 Es kostet Sie eine Handvoll Zeilen. Der letzte Punkt ist praktisch für bestehende Projekte: Der Wechsel von Radix ist machbar, weil die Denkweise dieselbe ist. Aber eben nicht durch Suchen und Ersetzen — die Unterschiede sind klein und zahlreich. Diese fünf Punkte sind eine gute Prüfliste, bevor eine Komponente ins Design-System wandert.

20:20 Der vierte verdient Aufmerksamkeit, weil er das Thema aus der Absichtserklärung holt: Tastaturbedienung lässt sich automatisiert testen. Ein Test, der einen Dialog per Tabulatortaste durchläuft und prüft, wo der Fokus landet, hält diese Qualität dauerhaft — sonst bröckelt sie beim ersten Umbau, den niemand von Hand nachprüft.

20:39 Der letzte Punkt betrifft wieder nur Server-gerenderte Projekte, dort aber verlässlich. Zwei kleine Regeln, die stellvertretend für das ganze Kapitel stehen. Oben der sichtbare Fokus — und beachten Sie die genaue Bedingung: Sie greift nur bei Tastaturbedienung, nicht beim Mausklick. Das ist die Lösung für den alten Konflikt zwischen Design und Bedienbarkeit; Sie müssen den Rahmen nicht global entfernen, um ihn beim Klicken loszuwerden.

21:05 Unten die Rücksicht auf reduzierte Bewegung. Beides zusammen sind fünf Zeilen. Der Unterschied für einen Teil Ihrer Nutzer ist die Differenz zwischen benutzbar und unbenutzbar. Nehmen Sie sich eine Ihrer gestalteten Komponenten vor und machen Sie sie belastbar: sichtbarer Fokus, geprüfte Kontraste, Rücksicht auf reduzierte Bewegung.

21:24 Für die Kontraste nutzen Sie ruhig ein Prüfwerkzeug statt des Augenmaßes — helle Grautöne täuschen zuverlässig. Und wer Zeit hat, schreibt den Tastaturtest dazu. Das ist der Schritt, der aus einer einmaligen Aufräumaktion eine Eigenschaft macht, die auch in einem halben Jahr noch gilt. Der erste Punkt ist das Missverständnis dieses ganzen Kapitels: Die Bibliothek nimmt Ihnen die Struktur ab, nicht die Verantwortung.

21:48 Der zweite ist der häufigste echte Schaden im Web überhaupt — der global entfernte Fokusrahmen. Er wird aus gestalterischen Gründen entfernt, und danach ist die Anwendung ohne Maus praktisch nicht mehr bedienbar, weil niemand sieht, wo er gerade ist. Wenn Sie heute nur eine Sache mitnehmen: Entfernen Sie den Fokusrahmen nicht, ersetzen Sie ihn durch einen, der zu Ihrem Design passt.

22:10 Fassen wir zusammen. Base UI verschiebt die Arbeitsteilung: Verhalten und Struktur kommen fertig, das Aussehen bleibt vollständig bei Ihnen. Sie bauen aus Bausteinen statt aus Einstellungen, schleusen eigene Elemente ein statt Hüllen zu akzeptieren, und gestalten über Zustandsattribute statt über umgeschaltete Klassen. Overlays folgen alle demselben Muster. Und die vierte Zeile ist die wichtigste: Die Bibliothek liefert die halbe Zugänglichkeit — die Hälfte, die man schlecht selbst baut.

22:38 Die andere Hälfte bleibt eine bewusste Entscheidung, die Sie täglich treffen.

Fragen & Weiterarbeiten

22:43 Alle Komponenten und Übungslösungen liegen in der Freigabe. Nehmen Sie sich vor allem Ihre gestalteten Wrapper mit — das ist der Kern eines eigenen Design-Systems, und der Rest ergibt sich daraus. Die offizielle Dokumentation ist ausgesprochen gut, mit lauffähigen Beispielen zu jedem Baustein; ein Blick auf die Roadmap lohnt sich, wenn Sie langfristig planen.

23:04 Für Fragen aus dem eigenen Projekt sind wir erreichbar. Vielen Dank für Ihre Aufmerksamkeit.