Accessibility of Labelless Inputs

When reading about web accessibility, you tend to hear a couple of axioms repeated over and over, like:

Always provide labels for your inputs

Truthfully, web accessibility is an ongoing practice that can’t be boiled down to a few tips. However, I’ve always felt this tip in particular was a Golden Accessibility Truth no one could argue against. Have an input? You always need a label. No matter what.

Right?

In most cases, this is a pretty easy guideline to follow: you generally want a label with your inputs to help users understand your form.

But what about the cases where you don’t want a label?

For example, check out this search form:

The additional “Search Query” label is so visually redundant: it’s likely understood by users that whatever they enter into the search box will serve as the query for their search. In fact, this is a pattern ingrained into the brains of most users by search engines:

Dropping the Label

So how should we go about getting rid of the label?

The first option is to simply drop it it; take it out of the markup altogether. And, actually, there is a WCAG 2.0 accessibility technique (G167) suggesting just that:

When a button invokes a function on an input field, has a clear text label, and is rendered adjacent to the input field, the button also acts as a label for the input field. This label helps users understand the purpose of the field without introducing repetitive text on the Web page. Buttons that label single text fields typically follow the input field.

However, despite this general recommendation, you don’t want to just drop the label altogether.

Eric Mayes and I conducted some tests and confirmed that, while the field’s purpose is visually obvious, it’s not at all obvious at first to a user with a screenreader.

Take the following markup for our simple search bar with a label:

<label for="query">Search Query</label>
<input type="text" name="query" id="query">
<input type="submit" value="Search">

Encountering this, the screenreader says the following when the text input field gains focus:

Search Query, Edit Text

(The “Edit Text” piece varies from screenreader to screenreader and browser to browser, but the basic idea is that the label is read first)

Let’s try just popping out the label:

<input type="text" name="query" id="query">
<input type="submit" value="Search">

The screenreader says (as you might expect):

Edit Text

Of course, once we tab over to the adjacent search button, the screenreader will announce the search button and we’ll understand what the previous field was all about; but up until that point, we’re in the dark.

So, to that end, we do want to include some kind of label, we just don’t it to display visually.

Hiding the Label

Our first option to include the label in the markup but not visually, is to use the ol’ standby of just shoving the label offscreen with CSS:

/* Source: http://webaim.org/techniques/css/invisiblecontent/#absolutepositioning */
.hidden
{
  height: 1px;
  left: -10000px;
  overflow: hidden;
  position: absolute;
  top: auto;
  width: 1px;
}

With this approach, the label element is absolutely positioned and then pushed way outside the screen. This works really well: the label acts just as a label should for screenreaders and our search form is left visually clean.

But doesn’t it just feel gross somehow?

I mean, the web is moving forward at full speed: we have native responsive images. JavaScript on the client-side and server-side. Browser support for virtual reality.

And our de facto solution for this classic problem in front-end web development is: “I don’t know, just put it somewhere you can’t see it.”

Label Without a Label

So can we visually hide the label using a less hacky technique?

The first candidate is the title attribute:

<input type="text" name="query" id="query" title="Search Query">
<input type="submit" value="Search">

There’s a lot of caution against using the title attribute since it’s not accessible across the board (for example, it historically hasn’t held up well for a elements).

However, the case of the visually-redundant-label is special. From one one article cautioning against the title attribute:

Only use it to label a form control when the same text is provided as visible text.

And another:

Providing a programmatically associated label for a control in situations where a visible text label would be redundant

The WCAG 2.0 accessibility technique H65 also explicitly includes this very example:

A Web page contains a text field where the user can enter search terms and a button labeled “Search” for performing the search. The title attribute is used to identify the form control and the button is positioned right after the text field so that it is clear to the user that the text field is where the search term should be entered.

Furthermore, our tests demonstrated that this works quite well as a pseudo-label: with a sampling of the latest screenreaders across a sampling of the latest browsers, the title attribute was always read as if it were a label.

However, title also exhibits this specific behavior where it causes a tooltip to appear (often on mouse hover, sometimes on keyboard focus):

We’re definitely better off than we were before: we’ve got a screenreader-accessible label without any CSS hacks. But the fact that title is considered brittle for accessibility and that looming tooltip make me nervous: can’t we do better than title?

ARIA to the Rescue

We can!

The Accessible Rich Internet Applications (ARIA) standard provides us with a new HTML attribute that we can use in this situation, aria-label:

<input type="text" name="query" id="query" aria-label="Search Query">
<input type="submit" value="Search">

Given that it’s a relatively new attribute, there are fewer recommendations for this technique: both the WCAG Working Group wiki and MDN recommend this approach, although the recommendations are bare-bones nods to the idea, couched in caveats about the volatility of screenreader support.

However, at least in our limited tests (with the latest screenreaders and the latest browsers), aria-label, like title, performed just as well as a regular label.

For now, I think the most forward-looking recommendation is the use of aria-label. More testing is needed to confirm an acceptable level of support for the attribute, but our run of tests was promising.