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.

Read the notes for this test
Go to the test form

Notes

Testing the following things:

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.
The problems covered by Checkpoint 10.4 are due to fairly ancient issues with browsers and assistive technologies. The WAI specifically mention:
- 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.

Test 1: Using JavaScript to select placeholder text

If JavaScript is available and placeholder text is set and will be selected when the input box receives focus. The user should then be able to type in the box, replacing the placeholder text. The placeholder text should still be available to assistive software while it is selected (for example, it should still be read out by screen readers).

Text input 1: Text area 1:

Test 2: Using JavaScript to clear placeholder text

In this test, the placeholder text is cleared from the input box instead of being selected. This difference could mean that the placeholder text does not get passed to assistive software and to the user.

Text input 2: Text area 2:

Test 3: No placeholder text (title attribute set)

Some people prefer not to have placeholder text at all. However, a helpful prompt is still available in the title attribute, but no placeholder text should be set, even if JavaScript is available.

Text input 3: Text area 3:

Test 4: Classic placeholder text without JavaScript

Placeholder text is set as a value of the input within the HTML rather than by JavaScript, leaving behaviour up to the browser default. For example, in Firefox the text input should select any text when it receives focus, but when the text area receives focus, the cursor will simply go to the end of the placeholder text.

Text input 4: Text area 4:

Back to the notes for this test
Back to the top of the test form