Why should every form input have a <label>?
Importance of <label> for Form Inputs
Every form input should have a <label> to ensure accessibility, clarity, and usability. Labels provide a clear, descriptive name for the input, which is essential for all users, especially those using screen readers.
- 1
Screen reader support –
<label>allows assistive technologies to announce the purpose of the input. - 2
Clickable area – Clicking the label focuses the associated input, improving usability.
- 3
Form clarity – Labels provide context for what data is expected, reducing errors.
- 4
Keyboard navigation – Helps users navigate forms efficiently using Tab and Shift+Tab.
- 5
Consistency – Supports standardized accessibility practices across web forms.
- 1
Associate the label using the
forattribute pointing to the input'sid:<label for="email">Email:</label><input id="email" type="email"> - 2
Alternatively, wrap the input inside the label:
<label>Email: <input type="email"></label> - 3
Ensure label text is clear, concise, and descriptive.
- 1
Never rely solely on placeholders as labels; they disappear on focus and may not be read by screen readers.
- 2
Use visible text for labels whenever possible.
- 3
Combine labels with
aria-describedbyif additional instructions are needed.
Scenario Questions
0-2 years experience
- 1You need to add an email input on a signup page. How would you write the HTML so that a screen reader can identify the field correctly?
- 2If you forget to add a <label> to a checkbox, what problems might a user encounter?
- 3Show me the markup for a password field with a proper label and explain why you chose that structure.
2-5 years experience
- 1Our legacy forms have many inputs without <label> elements, and adding ARIA attributes didn't fully fix the issue. How would you remediate the problem?
- 2During a UI audit you notice that clicking a radio button's label doesn't select the option. What could be causing that, and how would you fix it?
- 3Explain the trade‑offs between using a <label> with a 'for' attribute versus wrapping the input inside the label.
5-8 years experience
- 1You're leading a redesign of an enterprise app with thousands of forms. How would you enforce consistent use of <label> across teams and ensure accessibility compliance at scale?
- 2When building a custom component library, how do you guarantee that your components expose proper label associations for both native and custom inputs?
- 3Discuss any performance or SEO implications of missing labels in a high‑traffic checkout flow and how you would mitigate them.
8+ years experience
- 1Our front‑end is moving to a micro‑frontend architecture. How would you design shared accessibility guidelines and tooling to ensure every form input across all micro‑frontends has an appropriate label?
- 2If we must support legacy browsers that don't fully honor the 'for' attribute, what strategy would you adopt to maintain label functionality without breaking existing code?
- 3We are building a form builder for non‑technical users. How would you design the UI and data model so that generated forms always include correct <label> associations and prevent user errors?
Follow-up Questions
- How does a label improve keyboard navigation for form controls?
- What are the differences between using the 'for' attribute and wrapping the input inside a label?
- If a required field lacks a label, what accessibility issues arise and how would you detect them?