Input Placeholder Text – JavaScript selection versus clearing and related notes
Last updated: October 26, 2009
This experiment is getting a bit old now. I might come back to it for some actual user testing soon.
The most useful thing to most visitors right now is probably the JavaScript I wrote to handle the placeholder text. There are notes in that file to show you how it is used. The license on this code is “take it, use it however you like”.
There are also a few notes below discussing whether or not form placeholder text is really useful or not, and whether or not it should actually be a requirement to meet WCAG.
the use of JavaScript to pre-populate form fields with placeholder text.
the effects of selection versus clearing of placeholder text.
how placeholder text affects current assistive software (screen readers, Braille devices).
Questions to answer for screen readers and, particularly, Braille devices:
Do title attributes on the input elements get conveyed to the user? (would depend on screen reader settings)
Does the selected placeholder text get conveyed to the user?
Does the selected placeholder text get over-written when the user types?
Does the cleared placeholder text get conveyed to the user before it is cleared?
What happens when JavaScript is not available? (expect title attribute to be read to user, but would depend on screen reader settings)
How does a user cope when no placeholder text is used?
Additional notes and thoughts:
This experiment came about following discussion on the Web
Accessibility Initiative interest group mailing list concerning Braille devices and reports that problems can still arise from empty form
inputs for users of Braille displays, etc. This may help in answering the question of whether or not
Checkpoint 10.4 ("Until user agents handle empty controls
correctly, include default, place-holding characters in edit boxes and text areas.") is still relevent today. Gez Lemon has some interesting
discussion on the matter: Juicy Studio: Default Place-Holding
Characters.
Older browsers (Netscape 2.0?) did not allow users to navigate into form controls
Older assistive technologies in trying to overcome this issue would only navigate into form controls with content
Some users prefer no placeholder text at all because it gets in the way if it is there, or are at least happy for any placeholder text to be
cleared when an input receives focus. Some users prefer that placeholder text remains when an input receives focus. These opposing preferences
make it difficult to reach a satisfactory solution.
Placeholder text can give rise to the problem of that text not being cleared by the user agent or the user and then being submitted along
with other form data.
Potential solution 1: Check server-side for placeholder text for the inputs turning up within data when it is submitted.
Potential solution 2: Use a space as placeholder text to satisfy Checkpoint 10.4 and trim submitted data server-side.
No default values (element.defaultValue) are used in this experiment. Title attributes are used to populate the inputs.
Problem: This relies on JavaScript to populate the inputs.
Proposed solution 1: Check for default values and add select or clear behaviour there too.
Proposed solution 2: Provide a server-side backup.
If Web developers want to know how the JavaScript adds the placeholders and controls their behaviour, I have commented the markup and
JavaScript file as best as I could.
Perhaps try to extend this by adding an on/off switch for pre-population (would use cookies) so users have a preference setting.
Scripts that accept information from fields with placeholder text could check for placeholder text being prepended to what the user
actually meant to enter into the field, but it could be an inelegant solution (server-side versus client-side issues and "keeping everything in
one place"). If JavaScript is available, and therefore populates the fields, perhaps it could be used to do this check?
Test Form
Please note: the following form does not yet submit to anywhere.