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.
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.
Testing the following things:
- 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?
- 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
- 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.
Proposed solution 1: Check for default values and add select or clear behaviour there too.
Proposed solution 2: Provide a server-side backup.
- 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
Please note: the following form does not yet submit to anywhere.