Empty text

Usage

Overview

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.

When to use

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.

When not to use

Validation failures—show field-level errors and Banner summaries instead.
States that should prompt action—use helper text, Button, or Banner to guide next steps.
Secure fields—use Secret or masking patterns, not generic empty text.

Variants

Default label prop covers most cases; custom children only when the em dash default is semantically wrong for the domain.

Anatomy

Inline text with subdued color; should align with surrounding Text scale.

Content guidelines

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.

Behavior and states

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.

Best practices

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.

Accessibility

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.

Data list for label–value rows.
Table and Data table for grid contexts.
Banner when absence implies a problem users must fix.

Dynamic Importer / Accessibility

Empty text / API and Development

On this page

Empty text

Usage

Overview

When to use

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.

When not to use

Validation failures—show field-level errors and Banner summaries instead.
States that should prompt action—use helper text, Button, or Banner to guide next steps.
Secure fields—use Secret or masking patterns, not generic empty text.

Variants

Default label prop covers most cases; custom children only when the em dash default is semantically wrong for the domain.

Anatomy

Inline text with subdued color; should align with surrounding Text scale.

Content guidelines

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.

Behavior and states

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.

Best practices

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.

Accessibility

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.

Data list for label–value rows.
Table and Data table for grid contexts.
Banner when absence implies a problem users must fix.

Dynamic Importer / Accessibility

Empty text / API and Development

On this page