USWDS Components: Date Picker, Memorable Date, Character Count, Input Mask, Text Input, Validation
Six component-documentation pages from the U.S. Web Design System covering specific form-input patterns.
License: CC0 1.0 Universal (public domain) — https://creativecommons.org/publicdomain/zero/1.0/
Key points
- Date Picker vs. Memorable Date: USWDS splits date entry into two distinct components depending on what the date means to the customer. The Date Picker (a calendar overlay paired with a text field) suits scheduling scenarios where the day of week or surrounding calendar context matters. The Memorable Date component (separate day/month/year text fields, no calendar) suits dates the customer already knows by heart, like a birthdate, where a calendar adds friction without adding value. Whichever is offered, USWDS’s own usability testing found some customers consistently prefer typing over the calendar UI, so manual entry must always remain available even when a picker is the default.
- Character Count: a live counter of remaining characters, reserved for fields with a genuine reason to cap length (a legal limit, or a UI needing brevity) — not for fields where the limit is essentially never reached, or where the limit is a backend constraint rather than something the customer’s own writing runs into. The counter should be programmatically associated with its input (
aria-describedby) so a screen reader announces it, with a brief pause before announcing to avoid interrupting typing; USWDS notes screen reader users still have some trouble noticing when they’ve gone over the limit, an open usability concern rather than a solved problem. - Input Mask: a pattern that constrains typing in real time toward one fixed, well-known format (a Social Security number, a phone number, a ZIP code) via placeholder punctuation and auto-advancing segments. Suited only to rigid, predictable formats — not free-form fields or patterns too complex to mask cleanly (an email address). The documented downside: masked fields give little feedback about what went wrong when an error does occur, making recovery harder than with an unmasked field; USWDS recommends delaying any validation styling until after the customer has actually finished with the field.
- Text Input: validation messages/styling should appear only after a customer has interacted with a given field, not before. Placeholder text is discouraged as a hint mechanism — it disappears once typing starts, and is a bigger loss for customers with cognitive or visual disabilities who rely on it staying visible. A field’s own width is itself a hint: a short field suggests a short answer, a textarea signals a longer one is expected.
- Validation: USWDS built and has since deprecated a live-validation component (a requirements checklist, like password rules, updating in real time as the customer typed) after testing found screen reader and screen-magnification users often didn’t notice the status change, and other users were confused about what the live checklist was for. The component will be removed in a future release with no direct replacement documented — a concrete, tested case for validating on submit rather than live, not just a theoretical preference. See Error Messages.