Skip to main content
Accessibility Field Guide

Link Text and Button Labels

A practical Field Guide page about writing link text and button labels that make sense before someone activates them.

Hands organize file folders and bundled documents inside a cardboard box.
Photo: Cardboard Box Full of File Folders via Pexels — https://www.pexels.com/photo/cardboard-box-full-of-file-folders-8371705/
View full screen Download image

Links and buttons are small pieces of copy, but they carry a lot of responsibility.

They tell people where they can go, what they can do, and what might happen next.

When the words are clear, a screen feels easier to scan. When the words are vague, people have to slow down, infer meaning from nearby content, or activate something just to find out what it does.

That is frustrating for anyone.

It is especially costly for people who navigate by keyboard, screen reader links lists, voice control, magnification, or memory of the page structure.

A useful starting point is simple:

The label should still make sense when someone encounters it out of context.

The common project moment

A screen has a set of cards, rows, actions, or calls to action.

The design looks clean because repeated actions are short:

  • Learn more
  • Click here
  • Read more
  • View
  • Details
  • Submit
  • Continue
  • Next
  • Open
  • Select

Those labels may look tidy in a mockup. They may even feel obvious when the whole page is visible at once.

But users do not always experience the screen that way.

A screen reader user may pull up a list of links and hear several items named Read more. A voice-control user may try to say the name of a button and find several controls with the same visible label. A keyboard user may tab through repeated actions and lose track of which one belongs to which item.

The problem is not that short labels are always bad.

The problem is that the label has to carry enough meaning for the action it represents.

Before polishing the words, make sure the control itself is doing the right job.

A link takes someone somewhere.

A button does something.

That distinction matters because the label should match the behavior.

Good link text usually answers:

  • Where does this go?
  • What page, section, document, file, or external resource will open?
  • Is the destination different from the current context?

Good button text usually answers:

  • What action will happen?
  • What object will the action affect?
  • Is the action safe, reversible, destructive, or final?

If the label and behavior do not match, the user has to recover from a surprise.

Link text should name the destination or purpose of the link.

Instead of:

  • Click here
  • Learn more
  • Read more
  • View document

Try labels that explain the destination:

  • Review readiness checklist
  • WCAG 2.1 A/AA Map
  • Download the accessibility test report
  • Read more about keyboard-only navigation
  • View vendor accessibility questions

The link can still be concise. It just needs enough information to stand on its own.

A good test is to read only the links on the page.

If the links sound like a useful outline of destinations, they are probably doing their job.

If the list sounds like click here, read more, learn more, read more, details, the page is asking users to reconstruct meaning from context they may not have.

Write buttons as actions

Button labels should name the action.

Instead of:

  • Submit
  • Go
  • OK
  • Yes
  • No
  • Continue
  • Done

Use the action and, when needed, the object:

  • Submit application
  • Save changes
  • Search records
  • Add mailing address
  • Remove attachment
  • Close dialog
  • Continue to payment
  • Confirm appointment

Short labels can work when the context is truly clear. For example, Search beside one search field may be enough.

But repeated or high-stakes actions usually need more detail.

Delete might be technically accurate. Delete saved address is safer. Cancel might be fine in a simple dialog. Cancel appointment is clearer when the consequence matters.

Make repeated actions unique

Repeated cards and table rows are where vague labels often hide.

A list of programs might have five Learn more links. A table might have several View or Edit buttons. A set of document rows might repeat Download again and again.

Visually, the surrounding card or row may explain the action.

Programmatically, the accessible name may still be repeated and unclear.

Better patterns include:

  • Learn more about renewal requirements
  • View January statement
  • Edit mailing address
  • Download eligibility notice
  • Remove proof of income attachment

Sometimes the visible label can stay short if the accessible name is completed in a reliable way by nearby text or hidden text.

But that should be handled carefully.

Do not use hidden text as a way to keep visually vague controls everywhere. If sighted users also need the extra context, the visible label should probably be clearer too.

Keep the visible label and accessible name aligned

For controls, the name exposed to assistive technology should include the words people can see.

This matters for voice control.

If a button visibly says Save, but its accessible name is only Submit form, someone may try to say “click Save” and the control may not match as expected.

A safer pattern is to keep the visible words at the start of the accessible name:

  • Visible label: Save
  • Accessible name: Save changes

Or, when space allows, make the visible label complete:

  • Visible label: Save changes

This also helps teams review the page because the visible interface and the programmatic interface are telling the same story.

Be careful with icons and visual-only labels

Icon-only controls need accessible names.

A magnifying glass might mean search. A trash can might mean remove. A pencil might mean edit. But icons are not always interpreted the same way by every user, and they may not announce anything useful without a name.

If an icon-only control is necessary, give it a clear accessible name:

<button aria-label="Search records">
  <svg aria-hidden="true" focusable="false">...</svg>
</button>

If the icon appears with visible text, the text usually gives the control its name.

Do not add a conflicting aria-label just because the control has an icon. Native text is usually better than a hidden override.

Tell people when the result is unusual

Most links and buttons do not need long warnings.

But some actions have consequences users should understand before they activate the control.

Consider adding clear words when a control:

  • opens a file instead of a page
  • downloads something
  • leaves the current site
  • opens a new tab or window
  • deletes, cancels, submits, or confirms something
  • changes data that cannot be easily restored

Examples:

  • Download appeal form PDF
  • Open W3C WCAG guidance in a new tab
  • Cancel appointment
  • Delete draft request
  • Submit final report

The goal is not to make every label long.

The goal is to avoid surprise.

Do not rely on position alone

Labels like Previous, Next, Left, Right, Above, or Below can be ambiguous when the page changes at different screen sizes, zoom levels, or reading orders.

If the label depends on position, ask whether it will still make sense when:

  • the layout stacks on mobile
  • the user is zoomed in
  • a screen reader reads controls one at a time
  • the page is translated
  • the user returns later and only remembers part of the flow

Sometimes Next is fine inside a clear step-by-step flow.

But Next: Review your answers is better when the user needs confidence about where the flow is going.

Questions teams can ask

During content and design

  • Does each link say where it goes?
  • Does each button say what it does?
  • Are repeated labels unique enough to make sense on their own?
  • Would the label still make sense if it appeared in a list of links or controls?
  • Are destructive or final actions labeled with the object they affect?
  • Are icon-only controls necessary, or could visible text make the action clearer?

During development

  • Is the control a real link or a real button, matching the behavior?
  • Does the accessible name include the visible label?
  • Are icon-only controls named clearly?
  • Are repeated controls programmatically distinguishable?
  • Are hidden labels used only when they clarify, not to hide meaning users need visually?
  • Do ARIA labels avoid overriding useful visible text with something less clear?

During QA

  • Can you understand the page by reading only the links?
  • Can you understand the actions by tabbing through buttons?
  • Do screen-reader link and button lists contain meaningful names?
  • Can voice-control users activate controls by saying the visible label?
  • Do download, external, destructive, or final actions set the right expectation?
  • Are labels still clear at mobile widths and high zoom?

Common trail hazards

  • Several links on one page named Click here, Learn more, or Read more.
  • Table-row buttons named only View, Edit, or Delete.
  • Card links where every card has the same visible link text.
  • Icon-only buttons without accessible names.
  • aria-label text that does not include the visible label.
  • Buttons labeled Submit when the action is specific or high-stakes.
  • Links styled like buttons but labeled as vague actions.
  • Buttons used for navigation with link-like labels.
  • Hidden text used to compensate for visibly unclear labels.
  • Labels that depend on layout position instead of meaning.

Small habit

Read the label by itself.

Then ask:

  • Would I know where this link goes?
  • Would I know what this button does?
  • Would I know what object this action affects?
  • Would this still make sense if there were five similar controls on the page?

If the answer is no, add the missing noun or destination.

Small wording changes can prevent a lot of uncertainty:

  • Read more becomes Read more about review readiness.
  • Submit becomes Submit application.
  • Delete becomes Delete uploaded document.
  • View becomes View payment history.

That is not just content polish.

It is accessibility work.

Use these as trail markers, not as the whole conversation:

  • Accessible Names — for how visible labels, hidden names, and control names work together.
  • Button vs Link — for deciding whether the control should be a link, button, or state-changing control.
  • Name, Role, and Value — for checking whether custom controls expose the right role, state, and value after the label is clear.
  • ARIA Is Not Duct Tape — for avoiding hidden ARIA names or attributes that cover up unclear visible wording or broken behavior.
  • Native HTML First — for choosing links, buttons, and form controls with built-in behavior.
  • Headings and Page Structure — for giving links and controls useful surrounding context.
  • Alt Text Basics — for linked images, icon-only controls, and image buttons that need useful text alternatives.
  • Tables and Data Displays — for repeated table actions like View, Edit, Download, Delete, or Sort.

What to do next