skip to content

What accessible name should a car-rental results page give an icon-only heart button that saves a car, and why?

level: juniorimportance: must knowfreq 62%

answer

  1. otherwise announced as just “button”
  2. what it does, not what it shows
  3. verb first, no role word
  4. thirty cards, thirty distinct names
  5. toggle: pressed state or new name

basics

~20 s

Name it by its function, not its picture: “Save to favourites”, made unique per card, such as “Save compact hatchback to favourites”. Leave out the role word, and expose the saved status as a pressed state or a changing name.

solid answer

~40 s

An icon-only button has no text, so without a written name it is announced as just “button”; WCAG 2.2 requires controls to have a name describing their purpose (1.1.1) that is programmatically determinable (4.1.2). The name follows the Authoring Practices guidance: **function, not form** (“Save to favourites”, not “Heart”), **verb first**, concise, and **no role word** because the role is announced anyway. On a results page the same button repeats on every card, so each name includes the car's visible title to stay distinguishable out of context. Because the heart toggles, pick one model: a fixed name plus a pressed state, or a name that flips to “Remove from favourites” with no pressed state. A hover tooltip can show the name visually but never replaces it.

go deeper

for a junior

Recall that an icon-only control needs a written accessible name describing its action, verb first, without the word “button”, and that a filled icon alone does not expose state.

for a middle

Explain the two toggle models from the Authoring Practices button pattern, why mixing them confuses, and why repeated controls need the item in their names.

for a senior

Show how a component can compose distinct names from an action plus the item's visible title, and how you would catch drawing-based names that automated checks pass.

for a principal

Argue when a system should require icon-plus-label buttons instead of icon-only ones, weighing density against voice-control guessing and comprehension for sighted users.

## What an accessible name is Every interactive control exposes to assistive technology a **role** (what kind of thing it is, such as a button or a link), an **accessible name** (what it is called) and any **state** (pressed, expanded, checked). A screen reader announces all three; voice-control software lets a user activate a control by speaking its name; and keyboard and switch users often browse a list of controls by name. WCAG 2.2 requires the name in two places: **1.1.1 Non-text Content** (Level A) says non-text content that is a control needs a name that describes its purpose, and **4.1.2 Name, Role, Value** (Level A) says the name and role of every user interface component can be programmatically determined. A button with visible text usually gets its name from that text. An **icon-only** button has no text, so unless someone writes a name it is announced as just “button” — the unlabeled button that interviewers probe. ## Writing the name: function, not form The WAI-ARIA Authoring Practices guidance on composing names fits icon-only controls directly: - **Convey function or purpose, not form.** Its own example: an icon that looks like an X and closes a dialog is named “Close”, not “X”. The heart button is “Save to favourites”, not “Heart”. - **Put the most distinguishing word first**, usually the verb: “Save”, “Share”, “Show on map”. - **Be concise** — one to three words are often enough for a standalone control. - **Do not include the role.** “Save button” is announced as something like “Save button, button”. ## Repeated controls need distinct names A results page repeats the same icon-only buttons on every vehicle card. If all thirty are named “Save to favourites”, a user who pulls up a list of all buttons, or who reaches one without the card's context, cannot tell which car each one saves. The fix keeps the verb first and adds the item: “Save compact hatchback, automatic, to favourites”, using the card's visible title. Many systems build this into the component: it takes a short action name plus a reference to the item's visible title and composes the two. | Name | Problem | |---|---| | (none) | Announced as “button”; unusable | | “Heart” | Describes the drawing, not the action | | “Favourite button” | Duplicates the role; action unclear | | “Save to favourites” on all 30 cards | Right action, indistinguishable in a list | | “Save [car title] to favourites” | Function first, distinct, still short | ## When the button toggles The heart usually toggles between an outline (not saved) and a filled shape (saved). The fill change is visual only, so the state must also be exposed. The Authoring Practices button pattern describes two consistent models: 1. **Fixed name plus a pressed state.** The name stays “Save to favourites” and the control is exposed as a toggle whose pressed state flips; a screen reader says something like “Save to favourites, toggle button, pressed”. 2. **A name that changes, with no pressed state.** The name flips between “Save to favourites” and “Remove from favourites”; the pattern notes that a pressed state is not needed in that design. Mixing the two — changing the name and also marking it pressed — produces “Remove from favourites, pressed”, which reads as a contradiction. A system picks one model and documents it for every toggle icon. ## What does not count as the name - **A hover-only tooltip.** Touch screens have no hover, and a purely visual tooltip gives assistive technology nothing. A tooltip may display the name for sighted users, but the name must exist on the control itself. - **The glyph's file name.** “heart-outline-24” is an implementation detail, and it is what some platforms fall back to when nobody writes a name. - **Nearby text that is not connected.** A caption elsewhere on the card does not name the button unless it is programmatically associated as its label. - **The inner icon's own alternative, left to chance.** The control should carry the name and treat its icon as decorative, so the name is announced once. ## Voice control and the visible icon A voice-control user sees a heart and has to guess what to say. Conventional names (“Save”, “Share”, “Close”) make that guess work, and a visible text label removes the guesswork entirely, which is one reason many systems prefer icon-plus-label buttons where space allows. WCAG 2.2 criterion **2.5.3 Label in Name** (Level A) applies to components whose labels include text: a purely icon-only control has no visible words to match, but the moment the design adds a visible word such as “Save”, the accessible name must contain that text, ideally at its start. The same model holds on native mobile: every platform's accessibility layer reads a control's label, role and state, and the design decision — what the label says and how the toggle state is exposed — is identical.

  • Is a tooltip that shows “Save” on hover enough to label the icon-only heart button?
    No. Touch screens have no hover, keyboard users may never trigger it, and a purely visual tooltip exposes nothing to assistive technology. The control must carry its own accessible name. A tooltip can then show that same name visually for sighted pointer users, which helps them, but it is a supplement to the name, not the name.
  • The design later adds the visible word “Save” next to the heart. What changes for the accessible name?
    WCAG 2.2 criterion 2.5.3 Label in Name (Level A) now applies: the accessible name must contain the visible text, and best practice puts it first. “Save compact hatchback to favourites” passes; a name like “Add to wishlist” fails, because a voice-control user saying the visible word “Save” would not match it.
  • Should the heart's name change to “Saved” once pressed?
    Avoid “Saved”: it describes a state, so the button no longer says what pressing it does. Either keep “Save to favourites” and expose a pressed state, or change the name to the next action, “Remove from favourites”, without a pressed state. Both tell the user the current status and the effect of pressing.

saying these in an interview costs you the question

  • Name the button after its icon, such as “Heart” or “Star”.
  • A tooltip shown on hover is enough on its own to name the button.
  • Adding the word “button” to the name helps screen reader users.
  • Thirty identical save-button names cause no problem for screen reader users.
  • The filled heart alone tells screen reader users the car is saved.