In a patient portal, why should a 1,000-character message to the care team use a multi-line text area, and how should its character counter behave?
answer
- box size signals answer size
- what the Enter key does
- remaining, not just used
- never truncate silently
- announce thresholds, not keystrokes
basics
~20 sA multi-line text area signals that sentences are expected, wraps text and lets Enter add a line. Its counter states the limit up front, shows what remains, flags and blocks over-limit text instead of cutting it, and announces only at thresholds.
solid answer
~50 sThe field's size tells people how much to write: a one-line box invites a few words, while a **multi-line text area** of several visible lines invites the symptoms and questions a care-team message needs. It wraps text so the whole message can be reread, and Enter inserts a new line instead of submitting. The **character counter** should state the limit before typing ('Up to 1,000 characters'), show what remains ('212 characters left'), and when the patient goes over, keep every character, say '48 characters too many' in text with a non-colour cue, and block sending. Silently cutting pasted text is the failure to avoid; in a clinical message the lost end may be the important part. For screen readers, tie the counter to the field so the limit is read on focus, and announce only at thresholds or after a pause, since a count per keystroke drowns out the typing.
go deeper
Know the cues for choosing a multi-line text area over a single-line field, and that a counter should show what remains and state the limit up front.
Explain soft limits versus hard stops, why silent truncation is dangerous, and how to announce a counter without flooding a screen reader.
Anticipate the production failures: client and server counting characters differently, growing areas hiding the send action on mobile, and limits nobody can justify.
Push back on arbitrary limits by tracing each one to a real downstream constraint, and make the counting unit a documented contract shared by every platform and service.
## Single-line field or multi-line text area A **single-line text field** holds a short value on one line; a **multi-line text area** holds free text that wraps across several lines. The choice is about the expected answer, not about what the database can store. | Cue | Single-line field | Multi-line text area | |---|---|---| | Expected answer | A name, an ID, a date, a short phrase | Sentences or paragraphs | | Enter key | Commonly submits the form | Inserts a new line | | Overflow | Scrolls sideways, hiding the start | Wraps, so the whole text is visible | | Visible size | One line, width hints length | Several lines, height hints length | | Review | Hard to reread a long value | Easy to reread and edit | The visible height is a signal. A three-line box for a care-team message says 'a few sentences'; a one-line box says 'a few words' and gets them. Many systems let the area grow with its content up to a maximum, or let the person resize it, so a long message is never read through a tiny scrolling window. In the patient portal, the message subject is a single-line field and the body is a text area. Both come from the same component family with the same label, helper and error slots, so a patient meets one anatomy whichever box they are in. ## Anatomy of a character counter A **character counter** is supplementary text, usually below the box and aligned to the end, that tracks the length of the value against a limit. - **State the limit up front** in helper text or the counter itself, so the patient plans before writing. - **Prefer remaining over used.** '212 characters left' answers the real question; '788/1000' makes people subtract. - **Choose when it appears.** Some systems show it always; others show it once the person nears the limit, often around the last fifth. That threshold is a convention, not a standard. - **Say the over-limit state in text.** '48 characters too many', with an error icon, not only a red number, because colour alone fails WCAG 2.2 1.4.1 Use of Color. ## Soft limit, not silent truncation There are two ways to enforce a limit, and one of them loses data. 1. **Hard stop.** Typing stops at the limit and pasted text is cut to fit. The person may never notice the end is gone. 2. **Soft limit.** The text is kept, the counter turns into an error, and sending is blocked until the person edits it down. For a patient pasting a symptom diary, a hard stop can silently drop the most recent, most relevant entries. The soft limit keeps the person in control of what to cut, which is why many systems prefer it for anything longer than a short code. ## Counters and screen readers A counter changes on every keystroke. If every change is announced, a screen-reader user hears numbers instead of their own typing. The usual pattern: - tie the counter text to the field programmatically, so the limit and remaining count are read when the field gets focus; - announce politely only at thresholds, such as 100 left, 20 left and over the limit, or after typing pauses; - announce the over-limit state as an error the person must act on. WCAG 2.2 **4.1.3 Status Messages** (level AA) covers messages about the existence of errors or results that appear without moving focus, so the over-limit warning should be available to assistive technology without the person having to hunt for it. The Understanding text also warns against making an interface too 'chatty', which is the case for throttling. ## Counting the way the server counts The counter and the server must agree on what a character is. Line breaks, emoji and some accented letters can count as more than one unit depending on how text is encoded, so a message the counter shows as 1,000 can be rejected as longer. Define the unit once in the spec, and have the server enforce the same one. ## Question the limit itself A limit should come from a real constraint: a downstream system, a clinical triage workflow, a fair-use rule. If none exists, a generous limit or none at all may serve patients better than a counter they must fight.
- Should a text area that grows with its content have a maximum height?Usually yes. Unlimited growth can push the send action and the rest of the form off screen, especially on a phone with the on-screen keyboard open. Growing to a sensible maximum, then scrolling inside, keeps the message readable and the surrounding actions reachable.
- Why might the character counter and the server disagree on a message's length?Because 'character' is ambiguous. Some emoji and combined accented letters are several code units, and a line break may be counted as one or two characters depending on how text is transmitted. If the counter counts one way and the server another, a message can pass the counter and still be rejected. The spec should define the unit and both sides should use it.
saying these in an interview costs you the question
- Cutting pasted text at the limit is fine because the counter shows the limit.
- A counter should announce the new count on every keystroke.
- The database column size decides whether a field is single-line or multi-line.
- A red counter number alone is enough to show the message is over the limit.
- A text area should stay a fixed small size and scroll internally to save space.