Field Guide
Labels and Names
Labels and names are the text that assistive technology reads out when a user encounters a button, link, or form field — without them, screen readers and voice control tools cannot tell users what an interactive element does.
Why it matters for your site
When a screen reader encounters a button, it announces the button's accessible name. If that name is empty — because the button has no visible text and no aria-label — the screen reader announces only 'button'. A user navigating by keyboard or voice has no way to know what it does, so they cannot use it.
This affects users with visual impairments and motor disabilities who rely on screen readers or voice control tools. For them, an unlabelled control isn't inconvenient — it's a hard block. The EU Accessibility Act (2025) and WCAG 2.2 AA both require accessible names on interactive elements.
Form labels have a secondary effect beyond assistive technology: browsers use explicit label associations to power autocomplete. A field that isn't correctly labelled is often skipped by autofill — adding friction for every user, not just screen reader users.
How to check it yourself
- In Chrome, right-click any button, link, or form field and choose Inspect. In the Elements panel, open the Accessibility pane and look at Computed Properties → Name. If the name is empty or just the element type, that element needs a label.
- The axe DevTools browser extension (free) audits an entire page at once. It flags all five of the naming violations that Kweri checks and shows you exactly which elements are affected.
- On macOS, enable VoiceOver (Cmd+F5) and Tab through your page. Listen to what each button, link, and form field announces. If you hear only 'button' or 'text field' with no further description, that element is missing an accessible name.
- The Kweri accessibility audit runs automated axe checks and surfaces these violations in the Accessibility section of your report.
Technical detail
button-name: Every <button> and element with role='button' must have an accessible name. It can come from visible text content, an aria-label attribute, or an aria-labelledby reference. Icon-only buttons without any of these are the most common violation.
link-name: Every <a> element must have discernible link text. Linked images need alt text to serve as the accessible name. Generic text like 'click here' technically passes the check but is poor practice — the name should describe where the link goes.
label: Every <input>, <select>, and <textarea> must have an associated label — via a <label for='id'> pairing, an aria-label, or an aria-labelledby. Placeholder text does not satisfy this requirement: placeholders disappear when the user starts typing and are not reliably announced by all screen readers.
aria-required-attr: When an element uses an ARIA role, any attributes that role requires must be present. For example, a role='checkbox' requires aria-checked. Missing required attributes leave the element in an incomplete state that assistive technology cannot interpret correctly.
aria-allowed-attr: ARIA attributes must be ones permitted for the element's role. Using an attribute on the wrong role — for example, aria-checked on a plain text input — causes screen readers to misinterpret the element's state.
For the rule detail: buttons must have an accessible name, see Deque — button-name rule →
For the rule detail: links must have discernible text, see Deque — link-name rule →
For the rule detail: form elements must have associated labels, see Deque — label rule →
For the rule detail: required ARIA attributes must be provided, see Deque — aria-required-attr rule →
For the rule detail: ARIA attributes must conform to the element's role, see Deque — aria-allowed-attr rule →
Related
Every image, icon, or non-text element that conveys meaning must have a text alternative that communicates the same information to users who cannot see it.
Web accessibility is organised around four principles: content must be Perceivable, Operable, Understandable, and Robust — failure on any one principle makes content inaccessible to some users.
Keyboard focus must be visible at all times, move in a logical order, and be actively managed when content changes — especially when modals open, overlays appear, or dynamic content updates.
See Labels and Names on your own site
Run a free Kweri audit — a plain-English review of your site’s speed, accessibility, SEO and design, ranked by what to fix first. No login, no jargon.
Run a free audit →