Date Input aufgeteilt in 3 Nummernfelder statt natives Input Feld

[BF150]

Diskussion aufgeteiltes vs natives Date Input

aufgeteilt

pro	contra
klareres Design	Eingabe nicht begrenzt auf auf 2 Ziffern bei Tag/Monat/Jahr
geführte Eingabe - Man kann Tag und Monat nicht verwechseln	Man kann nicht durchgehend ein Datum eingeben
freies Styling	Man kann nicht durchgehend ein Datum eingeben
Screenreader liest klar die einzelnen Datumselemente vor	Komponente hat mehrere fokussierbare Elemente
	Touch devices geben einzelne Zahlen an statt nativer Picker
	Internationalisierung muss manuell implementiert werden statt Browser Sprache
	manuelle Validierung der Einzelfelder
	Datumsobjekt muss zusammen geführt werden
	Mauseingabe umständlich
	Nur Eingabe Datum ohne Zeit oder andere Typen (nur Monat,...)
	3x tap statt 1x

nativ

pro	contra
folgt
Screenreader?

[deleonio]

Analyse: Aufgeteiltes vs. natives Date Input

Strategische Aspekte

Aufgeteiltes Datum (Tag / Monat / Jahr separat)

• Wartung:

  • Eigene Validierung, Maskierung, i18n-Logik müssen dauerhaft gepflegt werden.
  • Ständige Verantwortung bei uns, neue Edge Cases (Schaltjahre, kulturelle Formate) selbst zu lösen.

• Abhängigkeit:

  • Keine direkte Browserabhängigkeit, aber hohe interne Code-Abhängigkeit → wir werden selbst zum „Mini-Browser-Hersteller“.

• Verantwortung:

  • Alle Accessibility- und UX-Probleme liegen in unserer Verantwortung.
  • Risiko: wir schaffen eine „Sonderlösung“, die später gegen Standard läuft.

• Nachhaltigkeit:

  • Schwer zu skalieren → z. B. Zeit, Monat, Woche → müssten alles nachbauen.

Native <input type="date">

• Wartung:

  • Validierung, Locale-Anzeige, Picker-Verhalten werden vom Browser übernommen.
  • Unser Aufwand minimal, wir pflegen nur API/Wrapper.

• Abhängigkeit:

  • Wir sind abhängig von Browser/OS-Umsetzung. In manchen Fällen (z. B. Firefox Desktop) unvollständig.

• Verantwortung:

  • Wir können auf Standards verweisen: Barrierefreiheit ist primär Aufgabe der Browser/AT-Hersteller.
  • Wir müssen nur Fallbacks bereitstellen.

• Nachhaltigkeit:

  • Standards entwickeln sich weiter → unsere Lösung profitiert automatisch von Verbesserungen in Browsern/OS.

---

Empfehlung

👉 Strategisch ist das native Date-Input die nachhaltigere Wahl.

• Warum?

  • Es verschiebt Verantwortung dorthin, wo sie hingehört: Browser & OS.
  • Es reduziert unseren Wartungsaufwand massiv.
  • Es hält uns kompatibel zu internationalen Standards und zukünftigen Verbesserungen.
  • Es macht Barrierefreiheit konsistenter, weil Screenreader & OS-UX direkt angebunden sind.

• Was tun mit den Schwächen?

  • Fallback-Strategie definieren:

    • Mobile → immer native, weil dort UX top ist.
    • Desktop, wenn der Browser keinen Picker rendert (Firefox):
      → Fallback = ein einfaches Textfeld mit Maskierung (aber nicht die volle 3-Teilung).

  • Optional ein Custom-Picker zusätzlich anbieten (Button „Datum auswählen“), aber nicht als Ersatz, sondern als Ergänzung.

---

Klare Linie für KoliBri

• Primär: type="date" (Standard-Input).
• Fallback: kontrolliertes Textfeld (z. B. mit Maskierung DD.MM.YYYY).
• Kein eigener 3-Felder-Ansatz mehr – nur noch als „legacy pattern“ dokumentieren, aber nicht weiterentwickeln.
• Verantwortung klar: Accessibility-Probleme primär bei Browsern, nicht bei uns. Wir melden Bugs upstream statt Krücken einzubauen.

---

➡️ Empfehlung: KoliBri sollte auf das native Date Input setzen, Fallbacks schlank halten und die Verantwortung für Barrierefreiheit bewusst bei den Plattformherstellern belassen.