Ein Button federt beim Klick nach, ein Schieberegler dehnt sich wie Gummi: Die Web-Components-Bibliothek Jelly UI verpasst HTML-Formularelementen eine weiche Physik. Der Effekt wirkt verspielt, doch für Unternehmen steckt darunter eine handfeste Frage nach Barrierefreiheit und Performance.
drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügenJelly UI stammt vom Studio bmson, bündelt 40 fertige Custom Elements und lässt sich mit einem einzigen Script-Tag einbinden.[1] Die Bibliothek ist quelloffen unter MIT-Lizenz und kommt ohne externe Abhängigkeiten aus. Genau diese Leichtigkeit ist der Reiz, und genau hier beginnt die Diskussion.
Das Wichtigste in Kürze
- Jelly UI bringt Soft-Body-Physik auf Buttons, Slider und Eingabefelder, als quelloffene Web Components.
- 40 Custom Elements, null Abhängigkeiten, Einbindung über ein Script-Tag.
- Der Knackpunkt: Nachgebaute Bedienelemente müssen Tastatursteuerung und Screenreader-Rollen selbst mitbringen, die native Elemente gratis liefern.
- Seit dem 28. Juni 2025 verlangt das Barrierefreiheitsstärkungsgesetz für viele Websites WCAG 2.1 AA.
Was steckt in Jelly UI?
Jelly UI ist eine quelloffene Web-Components-Bibliothek, die Standard-Formularelemente um Feder- und Verformungs-Animationen ergänzt: 40 Elemente, keine Abhängigkeiten, Einbindung per Script-Tag.
Die Idee ist eine haptische Anmutung: Elemente reagieren auf Klicks und Ziehen mit weichen, elastischen Bewegungen. Dark Mode, Rechts-nach-links-Sprachen und WCAG-AA-Farbkontraste sind bereits eingebaut.
Physik in der Oberfläche hat Tradition. Schon Compiz hat Anfang der 2000er Fenster wackeln lassen, und Apples aktuelle Systeme setzen stark auf Feder-Animationen. Neu ist, dass der Effekt hier direkt auf den Bausteinen von Formularen sitzt.
Sind das wirklich native Formularelemente?
Nur bedingt. Jelly UI ersetzt Standard-Elemente durch eigene Custom Elements. Native Bausteine wie Button oder Eingabefeld liefern Tastaturbedienung, Fokus und Screenreader-Rollen automatisch, ein Nachbau muss all das selbst nachliefern.
Darin liegt der eigentliche Mechanismus. Ein natives Eingabefeld ist nicht nur ein Aussehen, sondern ein Vertrag: Der Browser garantiert Fokus, Beschriftung und eine maschinenlesbare Rolle. Als gestyltes Div nachgebaut, gehen diese Garantien verloren, solange die Bibliothek sie nicht über ARIA und Fokus-Logik wiederherstellt.
Dazu kommt die Performance. Weiche Physik entsteht durch fortlaufende Neuberechnung im Browser, und jede Animation kostet Zeit im Frame-Budget. Bei knappen Core Web Vitals kann eine dauernd rechnende Oberfläche die Interaktionslatenz verschlechtern, also den Wert, den Google als INP misst. Vieles davon lässt sich heute mit modernem CSS ohne JavaScript umsetzen.
Verspielte Oberflächen sind erlaubt, solange sie die eingebauten Garantien nativer Elemente nicht opfern. Ein Button, der schön nachsackt, aber die Tastatur ignoriert, ist 2026 kein Designdetail mehr, sondern ein Rechtsrisiko.
— Markus Seyfferth, Chefredakteur Dr. Web
Seit 28. Juni 2025 verlangt das Barrierefreiheitsstärkungsgesetz für viele Websites WCAG 2.1 AA. Native Formularelemente liefern Tastaturbedienung und Screenreader-Rollen von Haus aus, Nachbauten müssen beides erst nachrüsten.
Was bedeutet das für Betreiber im DACH-Raum?
Seit dem 28. Juni 2025 müssen viele Websites barrierefrei sein, Maßstab ist WCAG 2.1 AA. Ausgetauschte Formularelemente müssen ihre Bedienbarkeit lückenlos nachbauen, sonst drohen Nachbesserung und Bußgeld.
Das Barrierefreiheitsstärkungsgesetz setzt eine EU-Richtlinie um und greift vor allem für Onlineshops, Banken, Verkehr und Telekommunikation. Der technische Maßstab ist die Norm EN 301 549, die auf WCAG 2.1 in den Stufen A und AA verweist. Tastaturbedienbarkeit und korrekte Rollen sind dort schon auf Stufe A Pflicht.
Kleinstunternehmen mit unter zehn Beschäftigten und weniger als zwei Millionen Euro Umsatz bleiben ausgenommen. Für alle anderen gilt: Jelly UI darf zum Einsatz kommen, aber jedes verbaute Element gehört mit Tastatur und Screenreader geprüft und auf schmalen Viewports im Responsive Design getestet.
Jelly UI ist ein charmantes Experiment und ein guter Anlass, die eigene Formularlandschaft zu prüfen. Der Rat für Entscheider: den Effekt gern testen, im Zweifel die Prüfung an eine erfahrene Webdesign-Agentur geben, aber jede Interaktion vorher gegen die WCAG-Kriterien halten, statt Optik über Bedienbarkeit zu stellen.
Quelle
[1] Jelly UI (bmson): „Jelly UI — Soft Web Components“
Mehr Newshunger?
- Braucht es 2026 noch HTML-Templates? 30 Quellen und die überraschende Antwort
- Modernes CSS 2026: Was ersetzt JavaScript jetzt?
- 3 Core Web Vitals, die Google liebt, und wie Sie sie verbessern
- Braucht es für Responsive Design noch Media Queries in 2026?
- Webdesign Agentur finden für 2026: Vergleich und Checkliste
