Interactive elements need a high-quality accessible name

Rule accessible-name-quality · Deeper checks · impact moderate · Static + live

↩ Back to the rules index · WCAG cross-reference

Why it matters#

Going beyond "does it have a name?", this rule computes the full ACCNAME 1.2 name and judges its quality. A name that comes only from a title tooltip (not shown on hover for touch/keyboard), only from a placeholder (disappears on input), or that is generic ("button", "click here") technically exists but fails real users.

How to fix#

Provide a visible label or aria-label with a specific, descriptive name. Don’t rely on title or placeholder as the only name.

Example#

<button title="Close"></button>

<button aria-label="Close dialog">×</button>

Example#

<button title="Settings"><span aria-hidden="true">⚙</span></button>

<button aria-label="Settings"><span aria-hidden="true">⚙</span></button>

WCAG success criteria#

4.1.2 Name, Role, Value — Level A#

Every UI component must expose a correct name, role, and (where relevant) state/value to assistive technology.

Understanding 4.1.2

2.4.6 Headings and Labels — Level AA#

Headings and labels must describe the topic or purpose of the content they introduce.

Understanding 2.4.6

1.1.1 Non-text Content — Level A#

All non-text content (images, icons, controls) needs a text alternative that conveys the same purpose, or be marked decorative so assistive tech can ignore it.

Understanding 1.1.1

Standards#

This rule contributes to the following standards:

WCAG A WCAG AA EN 301 549

References#

• W3C — ACCNAME 1.2