More Than Just Text: The Real Power of Labels

Have you ever thought about why defining a clear and descriptive label matters so much in accessibility?

Initially, I wondered why visible labels even need to be discussed in accessibility; after all, this is usually the first thing developers add when creating a user interface control. Surely, they’ll label it in a way that makes sense, right? But here’s the catch: what seems obvious to one person isn’t necessarily clear to everyone else.

Let’s consider an analogy. Imagine your best friend, someone whose details you know inside and out, including their address. If I hand you a parcel labeled “Deliver to Your Best Friend,” it’s an easy task for you. But what if the parcel said, “Deliver to My Best Friend”? Now you’re confused, you don’t know who my best friend is.

This is similar to what a new user may experience when navigating an unfamiliar interface. For instance, imagine a field labeled simply “ID.” Is it asking for a national ID number? An employee ID? A student ID?

That’s why providing clear, descriptive labels for all user interface components is so important, so that every user, including those using assistive technologies, can easily understand the purpose of each control. Clear labeling promotes usability, inclusivity, and a more intuitive experience for all.

What is Required?

Success Criterion 3.3.2 Labels or Instructions states:

Labels or instructions are provided when content requires user input.

This seems simple on the surface: if an input field expects the user to take action, there should be a label or instructions present to clarify what is expected. But “labels or instructions” is often interpreted to mean “visible labels or instructions”, and that’s where we run into accessibility problems.

The Limitations of Visible Label

When we talk about “visible labels” in accessibility discussions, we often assume we know what we mean — something visually perceivable on screen that tells users what to do with a form input. But that definition leaves out the needs of a significant portion of users.

• For blind screen reader users, “visible” is irrelevant, and what matters is whether the label is programmatically exposed.
• For users with low vision using magnification software, what matters is that the label is located close enough to the input that the association is clear when content is magnified.
• For voice control users (such as those using Dragon or iOS Voice Control), the label must be both visually present and match the accessible name to support voice-based interaction. A more detailed explanation of the requirement of voice control software can be found in the article: How to Meet SC 2.5.3 – Label in Name.

What About Using Icons as Labels?

For instance, let’s say that a login screen has just two icons, an envelope and a lock, next to inputs with no text. Visually minimal, yes. Usable? Not really.

• Sighted users have to guess what each field is for. Does the envelope mean email or username? Does the lock represent a password or a security code?
• Screen reader users are fine if the icons or inputs have accessible names defined using ARIA attributes like aria-label="Email" and aria-label="Password". If not, the screen reader may well announce unhelpful information like “envelope” and “lock”, if they recognize the icons at all.
• Voice control users are in trouble. Tools like Dragon or iOS Voice Control rely on visible text being included in the accessible name so that users know what to say to interact with the fields.

That’s three user groups with unsatisfactory outcomes from one design choice.

Rethinking What ‘Visible’ Means in Accessibility

In my opinion, we need to stop thinking of labels as “visible” in the context of accessibility, i.e., they should not be limited to what sighted users perceive. Instead, they should be perceivable and operable to users through their preferred mode of access, whether that’s sight, sound, speech, or tactile information.

In everyday conversations, a label is often interpreted as being purely visual. That mismatch between intent and interpretation can create real usability risks and accessibility issues for web content.

So, is a visible label always the same as an accessible label? Not unless it’s both programmatically exposed and perceivable to the user.

Key Considerations Before Defining a Label

There are several important points to keep in mind when defining labels for user interface components:

The Label Must be Perceivable to All Users

As mentioned earlier, every user interface component, such as text fields, dropdowns, and checkboxes, must have a visible and accessible label. When form fields lack meaningful and always-visible labels, users are left to guess what kind of input is expected.

<label for="fname">First Name:</label> 
<input type="text" name="fname" id="fname">

That example would look something like this:

The Label Must be Clear and Descriptive

To help users successfully interact with forms and controls, labels must be clear, accurate, meaningful, and context-specific. A well-crafted label guides users by telling them exactly what is expected or what action will occur, without the need for guesswork.

That doesn’t mean labels must be long. Sometimes a single word or even a single character is enough, as long as it effectively communicates the control’s purpose. The key is to provide just enough context so the user can confidently move forward.

Example: Unclear Date Format

Date input fields can be particularly confusing due to regional differences in formatting:

• United States: MM/DD/YYYY
• Canada: YYYY-MM-DD
• India: DD/MM/YYYY

This inconsistency often leads to misinterpretation. Take this date, for instance — 11/12/2024 — does it refer to 11th December 2024, or 12th November 2024? Without clarification, it can be confusing.

To avoid this ambiguity, the label should explicitly mention the expected format:

<label for="date">Date (dd/mm/yyyy)</label>
<input type="text" name="date" id="date">

Which would look like this:

Note: Form fields are not the only kinds of content that need clear and descriptive labeling; for example, link text is a kind of accessible label that needs to make sense in context, and ideally out of context too. However, that’s beyond the scope of this article.

Labels Must be Persistent

Another critical aspect of accessible labeling is persistence. If a label disappears after the user starts interacting with a form field, it defeats its very purpose. A label should always remain visible to provide ongoing guidance and context

Avoid Using Placeholder Text as the Only Label

Many developers mistakenly use placeholder text as a substitute for a visible label. However, placeholder text has a default behavior; it disappears as soon as the user starts typing or if the field already contains a value.

Imagine a user begins typing in a date field. After entering the first two digits, they pause and wonder:

• Should they enter the day or the month first?
• Should the year be two digits or four?

With no persistent label or visible formatting hint, the only way to check is to delete what they’ve typed to make the placeholder reappear.

Now, consider a common scenario: a user is reviewing their form entries before submission. If placeholder text was used as the only label, and the fields are already filled out, the placeholder disappears, leaving the user with no visible indication of what each field was originally asking for. To verify their input, they may have to guess or even delete the entered content just to see the placeholder again. This creates unnecessary friction for all users.

Instead, a persistent label should be placed adjacent to the field to communicate its purpose. Placeholders can still be helpful, but only as a secondary aid, such as providing input examples or formatting hints (e.g., “abc@example.com” for an email field). For example:

<label for="email">Email:</label>
<input type="text" name="email" id="email" placeholder="abc@company.com">

Which would look like this:

In this case:

• The label “Email:” always remains visible.
• The placeholder serves as an optional hint, not the primary label.

Don’t Use First Option Text as a Label in Dropdowns

Another common mistake is using the first selectable option in a dropdown list as a visual label. This approach works only until the user makes a selection, then the “label” disappears.

For instance, in the following example, the first option, “Select Car,” may seem like a label:

<select name="cars" id="cars">
  <option value="select">Select Car</option>
  <option value="volvo">Volvo</option>
  <option value="saab">Saab</option>
  <option value="mercedes">Mercedes</option>
  <option value="audi">Audi</option>
</select>

Once the user selects a car, the “label” is gone. If the user is reviewing their selection, there’s no longer any context about what the dropdown was asking.

The correct way is to define a persistent label separately:

<label for="cars">Select a Car:</label>
  <select name="cars" id="cars">
  <option value="volvo">Volvo</option>
  <option value="saab">Saab</option>
  <option value="mercedes">Mercedes</option>
  <option value="audi">Audi</option>
</select>

Which would look like this:

With this structure:

• The label “Select a Car:” always remains visible.
• The purpose of the dropdown is always clear, no matter the selected option.

Icons Can Serve as Labels, but With Caution

In some scenarios, text is not the only way to define a label. Icons can also act as visual labels or cues to represent the purpose of control.

For example:

• An “X” icon is commonly understood to mean “Close” or “Clear.”
• A magnifying glass icon is universally recognized as “Search.”

These icons are acceptable as labels only because they are universally familiar, and their meaning is widely understood through repeated use across applications and platforms. However, for these icons to function as accessible labels, they must also include accessible text, such as an aria-label or visually hidden text. This is not only required under WCAG 1.1.1 – Non-text Content, but is also essential for the icon to be programmatically recognized as a label by assistive technologies.

<button type="submit" aria-label="Submit Search">
  <span class="fas fa-search" aria-hidden="true"></span>
</button>
<input id="searchfield" type="text" name="search" aria-label="Search">

Note: Make sure that the icon does not change unexpectedly. For example, in the above-mentioned search field, when the user begins typing in the input field, the magnifying glass icon changes to a cross (X) icon. As a result, sighted users may no longer be able to discern the purpose of the field once text has been entered.

Note: Be careful with less familiar icons. Problems arise when icons are used without accompanying text, and their meaning is not obvious. For instance, if a unique or unfamiliar symbol is used to represent a combo box for “Assignment Type” then users, especially first-time visitors, may not understand its purpose. In such cases, it’s essential to provide a text label that is perceivable by all users, including sighted users.

Conclusion – Bringing It All Together

Clear, consistent, and accessible labels are fundamental to creating inclusive user experiences. While it might seem like a simple matter of adding text near a form field, labels carry far more weight in accessibility than they first appear to.

We’ve seen how misused placeholders, ambiguous icons, or contextless labels can create significant barriers for users. Just as importantly, we explored how the term “visible label” itself can be misleading if it’s only understood visually; true accessibility means making content perceivable and actionable for everyone, regardless of how they access it.

Ultimately, good labeling is not just about conformance, it’s about clarity and usability. By being intentional with how we define and present labels, we reduce friction and ensure our digital spaces are welcoming to all.

Image credit: Chernetskaya