EmptyText standardizes how missing or inapplicable values read (“Not provided”, “—”) so interfaces do not look broken when data is legitimately absent. It improves screen reader rotor clarity and visual consistency across dispatch tables and detail panes.
- Optional profile fields, incident attributes, or integration settings that may be blank.
- Table cells where null database values are common and not errors.
- Read-only summaries where showing nothing would look like a layout bug.
- Validation failures—show field-level errors and
Callout summaries instead.
- States that should prompt action—use helper text,
Button, or Callout to guide next steps.
- Secure fields—use Secret or masking patterns, not generic empty text.
Default label prop covers most cases; custom children only when the em dash default is semantically wrong for the domain.
Inline text with subdued color; should align with surrounding CoreText scale.
- Keep
label strings short and meaningful in screen readers (“No dispatch center”, “Not provided”); use formatMessage.
- Avoid humorous or flippant placeholders in emergency operations products unless brand explicitly allows.
- Empty text is not interactive; if the cell should be clickable to add data, use a
Button or link styled per patterns—not fake empty text.
- Do use one canonical phrase per concept across a surface (don’t mix “N/A”, “—”, and “None”).
- Do test rotor / VoiceOver announcements for tables with many empty cells—avoid noisy repetition if possible via row semantics.
- Don’t use empty text to hide loading—use skeletons or spinners.
- Don’t use empty text for zeros that are meaningful—show
0 with proper numeric formatting.
- Ensure the visible placeholder has sufficient contrast in both themes.
- If the empty state conveys status, expose that in the cell’s accessible name for tables.
