W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > October to December 2011

RE: placeholder text in input controls

From: Jason Megginson <jason.megginson@ssbbartgroup.com>
Date: Mon, 12 Dec 2011 12:52:35 -0500
Message-ID: <55ec62e0938a81af82456072aed0b858@mail.gmail.com>
To: Devarshi Pant <devarshipant@gmail.com>, w3c-wai-ig@w3.org
There is a noted "failure of success criterion" of 3.3.2 at:
http://www.w3.org/TR/2010/NOTE-WCAG20-TECHS-20101014/F82.  Although this
failure example is specific to "phone numbers" there are other scenarios
for which a visible label should be present. As Bart mentioned, the
placeholder value disappears visually and the title attribute value
appears only upon a mouse-over.  Overall, the code example is fine in
regards to providing an accessible label for users of screen readers. If
the placeholder attribute is used, the title attribute must accompany it
at a minimum.  However, users with low-vision or users with cognitive
disabilities could be at a disadvantage. Among this scenario and the
following screen reader observation, there is a strong argument to use
explicit label markup with the label element and 'for' attribute with a
visible (on-screen) label.

My primary concern with the use of "placeholder" is how consistently or
inconsistently is it used by developers to denote the fields' labels
versus (e.g. date) mere field constraints (e.g. field format or help
text).

In regards to screen reader support, it may be more likely that the lack
of "JAWS" support is an IE9 issue when implemented without the title
attribute. When JAWS is used with IE9, the placeholder attribute value is
not announced by the screen reader after tabbing to the field because
there is no MSAA name or MSAA description assigned via the placeholder
attribute. In contrast, Firefox renders the "placeholder" value as the
accessible name of an input field; in other words, the placeholder value
takes precedence as the label in Firefox and will be read by JAWS.

When a title attribute is used in addition to the placeholder, Firefox
sets the placeholder attribute value as the MSAA name and the title
attribute value as the MSAA description. If I had my druthers, it would be
the opposite. I would prefer the title attribute being set as the "label"
via the MSAA name property and the placeholder value as the MSAA
description. The placeholder should act as supplemental information to the
label set via the title attribute. In comparison, IE 9 sets the title
attribute value as the MSAA name (or label). Unfortunately, the two
browsers don't render the placeholder attribute similarly.  Per the MSDN
definition of the Accessible Description property, the AccessibleName
would describe its [object's] purpose while the AccessibleDescription
would convey information that is less tangible.

http://msdn.microsoft.com/en-us/library/system.windows.forms.control.acces
sibledescription%28v=vs.71%29.aspx

When explicit label structure is used (label tag and the for attribute),
Firefox will rely on the explicit label (set as the MSAA name) and ignore
the placeholder text completely.  Again, if Firefox would render the
placeholder as the MSAA description, this would be optimal. This is
unfortunate because I too find value from the placeholder attribute for
sighted users but at this time the placeholder attribute must not be the
sole means of label markup. In my opinion, the best use of the placeholder
attribute among the popular browsers (IE and FF) is to use it for
supplemental information (i.e. constraint information) and used in
conjunction with explicit label markup and the title attribute.

<label for="birth_date">Enter birth date</label><input title="birth date
(mm/dd/yyyy)" type="text" id="bd" name="bd" placeholder="mm/dd/yyyy"/>

In summary, I would argue that the "failure of success criterion" for
3.3.2 applies to all scenarios where an adjacent on-screen label or button
does not accompany a field. The placeholder alone, does not provide screen
reader users the optimal label. The placeholder and title attributes do
but this could leave a user of screen magnification, a keyboard-only user,
or a user with a cognitive disability at a disadvantage.

Jason Megginson
SSB BART Group
703-637-8964 (o)
703-244-7755 (c)


-----Original Message-----
From: Devarshi Pant [mailto:devarshipant@gmail.com]
Sent: Monday, December 12, 2011 11:59 AM
To: w3c-wai-ig@w3.org
Subject: RE: placeholder text in input controls

Hi All -- Reverting to the original post from Bart:
Bart wrote:
Now some sites start to use placeholder text instead of visible labels
next to the control. I don't see this technique in WCAG2.0. Do you
consider this sufficient to comply with success criterium 3.3.2 labels or
instructions?
Example:
<input title="What is your first name?" type="text" name="f"
placeholder="First name">
<input title="What is your last name?" type="text" name="l"
placeholder="Last name">

***When I tested the code with JAWS 10 on IE7 and Firefox 3.6, (using
different screen reader settings), the forms list utility displayed the
placeholder attribute. MAGic 11 gave the same result (Note: MAGic does not
detect the title attribute - only the label). My previous post suggested
that the form would be inaccessible when the settings favor the label, but
it is not the case-it is accessible. If possible, could someone reconfirm
this?***

John Foliot wrote:
(*In a related question(s), _should_ the placeholder value be exposed to
the AAPI? Would this end up being redundant information? Would the user
experience be improved or hindered if it were exposed? I'm not sure at
this time...)

***You make a good point. However, based on the results above, I have a
question: As the AT picks up the placeholder name and displays it just as
it would a label, isn't the AAPI already exposing the placeholder
attribute?***

Thanks,
Devarshi
Received on Monday, 12 December 2011 17:53:07 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 12 December 2011 17:53:09 GMT