Perspective

A control has no useful accessible name

The control is present and operable, but its purpose is missing, vague or misleading when exposed to assistive technology.

A button can look completely obvious and still be difficult or impossible to identify through another interaction mode.

An icon-only button showing a familiar trash-can symbol, for example, may visually communicate “Delete”. If its accessible name is missing, a screen reader may announce only “button” — or expose an implementation detail that is no more useful.

What happens

The user can reach a control, but cannot reliably determine what it does from the information exposed to them.

This is not limited to screen readers. Useful programmatic names can also matter to speech-input users who need to identify a control by name.

Why it matters

Being technically focusable or clickable is not enough. A person needs enough information to decide whether activating a control will do what they intend.

The cost is particularly high for destructive or consequential actions such as Delete, Pay, Send or Submit.

Who may encounter it

This barrier may affect, among others:

• screen-reader users;
• speech-input users;
• people using alternative interfaces built from the accessibility tree;
• testers and support staff trying to understand an interface non-visually.

This list is not exhaustive.

How to test it

1. Inspect the control semantically

Ask what role, name and state are exposed — not merely what text appears visually.

For a native HTML button, visible text usually supplies the accessible name automatically. Icon-only controls need an equivalent name from an appropriate source.

2. Navigate without relying on the visual icon

Using a screen reader, move to the control and listen to what is announced.

Could you understand the action if you could not see the icon?

3. Check that the name describes the action

“Button”, “icon”, a filename, or an internal component name is not useful.

A good name communicates purpose. Context still matters: several buttons all named “Delete” may need additional context if the user cannot determine what each one deletes.

Can automation detect it?

Partially.

Automated rules can identify many interactive elements with no programmatically determinable accessible name. They cannot reliably decide whether an existing name is clear, accurate or sufficiently contextual.

A passing automated rule therefore establishes less than “this control has a good accessible name.”

Relevant WCAG

This barrier commonly relates to WCAG 2.2 Success Criterion 4.1.2 — Name, Role, Value.

Depending on the implementation and visible label, other criteria may also be relevant. The WCAG mapping should follow the actual failure rather than being treated as a diagnosis from the symptom alone.

How to fix it

Prefer native controls and visible text when they fit the design.

For an icon-only button, provide a concise programmatic name that describes the action. Do not add ARIA when the native HTML already exposes the correct semantics and name.

Then test the result through the accessibility tree and with representative assistive technology.

What a pass does not prove

A correctly named button does not prove that:

• the surrounding workflow is understandable;
• focus moves appropriately after activation;
• the resulting status is announced;
• the action is easy to recover from;
• the touch target is large enough;
• the overall experience is usable.

It proves one important thing about one control.

Follow the evidence trail

• Standard: WCAG 2.2 — 4.1.2 Name, Role, Value
• Test it: Screen-reader testing as a task, not a tour
• Try it: What does this button tell you?
• Evidence limit: a correct accessible name does not establish that the control is understandable, reachable or usable in context.