WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Placeholder

for

From: Patrick H. Lauke
Date: Mar 11, 2019 1:56PM

On 11/03/2019 19:00, Eilana Benish wrote:
[...]
> I know that the popular screen reader reads the place holder.

Note that this is not the case in all browsers/assistive technology
combinations. Off the top of my head, I seem to remember Internet
Explorer in particular being quite stubborn about not announcing
placeholder in certain situations in combination with JAWS.

> But this
> is mey not be accessible to users with cognitive disabilities.

Indeed. Some of the major problems with just using placeholder to
provide a label for an input are:

- users may mistake the placeholder text for a value that's already
filled-in in the input
- to avoid that, often placeholder text is made very light/low contrast,
but that can lead to placeholder text itself being difficult to read /
have a contrast ratio that falls below the required 4.5:1 minimum (or
3:1 if "large" text)
- once a user has entered information, the placeholder text is not
visible anymore - and, depending on the form, this may well be confusing
as a user returning to that form (e.g. because there was an error and
they're asked to go back and rectify something, or because the form is
there to edit current values, or something) as then they won't see the
placeholder text at all, just a bunch of inputs with some data already
filled in.

Particularly for the last point, to me that's a violation of SC "3.3.2
Labels and Instructions" (as clearly at that point, those inputs lack
any discernible label/instruction).
https://www.w3.org/TR/WCAG21/#labels-or-instructions

Note that HTML5.x itself advises that placeholder should not replace a
proper label
https://w3c.github.io/html/sec-forms.html#the-placeholder-attribute

> The development team thought otherwise and implemented the place holder.
> When I told them to change to standard labels – I got the answer that
> using the Placeholder is WCAG 2 compliant.

I'd say in general developers should move away from the binary
"compliant" vs "non-compliant" mindset (which often leads to achieving
the absolute minimum that allows one to "pass" WCAG 2). There's often
quite a bit of nuance, particularly in the AA and AAA criteria. While
use of placeholder attributes may well pass "4.1.2 Name, Role, Value" as
the form controls generally expose a name (though, as noted, not
consistently in all browser/AT combos), that's not all that's needed
(and yes, accessibility isn't just about "screen reader users").

> I have also tried to find information on the W3C accessibility resources
> – Without success.
>
> So, is the place holder WCAG 2 compliant

WCAG itself is generally quite tech-agnostic, expressed in general
principles and high-level requirements, rather than very specific advice
on "doing this specific thing is a pass / this is a fail". Just because
a particular approach or technique is not explicitly mentioned, doesn't
mean that it's kosher to use it, for instance. What counts is evaluating
a particular specific approach against "can a user still achieve the
desired outcome / does the content still fulfill this high-level
requirement". And there may well be disagreement on some of the finer
points of interpretation, or on how good/bad a particular approach is.

> And what the WCAG 2 working group has to say about that topic?

I'd say if you wanted to know the take of the WCAG 2 WG, you should ask
directly there - <EMAIL REMOVED>

As a (semi absent most times) WG participant, I personally would say
that unless the form in question is super simple, or there are other
aspects that can still provide a hint/clue to users what a form field is
even when the input is filled-in and the placeholder isn't visible
anymore, reliance on just placeholder as a label is a violation of
"3.3.2 Labels and Instructions" when the inputs are filled in.

More importantly, going beyond just "is this a pass or a fail"
territory, there are many usability reasons why reliance on pure
placeholders can be problematic, or at the very least confusing, for users.

Note that the problem of 3.3.2 when fields are filled in can be
mitigated with approaches like floating labels
https://css-tricks.com/float-labels-css/ (hated by some, loved by
others). This still leaves some niggling doubts about whether
placeholder text may be mistaken as an alreay entered value or not by
some users, but it's at least a step towards mitigating one of the
problems inherent with placeholders.

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke