In a payroll product, why should a button say 'Approve pay run' rather than 'OK' or 'Submit'?
answer
- a label is a promise
- verb plus object
- read out of context
- same action, same verb
- Headings and Labels, Label in Name
basics
~20 sA verb-plus-object label tells people exactly what will happen before they act, still makes sense when read on its own, as in a screen reader's list of controls, and removes the need to reread the surrounding text to decide.
solid answer
~50 sAn action label is a promise about the outcome. 'OK' acknowledges a message and 'Submit' describes what the system does with a form; neither says that 240 people are about to be paid. 'Approve pay run' uses a **verb plus object**, so a payroll manager scanning the screen knows the consequence without rereading the heading. Specific labels also work out of context: people using assistive technology often move through a list of controls where each label appears alone. For choices, pairs such as 'Approve pay run' and 'Keep reviewing' are unambiguous where 'Yes' and 'No' depend on how the question was phrased. WCAG 2.2 2.4.6 Headings and Labels (Level AA) asks labels to describe purpose. The style guide should also fix one verb per action - 'Approve' everywhere, not 'Confirm' on one screen and 'Authorise' on another.
go deeper
Write action labels as a verb plus an object, such as 'Approve pay run', and avoid 'OK', 'Submit', 'Yes/No' and 'Click here' for actions with consequences.
Explain why specific labels work out of context, how action pairs should both name their outcome, and what 2.4.6 and 2.5.3 in WCAG 2.2 ask of labels.
Show how you would find inconsistent verbs across a product, fix them through the glossary, and make the label rules easy for engineers to apply while building.
Weigh strict label patterns enforced across every team against local flexibility, and decide how far the system should encode labels in shared components.
## A label is a promise An **action label** is the text on a button, a menu item or a link that performs an action. People read labels first - often before the heading or the body text - and decide from the label alone whether to act. A good label is therefore a promise about what will happen. In a payroll product, where one click can pay hundreds of people, a vague promise is a real risk. ## The verb-plus-object pattern Most style guides ask for labels that start with a **verb** and name the **object** when it is not obvious: | Weak label | Stronger label | Why | |---|---|---| | OK | Approve pay run | Says what happens, not that the message was read | | Submit | Send for approval | Names the outcome from the user's point of view | | Yes | Remove deduction | Makes sense without rereading the question | | Click here | Download payslip | Describes the destination or result | | Continue | Review 3 warnings | Says what the next step contains | The verb carries the action; the object removes ambiguity when there are several things the action could apply to. On a screen with only one possible object, the verb alone can be enough - 'Save' in a settings panel - as long as the result is unmistakable. ## Why vague labels fail - **They push reading onto the user.** 'OK' forces people to find and reread the question to know what they are agreeing to. - **They hide consequence.** 'Submit' does not reveal whether a pay run is sent for approval, approved or paid. - **They break out of context.** People using screen readers or voice control often navigate by a list of controls; 'Yes', 'OK' and 'Click here' mean nothing there. - **They invite mistakes in pairs.** 'Yes' and 'No' depend on how the question was phrased; a negative question ('Don't send payslips?') makes them actively confusing. - **They slow people down.** In usability sessions, participants who hesitate over a button are often rereading the screen to work out what 'OK' will do; a specific label removes that pause. ## Pairs of actions When a screen offers a choice, both options should name their outcome: 'Approve pay run' and 'Keep reviewing', or 'Send 240 payslips' and 'Review first'. The cancelling option should say what it keeps, not only what it stops. Neither label should rely on the other to make sense. The placement and emphasis of the two buttons are decided by the button and dialog patterns; the style guide decides only the words, which must make sense whatever the order or position. ## Accessibility criteria that apply Several WCAG 2.2 success criteria bear on action labels: - **2.4.6 Headings and Labels (Level AA)** - headings and labels describe topic or purpose. - **2.5.3 Label in Name (Level A)** - for a component whose label includes text, its accessible name contains the text presented visually. If the button shows 'Approve pay run', the name exposed to assistive technology must include those words, so voice-control users can say what they see. - **2.4.4 Link Purpose (In Context) (Level A)** - the purpose of a link can be determined from its text alone or together with its programmatically determined context. Descriptive link text such as 'Download payslip' meets this without relying on context. ## Rules for the style guide 1. **Start with a verb** in the imperative: 'Approve', 'Add', 'Download'. 2. **Name the object** when more than one thing could be meant. 3. **One verb per action across the product** - if approving is 'Approve', it is never 'Confirm' or 'Authorise' elsewhere; record the verbs in the glossary. 4. **Keep labels short** - usually two to four words - and in the product's capitalisation convention. 5. **Match the heading's words** - a panel titled 'Approve pay run' has a button that says 'Approve pay run', not 'Proceed'. 6. **Avoid 'Click here', 'OK', 'Yes/No' and 'Submit'** for anything with a consequence. These rules are simple enough for engineers to apply while building, which matters because engineers write a large share of interface labels in most products. A label that still makes sense when read alone, out of order and aloud is usually a good one.
- Is 'Save' acceptable on its own, or does every button need an object?'Save' alone is fine where there is only one thing to save and the result is obvious, such as a settings panel. Add the object when several things could be meant or the consequence differs - 'Save draft' versus 'Save and send'. The rule is that the label must be unambiguous where it sits, not that it must always be long.
- Why does WCAG 2.2 2.5.3 Label in Name matter for how labels are written?It requires that a component's accessible name contains the text shown on it. Voice-control users activate a button by saying its visible words; if the button shows 'Approve pay run' but its name is 'Submit form', the command fails. So the visible label is the one to write carefully, and the underlying name must include it.
saying these in an interview costs you the question
- 'OK' works for any confirmation because users read the message first.
- 'Submit' is clear enough since everyone knows they are sending a form.
- Different teams can use different verbs for the same action.
- 'Click here' is a good link label because it tells people what to do.
- Longer, explanatory labels are always clearer than short ones.