Custom Selects: Designfreiheit ohne Accessibility-Schulden

Ein kleines UI-Element mit überraschend hohen Kosten

Ein Dropdown wirkt in einem Design schnell banal: ein Feld, ein Pfeil, eine Liste. In der Entwicklung ist es oft das Gegenteil. Sobald ein Team das native Select-Element durch ein selbst gebautes Menü ersetzt, übernimmt es Arbeit, die der Browser vorher still erledigt hat: Tastaturnavigation, Fokus, mobile Bedienung, Screenreader-Informationen, Formularwerte, Validierung, Zurücksetzen und lange Listen.

Am 17. September 2026 hat WebKit Safari 27 veröffentlicht. Zu den neuen Funktionen gehören anpassbare native Select-Elemente und Scroll Anchoring. Gerade die Selects sind für Produktteams interessant: Zum ersten Mal lässt sich das echte Formularfeld deutlich weiter gestalten, ohne seine eingebaute Semantik wegzuwerfen.

Das ist keine Einladung, jedes Auswahlfeld in ein kleines Kunstwerk zu verwandeln. Es ist die Chance, weniger JavaScript zu bauen und trotzdem ein Interface zu liefern, das zur Marke passt.

Was sich technisch verändert hat

Der neue Ansatz beginnt weiterhin mit einem normalen select und normalen option-Elementen. Das ist der wichtigste Punkt. Das Formular kennt den Wert, die Tastatur kennt die Auswahl und assistive Technik bekommt ein vertrautes Steuerelement.

Mit appearance: base-select können Browser in einen neuen Darstellungsmodus wechseln. Darauf bauen mehrere CSS-Bausteine auf:

• ::picker(select) gestaltet die geöffnete Auswahlliste;
• ::picker-icon adressiert das Pfeilsymbol im geschlossenen Feld;
• ::checkmark gestaltet die Markierung der aktiven Option;
• :open beschreibt den Zustand, während die Liste geöffnet ist;
• selectedcontent kann die gewählte Option im Button des Feldes darstellen.

Optionen dürfen dabei mehr enthalten als eine nackte Textzeile. Ein Produkt kann zum Beispiel ein kleines Symbol, einen Titel und eine ergänzende Information zeigen. Das ist nützlich für Versandarten, Teamrollen, Standorte oder Tarife. Die eigentliche Auswahl bleibt dennoch ein natives Form-Control.

Die goldene Regel: Jede Option braucht verständlichen Text

WebKit formuliert für anpassbare Selects eine einfache Regel: In jeder Option muss Text oder ein zugänglicher Textname erhalten bleiben. Ein Icon allein reicht nicht. Eine Landesflagge benennt kein Land, ein farbiger Punkt erklärt keinen Status und ein Paket-Symbol sagt nicht, welche Versandart gemeint ist.

Diese Regel hilft gleich auf drei Ebenen:

1. Screenreader können die Option ansagen.
2. Wenn CSS ausfällt oder der Browser die neue Darstellung nicht unterstützt, bleibt ein lesbares Standardfeld.
3. Menschen müssen Symbole nicht erraten.

Die visuelle Ebene ergänzt also den Namen; sie ersetzt ihn nicht. Ein gutes Beispiel wäre „Express · morgen“ neben einem Blitz-Symbol. Ein schlechtes Beispiel wäre nur der Blitz.

Progressive Enhancement statt Browser-Roulette

MDN markiert die Technik weiterhin als eingeschränkt verfügbar. Das ist kein Gegenargument, sondern eine klare Implementierungsanweisung: Zuerst muss das klassische Select vollständig funktionieren. Die neue Darstellung kommt als zusätzliche CSS-Schicht darüber.

Ein robuster Ablauf sieht so aus:

1. Semantisches Select mit Label, Namen, Werten und lesbaren Optionen bauen.
2. Ohne eigene Styles Tastatur, Formular-Submit, Validierung und Fehlermeldungen prüfen.
3. Den neuen Modus nur in Browsern aktivieren, die ihn verstehen.
4. Die erweiterte Darstellung mit langen Inhalten und realen Daten testen.
5. In nicht unterstützten Browsern bewusst das native Standardfeld akzeptieren.

Das Ergebnis muss nicht pixelgleich sein. Es muss in jedem Browser klar, bedienbar und markenkonform genug bleiben. Wer für den Fallback dieselbe optische Präzision erzwingen will, landet schnell wieder bei einem kompletten JavaScript-Widget — und damit bei den alten Risiken.

Ein sinnvoller Anwendungsfall

Nehmen wir die Wahl einer Lieferoption im Checkout. Drei Optionen sollen Preis, voraussichtlichen Zeitpunkt und eine kurze Erklärung zeigen. Früher gab es meist zwei schlechte Extreme: ein schmales Standard-Select mit zu wenig Kontext oder drei vollständig selbst gebaute Karten mit eigener Auswahl- und Fokuslogik.

Ein anpassbares Select kann dazwischen liegen. Im geschlossenen Zustand zeigt es „Standard · 2–3 Werktage“. Geöffnet erscheinen alle Optionen mit Symbol, Name, Zeitraum und Preis. Der Browser verwaltet weiterhin den ausgewählten Wert und übergibt ihn mit dem Formular.

Ob dieser Aufbau wirklich besser ist, entscheidet nicht die Demo. Entscheidend sind Aufgaben: Finden Menschen schneller die richtige Option? Verstehen sie Preisunterschiede? Können sie die Auswahl allein mit der Tastatur ändern? Bleibt die Seite bei 200 Prozent Zoom verständlich? Erst diese Antworten rechtfertigen die reichere Darstellung.

Die Zustände, die im Mock-up gern fehlen

Ein schönes Feld im Ruhezustand ist nur ein Bruchteil der Arbeit. Für ein produktionsreifes Select gestalten und testen wir mindestens:

• normal, hover, focus-visible und geöffnet;
• ausgewählt, leer, ungültig und deaktiviert;
• einzelne deaktivierte Optionen und Optionsgruppen;
• sehr lange deutsche Bezeichnungen und schmale mobile Viewports;
• hohe Zoomstufen, starke Kontraste und reduzierte Bewegung;
• Fehlertexte, Hilfetexte und das zugehörige Label;
• Zurücksetzen des Formulars und erneutes Laden vorhandener Werte.

Animationen sollten Orientierung geben, nicht die Bedienung verzögern. Ein kurzer Farb- oder Schattenwechsel reicht oft. Wenn die Liste mit einer großen räumlichen Bewegung erscheint, braucht sie eine ruhige Variante für prefers-reduced-motion.

Eine Testmatrix, die mehr findet als ein Screenshot

Für jedes neue Select gehen wir die Bedienung als kleine Reise durch:

Tastatur: Tab erreicht das Feld. Pfeiltasten wechseln sinnvoll. Enter, Leertaste und Escape verhalten sich erwartbar. Der Fokus verschwindet nicht hinter eigenen Ebenen.

Screenreader: Label, aktueller Wert, Zustand und Optionen werden verständlich angesagt. Dekorative Icons verdoppeln keine Informationen.

Formular: Submit, serverseitige Validierung, Browser-Validierung, Reset und vorausgefüllte Werte liefern denselben Wert wie das unveränderte Select.

Browser: In unterstützten Browsern erscheint die erweiterte Gestaltung. In anderen bleibt das Standardfeld vollständig nutzbar. Ohne CSS ist die Reihenfolge der Optionen weiterhin logisch.

Inhalt: Lange Texte, Übersetzungen, Sonderzeichen, viele Optionen und dynamisch geladene Werte brechen weder Layout noch Auswahl.

Bei React, Vue oder anderen UI-Frameworks lohnt außerdem ein echter Produktions-Build. Neue HTML-Strukturen werden von Werkzeugen nicht immer gleichzeitig unterstützt; ein Browser-Feature ist erst dann im Produkt angekommen, wenn auch Rendering, Hydration und Tests es sauber durchlassen.

Das zweite Safari-27-Detail: Scroll Anchoring

Safari 27 aktiviert außerdem Scroll Anchoring. Wenn oberhalb der aktuellen Leseposition verspätet Inhalt erscheint, versucht der Browser den sichtbaren Abschnitt stabil zu halten. Das reduziert den typischen Sprung, wenn Bilder, Hinweise oder asynchrone Komponenten nachladen.

Die beste Lösung bleibt, Platz früh zu reservieren: Bilder bekommen Breite und Höhe, Skeletons entsprechen ungefähr dem späteren Inhalt und Werbeflächen haben feste Grenzen. Scroll Anchoring ist ein Sicherheitsnetz, kein Ersatz für ein stabiles Layout.

overflow-anchor: none sollte deshalb nicht global abgeschaltet werden. Es gehört nur an konkrete Bereiche, in denen eine Anwendung absichtlich eine andere Position kontrolliert, etwa eine eigene Chat-Logik. Sonst entfernt man eine Browserhilfe, die Lesenden gerade Stabilität geben soll.

Unser Rollout-Plan in sieben Schritten

1. Ein bestehendes, problematisches Dropdown wählen — nicht sofort die ganze Komponentenbibliothek.
2. Native Semantik und Formulardaten wieder zur Quelle der Wahrheit machen.
3. Einen lesbaren Fallback ohne neue CSS-Funktionen sichern.
4. Die erweiterte Gestaltung als progressive Schicht hinzufügen.
5. Die vollständige Zustands- und Accessibility-Matrix prüfen.
6. Verhalten auf echten mobilen Geräten und mit langen Übersetzungen testen.
7. Nach dem Release Fehlerquote, Abbrüche und Support-Rückfragen beobachten.

Weniger Widget, mehr Produkt

Die spannendste Neuerung an anpassbaren Selects ist nicht, dass Dropdowns nun schöner aussehen können. Sie verschiebt die Grenze zwischen Browser und Produktteam an eine sinnvollere Stelle. Der Browser behält die schwierige Basis; das Team gestaltet Information, Hierarchie und Marke.

Genau so sollte moderne Frontend-Entwicklung funktionieren: native Fähigkeiten zuerst, progressive Verfeinerung darüber und JavaScript nur dort, wo es einen echten zusätzlichen Nutzen gibt.

Quellen

• WebKit Features in Safari 27.0
• The golden rule of customizable select
• MDN: Customizable select elements