Aktuelle Umsetzung:

<span class="counter" aria-atomic="true" aria-live="polite" data-testid="input-counter">
    46 
    <span>
        characters
    </span>
</span>

Das Gov.uk hat hier ein sehr schöne Seite dazu, die bereits auf Recherche und User-Testing basiert: https://design-system.service.gov.uk/components/character-count/

Ich habe für uns abgeleitet:

Fragen:

• Welchen Zweck erfüllt ein reiner Counter, ohne Limit? Ist das ein notwendiges Feature in KoliBri?

Empfehlungen:

• Der Text sollte überarbeitet werden: "8 von 10 Zeichen" könnte implizieren, dass 10 Zeichen notwendig sind. Besser: "Noch 2 Zeichen verfügbar.".
• Das Limit (o.g. Text) sollte vorgelesen werden, wenn der Nutzende aufgehört hat zu tippen (Debounce, wie durch Christian empfohlen).
• Das Limit sollte schon vor der Eingabe über ein zusätzliches aria-describedby-Feld kommuniziert werden ("Es können bis zu 200 Zeichen eingegeben werden.").
• Bessere Beispiele in der Sample App: Die Best Practice-Empfehlung sollte eine Textarea ohne maxlength, aber mit Zeichenlimit im Counter und entsprechender Validierung sein. So können auch längere Text reinkopiert und anschließend gekürzt werden.

@cbraehmig @laske185 @deleonio
Schonmal vorab zur Info. Wir können die konkreten nächsten Schritte gerne im nächsten Daily oder Planning besprechen.

Ich finde die Vorschläge gut. Ein reiner Counter macht keinen Sinn, bzw. mir fehlt dazu ein valider Use-Case.

Für eine Beschränkung ist das Feature nützlich. Es sollte sich dann so verhalten, wie beim oben genannten Beispiel:

Umsetzungsplan bzw. Vorschlag:

• V3
  • _has-counter für alle Komponenten entfernen. Für kol-input-x ersatzlos.
  • _character-limit für kol-textarea einführen. Setzt das beschriebene Verhalten um und funktioniert unabhängig von _max-length.
• V2
  • _has-counter wird aus Kompatibilitätsgründen beibehalten.
  • tbd: Ist das neue Feature _character-limit für V2 notwendig oder kommt es nur in V3?
    • Falls notwendig: Umsetzen analog V3, es darf nur entweder _character-limit ODER _has-counter gesetzt sein.
    • Falls nicht notwendig: Counter bleibt konzeptionell wie er ist, aber das Screenreader Announcement wird throttled.

@cbraehmig - bitte den PR nachtesten - dazu einfach den Netifly-Link im PR öffnen: #7707

@cbraehmig - bitte den PR nachtesten - dazu einfach den Netifly-Link im PR öffnen: #7707

V2 steht jetzt ebenfalls bereit: #7727
Hier habe ich nur den alternativen Text mit Debounce ergänzt, damit es keinen Breaking Change gibt. Die visuelle Darstellung bleibt also die gleiche wie vorher.