DEV Community

Cover image for I was shocked 😱 that placeholder text on an <input> (instead of a <label>) might TECHNICALLY PASS WCAG⁉ Do you agree?

I was shocked 😱 that placeholder text on an <input> (instead of a <label>) might TECHNICALLY PASS WCAG⁉ Do you agree?

GrahamTheDev on July 15, 2021

Does a placeholder on an &lt;input&gt; without a &lt;label&gt; pass WCAG? From my assessment I would say technically yes...but please don't do it! ...
Collapse
 
cromodder profile image
Paolo Božac

Although I totally agree that placeholders shouldn't be used instead of labels I came to one case which I think is exception - message input. In the case of an message input where it's clear that it's a message input you don't need a visible label, and the placeholder value of "Message" is there with enough color contrast. Then having an aria-label of "Message" can just make the screen readers to read the same thing twice. (Didn't test it in other screen readers, but VoiceOver is smart enough to not read it twice). And the thing is that if you enter some text inside, focus out of the input and then back in, the placeholder will still be announced, so there is no issue.

Image description

Collapse
 
grahamthedev profile image
GrahamTheDev

There is no issue if you have no impairments. But if you are highly anxious, have a learning difficulty etc. then it is beneficial to have an always visible label on the input.

With that being said, the example you used would be fine (as lets face it, that interface is very confusing in of itself so the message input is the least of our concerns there), similarly it is widely accepted that "search" is fine to not have a visible label if there is a search icon next to it (but yet again, it would be beneficial to have one if you can design it in.).

The advice here is for forms with more than a single input really, but you should always try to have a visible label to minimise confusion, increase the tap target area etc. etc.

Collapse
 
cromodder profile image
Paolo Božac • Edited

that interface is very confusing in of itself so the message input is the least of our concerns there

That is a screenshot from the Whatsapp, but this is how it looks pretty much the same for every other chat app out there. So this would mean that there is no single chat app that is accessible? There are other things where Whatsapp fails (having the same icon for sent and delivered status, so they rely on color alone to convey the information) but for the standard message input (I'm talking here also about emoji picker/attachments) I don't know what is confusing? If there would be visible labels for every action it will take a lot of space and it will be everything cluttered which will as a result lead for even worse experience for everyone.

Thread Thread
 
grahamthedev profile image
GrahamTheDev

Accessibility is a scale, and there is no such thing as perfect. The whole thing is about balance.

So in the WhatsApp keyboard there are loads of things that make it less accessible.

Some people cannot recognise iconography and interpret that, so most of the different functions become a guessing game as to what does what.

Some people are highly anxious, so that interface is both overwhelming and also adds a lot of uncertainty (if I click this button, will it send something I don't want it to?) - this is similar with that input box, if the "label" disappears and I go do something else, I may be worried about what information is in that box. (it is worth noting as this is single use and a single input, that is less of a concern, and that is where the balance comes in).

So although for you that interface is fine, for some people it is a nightmare, overwhelming and anxiety inducing.

So that is where a designer / developer should ask themselves questions like:

  • could I have a simplified mode
  • could I have a button that has a full label that shows all the other functions as a list?
  • could I add a scrolling section that has the extra functions in (and then ask yourself if that is more clear or less clear - balance / compromise once again).
  • could I fit a visible label above the input?
  • could I make the buttons bigger (we have people with dexterity / accuracy issues such as people with Cerebral Palsy or Parkinson's).

So the fun part of accessibility is always trying to find a balance between all of these things (and much more) so that you don't make things worse!

The biggest thing I would say about that interface is that an option to have a different layout (that may be larger) coupled with a visible "help" button that I can re-reference would be beneficial not just for those with accessibility needs, but also for those learning the interface for the first time (as you could show the icon next to the text in a list for example). So you could improve UX for everybody.

Just thoughts off the top of my head, but I hope it gives you an idea of how you can think outside of the established norms at ways to make better interfaces while using accessibility as a good guide.

Collapse
 
lexlohr profile image
Alex Lohr

In my personal a11y rules, placeholders should only ever contain the default values of optional fields. That's the only place they make perfect sense. Otherwise, just use a label. There is one exception, though: an <input type="search" placeholder="Search&hellip;">, which is already rather accessible on its own (though it may profit from a separate button).

Collapse
 
grahamthedev profile image
GrahamTheDev

Yeah search is one of those weird exceptions to a visible label, but even then aria-label="search the site" is advised.

Actually a better way is to do it "properly" and do:

<form role="search">
   <!-- your input, submit button (preferable, depending on implementation though) and a visually hidden label using CSS to make it accessible to screen readers but invisible visually -->
</form>
Enter fullscreen mode Exit fullscreen mode

Or use the floating label technique (where the label moves up when the field is focused) if space / design allows.

Collapse
 
grahamthedev profile image
GrahamTheDev

I seriously do hope that somebody can find the missing sentence that explicitly states that you must not use a placeholder and must have a <label>.

If you do let me know and I will update the article!

Collapse
 
alohci profile image
Nicholas Stimpson

I think you're dismissing 3.3.2 incorrectly. It says that the label needs to be provided, it just doesn't require that it be marked up correctly, because that requirement is elsewhere. And a placeholder cannot provide a label because it is unavailable once the user starts entering data into the field.

Collapse
 
grahamthedev profile image
GrahamTheDev • Edited

It doesn't actually state a label must be provided though, it states labels or instructions.

There is no real definition of an instruction so a placeholder could do.

Also when it points you to 1.3.1 that only wants a label to be programatically determinable (which we established a placeholder is).

It also doesn't state a label must always be visible.

I know I am being pedantic and silly but I still find it amazing that I can even argue the point in the first place!

And if we go down this route focusing on 3.3.2 as the centre of our argument then

<p>First Name</p>
<input type="text" placeholder="First Name">
Enter fullscreen mode Exit fullscreen mode

could pass all criteria (I would have to have a think about it as info and relationships might now make the above a fail), and that is nearly as bad!

Collapse
 
auroratide profile image
Timothy Foster

This is pretty funny ( :

I did find that the HTML Living Standard explicitly says the placeholder attribute should not be used as an alternative to a label, but that's not WCAG, so yeah ^^'

Collapse
 
grahamthedev profile image
GrahamTheDev • Edited

Yes and the HTML spec is actually referenced in WCAG on that exact point. But then it goes on to say that a label in that Success Criterion is not the same as a <label> and ruins it! 🤣

I covered that in 2.5.3 as it amazed me that it was so close to being definitive and then back tracked on it!

Collapse
 
grahamthedev profile image
GrahamTheDev

I have added a massive disclaimer just so people don't get the wrong idea. I realised that I didn't cover that you shouldn't do this until a few paragraphs in and if skim reading you might miss it.

It now has pride of place at the start of the article so I hope that clarifies! Thank you for pointing it out!

Collapse
 
grahamthedev profile image
GrahamTheDev

Sorry I really must make my article more clear, this is purely about technicalities and not whether you should or shouldn’t do it.

You should always have a label and unless completely necessary it should always be visible (I.e. an actual label element properly associated with the input)

Do not just use a placeholder alone!!!!!!!

Collapse
 
Sloan, the sloth mascot
Comment deleted
Collapse
 
grahamthedev profile image
GrahamTheDev • Edited

No and I would hope it wouldn't!

But that isn't the point of the article.

For example what rule are the accessibility validators and testers citing when it says it fails? I can almost guarantee they point to one of the 6 Success Criterion I mentioned.

It is more of a thought experiment / critique than something you should actually be doing! (and I really I hope I made that clear otherwise I am adding to the problem instead of just writing an interesting (to me) article🤣 )

It can't be that difficult to write "an <input> should always have a correctly associated <label> or at the very least make use of WAI-ARIA to label the input. For example using either aria-label or aria-labelledby would be sufficient even if a visible and native <label> is strongly encouraged and preferred."

Collapse
 
lexlohr profile image
Alex Lohr

If you enter a field with a default value in it, your input could be appended, which might be unexpected behavior and even more confusing than a placeholder that vanishes if you enter something else.

Thread Thread
 
grahamthedev profile image
GrahamTheDev • Edited

I think @codingsafari meant you should use a real world example of valid input as your placeholder text.

I would say you are both right depending on the circumstances.

So for a search box "Search...." might be applicable (a generic instruction) whereas for a "first name" field it might be better to have "e.g. Mike, Sarah etc." as the placeholder (providing an example of valid input).

For a normal input field, the following is "the ideal" Markup

<label for="dob">Your Date of Birth</label>
<p id="dob-instructions">Please enter your Date of birth in the format DD/MM/YYYY</p>
<input id="dob" type="text" aria-describedby="dob-instructions" placeholder="e.g. 17/01/1994">
Enter fullscreen mode Exit fullscreen mode

As the instructions are visible and clear in the <p>, which is correctly read after the label for screen readers using aria-describedby and we have linked the label to the input correctly (so you can click it to focus the input and screen readers get the info) the placeholder is ideal for an example of valid input.

Also as I said in the article, using old school for attributes on the label is more robust due to issues with voice control software and implicit (wrapped) labels!

Collapse
 
link2twenty profile image
Andrew Bone

Problem solved, right? 🙃

Collapse
 
grahamthedev profile image
GrahamTheDev

Well if you are going to use a label that is cheating!

I both love (for the technicality part of it) and hate this at the same time (as somebody is bound to think this is a good idea lol).

I think this also technically passes, even if I do hate it so so much and want to burn it with 🔥