You press Save.
A small line appears:
Saved.
You add an item to a cart.
5 items.
You begin an upload.
Uploading… 62%.
You submit a form.
Your application was submitted.
You do not press anything.
Your phone lights up.
Your lesson starts in 30 minutes.
These are all relatives in the same family.
They are English sent because the system believes the reader needs to know that something is now different.
A notification is a sentence attached to a state change.
That makes notification English unusually demanding.
The system must decide:
What changed?
Does the reader need to know?
Do they need to know now?
Should the message interrupt them?
What is the smallest amount of language that restores an accurate model of the current state?
Quick Read
One-sentence answer: a notification works when English makes an important state change visible at the right time, with enough context to tell the reader what happened and what matters next, while consuming no more attention than the change deserves.
A useful notification often carries several elements:
- change: what is different now;
- object: what the change affects;
- status: success, failure, progress, waiting, completion or new information;
- time: when the change occurred or when it will matter;
- importance: whether immediate attention is justified;
- next action: what the reader can or should do, if anything;
- persistence: whether the message can disappear safely or needs a durable record.
W3C’s accessibility guidance gives one precise subset of this wider family: the status message. W3C defines status messages as content changes that report the success or results of an action, the waiting state of an application, the progress of a process or the existence of errors without changing the user’s context. The goal is to make important changes perceivable—including to screen-reader users—without unnecessarily interrupting the user’s work.
That balance is the central problem of notifications:
Make the change noticeable enough to matter.
Do not make every change important enough to interrupt.
The Notification Is Not the Warning
A warning tries to alter behaviour before a possible bad outcome.
Wet floor. Walk carefully.
A notification usually reports or announces a state that already exists or is about to matter.
Your train is delayed by 15 minutes.
The genres can overlap.
A weather notification may contain a warning.
A security notification may say that suspicious activity has been detected and urge immediate action.
But their primary temporal orientation differs.
Warning:
Possible harmful future → change behaviour now.
Notification:
Changed present state → update your model now.
The Notification Is Not the Error Message Either
An error message explains a failure and often supports recovery.
The file is larger than 20 MB. Choose a smaller file and try again.
A notification may simply announce the existence or count of errors:
5 errors on page.
W3C uses this exact kind of message as a status-message example.
The detailed error belongs near the field.
The notification updates the reader’s overview:
The form is not yet valid, and there are five places requiring attention.
These layers can cooperate without being identical.
Success Needs a Receipt
You press Submit.
If the page remains visually unchanged, uncertainty begins immediately.
Did it work?
Should I press again?
Did the connection fail?
Was my work saved?
W3C specifically gives:
Your form was successfully submitted.
as an example of a status message.
The sentence closes an action loop.
intention → action → system event → notification → certainty
This is why confirmation is not decorative.
It prevents the human from remaining in the old state model after the system has changed.
Progress Messages Explain Time That Has Not Finished Yet
Some operations take long enough that silence becomes alarming.
Uploading a large file.
Installing software.
Generating a report.
Processing a payment.
The system has started but not finished.
A progress notification tells the reader:
The process is alive.
W3C includes dynamic progress bars and announcements of upgrade progress as status-message examples.
Useful progress language may include:
- Uploading…
- 62% complete
- 3 of 8 files processed
- About 2 minutes remaining
- Waiting for payment confirmation
Each sentence repairs a different uncertainty.
Has it started?
How far has it gone?
How much remains?
What is it waiting for?
Progress English turns invisible machine time into human time.
Waiting States Need End States
A message appears:
System busy.
Then it disappears.
A sighted user may infer that the system is ready because the busy indicator vanished.
W3C notes that this disappearance may not be obvious to a non-sighted user and recommends communicating the end of the waiting state where needed—for example, with a message such as system available.
This is a subtle but important language lesson.
Absence can communicate visually.
It may not communicate across modalities.
If the end state matters, sometimes it needs its own words.
Counts Need Context
A badge changes:
3
Three what?
Unread messages?
Errors?
Items in cart?
Missed calls?
Visual proximity may provide context to sighted users.
W3C specifically warns that if only a number changes and is announced, a screen-reader user may hear merely “three,” which is insufficient. Announcing the fuller phrase—3 items in shopping cart—restores context.
This is referential completeness.
Numbers are compact.
They still need a noun when the noun is not otherwise available to the receiver.
A Notification Competes with Whatever the Reader Was Already Doing
This is the central ethical problem.
Every interruption has a cost.
The reader may be:
- writing;
- reading;
- driving;
- teaching;
- thinking;
- sleeping;
- speaking to another person.
A notification asks attention to leave that task and come here.
Therefore notification design is partly a question of proportionality.
How much attention does this state change deserve?
A successful save may need a quiet inline message.
A security breach may need an urgent alert.
A new promotional offer may deserve no interruption at all.
W3C’s status-message guidance embodies the same restraint: important content changes can be announced without necessarily taking focus or changing context, because taking focus itself is an interruption.
Not Every Update Deserves an Alert
Imagine an application announcing:
- Cursor moved.
- Autosaved.
- Autosaved again.
- Word count changed.
- Connection stable.
- Autosaved again.
The information may all be true.
The user experience is unbearable.
W3C warns that live regions and alerts can make applications too “chatty” for screen-reader users and recommends user testing to find an appropriate level of feedback.
This is a general writing lesson:
Relevance is not enough.
The message must also earn its interruption.
Notification fatigue is what happens when the system spends attention too freely.
Priority Needs a Vocabulary
Notifications range from quiet to urgent.
A mature system may distinguish:
- informational update;
- success confirmation;
- progress update;
- reminder;
- warning;
- critical alert.
The words, sound, placement and persistence should reflect that hierarchy.
If a sale promotion uses the same sound and visual urgency as a security alert, the system damages its own scale.
This is the same calibration problem we saw in warning English.
Strong signals remain meaningful only when reserved for strong events.
The Subject Line Must Survive the Lock Screen
Push notifications often appear outside the application that generated them.
The user may see only a title and one line.
That means the notification must carry enough context to stand alone.
Weak:
Update available
Update to what?
Better:
Class schedule changed
Saturday’s Secondary 2 English lesson now starts at 3:30 pm.
The title names the changed object.
The body gives the new state.
This is similar to out-of-context link writing.
When the surrounding interface disappears, the message needs more self-contained English.
Relative Time Decays
A notification says:
Your application was approved yesterday.
That makes sense at the moment of delivery.
If the notification is stored in a history log and read three weeks later, yesterday becomes misleading unless the system re-renders relative time dynamically.
Durable notifications may need absolute timestamps.
This is where Notification meets Timestamp.
Short-lived attention messages can use relative time naturally.
Persistent records need stable temporal coordinates.
Persistence Should Match Consequence
A toast message saying:
Copied
can disappear after a moment.
A notification saying:
Your examination venue has changed.
should probably remain findable somewhere durable.
This reveals two different jobs:
- alerting: get attention now;
- recording: preserve the information for later retrieval.
One message can do both, but the system should not assume that seeing once equals remembering forever.
High-consequence changes need a recoverable source of truth.
Notifications Need an Object
Weak:
Completed.
What completed?
Weak:
Changed.
What changed?
Better:
Report export completed.
Your class venue changed to Room 4.
A notification usually interrupts another task.
It should not make the reader spend extra cognition reconstructing the missing subject.
Concise does not mean contextless.
Notifications Should Separate Fact from Recommendation
Consider:
Your password may be compromised. Change it now.
Two things are happening.
State claim:
Your password may be compromised.
Action recommendation:
Change it now.
The strength of the recommendation should match the evidence and consequence.
If suspicious activity is merely possible, the wording should not falsely state:
Your account has been hacked.
Notification English still needs epistemic calibration.
Urgency does not grant permission to invent certainty.
Accessibility Means the Change Cannot Exist Only Visually
A sighted user may see a green message appear in the corner.
A screen-reader user may remain focused inside the form and never know that new text appeared elsewhere.
W3C’s Status Messages success criterion addresses exactly this problem. Important changes that do not take focus should be programmatically determinable so assistive technologies can announce them without forcing the user away from their current task.
This creates a beautiful design principle:
Notification should travel to the reader; the reader should not have to hunt the page to discover that the state changed.
That principle helps everyone, not only assistive-technology users.
Primary School: What Changed?
Young learners can practise notification thinking with simple scenarios.
Scenario:
A library book you requested is now ready for collection.
Weak notification:
Update!
Better:
Your reserved book is ready for collection.
Then ask:
- What changed?
- Who needs to know?
- Does anything need to happen next?
This teaches informative sentence design.
Lower Secondary: Rank the Interruptions
Give students ten possible notifications:
- Your document was saved.
- Your class begins in five minutes.
- Your account password was changed.
- A new article was posted.
- Your building is being evacuated.
Ask them to rank:
- quiet status;
- visible notification;
- urgent alert.
Then justify the ranking.
The task connects language to attention economics and consequence.
Upper Secondary: Audit Notification Power
Older students can analyse the notifications on a phone or application.
- Which notifications represent genuine state changes?
- Which are marketing disguised as urgency?
- Which use fear?
- Which hide the relevant object?
- Which lack timestamps?
- Which should be persistent records rather than disappearing alerts?
- Which demand action without explaining why?
- Which could be batched rather than interrupting separately?
This reveals that notification design is not neutral.
Whoever controls the notification channel has partial control over attention.
Ten Failure Modes of Notification English
- No object. “Updated” or “Completed” leaves the reader guessing what changed.
- No new state. The notification announces change without telling the reader the resulting condition.
- No receipt. A consequential action completes silently.
- No end state. Waiting or busy messages disappear without communicating readiness.
- Contextless count. The user hears “three” rather than “three unread messages.”
- Urgency inflation. Routine updates use the same interruption level as critical alerts.
- Notification fatigue. Too many low-value changes consume attention.
- Relative-time decay. “Yesterday” survives inside a persistent history after its meaning shifts.
- Visual-only update. The change appears on screen but is not announced to users who cannot see it.
- Fact-action collapse. The notification converts suspicion into certainty or recommendation into fact.
How to Write a Better Notification
Start with the state change.
What is different now?
Then ask whether the reader needs to know.
If yes, ask whether they need to know now.
Then write the smallest message that restores the relevant model.
object + changed state + next action if needed
For example:
Your report is ready. Download PDF.
Or:
Payment failed. Your booking is not confirmed. Choose another payment method.
Then choose interruption level deliberately.
Quiet inline status?
Toast?
Persistent inbox item?
Urgent alert?
Make it accessible across modalities.
And perform the attention test:
If I interrupt a person’s current thought with this sentence, is the state change important enough to justify the cost?
The Deeper Idea: Notifications Keep Human Models Synchronized with Changing Systems
A system changes whether the human notices or not.
The payment succeeds.
The upload finishes.
The train is delayed.
The account password changes.
The class moves rooms.
If the human keeps operating from the old model, errors begin.
The notification exists to synchronize models:
world state changes → system detects change → English represents change → human updates belief → action can adapt
This is why notification quality matters.
Too little communication and the human remains behind reality.
Too much communication and the human learns to ignore the channel.
The craft lies in preserving synchronization without destroying attention.
That is a very modern job for very small English.
Reader Checklist
- What changed?
- What object does the change affect?
- Is this success, progress, waiting, failure or new information?
- Does the reader need to know now?
- How much interruption does the event deserve?
- Is the resulting state explicit?
- Is a next action needed?
- Does the message need to remain available later?
- Is time expressed in a way that will remain meaningful?
- Can assistive technology perceive the same change without forcing the user to abandon their current task?
Related eduKateSG Reading
- How English Works | The Button
- How English Works | The Error Message
- How English Works | The Warning
- How English Works | The Form
- How English Works | The Time Machine
Research and Further Reading
Final idea: a notification is good when reality changes, the right human learns enough to update, and the message disappears before it becomes the next problem.