People with disabilities rely on interface controls that are used programmatically. These controls have a visual label, as well as a programmatic label, known as its Accessible Name. Users have a much better experience if the visible text labels of controls match their accessible names.
Speech input users can navigate by speaking the visible text labels of menus, links and buttons that appear on the screen. It’s confusing to speech input users when they say a visible text label they see, but the speech input does not work because the accessible name that is enabled as a speech input command does not match the visible label.
Examples
✗ Bad example:
An icon has no accompanying text, assuming that the function it depicts matches the function that it triggers
✓ Good example:
If an icon has no accompanying text, consider using its hover text (tooltip via title or alt tags) as its accessible name
✗ Bad example:
Accessible name contains the visible label text, but the words of the visible label are not in the same order as they are in the tooltip
✓ Good example:
Accessible name contains the visible label text, which matches the order of the words in the tooltip
✗ Bad example:
The button below each product has the label “Buy.” A screen reader would say “buy,” but this doesn't provide sufficient information to the user to understand which which item to buy.
✓ Good example:
To solve this issue, make the label and the accessible name the same. The aria-label (which is the accessible name) of button should include information such as: “Buy <item name> for <amount>.”
In this example, the accessible name that a screen reader user hears is “Buy <item name> for <amount>.” Any other user also benefits by seeing “Buy <item name> for <amount>”.
(Source: Knowbility article on label in name)