ARIA Labels

The `aria-label` attribute directly provides an accessible name for an element when an appropriate visible label or native labeling mechanism is unavailable. It should be used selectively because visible text and native HTML labeling are generally preferable when they can provide the same accessible name.

An accessible name is the text assistive technologies can use to identify a UI control. `aria-label` lets an author explicitly supply that name, such as giving an icon-only button the label "Close".

Use `aria-label` when an element needs an accessible name but there is no suitable visible text to reference. Common examples include icon-only buttons, where the visual icon communicates the action but contains no usable text.

Prefer native HTML labeling and visible text when available. For example, a `<label>` associated with an `<input>` can provide the control's accessible name, while a button containing visible text such as `<button>Save</button>` normally does not need an `aria-label`.

An `aria-label` value is not intended to provide visible text. It can also override or compete with other naming mechanisms, so adding it indiscriminately can make accessibility behavior harder to maintain and can create confusing names for assistive technology users.

Key points

• Use `aria-label` to provide an accessible name when suitable visible or native labeling is unavailable.
• Icon-only controls are a common appropriate use case.
• Prefer visible text and native HTML labeling mechanisms when they can provide the name.
• The attribute affects the accessible name; it does not create visible text.
• Avoid adding redundant or conflicting labels without a specific accessibility reason.

Interview questions

What is `aria-label` used for?

`aria-label` provides an accessible name for an element. It is particularly useful when the element has no suitable visible text, such as an icon-only button. The supplied value can be exposed to assistive technologies as the control's name. I would prefer native HTML or visible text when those mechanisms can provide the same name.

Why is `<button>Save</button>` usually preferable to `<button aria-label="Save">Save</button>`?

The first version already has meaningful visible text that can provide the button's accessible name. Adding `aria-label` is redundant and can create an unnecessary alternative naming mechanism. Keeping the name in visible text also ensures sighted users and assistive technology users receive the same label. I would add `aria-label` when the needed accessible name is not otherwise available.

How would you make an icon-only close button accessible?

I would use a native `<button>` and give it an accessible name such as `aria-label="Close dialog"` if there is no suitable visible label. The button should still have the normal keyboard and interaction behavior provided by the native element. The label should describe the action rather than the graphical symbol itself. I would also verify the result with accessibility inspection or a screen reader.

What is the difference between `aria-label` and `aria-labelledby`?

`aria-label` supplies the accessible name directly as a string in the attribute. `aria-labelledby` instead points to other elements whose text is used to construct the accessible name. `aria-labelledby` is useful when an existing visible heading or label should also serve as the accessible name. When appropriate visible text already exists, referencing it can avoid duplicating the same wording.

What accessibility principle should guide your use of ARIA labels?

ARIA should solve a specific naming or semantics problem rather than being added mechanically. I would first use native HTML semantics and meaningful visible text, then choose an appropriate ARIA naming mechanism when those options do not meet the requirement. I would ensure the resulting accessible name matches the control's purpose and is consistent with what users can perceive. Finally, I would verify the computed accessibility tree and test important interactions with assistive technology.