Skip to content
Style Guide
v0.1.0

Components

Alerts

Page-level messages about something that has happened or is about to. Four statuses, each carried by an icon, a title and an accent bar — never by colour on its own.

The four statuses

Schedule saved

Morning lights will run on weekdays from tomorrow.

Window sensor battery is low

About two weeks of charge left. Replace the battery to keep alerts working.

Scheduled maintenance on 12 September

The app will be unavailable between 02:00 and 04:00.

Alerts
StatusClassMeansRole
Success--successSomething the person asked for has completed.status
Warning--warningStill working, but it needs attention soon.status
Error--errorSomething failed, or is blocked until they act.alert
Information--infoContext that is useful but requires nothing.note
NeutralnoneA quiet notice with no status meaning.note

Three signals, not one

Every alert carries its meaning three ways: the icon, the title, and the accent bar on the inline-start edge. The colour is the fourth, and the least important.

This is not only about colour blindness. Tomatico's palette is monochrome, so a screen may legitimately be rendered without hue at all, and a printed report certainly is. An alert that only works in colour does not work.

The icon is aria-hidden — it repeats what the title already says, and announcing "check mark" before the message adds nothing.

Announcing alerts

An alert that appears after an action has to reach someone who cannot see it appear. The ARIA role decides how urgently it is announced.

  • role="alert" interrupts whatever the screen reader is saying. Reserve it for errors and for anything the person must act on now.
  • role="status" waits for a pause. Right for confirmations and warnings.
  • role="note" is not announced at all. Right for anything present when the page loads.
The container has to exist before the message does. A live region added to the page at the same moment as its text is usually not announced. Render the empty alert container up front and inject the text into it — or, more simply, keep a single permanent live region on the page and write messages into it.

Dismissible alerts

Only a message a person has finished with should be dismissible. Errors that block a task stay until the task is fixed.

Device added

"Hallway lamp" is now in your Living room group.

Dismissible

When an alert is dismissed, move focus somewhere sensible — usually the element that triggered the action. Focus left on a removed element falls back to the document, and the person loses their place.

Do not dismiss alerts on a timer. Someone reading with a magnifier, or in their second language, may not have finished.

Placement

  • Page-level messages go at the top of the main content, below the heading. Not above the masthead.
  • Form errors go in a summary at the top of the form and again beside each field. See Form validation.
  • Field-level messages are not alerts — use .tmt-error-text.
  • One alert at a time. A stack of four is a screen nobody reads.

Writing them

The title states what happened, in one line, with no full stop. The body says what it means and what to do next.

Write

  • "We could not reach the front door lock" — then how to fix it.
  • "Window sensor battery is low" — then how long is left.
  • "Schedule saved" — then what will happen because of it.

Not

  • "Error!" or "Warning:" as a title.
  • "Something went wrong. Please try again later."
  • "Success!"
  • A raw error code with no explanation.