WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Placeholder

for

From: Jim Homme
Date: Mar 11, 2019 2:01PM

Hi,
My experience is that NVDA now speaks the placeholder, even if it disappears. I verified this with a sighted colleague. This makes it difficult to test properly for field labels.

Jim



=========Jim Homme
Digital Accessibility
Bender Consulting Services
412-787-8567
https://www.benderconsult.com/our%20services/hightest-accessible-technology-solutions

-----Original Message-----
From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of Patrick H. Lauke
Sent: Monday, March 11, 2019 3:56 PM
To: <EMAIL REMOVED>
Subject: Re: [WebAIM] Placeholder

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