Dropdown oder Radiobutton? Das richtige Auswahlfeld

Ein Dropdown ist nicht automatisch besser als ein Radiobutton. Wenn die Auswahl klein ist und Menschen die Optionen vergleichen sollen, sind Radiobuttons meist klarer. Wenn die Liste länger ist oder der Platz knapp ist, gewinnt das Dropdown. Bei wichtigen Formularen zählt Sichtbarkeit oft mehr als Kompaktheit.

NNGroup beschreibt den Unterschied in Listboxes vs. Dropdown Lists sehr pragmatisch: kleine, gegenseitig ausschließende Optionen bleiben sichtbar, große Listen werden kompakter. Das passt auch zu Kanton Zürichs Dropdown-Auswahlfeld und zu der technischen Sicht auf das native <select>-Element.

Die kurze Faustregel

Nehmen Sie Radiobuttons, wenn Nutzerinnen und Nutzer zwischen wenigen klaren Optionen abwägen und den Unterschied direkt sehen sollen. Nehmen Sie Dropdowns, wenn die Liste länger ist, der Platz begrenzt ist oder eine native Auswahl auf Mobilgeräten den Ablauf einfacher macht.

Wenn eine Auswahl nur zwei Werte hat, ist ein Dropdown oft unnötig versteckte Arbeit. Wenn eine Auswahl 8, 15 oder 30 Einträge hat, wird ein Radiobutton-Set schnell zu breit, zu lang und zu schwer scannbar.

Radiobuttons halten kleine, feste Auswahlmengen sichtbar; Dropdowns bündeln längere Listen in ein Feld.

Wann Radiobuttons die bessere Wahl sind

Radiobuttons sind ideal für Entscheidungen, die Nutzer bewusst vergleichen wollen: Preisstufen, Versandarten, Abos, Liefergeschwindigkeiten oder andere kleine, mutually exclusive Sets. Sichtbarkeit senkt die mentale Last, weil der Zustand sofort klar ist.

Sie funktionieren auch gut, wenn Sie erklären müssen, warum eine Option teurer, langsamer oder eingeschränkt ist. Dann kann jede Option direkt mit einem kurzen Hilfetext ergänzt werden, ohne dass man erst ein Menü öffnen muss.

Wann Dropdowns die bessere Wahl sind

Dropdowns sind sinnvoll, wenn die Antwortmenge feststeht, aber zu lang für eine sichtbare Liste ist: Länder, Regionen, Branchen, Zeitfenster oder technische Werte. Sie helfen auch auf kleinen Bildschirmen, solange der Nutzer die Auswahl nicht ständig wechseln muss.

Für sehr große, bekannte Mengen ist ein Suchfeld oft besser als ein Dropdown. Kanton Zürich empfiehlt das native Auswahlfeld dort, wo eine geordnete Auswahl genügt; bei langen Listen lohnt sich oft ein anderer Interaktionsweg, weil Scrollen im Menü schnell zur Reibung wird.

Barrierefreiheit und Umsetzung

Aus technischer Sicht ist ein natives <select>-Element oft die beste Basis. Es bringt Tastaturbedienung, Fokusverhalten und Plattformkonventionen mit, die eigene Custom-Dropdowns erst zuverlässig nachbauen müssen. Wenn Sie visuell mehr Kontrolle brauchen, sollten Sie die Semantik trotzdem sauber erhalten.

Wichtiger als der Look ist der Entscheidungsfluss: ein eindeutiges Label, ein sinnvoller Default nur dort, wo er wirklich korrekt ist, keine versteckten Pflichtfelder und keine Auswahl, die erst nach mehreren Klicks verständlich wird.

Beschriftung, Fokus und Validierung sind Teil des Erlebnisses — nicht nur die Auswahl selbst.

Häufige Fehler

• Verwenden Sie keinen Dropdown für Ja/Nein, wenn zwei Radiobuttons schneller verständlich wären.

• Verstecken Sie keine kritische Auswahl hinter einem voreingestellten Wert, den niemand bemerkt.

• Bauen Sie keine Custom-Dropdowns ohne Tastatur, Fokus und klare Fehlermeldungen.

• Nutzen Sie Dropdowns nicht bloß, um Platz zu sparen, wenn die Entscheidung eigentlich sichtbar sein sollte.

• Wenn Nutzer mehrere Werte auswählen müssen, ist weder das klassische Dropdown noch das klassische Radiobutton-Set die richtige Lösung; dann sind Checklisten, Tags oder eine Suche oft die bessere Architektur.

Die beste Wahl ist selten das auffälligste UI-Muster. Meist ist es das Formularfeld, das die Entscheidung sichtbar macht, die Bearbeitung nicht verlangsamt und auf Desktop wie Mobile verlässlich funktioniert.