ARIA input fields must have an accessible name
Accessibility isn’t only about avoiding violations — it’s about ensuring your product can be used confidently by everyone. This guide explains the principle of this rule, shows what goes wrong in real-world code, and provides a verified fix that meets WCAG and the European Accessibility Act (EAA).
Why this matters and how to fix it
Why this matters
Every form control or input field must have an accessible name so assistive technologies can communicate its purpose to users. Without a name, screen reader users will only hear a generic control type, such as 'edit text,' without context for what information is expected. This leads to confusion, form abandonment, and critical accessibility failures in login, checkout, or registration workflows.
How to fix this issue
Add an accessible name using a visible label, aria-label, or aria-labelledby attribute. The label should describe the field’s purpose clearly and concisely, such as 'Email address' or 'Search site.' Avoid redundant naming such as 'Search search field.' Verify with a screen reader that each input’s name is announced correctly when navigating forms.
Developer guidance
This error frequently arises when developers replace native inputs with custom-styled ARIA widgets. In large systems, enforce accessible naming in your component library — every custom input component should require a name or label prop. Add form testing scripts using Playwright + axe-core or jest-axe to automatically detect missing names in CI.
Code examples
Incorrect Implementation
<div role="textbox"></div>Correct Implementation
<div role="textbox" aria-label="Search"></div>
Trusted by organizations across Europe working toward WCAG and EAA conformance