A webpage is not always broken because of a large mistake. Small details can produce exactly this problem: debugging: screen reader announces wrong label. This guide shows you what to look for, a concrete fix, and how to check that it worked.
The Idea in Plain English
A control can receive the wrong name when for points to the wrong ID or an aria-label hides its visible label.
Try the example with a keyboard and an accessibility inspector. Visible appearance alone does not tell you whether its meaning is announced correctly.
A Working Example
The first part shows a problem. The second part shows a safer or more accurate version. Compare them before reading the explanation.
<!-- Problem -->
<label for="phone">Email</label>
<input id="email" type="email">
<!-- Corrected example -->
<label for="email">Email address</label>
<input id="email" name="email" type="email">What Each Part Does
- The label tells visitors and assistive tools what a control is for.
- The input creates a field; its type changes the editing controls and the name identifies submitted data.
- for connects a visible label to the control with the same ID.
- id names an element for labels, fragments, CSS or JavaScript; IDs should be unique.
- type chooses the relevant kind of script, input, media or embedded object.
Before the fix, the browser can behave incorrectly or report a warning. After the change, test the exact failure rather than assuming the page is fixed.
Try It Yourself
Inspect the Accessibility panel to confirm the name is Email address.
Common Beginner Mistakes
- Check the underlying cause before changing unrelated tags.
- Changing several parts of the example at once, making it difficult to see which part caused a different result.
- Choosing a tag only because its default appearance looks right, without checking whether it describes the content correctly.
Key Takeaways
- A control can receive the wrong name when for points to the wrong ID or an aria-label hides its visible label.
- Before the fix, the browser can behave incorrectly or report a warning. After the change, test the exact failure rather than assuming the page is fixed.
- Test the markup in a browser, and check accessibility and real-world behavior where relevant.