Writing Buttons and Labels

The button label is the most read piece of copy on a screen. Users who have skimmed all the surrounding content will read the button label, because it is the point at which they must act. Whatever they understand in that moment — what will happen, what they are committing to, whether this is reversible — comes from the button label, plus whatever context they have retained from the surrounding interface. Getting the button label right is high-leverage content work.

Generic labels fail at the moment of truth

“Submit,” “OK,” “Continue,” “Click here,” and “Go” all share the same flaw: they describe the action of pressing a button without describing the consequence of doing so. The user is not asking “what button am I pressing?” They are asking “what will happen when I press this?” A generic label answers the first question and ignores the second.

The consequence of this failure is that users either hesitate — reading the surrounding context to understand what the button does — or they press it hoping for the best, and are then surprised by the result. In high-stakes interactions (payments, deletions, irreversible actions), this surprise becomes a support request or a lost user.

The specificity principle

Specific button labels describe what happens when the button is pressed. “Send my application” is better than “Submit.” “Save and continue to billing” is better than “Continue.” “Delete this project permanently” is better than “Delete.” “Download the PDF” is better than “Click here.”

The specificity test: can you read the button label and know what will happen next? If not, the label needs more information.

Specificity also applies to labels that appear in lists or alongside other buttons. When two buttons appear together — “Cancel” and “Delete” — both need to be unambiguous. “Cancel” is fine; it is specific enough in context. But when the second button is “OK” rather than “Delete this project,” the consequence of pressing it is unclear. OK to what?

Form field labels

Form field labels have a different challenge from button labels: they must identify what the field is, in the user’s language, concisely enough to fit the space. The most common label failures are:

Using system terminology — “User ID” instead of “Username,” “Contact digit” instead of “Phone number.” The label should use the language the user would use.

Using a verb where a noun is better — “Enter your email” instead of “Email address.” The verb is redundant; the act of filling in the field is already implied.

Using a placeholder as a label — making the label text appear inside the empty field. This pattern fails when the user starts typing, because the label disappears and the user can no longer reference it if they forget what the field asked for.

Missing the required/optional distinction — not indicating which fields are required and which are optional. When everything looks the same, users often attempt to submit incomplete forms.

Navigation labels

Navigation labels share the specificity requirement with button labels, but have an additional constraint: they must fit the navigation pattern and be consistent with the other labels. A navigation item called “Solutions” alongside “Products” and “Services” is vague. “Solutions” could mean anything. “Case studies” or “How it works” would be specific.

Navigation labels also benefit from being parallel in grammatical form: all nouns, or all gerunds, or all sentence fragments. Mixing “Features,” “Why it works,” and “Getting started” creates a navigation that feels assembled rather than designed.

Accessible names

Screen readers announce the accessible name of every interactive element — button, link, input. The accessible name is derived from the visible label text, or from aria-label, or from aria-labelledby when neither is present. For buttons with visible text, the accessible name is simply the text. Generic labels (“Submit”, “Click here”) fail screen reader users in the same way they fail sighted users — and fail them additionally in the link list, a screen reader navigation mode that lists all links and buttons out of their visual context. “Click here” in a link list is meaningless; “Download the 2025 annual report (PDF)” is not.

Icon-only buttons — a search icon, a close button, a share icon — have no visible text. Every icon-only button needs an accessible name provided via aria-label or visually-hidden text. A close button rendered with an × character and no label announces as ”×” to a screen reader. A button with aria-label="Close dialog" announces as “Close dialog.”

Navigation labels read aloud in sequence. “Our services,” “Our products,” “Our solutions” is repetitive. “Services,” “Products,” “Solutions” reads faster and more clearly. Parallelism in navigation labels benefits both sighted and screen reader users.

Error messages — when users get things wrong, the content of the error is the last chance to help them recover without leaving.