E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 11 (In chronological order)

From: Jesse Hausler
Date: Fri, Mar 20 2015 10:56AM
Subject: Placeholder text contrast
No previous message | Next message →

If placeholder text is being used properly (input masks, giving examples,
etc) and visible form labels are present, does the placeholder text need to
meet contrast ratios?

Browser defaults appear to be 2.2:1 or so... Are people expected to
override browser defaults?

Our usability studies found that people thought that form fields were
already filled out when placeholder text color met 4.5:1.

Thanks,
Jesse

From: Andrew Kirkpatrick
Date: Fri, Mar 20 2015 11:46AM
Subject: Re: Placeholder text contrast
← Previous message | Next message →

Jesse,

The WCAG group added a note to this effect (http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html) in a recent update to the understanding document, which reads:

Note 3: The minimum contrast success criterion (1.4.3) applies to text in the page, and placeholder text is text in the page. If used, placeholder text needs to provide sufficient contrast.

It is of course a little ironic that usability tests indicate that people think that the field is already completed when the contrast is high enough, since misunderstanding a control as being already filled out can happen when a screen reader user encounters a control with placeholder text.

Have your usability studies found a definite benefit to having placeholder text at all?

AWK

From: Jonathan Avila
Date: Fri, Mar 20 2015 11:47AM
Subject: Re: Placeholder text contrast
← Previous message | Next message →

> If placeholder text is being used properly (input masks, giving examples,
etc) and visible form labels are present, does the placeholder text need to meet contrast ratios?

IMO if the information in the placeholder such as example or masks is not available elsewhere then contrast would be an issue. If that information is duplicated in the label then technically you would be fine -- but in general placeholders can be confusing unless you are very limited by space they may not be a good idea.

> Browser defaults appear to be 2.2:1 or so... Are people expected to override browser defaults?

IMO most people will not know how to.

> Our usability studies found that people thought that form fields were already filled out when placeholder text color met 4.5:1.

In general it may be best to avoid them if you can. Small screen sizes make this a challenge though.

-- 
Jonathan Avila 
Chief Accessibility Officer
SSB BART Group 
= EMAIL ADDRESS REMOVED =
Phone 703.637.8957  
Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter

From: Jesse Hausler
Date: Fri, Mar 20 2015 11:53AM
Subject: Re: Placeholder text contrast
← Previous message | Next message →

Thanks for the responses guys. That's very interesting that w3c
specifically notes that placeholder text should meet the standard.

I agree with that in principal, but it is curious that browsers fail this
by default.

I also agree with Jonathan's point about duplication.

Thanks again,
Jesse

On Fri, Mar 20, 2015 at 10:47 AM, Jonathan Avila < = EMAIL ADDRESS REMOVED =
> wrote:

> > If placeholder text is being used properly (input masks, giving examples,
> etc) and visible form labels are present, does the placeholder text need
> to meet contrast ratios?
>
> IMO if the information in the placeholder such as example or masks is not
> available elsewhere then contrast would be an issue. If that information
> is duplicated in the label then technically you would be fine -- but in
> general placeholders can be confusing unless you are very limited by space
> they may not be a good idea.
>
> > Browser defaults appear to be 2.2:1 or so... Are people expected to
> override browser defaults?
>
> IMO most people will not know how to.
>
> > Our usability studies found that people thought that form fields were
> already filled out when placeholder text color met 4.5:1.
>
> In general it may be best to avoid them if you can. Small screen sizes
> make this a challenge though.
>
> --
> Jonathan Avila
> Chief Accessibility Officer
> SSB BART Group
> = EMAIL ADDRESS REMOVED =
> Phone 703.637.8957
> Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
>
>
>

From: Bryan Garaventa
Date: Fri, Mar 20 2015 12:35PM
Subject: Re: Placeholder text contrast
← Previous message | Next message →

There are additional issues regarding placeholder that relate to current Accessibility API mappings that are having a significant
impact on accessibility for AT users at present as well, which I've already brought up recently at
http://lists.w3.org/Archives/Public/public-pfwg/2015Mar/0116.html
Which might be helpful to be aware of.

From: Cliff Tyllick
Date: Fri, Mar 20 2015 2:12PM
Subject: Re: Placeholder text contrast
← Previous message | Next message →

A number of times I have seen this sort of response to questions about making placeholder text work better: "In our website, we did away with it because [some percentage] of the responses left the placeholder text in place, and bad data is worse than no data. Do you know what that percentage is for your site?"

I don't recall ever seeing a response to that question—especially not an answer of, "We've tested that, and it never happens."

It seems like your group is doing some serious testing, Jesse. Is there any condition under which the form is never submitted with the placeholder text left in place?

If not, what is that error rate? And what is the impact to the customer's experience of your website?

Cliff Tyllick


Sent from my iPhone
Although its spellcheck often saves me, all goofs in sent messages are its fault.

> On Mar 20, 2015, at 1:35 PM, Bryan Garaventa < = EMAIL ADDRESS REMOVED = > wrote:
>
> There are additional issues regarding placeholder that relate to current Accessibility API mappings that are having a significant
> impact on accessibility for AT users at present as well, which I've already brought up recently at
> http://lists.w3.org/Archives/Public/public-pfwg/2015Mar/0116.html
> Which might be helpful to be aware of.
>
>

From: Jesse Hausler via WebAIM-Forum
Date: Fri, Mar 20 2015 6:28PM
Subject: Re: Placeholder text contrast
← Previous message | Next message →

As a follow up question to anyone still reading this thread... what would
you say to the idea that placeholder text is the browser default (poor
contrast) gray. Then onfocus, the placeholder contrast is upped to 4.5:1?

Cliff,
Our placeholder text uses the placeholder attribute, so it wasn't an issue
of users submitting bad data. Our researchers observed that some users
felt they had nothing to complete on a given page. They were faced with a
form, thought it was already filled out and then submitted without
completing or didnt submit at all.

I can't speak to an error rate, but it was enough for the team to ask me
about it. Our product relies on users inputing information about their
customers, accounts, leads, etc. If they think that a field is already
filled in and do not provide that piece of information, then they aren't
using the product to the fullest. That means we can't use that data to make
them more successful at their work, businesses, non-profits, etc.

Thanks,
Jesse



On Fri, Mar 20, 2015 at 1:12 PM, Cliff Tyllick < = EMAIL ADDRESS REMOVED = > wrote:

> A number of times I have seen this sort of response to questions about
> making placeholder text work better: "In our website, we did away with it
> because [some percentage] of the responses left the placeholder text in
> place, and bad data is worse than no data. Do you know what that percentage
> is for your site?"
>
> I don't recall ever seeing a response to that question—especially not an
> answer of, "We've tested that, and it never happens."
>
> It seems like your group is doing some serious testing, Jesse. Is there
> any condition under which the form is never submitted with the placeholder
> text left in place?
>
> If not, what is that error rate? And what is the impact to the customer's
> experience of your website?
>
> Cliff Tyllick
>
>
> Sent from my iPhone
> Although its spellcheck often saves me, all goofs in sent messages are its
> fault.
>
> > On Mar 20, 2015, at 1:35 PM, Bryan Garaventa <
> = EMAIL ADDRESS REMOVED = > wrote:
> >
> > There are additional issues regarding placeholder that relate to current
> Accessibility API mappings that are having a significant
> > impact on accessibility for AT users at present as well, which I've
> already brought up recently at
> > http://lists.w3.org/Archives/Public/public-pfwg/2015Mar/0116.html
> > Which might be helpful to be aware of.
> >
> >

From: via WebAIM-Forum
Date: Fri, Mar 20 2015 7:33PM
Subject: Re: Placeholder text contrast
← Previous message | Next message →

I would point the design team to the wealth of usability studies that say, even ignoring accessibility considerations, users simply don't understand how to interact with form field placeholders.

eg. http://www.nngroup.com/articles/form-design-placeholders/

They don't work, they confuse users, and they worsen form fill success. Given all the evidence, I don't see why developers won't give up on their conviction that placeholders are good design.

Deborah Kaplan



On Fri, 20 Mar 2015, Jesse Hausler via WebAIM-Forum wrote:

> As a follow up question to anyone still reading this thread... what would
> you say to the idea that placeholder text is the browser default (poor
> contrast) gray. Then onfocus, the placeholder contrast is upped to 4.5:1?
>
> Cliff,
> Our placeholder text uses the placeholder attribute, so it wasn't an issue
> of users submitting bad data. Our researchers observed that some users
> felt they had nothing to complete on a given page. They were faced with a
> form, thought it was already filled out and then submitted without
> completing or didnt submit at all.
>
> I can't speak to an error rate, but it was enough for the team to ask me
> about it. Our product relies on users inputing information about their
> customers, accounts, leads, etc. If they think that a field is already
> filled in and do not provide that piece of information, then they aren't
> using the product to the fullest. That means we can't use that data to make
> them more successful at their work, businesses, non-profits, etc.
>
> Thanks,
> Jesse
>
>
>
> On Fri, Mar 20, 2015 at 1:12 PM, Cliff Tyllick < = EMAIL ADDRESS REMOVED = > wrote:
>
>> A number of times I have seen this sort of response to questions about
>> making placeholder text work better: "In our website, we did away with it
>> because [some percentage] of the responses left the placeholder text in
>> place, and bad data is worse than no data. Do you know what that percentage
>> is for your site?"
>>
>> I don't recall ever seeing a response to that question—especially not an
>> answer of, "We've tested that, and it never happens."
>>
>> It seems like your group is doing some serious testing, Jesse. Is there
>> any condition under which the form is never submitted with the placeholder
>> text left in place?
>>
>> If not, what is that error rate? And what is the impact to the customer's
>> experience of your website?
>>
>> Cliff Tyllick
>>
>>
>> Sent from my iPhone
>> Although its spellcheck often saves me, all goofs in sent messages are its
>> fault.
>>
>> > On Mar 20, 2015, at 1:35 PM, Bryan Garaventa <
>> = EMAIL ADDRESS REMOVED = > wrote:
>> >
>> > There are additional issues regarding placeholder that relate to current
>> Accessibility API mappings that are having a significant
>> > impact on accessibility for AT users at present as well, which I've
>> already brought up recently at
>> > http://lists.w3.org/Archives/Public/public-pfwg/2015Mar/0116.html
>> > Which might be helpful to be aware of.
>> >
>> >

From: _mallory
Date: Sat, Mar 21 2015 9:51AM
Subject: Re: Placeholder text contrast
← Previous message | Next message →

On Fri, Mar 20, 2015 at 10:53:41AM -0700, Jesse Hausler wrote:
> Thanks for the responses guys. That's very interesting that w3c
> specifically notes that placeholder text should meet the standard.
>
> I agree with that in principal, but it is curious that browsers fail this

I assumed that they deliberaltely chose to have failing contrast
specifically because these are not supposed to trick users into
thinking the fields are pre-filled.

I liked the idea of placeholders gaining passing contrast onfocus,
but haven't found a cross-browser way of styling placeholders with
CSS. A few engines, like webkit/blink, have proprietary vendor
extensions targetting placeholder, but that's not universal.

_mallory

From: _mallory
Date: Sat, Mar 21 2015 10:10AM
Subject: Re: Placeholder text contrast
← Previous message | Next message →

On Fri, Mar 20, 2015 at 09:33:25PM -0400, via WebAIM-Forum wrote:
> I would point the design team to the wealth of usability studies that say, even ignoring accessibility considerations, users simply don't understand how to interact with form field placeholders.
>
> eg. http://www.nngroup.com/articles/form-design-placeholders/
>
> They don't work, they confuse users, and they worsen form fill success. Given all the evidence, I don't see why developers won't give up on their conviction that placeholders are good design.

Probably two reasons:
1. graphic designers often have the clout to tell developers what
to do, and clients and bosses seem to always side with the graphic
designers. Pretty almost always wins, and it will continue to do
so as long as the Majority views web sites and apps as things that
sell based on how artfully tasteful (or tastefully artful) they
are while usablity comes a distant second. This must be one of those
unfixible human-nature things...

2. Hints have always been a problem, and hints in some forms are
necessary. Placeholders were an attempt, but the implementation
is poor and the graphics people grabbed onto them as a "solution"
to "ugly" labels.

The other solutions?
1. Loads of text around each label (I was recently filling out a
government form and many fields had a good couple of sentences' worth
of explanation per field), which can and has tripped up people with
cognitive disorders.
2. on-hover popups, which tend to leave out keyboarders, and when the
developers load them into the labels or associate them with the inputs
using aria-describedby, some peoplw like SR users get a boatload of
text on focus of the input, causing then the same problems we got
when we just had the text sitting out around the label.
3. I've tried on-focus and on-click popups, but popups in general
have plenty of known problems themselves.

While Postel's law could help with some things (force the developer
to write a boatload of checks, tests, regexes and locale/i18n-aware
text filtering to allow any sort of, for example, date information
to become whatever format the back-end system requires, thus
removing the need to tell the user HOW to input the data), it
can't take care of all situations. And sometimes there's so much
info needed that we resort to links to other pages: and now what?
Should the user lose their place on the form? Should the page be
presented as a popup to prevent this? Should it be a "normal" link
and just go to the information page? If so, how to they get back
to exactly where they were, and how can we ensure that they also
can get back into their "filling out a form" state of mind?

And when the front-end developer (the one who's coding the form) has
zero control on the back-end processing, because the input is being
passed on to some 3rd party who isn't even the hiring client and is
using some ancient COBOL-based thing that nobody is going to touch
again until it's time to upgrade to some complete other system?

I think it's actually pretty easy to see why developers have glommed
onto placholders, for all their faults: it *looks* easy. It *seems*
to fix a bunch of problems. And we are lazy folk, not only in the good
Larry-Wall definition, but also the bad general-world definition.

The easiest way to get people to stop using placeholders (whether as
label replacements, or as they were meant to be used, as field hints)?
We need to fix these hard problems and present developer-usable answers.

I dunno, is this fixable? If not, how do we tell people "no" and expect
them to listen?

_mallory

From: Whitney Quesenbery
Date: Sun, Mar 22 2015 5:32AM
Subject: Re: Placeholder text contrast
← Previous message | No next message

Jesse: Our usability studies found that people thought that form fields were

already filled out when placeholder text color met 4.5:1.

This is really common, no matter what the contrast ratio is.

On placeholder text inside the form: just say no! It's bad for everyone.

Here's an article from Caroline Jarrett, who wrote the book on forms (Forms
that Work):
http://www.uxmatters.com/mt/archives/2010/03/dont-put-hints-inside-text-boxes-in-web-forms.php

Don't Put Hints Inside Text Boxes in Web Forms

She goes through some of the research and the logic, and ends with
"If you include hint text inside your form's text boxes, many users—quite
likely, the majority—will interpret the hint text as a default. If that's
what you want, go right ahead. Otherwise, think of another way of helping
your users."


On Sat, Mar 21, 2015 at 11:48 AM _mallory via WebAIM-Forum <
= EMAIL ADDRESS REMOVED = > wrote:

> On Fri, Mar 20, 2015 at 09:33:25PM -0400, via WebAIM-Forum wrote:
> > I would point the design team to the wealth of usability studies that
> say, even ignoring accessibility considerations, users simply don't
> understand how to interact with form field placeholders.
> >
> > eg. http://www.nngroup.com/articles/form-design-placeholders/
> >
> > They don't work, they confuse users, and they worsen form fill success.
> Given all the evidence, I don't see why developers won't give up on their
> conviction that placeholders are good design.
>
> Probably two reasons:
> 1. graphic designers often have the clout to tell developers what
> to do, and clients and bosses seem to always side with the graphic
> designers. Pretty almost always wins, and it will continue to do
> so as long as the Majority views web sites and apps as things that
> sell based on how artfully tasteful (or tastefully artful) they
> are while usablity comes a distant second. This must be one of those
> unfixible human-nature things...
>
> 2. Hints have always been a problem, and hints in some forms are
> necessary. Placeholders were an attempt, but the implementation
> is poor and the graphics people grabbed onto them as a "solution"
> to "ugly" labels.
>
> The other solutions?
> 1. Loads of text around each label (I was recently filling out a
> government form and many fields had a good couple of sentences' worth
> of explanation per field), which can and has tripped up people with
> cognitive disorders.
> 2. on-hover popups, which tend to leave out keyboarders, and when the
> developers load them into the labels or associate them with the inputs
> using aria-describedby, some peoplw like SR users get a boatload of
> text on focus of the input, causing then the same problems we got
> when we just had the text sitting out around the label.
> 3. I've tried on-focus and on-click popups, but popups in general
> have plenty of known problems themselves.
>
> While Postel's law could help with some things (force the developer
> to write a boatload of checks, tests, regexes and locale/i18n-aware
> text filtering to allow any sort of, for example, date information
> to become whatever format the back-end system requires, thus
> removing the need to tell the user HOW to input the data), it
> can't take care of all situations. And sometimes there's so much
> info needed that we resort to links to other pages: and now what?
> Should the user lose their place on the form? Should the page be
> presented as a popup to prevent this? Should it be a "normal" link
> and just go to the information page? If so, how to they get back
> to exactly where they were, and how can we ensure that they also
> can get back into their "filling out a form" state of mind?
>
> And when the front-end developer (the one who's coding the form) has
> zero control on the back-end processing, because the input is being
> passed on to some 3rd party who isn't even the hiring client and is
> using some ancient COBOL-based thing that nobody is going to touch
> again until it's time to upgrade to some complete other system?
>
> I think it's actually pretty easy to see why developers have glommed
> onto placholders, for all their faults: it *looks* easy. It *seems*
> to fix a bunch of problems. And we are lazy folk, not only in the good
> Larry-Wall definition, but also the bad general-world definition.
>
> The easiest way to get people to stop using placeholders (whether as
> label replacements, or as they were meant to be used, as field hints)?
> We need to fix these hard problems and present developer-usable answers.
>
> I dunno, is this fixable? If not, how do we tell people "no" and expect
> them to listen?
>
> _mallory
> > > >