E-mail List Archives

You are here: Home > Community > E-mail List Archives > View Thread

Thread: Placeholder

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

From: Eilana Benish
Date: Mon, Mar 11 2019 1:00PM
Subject: Placeholder
No previous message | Next message →

<html style="direction: rtl;">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style type="text/css">body p { margin-bottom: 1.5pt; margin-top: 0pt; } </style>
</head>
<body bidimailui-detected-decoding-type="preferred-charset"
style="direction: rtl;" text="#000000" bgcolor="#FFFFFF">
hello,
my name is Eilana from Israel. Currently, I work with
organizations required to make their websites accessible in
Israel. Â 
We
are working on developing a new Â website.
We
have a very serious disagreement about the place-holder as a
method to label forms fields.
I
know that the popular screen reader reads the place holder. But
this is mey not be accessible to users with cognitive
disabilities.
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
have also tried to find information on the W3C accessibility
resources â Without success. 
So,
is the place holder Â WCAG 2 compliant
And
what the WCAG 2 working group Â has to say about
that topic?
 

 

 

 

 

 

 

 

<div class="moz-signature">-- 
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="ProgId" content="Word.Document">
<meta name="Generator" content="Microsoft Word 15">
<meta name="Originator" content="Microsoft Word 15">
<link rel="File-List" href="××ª×××%20××¢×××× ×ª.files/filelist.xml">

<link rel="themeData" href="××ª×××%20××¢×××× ×ª.files/themedata.thmx">
<link rel="colorSchemeMapping"
href="××ª×××%20××¢×××× ×ª.files/colorschememapping.xml">

<style>

</style>
<div class="WordSection1" dir="RTL">
<a name="_Hlk530889354"></a><a
name="_MailAutoSig"></a><a name="_Hlk516343373"><span
style="font-size:14.0pt;
mso-ascii-font-family:Arial;mso-ascii-theme-font:minor-bidi;mso-hansi-font-family:
Arial;mso-hansi-theme-font:minor-bidi;mso-bidi-font-family:Arial;mso-bidi-theme-font:
minor-bidi;color:#000F19" lang="HE">×××××× ×¨×, Â ×××× ×
×× ××©, ×××¨×©× × ×××©××ª ×©××¨××ª (2200)<o:p></o:p></a>
<span
style="font-size:14.0pt;mso-ascii-font-family:Arial;mso-ascii-theme-font:minor-bidi;mso-hansi-font-family:Arial;mso-hansi-theme-font:minor-bidi;
mso-bidi-font-family:Arial;mso-bidi-theme-font:minor-bidi;color:#000F19"
lang="HE">×××××
×× ×××× ×¤×¨×××§×××: × ×××©××ª
××©×××©××ª ××× ××¨× × ×××× ×××××××ª
××××¢<o:p></o:p>
<span dir="LTR"
style="font-size:14.0pt;mso-ascii-font-family:Arial;mso-ascii-theme-font:minor-bidi;mso-hansi-font-family:Arial;mso-hansi-theme-font:minor-bidi;
mso-bidi-font-family:Arial;mso-bidi-theme-font:minor-bidi;color:#000F19">A.D.N:
Accessible digital knowledge 2009 â 2019<span
style="font-size:14.0pt;mso-ascii-font-family:Arial;mso-ascii-theme-font:minor-bidi;
mso-hansi-font-family:Arial;mso-hansi-theme-font:minor-bidi;mso-bidi-font-family:
Arial;mso-bidi-theme-font:minor-bidi;color:#000F19"> <span
style="font-size:14.0pt;
mso-ascii-font-family:Arial;mso-ascii-theme-font:minor-bidi;mso-hansi-font-family:
Arial;mso-hansi-theme-font:minor-bidi;mso-bidi-font-family:Arial;mso-bidi-theme-font:
minor-bidi;color:#000F19" lang="HE"><o:p></o:p>
<span
style="font-size:14.0pt;mso-ascii-font-family:Arial;mso-ascii-theme-font:minor-bidi;
mso-hansi-font-family:Arial;mso-hansi-theme-font:minor-bidi;mso-bidi-font-family:
Arial;mso-bidi-theme-font:minor-bidi;color:#000F19"
lang="HE">×××¤××Â
050-7100367Â ×××"×
<a
href="mailto: = EMAIL ADDRESS REMOVED = "><span dir="LTR"
style="font-size:14.0pt;mso-ascii-font-family:Arial;mso-ascii-theme-font:minor-bidi;mso-hansi-font-family:Arial;mso-hansi-theme-font:minor-bidi;
mso-bidi-font-family:Arial;mso-bidi-theme-font:minor-bidi;color:#000F19"> = EMAIL ADDRESS REMOVED = </a><span dir="LTR"
style="font-size:14.0pt;
mso-ascii-font-family:Arial;mso-ascii-theme-font:minor-bidi;mso-hansi-font-family:
Arial;mso-hansi-theme-font:minor-bidi;mso-bidi-font-family:Arial;mso-bidi-theme-font:
minor-bidi;color:#000F19"> <span
style="font-size:14.0pt;mso-ascii-font-family:Arial;mso-ascii-theme-font:minor-bidi;mso-hansi-font-family:Arial;mso-hansi-theme-font:minor-bidi;
mso-bidi-font-family:Arial;mso-bidi-theme-font:minor-bidi;color:#000F19"
lang="HE"> 
<a
href="https://adn-accesstime.com/2018/12/12/%d7%a9%d7%99%d7%9e%d7%95%d7%a9-%d7%93%d7%a4%d7%95%d7%a1%d7%99%d7%9d-%d7%90%d7%a4%d7%9c%d7%99%d7%9d-%d7%91%d7%90%d7%aa%d7%a8%d7%99-%d7%90%d7%99%d7%a0%d7%98%d7%a8%d7%a0%d7%98/"><span
style="font-size:14.0pt;
mso-ascii-font-family:Arial;mso-ascii-theme-font:minor-bidi;mso-hansi-font-family:
Arial;mso-hansi-theme-font:minor-bidi;mso-bidi-font-family:Arial;mso-bidi-theme-font:
minor-bidi;color:#000F19" lang="HE">××ª×¨ ×××× ××¨× ×
× ×××©××ª ××©×××©××ª ××× ××¨× × ×××× ×××××××ª ××××¢</a><span dir="LTR"
style="font-size:14.0pt;
mso-ascii-font-family:Arial;mso-ascii-theme-font:minor-bidi;mso-hansi-font-family:
Arial;mso-hansi-theme-font:minor-bidi;mso-bidi-font-family:Arial;mso-bidi-theme-font:
minor-bidi;color:#000F19;text-decoration:none;text-underline:none"> <span style="font-size:14.0pt;
mso-ascii-font-family:Arial;mso-ascii-theme-font:minor-bidi;mso-hansi-font-family:
Arial;mso-hansi-theme-font:minor-bidi;mso-bidi-font-family:Arial;mso-bidi-theme-font:
minor-bidi;color:#000F19;text-decoration:none;text-underline:none">Â â <a
href="https://itunes.apple.com/app/id1438649378?fbclid=IwAR2xQt2j9TXnIBdOVz1oY3T0oBPTepgWndQIlruALWr4q7T4gTZ1mUJAmCQ"><span dir="LTR"
style="font-size:14.0pt;
mso-ascii-font-family:Arial;mso-ascii-theme-font:minor-bidi;mso-hansi-font-family:
Arial;mso-hansi-theme-font:minor-bidi;mso-bidi-font-family:Arial;mso-bidi-theme-font:
minor-bidi;color:#000F19">IOS</a><span
style="font-size:14.0pt;mso-ascii-font-family:Arial;mso-ascii-theme-font:minor-bidi;mso-hansi-font-family:Arial;mso-hansi-theme-font:minor-bidi;mso-bidi-font-family:
Arial;mso-bidi-theme-font:minor-bidi;color:#000F19"> <span
style="font-size:14.0pt;mso-ascii-font-family:Arial;mso-ascii-theme-font:minor-bidi;mso-hansi-font-family:Arial;mso-hansi-theme-font:minor-bidi;mso-bidi-font-family:
Arial;mso-bidi-theme-font:minor-bidi;color:#000F19;text-decoration:none;
text-underline:none">Â Â â <a
href="https://play.google.com/store/apps/details?id=com.adn_accesstime.presspadnews&fbclid=IwAR2KslNcOzRqC8zD_Dpr9qI5EvHFjKAQK2-lCwFoMLVgVHw-M34OZIuUTDo"><span
style="font-size:14.0pt;
mso-ascii-font-family:Arial;mso-ascii-theme-font:minor-bidi;mso-hansi-font-family:
Arial;mso-hansi-theme-font:minor-bidi;mso-bidi-font-family:Arial;mso-bidi-theme-font:
minor-bidi;color:#000F19" lang="HE">×× ××¨××××</a><span
style="font-size:14.0pt;mso-ascii-font-family:
Arial;mso-ascii-theme-font:minor-bidi;mso-hansi-font-family:Arial;mso-hansi-theme-font:
minor-bidi;mso-bidi-font-family:Arial;mso-bidi-theme-font:minor-bidi;
color:#000F19;text-decoration:none;text-underline:none" lang="HE"><o:p></o:p>

<o:p>Â </o:p>
</div>
</div>
</body>
</html>

From: John Foliot
Date: Mon, Mar 11 2019 1:47PM
Subject: Re: Placeholder
← Previous message | Next message →

Hi Elena,

There are a number of concerns here.

1) The HTML 5 specification specifically states:

Use of the placeholder attribute as a replacement for a label can reduce
the accessibility and usability of the control for a range of users
including older users and users with cognitive, mobility, fine motor skill
or vision impairments. While the hint given by the control's label is shown
at all times, the short hint given in the placeholder attribute is only
shown before the user enters a value. Furthermore, placeholder text may be
mistaken for a pre-filled value, and as commonly implemented the default
color of the placeholder text provides insufficient contrast and the lack
of a separate visible label reduces the size of the hit region available
for setting focus on the control.

2) WCAG 2.0 (and 2.1) is silent on the use of @placeholder, because when
WCAG 2.0 was written, @placeholder didn't exist. Any claim that
using @placeholder is "WCAG Compliant" needs to have a reference-able
source - which I don't think anyone can produce.

...and so, politely, your development team is likely incorrect.

We're starting to see a "hybrid" solution that delivers on the 'design'
requirements, while still maintaining the accessibility needs. A common
example of that pattern can be found when logging into GMail, where the
placeholder text "shrinks" up into the top-left corner (top-right in the
context of Hebrew content?), there by "moving out of the way" but
none-the-less remaining persistent on the page.

Would something like that meet your internal needs?

JF

On Mon, Mar 11, 2019 at 12:00 PM Eilana Benish < = EMAIL ADDRESS REMOVED = >
wrote:

> hello, my name is Eilana from Israel. Currently, I work with organizations
> required to make their websites accessible in Israel.
>
> We are working on developing a new website.
>
> We have a very serious disagreement about the place-holder as a method to
> label forms fields.
>
> I know that the popular screen reader reads the place holder. But this is
> mey not be accessible to users with cognitive disabilities.
>
> 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 have also tried to find information on the W3C accessibility resources â
> Without success.
>
> So, is the place holder WCAG 2 compliant
>
> And what the WCAG 2 working group has to say about that topic?
>
>
>
>
>
>
>
>
>
> --
>
> *×××××× ×¨×, ×××× × ×× ××©, ×××¨×©× × ×××©××ª ×©××¨××ª (2200)*
>
> *××××× ×× ×××× ×¤×¨×××§×××: × ×××©××ª ××©×××©××ª ××× ××¨× × ×××× ×××××××ª ××××¢*
>
> *A.D.N: Accessible digital knowledge 2009 â 2019*
>
> *×××¤×× 050-7100367 ×××"× ** = EMAIL ADDRESS REMOVED = *
> < = EMAIL ADDRESS REMOVED = >
> *××ª×¨ ×××× ××¨× × × ×××©××ª ××©×××©××ª ××× ××¨× × ×××× ×××××××ª ××××¢*
> <https://adn-accesstime.com/2018/12/12/%d7%a9%d7%99%d7%9e%d7%95%d7%a9-%d7%93%d7%a4%d7%95%d7%a1%d7%99%d7%9d-%d7%90%d7%a4%d7%9c%d7%99%d7%9d-%d7%91%d7%90%d7%aa%d7%a8%d7%99-%d7%90%d7%99%d7%a0%d7%98%d7%a8%d7%a0%d7%98/> * â
> **IOS*
> <https://itunes.apple.com/app/id1438649378?fbclid=IwAR2xQt2j9TXnIBdOVz1oY3T0oBPTepgWndQIlruALWr4q7T4gTZ1mUJAmCQ> * â
> **×× ××¨××××*
> <https://play.google.com/store/apps/details?id=com.adn_accesstime.presspadnews&fbclid=IwAR2KslNcOzRqC8zD_Dpr9qI5EvHFjKAQK2-lCwFoMLVgVHw-M34OZIuUTDo>
>
>
> > > > >

--
*âJohn Foliot* | Principal Accessibility Strategist | W3C AC Representative
Deque Systems - Accessibility for Good
deque.com

From: Patrick H. Lauke
Date: Mon, Mar 11 2019 1:56PM
Subject: Re: Placeholder
← Previous message | Next message →

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 ADDRESS 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

From: Jim Homme
Date: Mon, Mar 11 2019 2:01PM
Subject: Re: Placeholder
← Previous message | Next message →

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

From: Patrick H. Lauke
Date: Mon, Mar 11 2019 2:06PM
Subject: Re: Placeholder
← Previous message | Next message →

Some more related link dumpage:

https://www.w3.org/WAI/GL/low-vision-a11y-tf/wiki/Placeholder_Research
https://www.smashingmagazine.com/2018/06/placeholder-attribute/
https://github.com/w3c/html-aam/issues/84
https://www.nngroup.com/articles/form-design-placeholders/
http://davidmacd.com/blog/is-placeholder-accessible-label.html

And a note that there's an internal (not public) mailing list for the
WCAG working group, and that the issue of placeholder (in the context of
4.1.2 and 3.3.2, not generally in a "is it WCAG compliant" sense, as
that's too reductive a question) was discussed in August 2018, and I
believe we roughly hit on the consensus I expanded on in my previous
email (that for modern browser/AT combinations, for the most part,
placeholder is exposed as the accessible name of a form control, but
while it then arguably passes 4.1.2, it doesn't pass 3.3.2 under certain
conditions.

Note that, as ever, this has to be evaluated on a case-by-case basis
though (as the form in question may well be obvious even without an
explicit label, or there may be other things like a big fat "SEARCH"
submit button next to a text input which makes it fairly clear that the
form control is a search query input, for instance, etc)

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

From: Patrick H. Lauke
Date: Mon, Mar 11 2019 2:10PM
Subject: Re: Placeholder
← Previous message | Next message →

On 11/03/2019 20:01, Jim Homme wrote:
> 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.

For sighted users, the placeholder text (when visible) IS the label /
the thing that acts as a label. Also, how do you mean "properly"? If the
outcome / success criterion you're trying ascertain is 4.1.2, then the
fact that your AT is announcing a name should be taken as passing that
criterion, no? If you mean "it makes it difficult to check if they've
given the input a label using <label>, I'd say that's irrelevant (they
may have used aria-label, or aria-labelledby, just as well, and your AT
announcing those would also make you none the wiser). Unless I'm missing
something?

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

From: Isabel Holdsworth
Date: Tue, Mar 12 2019 3:01AM
Subject: Re: Placeholder
← Previous message | Next message →

From a blind tester's perspective (hope I've got this right Jim):

Say a form element has a label and a placeholder, and the placeholder
is used to describe the expected data format. If the screenreader
speaks the placeholder even after it's been superseded by entered
data, then it's more challenging for a blind tester to know that the
screenreader is speaking invisible text and that there's a 3.3.2 fail.

Cheers, Isabel

On 11/03/2019, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:
> On 11/03/2019 20:01, Jim Homme wrote:
>> 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.
>
> For sighted users, the placeholder text (when visible) IS the label /
> the thing that acts as a label. Also, how do you mean "properly"? If the
> outcome / success criterion you're trying ascertain is 4.1.2, then the
> fact that your AT is announcing a name should be taken as passing that
> criterion, no? If you mean "it makes it difficult to check if they've
> given the input a label using <label>, I'd say that's irrelevant (they
> may have used aria-label, or aria-labelledby, just as well, and your AT
> announcing those would also make you none the wiser). Unless I'm missing
> something?
>
> 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
> > > > >

From: Patrick H. Lauke
Date: Tue, Mar 12 2019 3:17AM
Subject: Re: Placeholder
← Previous message | Next message →

On 12/03/2019 09:01, Isabel Holdsworth wrote:
> From a blind tester's perspective (hope I've got this right Jim):
>
> Say a form element has a label and a placeholder, and the placeholder
> is used to describe the expected data format. If the screenreader
> speaks the placeholder even after it's been superseded by entered
> data, then it's more challenging for a blind tester to know that the
> screenreader is speaking invisible text and that there's a 3.3.2 fail.

3.3.2 is tricky in any case, as it does not necessitate that whatever
text acts as a label/instruction is actually programmatically associated
(so it could just be text that happens to be "near" an input - for
whatever definition of "near" - but has no proper <label for="...">
connection or anything, but under 3.3.2 that's a pass; or the form
control could have explicit aria-label="..." but no actual visible text,
which would fail 3.3.2 even though it passes 4.1.2 and would be tricky
to spot unless a tester using just the screenreader both explores the
overall text of the page - and makes sure they don't land in visually
hidden text - and then compares notes with what they hear when focusing
a form field)...

But yes, this wouldn't help in this already very complex to test (mostly
visual) SC.

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

From: Isabel Holdsworth
Date: Tue, Mar 12 2019 5:13AM
Subject: Re: Placeholder
← Previous message | Next message →

I use a combination of DOM and CSS checking and JAWS OCR, which is
better than nothing but alas not foolproof.

On 12/03/2019, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:
> On 12/03/2019 09:01, Isabel Holdsworth wrote:
>> From a blind tester's perspective (hope I've got this right Jim):
>>
>> Say a form element has a label and a placeholder, and the placeholder
>> is used to describe the expected data format. If the screenreader
>> speaks the placeholder even after it's been superseded by entered
>> data, then it's more challenging for a blind tester to know that the
>> screenreader is speaking invisible text and that there's a 3.3.2 fail.
>
> 3.3.2 is tricky in any case, as it does not necessitate that whatever
> text acts as a label/instruction is actually programmatically associated
> (so it could just be text that happens to be "near" an input - for
> whatever definition of "near" - but has no proper <label for="...">
> connection or anything, but under 3.3.2 that's a pass; or the form
> control could have explicit aria-label="..." but no actual visible text,
> which would fail 3.3.2 even though it passes 4.1.2 and would be tricky
> to spot unless a tester using just the screenreader both explores the
> overall text of the page - and makes sure they don't land in visually
> hidden text - and then compares notes with what they hear when focusing
> a form field)...
>
> But yes, this wouldn't help in this already very complex to test (mostly
> visual) SC.
>
> 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
> > > > >

From: Yoandry Collazo
Date: Tue, Mar 12 2019 9:14AM
Subject: Re: Placeholder
← Previous message | Next message →

Hi, I'm not an expert, I hope this helps you.

1.

Placeholders

According to HTML5 specifications
<https://developer.paciellogroup.com/blog/2011/02/html5-accessibility-chops-the-placeholder-attribute/>,
The placeholder
<https://www.w3.org/TR/html/sec-forms.html#the-placeholder-attribute> attribute
should not be used as an alternative to a label
<https://www.w3.org/TR/html/sec-forms.html#the-label-element>.

Placeholder text disappears when a text box receives focus:

-

For keyboard users, this can be problematic
<http://mentalized.net/journal/2010/08/05/dont_use_placeholder_text_as_labels/>;
as they must read ahead of current focus when filling in forms.
-

Users, especially those with memory impairments will not have the text
label available for reference at the same time as filling in a field.

Other issues with placeholders

-

Users may think a text field is already filled in and skip over it. Data
suggests
<http://www.uxmatters.com/mt/archives/2010/03/dont-put-hints-inside-text-boxes-in-web-forms.php>;
that this can be an issue.
-

If the placeholder hint text is useful information it should be
available while the user is filling in the field.

On Mon, Mar 11, 2019 at 3:01 PM Eilana Benish < = EMAIL ADDRESS REMOVED = >
wrote:

> hello, my name is Eilana from Israel. Currently, I work with organizations
> required to make their websites accessible in Israel.
>
> We are working on developing a new website.
>
> We have a very serious disagreement about the place-holder as a method to
> label forms fields.
>
> I know that the popular screen reader reads the place holder. But this is
> mey not be accessible to users with cognitive disabilities.
>
> 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 have also tried to find information on the W3C accessibility resources â
> Without success.
>
> So, is the place holder WCAG 2 compliant
>
> And what the WCAG 2 working group has to say about that topic?
>
>
>
>
>
>
>
>
>
> --
>
> *×××××× ×¨×, ×××× × ×× ××©, ×××¨×©× × ×××©××ª ×©××¨××ª (2200)*
>
> *××××× ×× ×××× ×¤×¨×××§×××: × ×××©××ª ××©×××©××ª ××× ××¨× × ×××× ×××××××ª ××××¢*
>
> *A.D.N: Accessible digital knowledge 2009 â 2019*
>
> *×××¤×× 050-7100367 ×××"× ** = EMAIL ADDRESS REMOVED = *
> < = EMAIL ADDRESS REMOVED = >
> *××ª×¨ ×××× ××¨× × × ×××©××ª ××©×××©××ª ××× ××¨× × ×××× ×××××××ª ××××¢*
> <https://adn-accesstime.com/2018/12/12/%d7%a9%d7%99%d7%9e%d7%95%d7%a9-%d7%93%d7%a4%d7%95%d7%a1%d7%99%d7%9d-%d7%90%d7%a4%d7%9c%d7%99%d7%9d-%d7%91%d7%90%d7%aa%d7%a8%d7%99-%d7%90%d7%99%d7%a0%d7%98%d7%a8%d7%a0%d7%98/> * â
> **IOS*
> <https://itunes.apple.com/app/id1438649378?fbclid=IwAR2xQt2j9TXnIBdOVz1oY3T0oBPTepgWndQIlruALWr4q7T4gTZ1mUJAmCQ> * â
> **×× ××¨××××*
> <https://play.google.com/store/apps/details?id=com.adn_accesstime.presspadnews&fbclid=IwAR2KslNcOzRqC8zD_Dpr9qI5EvHFjKAQK2-lCwFoMLVgVHw-M34OZIuUTDo>
>
>
> > > > >

From: Birkir R. Gunnarsson
Date: Fri, Mar 15 2019 11:53PM
Subject: Re: Placeholder
← Previous message | Next message →

It is easy with Jaws to see the attribute of a formfield )just map
display advanced element information to a keyboard combination in the
Jaws keyboard manager for your browsers, (this is explained on
http://www.bats.fyi).
Once you have, focus the element with Jaws running, press the keyboard
combiantion and check if it has a placeholder attribute )the
attributes are listed alphabetically so it is A screen reader should
not allow the vaue of the placeholder attribute as the accesible name
of a form field if it has visually disappeared, that is a bug, and a
serious one at that.

On 3/12/19, Yoandry Collazo < = EMAIL ADDRESS REMOVED = > wrote:
> Hi, I'm not an expert, I hope this helps you.
>
>
> 1.
>
> Placeholders
>
> According to HTML5 specifications
> <https://developer.paciellogroup.com/blog/2011/02/html5-accessibility-chops-the-placeholder-attribute/>,
> The placeholder
> <https://www.w3.org/TR/html/sec-forms.html#the-placeholder-attribute>
> attribute
> should not be used as an alternative to a label
> <https://www.w3.org/TR/html/sec-forms.html#the-label-element>.
>
> Placeholder text disappears when a text box receives focus:
>
> -
>
> For keyboard users, this can be problematic
>
> <http://mentalized.net/journal/2010/08/05/dont_use_placeholder_text_as_labels/>;
> as they must read ahead of current focus when filling in forms.
> -
>
> Users, especially those with memory impairments will not have the text
> label available for reference at the same time as filling in a field.
>
> Other issues with placeholders
>
> -
>
> Users may think a text field is already filled in and skip over it. Data
> suggests
>
> <http://www.uxmatters.com/mt/archives/2010/03/dont-put-hints-inside-text-boxes-in-web-forms.php>;
> that this can be an issue.
> -
>
> If the placeholder hint text is useful information it should be
> available while the user is filling in the field.
>
>
> On Mon, Mar 11, 2019 at 3:01 PM Eilana Benish < = EMAIL ADDRESS REMOVED = >
> wrote:
>
>> hello, my name is Eilana from Israel. Currently, I work with organizations
>> required to make their websites accessible in Israel.
>>
>> We are working on developing a new website.
>>
>> We have a very serious disagreement about the place-holder as a method to
>> label forms fields.
>>
>> I know that the popular screen reader reads the place holder. But this is
>> mey not be accessible to users with cognitive disabilities.
>>
>> 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 have also tried to find information on the W3C accessibility resources â
>> Without success.
>>
>> So, is the place holder WCAG 2 compliant
>>
>> And what the WCAG 2 working group has to say about that topic?
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>>
>> *×××××× ×¨×, ×××× × ×× ××©, ×××¨×©× × ×××©××ª ×©××¨××ª (2200)*
>>
>> *××××× ×× ×××× ×¤×¨×××§×××: × ×××©××ª ××©×××©××ª ××× ××¨× × ×××× ×××××××ª ××××¢*
>>
>> *A.D.N: Accessible digital knowledge 2009 â 2019*
>>
>> *×××¤×× 050-7100367 ×××"× ** = EMAIL ADDRESS REMOVED = *
>> < = EMAIL ADDRESS REMOVED = >
>> *××ª×¨ ×××× ××¨× × × ×××©××ª ××©×××©××ª ××× ××¨× × ×××× ×××××××ª ××××¢*
>> <https://adn-accesstime.com/2018/12/12/%d7%a9%d7%99%d7%9e%d7%95%d7%a9-%d7%93%d7%a4%d7%95%d7%a1%d7%99%d7%9d-%d7%90%d7%a4%d7%9c%d7%99%d7%9d-%d7%91%d7%90%d7%aa%d7%a8%d7%99-%d7%90%d7%99%d7%a0%d7%98%d7%a8%d7%a0%d7%98/>
>> * â
>> **IOS*
>> <https://itunes.apple.com/app/id1438649378?fbclid=IwAR2xQt2j9TXnIBdOVz1oY3T0oBPTepgWndQIlruALWr4q7T4gTZ1mUJAmCQ>
>> * â
>> **×× ××¨××××*
>> <https://play.google.com/store/apps/details?id=com.adn_accesstime.presspadnews&fbclid=IwAR2KslNcOzRqC8zD_Dpr9qI5EvHFjKAQK2-lCwFoMLVgVHw-M34OZIuUTDo>
>>
>>
>> >> >> >> >>
> > > > >

--
Work hard. Have fun. Make history.

From: Bim Egan
Date: Sat, Mar 16 2019 12:41AM
Subject: Re: Placeholder
← Previous message | Next message →

An alternative to placeholders that may be worth looking at is accessible
floating labels. This uses CSS and Jquery to position the explicit label
over the text box so that it *looks* like a placeholder. The difference is
that when the field receives focus the label doesn't disappear, it moves up
above the field and remains visible. It's explained in the following post:
https://allthingssmitty.com/2016/09/25/accessible-floating-labels/

So the designers get the clean look they want and users get the permanent
access to the label they need.

The example in the blog post does have colour contrast issues, both when
it's showing like a placeholder and when it moves up to its permanent
position, Otherwise it seems to work in several browsers. Not tested on
mobile though.

Bim

-------------
Bim Egan
Skype phone: 01223 96 87 96
Personal Email: = EMAIL ADDRESS REMOVED =
Skype ID: bim.accessequals

Coordinator: Describe Online
W: www.describe-online.com
E: = EMAIL ADDRESS REMOVED =
----------------------------------------
Partner: AccessEquals
W: www.accessequals.com
E: = EMAIL ADDRESS REMOVED =

From: Jim Homme
Date: Mon, Mar 18 2019 9:32AM
Subject: Re: Placeholder
← Previous message | Next message →

Hi,
JAWS uses INSERT+SHIFT+F1.

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

From: Mohith BP
Date: Mon, Mar 18 2019 11:17PM
Subject: Re: Placeholder
← Previous message | Next message →

Hi Eilana,

Using placeholder instead of visible label is wrong as the placeholder
text disappears after user input the value.
For screen reader alone aria-label can be used however this will not
help people with cognitive disabilities.
The only work around is using the floating label if the design / ux is
stubbern on using placeholder.

Thanks & Regards,
Mohith B. P.

On 3/12/19, Eilana Benish < = EMAIL ADDRESS REMOVED = > wrote:
> hello, my name is Eilana from Israel. Currently, I work with organizations
> required to make their websites accessible in Israel.
>
> We are working on developing a new website.
>
> We have a very serious disagreement about the place-holder as a method to
> label forms fields.
>
> I know that the popular screen reader reads the place holder. But this is
> mey not be accessible to users with cognitive disabilities.
>
> 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 have also tried to find information on the W3C accessibility resources â
> Without success.
>
> So, is the place holder WCAG 2 compliant
>
> And what the WCAG 2 working group has to say about that topic?
>
>
>
>
>
>
>
>
>
> --
>
> ×××××× ×¨×, ×××× × ×× ××©, ×××¨×©× × ×××©××ª ×©××¨××ª (2200)
>
> ××××× ×× ×××× ×¤×¨×××§×××: × ×××©××ª ××©×××©××ª ××× ××¨× × ×××× ×××××××ª ××××¢
>
> A.D.N: Accessible digital knowledge 2009 â 2019
>
> ×××¤×× 050-7100367 ×××"× = EMAIL ADDRESS REMOVED =
> ××ª×¨ ×××× ××¨× × × ×××©××ª ××©×××©××ª ××× ××¨× × ×××× ×××××××ª ××××¢ â IOS â ×× ××¨××××
>
>

From: JP Jamous
Date: Tue, Mar 19 2019 10:41PM
Subject: Re: Placeholder
← Previous message | No next message

Placeholder is not WCAG 2 compliant at all. It is not listed in WCAG 2, because placeholders came out later. However, the way a placeholder functions fails other level AA success criteria of WCAG 2. (Smiles, I love it when developers have strong Egos. I have some of those at my company.)

I have worked at multiple corporates in the USA and I can assure you that placeholders are not compliant. In fact, we prefer labels using the FOR attribute even if HTML5 is being used.

1. People with cognitive disabilities can be impacted by place holders
2. Placeholders do not have a proper color contrast for low vision and color-blind users
3. Placeholders do not remain visible enough for low vision users to read them
4. Placeholders disappear automatically without the user being alerted beforehand, which fails level AA of WCAG 2

Do your developers want more evidence? I would also like to see where in WCAG 2.0, they found that placeholders are compliant. *smiles*

It is a typical pushback from the developers. My suggestion to you is to bring the UX designers to your side. Educate them so they do not use placeholders in their design and to refuse to have developers use it as it is not a good user experience anyways. That will be your best bet to enforce that upon them. They are using it because it is less coding and saves precious space on the page especially in a mobile UI.

--------------------
JP Jamous
Senior Digital Accessibility Engineer
E-Mail Me |Join My LinkedIn Network
--------------------