What should an icon-only button be called?

Name the action, not the drawing

An icon-only control can look obvious to its designer and remain opaque to a customer using a screen reader. A magnifying glass might mean search, open search, filter, inspect or zoom, depending on the page. W3C’s button pattern says a button needs an accessible label; native button text supplies one by default, while aria-label or aria-labelledby can supply one when visible text is absent. The editorial decision is to describe what activating the control will do in that specific place. “Search products” is more useful than “magnifying glass” on a product catalogue.

First decide whether the control performs an action or navigates to another destination. Use an actual button for an action such as adding to a basket or opening a panel, and a link for navigation to a product page. A clickable generic container can be made to behave correctly only with additional keyboard and semantic work, which creates avoidable risk. The accessible name should be concise but specific enough to distinguish neighbouring controls. Do not assume that a tooltip visible only to pointer users supplies a usable button name or keyboard path.

Audit the controls customers actually meet

List icon-only controls in the task flows: header search, basket quantity, saved items, carousel movement, product image viewer, account settings and dismissible notices. For each, record its page context, visible icon, current accessible name, action and resulting state. Include repeated controls in a list. Ten identical “Remove” buttons may each be technically named yet still leave the customer unable to tell which basket item will disappear. The fix can be a contextual name such as “Remove blue notebook” if the product name is stable and is the meaningful distinction.

Review what the name communicates before choosing an attribute. If the page already has visible text that can name the control, using that text often reduces translation and maintenance errors. The W3C naming practices warn that aria-label can override descendant content in the accessibility tree. A developer who adds a generic aria-label to a button that already contains a useful visible label may make the spoken name worse. Inspect the computed name in the browser rather than inferring it from the HTML attribute you intended to set.

Make repeated actions unambiguous

A product card with a heart icon illustrates why the noun matters. “Save” gives an action but may be ambiguous when many products are shown; “Save linen shirt” identifies the target. If the card’s product name changes with a selected variant, decide whether the button saves the product family or that precise variant, then name it consistently with the underlying action. Do not promise that pressing the control saves a specific size if the application actually saves only the product page. The label must match what the system will do.

The same principle applies to controls inside alerts and orders. “Close” may be enough for a single open dialog, but a row of removable upload attachments needs file-specific names. Avoid stuffing the full card description into every name; that makes keyboard exploration tiring and can repeat information already available from the surrounding structure. Use the shortest phrase that distinguishes the action and its target. If the target has a sensitive name, consider whether speaking it on a shared device would expose information; the interface can instead make the row context programmatically clear without unnecessary repetition.

Handle toggles and changing actions honestly

Some icons are toggle buttons rather than one-time actions. The W3C button pattern describes an aria-pressed state for a two-state toggle and says the label stays stable when that pattern is used. For a saved-item button, a stable label such as “Save linen shirt” can be paired with pressed or not pressed state, provided the behaviour truly follows that toggle model. Another design may change the action and label from “Save linen shirt” to “Remove linen shirt from saved items”; in that case it is no longer using the stable-label toggle convention. Decide which interaction you actually implement and test what assistive technology announces.

Do not make the icon shape carry the whole state. A filled heart might be visually meaningful but should not be the only indication that an item is saved. Check the name, role and state as a set, then verify the action persists or fails visibly as appropriate. A delayed network response needs a truthful status update, but adding “Saved” to the control before the server confirms would mislead the customer. The business rule should say when the state changes and what happens after a failure or retry; the accessible text should follow that rule.

Write English and Chinese for the same decision

Translate the action and target naturally, not word for word. “Open search” may become「開啟搜尋」when the button reveals a field, while「搜尋產品」fits a button that submits a product query. Those are different actions, so the content team must confirm the underlying behaviour before localising the name. Test whether the current document language is correctly identified, because a screen reader may pronounce Chinese words badly if the page declares only English. Avoid relying on an untranslated English aria-label embedded in an otherwise Chinese interface.

Visible text and accessible name should agree when a button has a visible text label. WCAG 2.5.3 says the programmatic name contains the visually presented text for relevant controls, which helps speech-input users activate them by saying what they see. An icon-only button has no visible word to match, but a nearby visible instruction or tooltip can still create a practical mismatch if it says “Search” while the name says “Open catalogue filter”. Review the whole interaction in each language so sighted, speech and screen-reader users receive compatible instructions.

Work through a basket example

Suppose a basket row shows a notebook, a quantity control and a small trash icon. The developer labels every trash icon “Delete”. A screen-reader user hears the same name several times and cannot safely tell which row will change. First decide that the action removes one basket line, not the customer account or the product itself. Then give the control a contextual name such as “Remove blue notebook from basket”, using the actual row title. After activation, verify the correct line disappears, the total updates and the customer receives a clear result. This is an illustrative design scenario, not an observed retailer defect.

Now test a second notebook with a similar title and switch to Traditional Chinese. If both buttons still announce the same object, add the distinguishing variant only if the row and business data reliably supply it. Navigate by buttons in a screen reader and also activate each with keyboard Space or Enter according to native button behaviour. Test the failure path: if removal fails, the row should remain and the result should say so. An attractive icon and a correctly spelled label are insufficient if the action applies to the wrong line or the resulting state is silent.

Review computed names and actual outcomes

Use the browser accessibility tree or equivalent inspector to read each control’s computed name, role and state. Then use the keyboard and a screen reader to hear the sequence in context. Compare the spoken name with the visible icon, nearby text and the action performed. This catches an accidental aria-label override, an empty name hidden by an SVG, a repeated generic label and a stale name after state changes. Automated scans can reveal empty names, but they cannot decide whether “Open” identifies the right destination among several adjacent controls.

Finish with a small acceptance sheet containing page, language, control, intended action, computed name, state before and after activation, and result on failure. Include any icon whose meaning changes between desktop and mobile, because the compact layout may remove nearby words that previously supplied context. Keep the labels in the same translation workflow as visible copy so later product or navigation changes trigger review. The useful next action is to audit one high-value customer journey, repair ambiguous buttons there, and reuse the naming rule in the component library.

Give the component team a small naming rule rather than a single approved word list. The rule can ask for the verb, the affected object when neighbouring buttons repeat, the state model, and the result the customer should observe. A new icon can then be assessed even if its artwork differs from the examples. Before release, compare the English and Chinese computed names in the actual rendered interface and perform each action once. If a button is disabled, check that the customer can understand why through nearby instructions or the surrounding state. Review labels again when product names, workflow steps or account permissions change, because a once-correct name can become misleading without any visible change to the icon.