Character count

Problem Context

• A legal, editorial, messaging, database, moderation, or downstream-display rule imposes a maximum number of characters or words.
• Users may paste text from another source and need to know whether the full draft fits before submitting.
• The product can validate the same unit it displays and can preserve the draft even when it exceeds the limit.
• Assistive technology users need the limit and count status without disruptive announcements on every keypress.
• If many users hit the backend limit, the product may need a higher limit or redesigned storage rather than count pressure.

Selection Rules

• Choose character count when the limit is real, useful to users, and enforceable in the same unit displayed by the interface.
• Use word count when policy or review standards are expressed in words, not when the server actually enforces characters.
• Use a textarea without count when users need paragraph entry but limits are absent, extremely high, or unlikely to affect real submissions.
• Use text input without count when the expected value is short enough that length is already apparent from the field type or format.
• Use inline validation for length errors that do not require continuous awareness while typing.
• Escalate backend constraints when users regularly exceed a service-imposed limit; do not make the counter compensate for a bad limit.
• Show a static maximum message when JavaScript is unavailable.
• Do not silently truncate pasted or typed content; preserve the draft and explain the exact reduction needed.

Required States

• Empty state with visible label, hint, and static maximum message.
• Typing state before threshold where the limit remains available but does not create urgency.
• Near-limit state showing remaining characters or words.
• At-limit state explaining that no characters or words remain.
• Over-limit state with error styling and exact amount over the limit.
• Trimmed recovery state after the user edits or accepts a trim action.
• Submitted valid state with accepted count and unit.
• No-JavaScript fallback state with a visible maximum message.
• Word-count mode when the actual constraint is word-based.
• Assistive announcement state that avoids excessive live updates.

Interaction Contract

• The field accepts typing and paste normally; the counter observes length rather than blocking editing prematurely.
• The count message uses the same character or word unit as validation and submitted payload checks.
• Before the warning threshold, the interface keeps the maximum visible without repeatedly announcing remaining amounts.
• When the remaining amount crosses the threshold, the count changes to a warning message near the field.
• When the user exceeds the limit, the field keeps the full draft and shows exactly how many characters or words must be removed.
• A trim or edit action is explicit and reversible through normal undo instead of automatic truncation.
• Errors, hints, and count messages are associated with the input or textarea through a shared description.

Implementation Checklist

• Define the enforced unit, maximum, warning threshold, validation rule, fallback message, and server-side normalization before adding the counter.
• Associate label, hint, count message, and error text with the field using stable ids and descriptions.
• Use maxlength only when blocking additional input is acceptable; otherwise allow over-limit drafts and validate with a specific recovery message.
• Implement pluralized messages for remaining, at-limit, and over-limit states in character and word modes.
• Throttle or delay assistive announcements so users are not interrupted on every keystroke.
• Keep count, error, and submitted payload checks aligned with server validation for Unicode, whitespace, pasted text, and line breaks.
• Test no-JavaScript fallback, paste over limit, screen readers, mobile keyboards, zoom, translated strings, and server-returned length errors.

Common Generated-UI Mistakes

• Adding a counter to an unrestricted writing field because it looks informative.
• Using a character counter when the server counts bytes, normalized characters, words, or rich-text markup.
• Hiding the limit until after submit.
• Interrupting screen reader users with a live count after every keypress.
• Silently truncating pasted text at the maximum length.
• Using a low backend limit as a reason to pressure users instead of increasing the limit.
• Showing remaining count in one place and a different maximum in validation.
• Letting the counter replace specific required, too-short, or disallowed-content errors.

Critique Questions

• Is there a real acceptance limit, and is it expressed in characters or words?
• Would most users ever approach the limit, or is the counter just adding pressure?
• Does server validation count the same text that the interface counts?
• What happens when users paste text that is far over the limit?
• Are count messages associated with the field without noisy announcements?
• Should the service increase the backend limit instead of exposing it to users?