Benutzerdefinierte Eingabekomponente

Was ist eine benutzerdefinierte Eingabekomponente?

Eine benutzerdefinierte Eingabekomponente ist ein Formularelement, das Sie selbst bauen, statt das native des Browsers zu verwenden: eine Datumsbereichsauswahl, ein Tag-Feld, eine Combobox, ein maskiertes Telefonfeld oder ein gestalteter Slider. Für Nutzer soll sie sich wie ein Eingabefeld anfühlen, und im Code soll sie wie eines am Formular teilnehmen: mit Namen, Wert, Label, Validierung und Tastaturbedienung. Fehlt eines davon, ist es ein Widget, das wie ein Eingabefeld aussieht, aber keines ist.

Erst nativ, nur im Notfall eigen

MDN listet viele native Eingabetypen: text, email, url, tel, number, range, date, time, datetime-local, month, week, color und file, dazu die Attribute inputmode, autocomplete, required, pattern sowie min/max. Sie liefern Tastaturverhalten, mobile Tastaturen, Autofill und Validierung gratis. Der W3C ARIA Authoring Practices Guide benennt die Kosten der Alternative deutlich: Anders als HTML-Eingabefelder geben ARIA-Rollen dem Browser weder Tastaturverhalten noch Gestaltung vor, Sie müssen alles selbst bauen, und „kein ARIA ist besser als schlechtes ARIA“. Bauen Sie eine eigene Komponente nur, wenn kein natives Element die Aufgabe erfüllt, etwa bei einer durchsuchbaren Combobox oder einem Mehrfachwert-Feld.

So bauen Sie eine, die funktioniert

• Beginnen Sie, wo möglich, mit einem nativen Element. Ein gestalteter Wrapper um ein echtes <input> oder <select> erhält das meiste Verhalten.
• Folgen Sie dem APG-Muster für Ihr Widget (Combobox, Listbox, Slider usw.). Es legt Rollen, Zustände und Tasten fest, die Nutzer erwarten. Eine Rolle ist ein Versprechen: Wer role="combobox" setzt, muss liefern, was die Rolle verspricht.
• Geben Sie ihr ein sichtbares Label, das mit dem Element verknüpft ist, und nutzen Sie den Platzhalter nicht als Label. Laut MDN verschwindet er beim Tippen und wird nicht zuverlässig vorgelesen.
• Machen Sie sie per Tastatur bedienbar, mit sinnvoller Fokusreihenfolge, sichtbarem Fokusstil und den Tasten, die das Muster vorsieht. Testen Sie ohne Maus.
• Machen Sie den Zustand mit ARIA sichtbar, wo native Semantik fehlt: Name, Rolle, aufgeklappt, ungültig, erforderlich.
• Binden Sie sie ins Formular ein. Eine Web Component kann formularassoziiert sein: static formAssociated = true setzen, attachInternals() aufrufen, dann mit setFormValue() den übermittelten Wert und mit setValidity() die Constraint-Validierung setzen. Dasselbe ElementInternals-Objekt kann Standardrolle und ARIA-Eigenschaften setzen. MDN führt es seit März 2023 als in allen Browsern weit verfügbar. Ohne das wird der Wert Ihrer Komponente nicht mit dem Formular gesendet.
• Behalten Sie den nativen Fallback. Fällt JavaScript aus, sollte ein einfaches Eingabefeld weiter funktionieren.

Häufige Fehler

• Ein <div> mit Klick-Handler, aber ohne Rolle, Label oder Tastaturunterstützung.
• Ein natives Element (Datumsfeld, Dateiauswahl) nachbauen und dabei weniger barrierefrei sein als der Browser.
• Validierung nur über Farbe zeigen oder mit einer Fehlermeldung, die Screenreader nie vorlesen.
• Einfügen, Autofill, Rückgängig oder Textauswahl durch eine aggressive Eingabemaske kaputt machen.
• Nur in einem Browser und ohne Hilfstechnologie testen. Der APG selbst verlangt, jede Kombination aus Browser und Hilfstechnologie vor dem Produktiveinsatz zu testen.

Eigene Eingabefelder, Standards und Monitoring

Eigene Eingabefelder berühren die Web Content Accessibility Guidelines (WCAG) unmittelbar: Labels, Tastaturzugang und Fehlerkennzeichnung gehören dazu und prägen die gesamte User Experience. Ein Rich-Text-Editor ist ein häufiges Beispiel und eines der schwersten, barrierefrei zu machen. Schwerer Widget-Code kostet außerdem Geschwindigkeit. Das Page Speed Monitoring von LoadFocus führt geplante Lighthouse-Audits aus, einschließlich der Kategorie Barrierefreiheit und der Core Web Vitals, sodass ein langsames oder beanstandetes Formular nach einem Release auffällt. Automatische Prüfungen erkennen nur einen Teil der Probleme, deshalb bleiben manuelle Tests mit Tastatur und Screenreader nötig.

Häufige Fragen zu Eingabekomponenten

Wann nehme ich ein eigenes statt eines nativen Felds?

Wenn kein natives Element passt, etwa bei einer durchsuchbaren Combobox, einem Tag-Feld oder einem Datumsbereich. Für Text, Zahlen, Datum, Farben und Dateien ist ein natives Feld barrierefreier und günstiger zu pflegen.

Werden eigene Felder mit dem Formular gesendet?

Nur, wenn sie angebunden sind. Ein formularassoziiertes Custom Element mit ElementInternals kann Übermittlungswert und Validität setzen. Andernfalls halten Sie ein verstecktes natives Feld synchron oder senden den Wert selbst.

Brauche ich immer ARIA?

Nein. Ein Element auf Basis eines echten Eingabefelds braucht wenig oder keines. ARIA füllt semantische Lücken in eigenen Widgets, und falsches ARIA ist schlimmer als keines.

Wie teste ich ein eigenes Feld auf Barrierefreiheit?

Bedienen Sie es nur mit der Tastatur, prüfen Sie, ob ein Screenreader Label und Zustand ansagt, und führen Sie ein automatisches Audit aus. Testen Sie danach mit den Browsern und Hilfstechnologien, die Ihre Nutzer wirklich verwenden.