What is the “accessible name” and why does the preview differ from my aria-label?

The accessible name is the string assistive tech announces for an element, and the browser computes it with a fixed priority order: aria-labelledby first, then aria-label, then a native source (a , alt text, or the element’s visible text), then title as a last resort. If you set several, only the highest-priority one is announced — so an aria-labelledby pointing at empty text can override the aria-label you expected to win. The preview shows the resolved name and which source produced it.

Why does it say my aria-label is being ignored on a ?

aria-label (and title) only name elements that have a semantic role. A bare or has no implicit role, so the attribute is dropped and the element isn’t exposed as nameable at all. The fix is to add an explicit role plus tabindex and keyboard handlers — or, far better, use a native or that already has the role and keyboard behaviour built in.

What is WCAG 2.5.3 “Label in Name” and how does the tool check it?

Success Criterion 2.5.3 requires that an element’s accessible name contains the text that’s visible on it, so someone using voice control can activate it by speaking the visible label. If you give a button visible text “Save” but an aria-label of “Submit form”, voice users saying “click Save” won’t match. When you enter the visible text, the audit warns whenever the spoken name doesn’t include it.

Should I use aria-label or a real for form inputs?

Prefer a visible for inputs. It’s the most robust option: it’s announced reliably, it’s clickable (expanding the hit target), it survives machine translation, and it doesn’t vanish the way a placeholder does. Reach for aria-label only when a visible label is genuinely impossible — and note that a placeholder is never a substitute for a label.

Does it generate React/JSX as well as HTML?

Yes. Toggle the output to JSX and the markup uses htmlFor instead of for and React-style attributes; ARIA attributes themselves are identical across HTML and JSX. You can copy either, and the whole configuration is encoded in the page URL so you can share a ready-made example.

When do landmarks like or actually need a name?

Name a when the page has more than one, so screen-reader users can distinguish “Primary” from “Footer” navigation in their landmarks list. A only becomes a region landmark once it has an accessible name (via aria-labelledby to its heading, or aria-label) — without one it’s skipped. A single, obvious nav doesn’t need a name.

ARIA Label Generator

Don’t just emit an aria-label — see the accessible name a screen reader will actually compute. Pick an element, choose a naming technique, and the tool runs the W3C Accessible Name Computation live: it shows exactly what NVDA/VoiceOver announce (“name, role”), generates copy-paste HTML or JSX, and audits for the bugs people ship every day — missing names, aria-label on a roleless div, and WCAG 2.5.3 Label-in-Name mismatches.

About this ToolHow it works, benefits & use cases

Most ARIA tools just paste an aria-label onto a tag. This one runs the W3C Accessible Name and Description Computation — the same algorithm a browser uses to expose a name to assistive tech — so you see the name a screen reader will actually announce, not just the attribute you typed. Pick an element (icon button, text link, form input, image, SVG icon, nav/search/region landmark, modal dialog, or a custom div control) and choose how it gets its name: aria-labelledby, aria-label, a native <label for>, alt, the element’s visible text, or title. The live preview reads it back the way NVDA or VoiceOver would — “Close dialog, button” — and shows which source won the priority contest. It generates copy-paste HTML or JSX, supports an optional aria-describedby, and audits your choice against the WCAG criteria that apply to that element. Everything is captured in a shareable URL.

How to Use

1Pick the element you’re naming — icon-only button, text link, form input, image, SVG, a landmark, a dialog, or a custom control.
2Choose the naming technique; the recommended one for that element is flagged, and only valid options are shown.
3Type the accessible name (and, when relevant, the element’s visible text so the tool can check WCAG 2.5.3 Label in Name).
4Read the “Screen reader announces” preview to confirm the name and role, and check the audit panel for issues.
5Toggle HTML or JSX, copy the generated markup, or share the URL with a teammate.

Key Benefits

Runs the real Accessible Name Computation — shows the announced “name, role”, not just the attribute
Resolves naming priority (aria-labelledby › aria-label › native › title) so you know which source wins
Per-element technique picker that only offers valid options and flags the recommended one
Catches missing accessible names (4.1.2), aria-label on a roleless <div>, and Label-in-Name mismatches (2.5.3)
Generates copy-paste HTML or JSX, including aria-describedby wiring for supplementary text
Maps each element to the WCAG success criteria it must satisfy
Shareable URL captures the element, technique, and content for handoff

Common Use Cases

Naming an icon-only button so it announces its action instead of just “button”
Deciding between a visible <label>, aria-labelledby, and aria-label for a form field
Distinguishing two <nav> landmarks (“Primary”, “Footer”) so screen-reader users can tell them apart
Checking that a control’s spoken name contains its visible text for voice-control users (WCAG 2.5.3)
Wiring a modal dialog’s name from its visible heading with aria-labelledby

Screen reader announces

“Close dialog, button”

Accessible name: Close dialogRole: buttonFrom: aria-label

Generated markup

Accessible icon-only button — HTML

<button aria-label="Close dialog">
  <svg aria-hidden="true" focusable="false">…</svg>
</button>

No accessibility issues found

Relevant WCAG1.1.14.1.22.5.3

Element

A button with only an icon has no accessible name unless you add one.

How it gets its name

Content

Accessible name / purpose

What the element does or conveys — write it the way you’d say it aloud.

Description (optional → aria-describedby)

Output

A name isn’t whatever you type

Browsers compute an element’s accessible name with a fixed priority order: aria-labelledby beats aria-label, which beats a native source (<label>, alt, or visible text), which beats title. If you stack several, only the highest-priority one is announced — a common reason “my aria-label isn’t working”. This tool resolves that chain for you and shows the winner.

The three bugs it catches

No accessible name — an icon-only button that announces just “button” (fails 4.1.2).
aria-label on a bare div — silently ignored because a <div> has no role.
Label in Name — a spoken name that doesn’t contain the visible text, so voice-control users can’t target it (2.5.3).

Was this tool helpful?

Share Your Experience

Help others discover this tool!

Share on

ARIA Label Generator

How to Use

Key Benefits

Common Use Cases

Screen reader announces

Element

How it gets its name

Content

Output

A name isn’t whatever you type

The three bugs it catches

Was this tool helpful?

Share Your Experience

Related tools

Frequently Asked Questions - ARIA Label Generator