RE: Placeholder behavior

I agree that these are concerns but I’m looking at how they map to WCAG success criteria. The only one that I think that there is likely to be debate around is whether 3.3.2 (Labels and instructions) is satisfied if the placeholder text is counted on to provide the label/instructions and only is available in the situation where the user hasn’t entered a value yet.  For that point, I think that the question is whether users with disabilities are disproportionately affected or if the issues created for users when the label disappears are effectively general usability issues rather than accessibility.

I absolutely agree that the contrast on the placeholder text needs to be made sufficient and it should also be made to look different from the manually entered text

I’m not sure of the answer.  I’m generally of the mind that placeholder text on a very small form (e.g. a username and pw login form) is probably not causing anyone real problems, but do worry that the relatively small form factor of mobile devices causes developers to make longer forms use placeholder and I don’t have good information on who is affected.

Is anyone aware of any studies on this?

Thanks,
AWK




From: Steve Faulkner [mailto:faulkner.steve@gmail.com]
Sent: Monday, October 06, 2014 4:59 PM
To: jon.avila@ssbbartgroup.com
Cc: Sailesh Panchang; Web Content Accessibility Guidelines Working Group
Subject: Re: Placeholder behavior

sure, use of placeholder alone is problematic for a number of reasons. that's why I put the following in the HTML spec[1]:

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.

[1] http://www.w3.org/html/wg/drafts/html/master/forms.html#the-placeholder-attribute



--

Regards

SteveF
HTML 5.1<http://www.w3.org/html/wg/drafts/html/master/>

On 6 October 2014 21:16, Jonathan Avila <jon.avila@ssbbartgroup.com<mailto:jon.avila@ssbbartgroup.com>> wrote:
Use of placeholder without other visual label also raises concerns under SC.  3.3.2 in my opinion.

Jon


On Oct 6, 2014, at 3:30 PM, Steve Faulkner <faulkner.steve@gmail.com<mailto:faulkner.steve@gmail.com>> wrote:
hi sailesh,

although placeholder should not be used as a label it sometimes is. For the purpose of accessible name calculation in browsers placeholder is used as a fallback accessible name in accessibility APIs when other names sources are not provided.

here are some results of browser testing from late last year http://www.html5accessibility.com/tests/placeholder-labelling.html


--

Regards

SteveF
HTML 5.1<http://www.w3.org/html/wg/drafts/html/master/>

On 6 October 2014 20:08, Sailesh Panchang <spanchang02@yahoo.com<mailto:spanchang02@yahoo.com>> wrote:
JAWS 14/15 and NVDA  read the placeholder label even after entering text into the text field  in Firefox32 and IE11. VoiceOver in Ios 7 does not do so.
So for instance in the following code, the placeholder "Account number:"  though not visible, is announced by JAWS and NVDA even when some text is present in the field.
<p><input type="text" placeholder="Account Number:" size="7" /></p>
(Note: There is no text  outside the input element that funtcions  like a label).
NVDA does not read it  when arrowing through the content (i.e. out of forms mode) when there's data in the field.
HTML5 specs clearly states using placeholder as a label poses accessibility problems.
But thought I'll note this interesting behavior with screen readers.
Sailesh