Does a placeholder on an <input> without a <label> pass WCAG? From my assessment I would say technically yes...but please don't do it!
...
For further actions, you may consider blocking this person and/or reporting abuse
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…">, which is already rather accessible on its own (though it may profit from a separate button).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:
Or use the floating label technique (where the label moves up when the field is focused) if space / design allows.
I seriously do hope that somebody can find the missing sentence that explicitly states that you must not use a
placeholderand must have a<label>.If you do let me know and I will update the article!
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.
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
placeholdercould do.Also when it points you to 1.3.1 that only wants a label to be programatically determinable (which we established a
placeholderis).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
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!
This is pretty funny ( :
I did find that the HTML Living Standard explicitly says , but that's not WCAG, so yeah ^^'
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!
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!
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!!!!!!!
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 eitheraria-labeloraria-labelledbywould be sufficient even if a visible and native<label>is strongly encouraged and preferred."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.
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
As the instructions are visible and clear in the
<p>, which is correctly read after the label for screen readers usingaria-describedbyand we have linked the label to the input correctly (so you can click it to focus the input and screen readers get the info) theplaceholderis ideal for an example of valid input.Also as I said in the article, using old school
forattributes on the label is more robust due to issues with voice control software and implicit (wrapped) labels!Problem solved, right? 🙃
Well if you are going to use a
labelthat 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 🔥