Microcopy
Microcopy is the small text that guides people through an interface: labels, buttons, help text, tooltips, placeholder text, and link text. It's often the difference between someone completing a task smoothly and getting stuck.
Good microcopy is invisible. People don't notice it because it just works. Bad microcopy creates friction, confusion, and support tickets.
All microcopy should follow the tone of voice guidelines: sentence case, contractions, active voice, and plain language.
Labels
Labels tell people what a field or element is. They should be short, specific, and visible.
| Do | Don't |
|---|---|
| Email address | Please enter your email address |
| Full name | Your Name: |
| Password | Create a secure password |
| Company | What company do you work for? |
Label rules
- Sentence case. "Email address" not "Email Address"
- No colons at the end of labels
- No full stops. Labels aren't sentences
- Be specific. "Work email" is better than "Email" if you need to distinguish between types
- Every input needs a visible label. This is a WCAG requirement (SC 1.3.1, 3.3.2), not a suggestion. Placeholder text is not a label.
Placeholder text
Placeholder text sits inside an input field before the user types. It disappears on focus, which makes it unreliable for anything important.
| Do | Don't |
|---|---|
| Use for format hints: "DD/MM/YYYY" | Use as a replacement for labels |
| Use for example values: "name@company.com" | Put instructions in placeholder text |
| Keep it short, under 40 characters | Repeat the label as placeholder text |
| Make it clearly an example, not a real value | Use placeholder text for required field indicators |
Why placeholders aren't labels
- They disappear when the user starts typing, so there's no reference for what the field is
- They often have low contrast, which fails accessibility requirements
- Screen readers may not announce them consistently
- Users sometimes mistake placeholder text for pre-filled data
If you need to explain what goes in a field, use help text below the label instead.
Help text and hints
Help text appears below a form field to give extra context, such as format requirements, constraints, or explanations. It stays visible while the user interacts with the field.
| Do | Don't |
|---|---|
| Must be at least 8 characters | Your password should be at least 8 characters long and contain at least 1 uppercase letter, 1 lowercase letter, 1 number, and 1 special character |
| We'll only use this to send your receipt | Please provide a valid email address so that we can send you confirmation of your purchase |
| Format: DD/MM/YYYY | Enter the date in day/month/year format (for example, 25/02/2026) |
Help text rules
- Keep it to 1 sentence. If you need more, the form design might need rethinking
- Put it below the input, not above. People scan top-to-bottom: label, input, help text
- Don't repeat the label. Help text should add information, not echo what's already there
- Use
aria-describedbyto associate help text with the input for screen readers - Don't use help text for every field. Only use it where the label alone isn't enough
For full form patterns, see form patterns.
Link text
Link text should describe where the link goes. The reader should know what they'll get before they click.
| Do | Don't |
|---|---|
| Read the full case study | Click here |
| View your recent orders | Read more |
| Download the annual report (PDF, 2.4 MB) | Download |
| See the accessibility standards | Learn more about this |
| Contact the support team | Get in touch |
Link text rules
- Never use "click here". It says nothing about the destination and is meaningless for screen reader users who navigate by links
- Never use "read more" on its own. Read more about what?
- Make it specific. "View the 2026 roadmap" is better than "View roadmap"
- Include file type and size for downloads. "Download the brand guidelines (PDF, 1.2 MB)"
- Don't use the URL as the link text. "Visit our blog" not "Visit https://enableamazing.com/blog"
- Links should make sense out of context. Screen readers can list all links on a page. Each one should be understandable on its own (WCAG SC 2.4.4)
Button text
Buttons trigger actions. The text should describe the action clearly and specifically.
| Do | Don't |
|---|---|
| Save changes | Submit |
| Delete account | OK |
| Create project | Yes |
| Send message | Confirm |
| Add to cart | Proceed |
| Sign in | Go |
| Cancel subscription | Cancel |
Button text rules
- Start with a verb. Buttons are actions, so lead with what happens
- Be specific. "Save changes" tells you exactly what happens. "Submit" doesn't.
- Match the button text to the action. If someone clicks "Delete account," that's what should happen. No surprises.
- Destructive actions should be explicit. "Delete this project" not "OK" or "Confirm." People should understand the consequences before they act.
- Primary and secondary buttons should clearly differ. "Save changes" (primary) and "Discard" (secondary), not "Yes" and "No"
- Don't use "Cancel" for both cancelling an action and cancelling a subscription. Be specific about what's being cancelled
Tooltips
Tooltips provide supplementary information on hover or focus. They're for nice-to-know context, not essential instructions.
| Do | Don't |
|---|---|
| Use for supplementary context: "Last updated 3 days ago" | Use for essential information the user needs to complete a task |
| Keep under 80 characters | Write paragraphs in tooltips |
| Make them keyboard accessible (triggered on focus, not just hover) | Rely on tooltips as the only way to communicate important information |
| Use for icon-only buttons: "Edit profile" | Duplicate the label text |
When to use a tooltip
- To label an icon-only button or action
- To provide additional context about a data point
- To explain what a setting does
When not to use a tooltip
- To communicate error messages (use inline validation instead)
- To provide instructions for completing a form field (use help text instead)
- To display content that people need to copy or interact with (tooltips disappear)
- On touch devices where hover doesn't exist (always provide an alternative)
Writing checklist for microcopy
- Is it in sentence case?
- Does it use contractions?
- Is it as short as it can be without losing clarity?
- Does every input have a visible label (not just placeholder text)?
- Do all links make sense out of context?
- Do buttons describe the specific action?
- Is help text associated with inputs using
aria-describedby?