 Rob Dodson [X](https://twitter.com/rob_dodson) [GitHub](https://github.com/robdodson) [Homepage](https://robdodson.me)
In order for a screen reader to present a spoken UI to the user, meaningful
elements must have proper labels or text alternatives. A label or text
alternative gives an element its accessible **name** , one of the key properties
to [express element semantics in the accessibility tree](https://web.dev/articles/semantics-and-screen-readers#semantic_properties_tree).
When an element's name is combined with the element's **role**, it gives the
user context so they can understand what type of element they're interacting
with and how it is represented on the page. If a name is not present, then a
screen reader only announces the element's role. Imagine trying to navigate
a page and hearing, "button," "checkbox," "image" without any additional
context. This is why labeling and text alternatives are crucial to a good,
accessible experience.
## Inspect an element's name
You can check an element's accessible name in Chrome's DevTools:
1. Right-click on an element and choose **Inspect**. This opens the DevTools Elements panel.
2. In the Elements panel, look for the **Accessibility** pane. It may be hidden behind a `>>` symbol.
3. In the **Computed Properties** drop-down, look for the **Name** property.
 DevTools accessibility pane showing the computed name for a button.
> [!TIP]
> **Tip:** Read all of DevTools [Accessibility resources](https://developer.chrome.com/docs/devtools/accessibility/reference).
Whether you're looking at an `img` with `alt` text or an `input` with a
`label`, all of these scenarios result in the same outcome: giving an
element its accessible name.
## Check for missing names
There are different ways to add an accessible name to an element,
depending on its type. The following table lists the most common element types
that need accessible names and links to explanations for how to add them.
| Element type | How to add a name |
|---|---|
| HTML document | [Label documents and frames](https://web.dev/articles/labels-and-text-alternatives#label_documents_and_frames) |
| `` or `
While an `iframe`'s contents may contain their own internal `title` element, a
screen reader usually stops at the frame boundary and announces the element's
role---"frame"---and its accessible name, provided by the `title` attribute. This
lets the user decide if they want to enter the frame or bypass it.
## Include text alternatives for images and objects
An `img` should always be accompanied by an
[`alt`](https://developer.mozilla.org/docs/Web/HTML/Element/img#Attributes)
attribute to give the image its accessible name. If the image fails to load, the
`alt` text is used as a placeholder so users have a sense of what the image was
trying to convey.
Writing good `alt` text is a bit of an art, but there are a couple of guidelines
you can follow:
1. Determine if the image provides content that would otherwise be difficult to attain from reading the surrounding text.
2. If so, convey the content as succinctly as possible.
If the image acts as decoration and does not provide any useful content,
you can give it an empty `alt=""` attribute to remove it from the accessibility
tree.
> [!NOTE]
> **Note:** Learn about writing effective `alt` text in [WebAIM's guide to Alternative Text](https://webaim.org/techniques/alttext/).
### Images as links and inputs
An image wrapped in a link should use the `img`'s `alt` attribute to describe
where the user will navigate to if they click the link:
Similarly, if an `` element is used to create an image
button, it should contain `alt` text that describes the action that occurs when
the user clicks on the button:
### Embedded objects
`
