Input Placeholder Text – JavaScript selection versus clearing and related notes
Last updated: May 8, 2007
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?
Please note: the following form does not yet submit to anywhere.
| dotjay’s lab / experiments / forms / input-placeholder-text