Some of the most important writing on the web is invisible. It is in the alt attribute of an image, the label of a button, the message that appears when a form fails, and the sentence a screen reader announces when a page loads. Nobody admires this text, and everybody is affected by it.
Microcopy is the general name for the small bits of language inside a product. Alt text is its most consequential form, because a reader who cannot see the image has no other way in.
Alt text is not a caption
A caption is written for everyone and displayed on the page. Alt text is written for people who cannot see the image, and it replaces the image rather than describing it.
The difference matters. A caption might say: "Figure 3. Annual rainfall in the region, 2015–2024." The alt text for the same image needs to convey what the chart shows, because the reader cannot see the line going up.
Alt text for a chart: "Line chart showing annual rainfall rising from 620 mm in 2015 to 910 mm in 2024, with the sharpest increase after 2021."
That is longer than most alt text, and it is correct, because the information the chart carries is the point of the chart.
Writing good alt text
Four rules cover most cases.
Say what the image is for, not what it is. A photograph of a team at a whiteboard might have alt text "The team reviewing the 2024 roadmap" rather than "Four people standing near a whiteboard." The second describes the pixels; the first describes the purpose.
Be specific about function. If the image is a link, the alt text should describe the destination, not the image. "Home" is better than "Company logo" for a logo that links to the homepage.
Keep it short when the image is decorative. If an image is purely ornamental, use empty alt text (alt="") rather than describing it. A screen reader will skip it, which is the right result. Do not put "decorative image" in the alt attribute; that is noise.
Do not start with "Image of." Screen readers already announce that it is an image. "Image of a red bicycle" becomes "image, image of a red bicycle."
Button labels and links
Button labels are instructions. A good label tells the reader what will happen when they press it.
"Submit" describes the mechanism, not the result. "Send message," "Create account," "Save changes," and "Download report" describe the outcome, which is what the reader is deciding about.
The same rule applies to links. "Click here" and "Read more" are invisible out of context, and screen reader users often navigate by listing every link on a page. A list of fifteen "Read more" links is useless. "Read the guide to editing" is not.
The technical version of this rule is that link text should make sense when read alone, without the surrounding sentence. It is a good rule for sighted readers too, because people scan.
Error messages
An error message has three jobs: say what went wrong, say why, and say what to do next.
Compare.
Error: Invalid input.
That message tells the reader they failed and nothing else. It is the most common error message on the web, and it is almost always wrong.
Better: Enter a date in the format DD/MM/YYYY, for example 14/11/2026.
This says what is expected, gives an example, and can be acted on immediately. The difference in support requests is measurable.
Two further rules. First, never blame the reader. "You entered an invalid date" and "That date is not valid" say the same thing, and only one of them sounds like a person wrote it. Second, place the message next to the field it concerns, not in a banner at the top of the page. The reader should not have to hunt.
Empty states and loading states
An empty state is what a reader sees before there is any content: a new inbox, a search with no results, a dashboard with no data.
"Nothing here yet" is a dead end. The useful version does two things: explains why the space is empty and offers the next action.
"No results for 'colour theory'. Try a broader term, or browse all guides."
That sentence tells the reader what happened, why, and what they can do. It is three short clauses and it turns a failure into a path.
Loading states deserve the same treatment. "Loading…" is fine. "Loading your draft — this usually takes a few seconds" is better, because it tells the reader whether to wait or to worry.
Placeholder text is not a label
Placeholder text disappears the moment the reader starts typing, which is exactly when they need the instruction. Every field needs a visible label outside the input, and a placeholder should be an example or a hint, never the only description of what goes in the field.
The accessibility reason is that screen readers handle placeholders inconsistently and some users never see them. The usability reason is that people forget what the field was for halfway through typing.
Character limits and tone
Interface text is short, and length is a design constraint as much as a writing one. Use the character counter when a label has a hard limit; use the readability checker when a sentence is going to be read by everyone, including people reading in a second language.
Tone matters more in error states than anywhere else. The reader is already frustrated. A friendly, precise message reduces the frustration; a cute one increases it. Save the personality for the moments when nothing has gone wrong.
The test
Read every piece of interface text as if you were seeing it alone, with no context, in a hurry, possibly through a screen reader. Does it tell you what is happening? Does it tell you what to do? If both answers are yes, it is doing its job.
The best interface writing is the writing nobody notices, because it worked.