Does using a placeholder as a label comply with WCAG 2?

Question

I get that using placeholder text as a label is not very accessible, but does it technically go against WCAG 2? I could not find anything explicit but I wonder if a more lawyerly reading of that standard would find something in there.

Answer 1

Read first: this is not a suggestion that you should use a placeholder instead of a label, more of a thought experiment as to whether a placeholder is sufficient under WCAG guidance. If you do use a placeholder instead of a label then your site is not accessible as I have stated in hundreds of answers before. If you ever get sued for discrimination I doubt anything in this answer will help you (and neither should it).

To be clear - use a visible and correctly associated label! /endRant hehe.

Short Answer

A placeholder only and no label more than likely DOES comply with WCAG 2.1, but who knows with all the conflicting guidelines.

You would think in tens of thousands of words there would be a line that says "use a label" or "a placeholder only input would fail this criterion" but I couldn't find it.

The following may be hard to read as I read every page I could find to get a definitive answer so it could be a bit disjointed, apologies!

Onto the question

OK so lets assume we do not care about usability for a second and focus on the "letter of the law" with regards to WCAG 2.1, as it is an interesting question.

Now let's also assume we are talking purely about standard <inputs> and <textarea>s to make this easy (as checkboxes, selects etc. all definitely need labels), plus they are the only ones that accept a placeholder value anyway (I think?!).

What rules apply to inputs and labels that may be relevant?

The ones that are relevant here are 1.1.1 Non-text Context, 1.3.1 Info and Relationships, 2.4.6 Headings and Labels, 3.3.2 labels or instructions and 4.1.2 Name, Role, Value. I later found 2.5.3: Label in Name.

1.1.1

Controls, Input: If non-text content is a control or accepts user input, then it has a name that describes its purpose.

Now technically a standard <input> isn't quite covered here, this criterion is more for things like images used as buttons, custom controls etc.

However if we assumed that we could stretch 1.1.1 to cover an <input> is there anything in this criterion that means we can't use a placeholder (or have to have an associated label).

If you read the whole page there is not one specific mention of a <label> element needing to be used on a form control.

outcome: so far no answer either way

1.3.1

Checking 1.3.1 - although it mentions labels, it does not specifically mention the <label> element anywhere. It also states that it is a "judgement call" as to whether relationships should be programmatically determined or presented in text.

There may also be cases where it may be a judgment call as to whether the relationships should be programmatically determined or be presented in text. However, when technologies support programmatic relationships, it is strongly encouraged that information and relationships be programmatically determined rather than described in text.

outcome: no definitive answer either way

2.4.6

Now we can discount 2.4.6 Headings and labels as that only requires labels are descriptive, it does not specifically state labels must be provided.

outcome: not relevant

3.3.2

Now we are talking, "labels or instructions" must give us some concrete answers, right?

This Success Criterion does not require that labels or instructions be correctly marked up, identified, or associated with their respective controls.

Well that is annoying, no answer here!

In fact it it points us back to 1.3.1, which we already looked at and determined there was no definitive answer.

It also points us to 4.1.2 - maybe we will have some look with that criterion?

outcome: not relevant

4.1.2

Right, this must be it! It starts out on the right track at least!

For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined;

Now the key part of this is "programmatically determined".

Ok so what is the definition of "programmatically determined"?

determined by software from author-supplied data provided in a way that different user agents, including assistive technologies, can extract and present this information to users in different modalities

Well now we might be onto something. Can different user agents and assistive technologies extract the placeholder information? Is it a valid labelling technique?

outcome: still no definitive answer

This is where we find the relevant WCAG recommendation finally (or do we?)

Success Criterion 2.5.3: Label in Name

2.5.3 label in name must be the confirmation we are looking for, surely.

Note that placeholder text within an input field is not considered an appropriate means of providing a label. The HTML5 specification states The placeholder attribute should not be used as an alternative to a . However, it is worth noting that "label" in that HTML5 statement is in code brackets and links to the label element. For the purposes of this Label in Name Success Criterion, "label" is not used in such a programmatic sense but is simply referring to a text string in close visual proximity to a component. As such, in the absence of any other nearby text string (as described in the preceding list), if an input contains placeholder text, such text may be a candidate for Label in Name. This is supported both through the accessible name calculation (discussed later) and from the practical sense that where a visible label is not otherwise provided, it is likely that a speech-input user may attempt to use the placeholder text value as a means of interacting with the input.

Within all of that rambling (as you can tell I am sick of reading the convoluted and unclear guidelines.) it says something interesting.

"if an input contains placeholder text, such text may be a candidate for Label in Name."

And with that we would have a "programmatically determined" name for the control. (see next heading)

side note on the paragraph above: The part "Note that placeholder text within an input field is not considered an appropriate means of providing a label." would lead you to believe that a placeholder is not valid as a label.

It also states that "The HTML5 specification states The placeholder attribute should not be used as an alternative to a <label>."

Now to me that would be enough to persuade you to use a label.

However yet again, WCAG says that a webpage should be "valid HTML" (under SC 4.1.1 - Parsing).

So is an <input> with a placeholder valid HTML? Well the answer (according to the W3C validator is yes! The following is valid HTML!

<html lang="en">
  <head>
    <title>test</title>
  </head>
  <body>
    <form>
      <input placeholder="test"/>
    </form>
  </body>
</html>

So if it is valid, I would say that is technically acceptable.

The accessible name computation

I got side-tracked there for a second. I was talking about the fact that a placeholder attribute is a valid candidate for an accessible name computation.

Here it is, the accessible name computation for an <input>. There relevant point is point number 4:

4. Otherwise use the control's placeholder attribute.

OK so placeholder is valid for "programatically determinable", but doesn't a label have to be visible?

Interestingly you do not have to have a visible label for 1.1.1, 1.3.1 and 4.1.2 so we can't use that argument as to needing an actual label.

Taken from H44: Using label elements to associate text labels with form controls

This technique (associating a label with an input) is sufficient for Success Criteria 1.1.1, 1.3.1 and 4.1.2 whether or not the label element is visible. That is, it may be hidden using CSS.

With that being said the next sentence....

However, for Success Criterion 3.3.2, the label element must be visible since it provides assistance to all users who need help understanding the purpose of the field.

But in 3.3.2 although it has to be visible, it doesn't have to be correctly marked up (remember, I did say it a long time ago!).

So there is all the relevant information I could find in WCAG and the outcome is still fuzzy, but with that being said I do have a conclusion for you!

Conclusion

Nowhere in WCAG does it explicitly state that a placeholder cannot be used as a label.

WCAG also states that a title can be used to label an input and that is worse than a placeholder.

It is possible I have missed a key sentence somewhere that would tie it all together but from what i have read I believe (very surprisingly!!) that it is valid under WCAG 2.1 to only have a placeholder on an <input>.

Obviously as I stated several times DO NOT USE A PLACEHOLDER ONLY ON AN INPUT as it is not accessible to a lot of users (people with anxiety disorders or learning difficulties really hate inputs with placeholder labels as the label disappears when they type so they can't check they have filled the correct field in without deleting everything), some screen reader and browser combinations do not work with them etc.

Answer 2

Real short answer: it's not sufficient to satisfy all success criterion

2.5.3: Label in Name states that the placeholder may be candidate for "Label in name".

This does not mean that this would satisfy 3.3.2 Labels or Instructions.

This is expained by the WAI:

While placeholder text provides valuable guidance for many users, placeholder text is not a replacement for labels. Assistive technologies, such as screen readers, do not treat placeholder text as labels.

The SC 3.3.2 does require a visible label (text or icon, eg. a Search form with a a magnifying glass button) or instructions.

This has also been discussed on the WCAG github about "hidden labels".

If you object that a placeholder is not "hidden", it won't be the case anymore once the field has been filled and it might be difficult to understand its meaning when using a screen magnifier for instance). It is also subject to browser autofill feature.

So using a placeholder, in fact, does not go against WCAG, it's just not sufficient : the 2.5.3 SC will be inapplicable when the placeholder is not visible and 3.3.2 will fail unless instructions or other techniques are used.