Have you ever validated your site and the validator grumbled to you about not having default place-holding text? Have you never heard of place-holding text nor understood why it’s used?. Gez Lemon has some answers and a method for dealing with place-holders.
Place-holding text and standards
Guideline 10.4 of the Web Content Accessibility Guidelines 1.0 (WCAG) requires that developers provide place-holding text for edit boxes and text area elements. This is a priority 3 issue, which means it’s desirable for developers who want to reach their maximum audience. This particular guideline comes under the general heading of “Use interim solutions”. The guidelines became a recommendation on the 5th May 1999, and obviously in the mean time, user agents have advanced such that they can cope without the need of place-holding text. So why should a developer consider providing placeholder text?
So why use place-holding text?
- The first and obvious answer is that there is no guarantee that your visitors are using modern user agents. Older user agents were unable to cope without place-holding text for these elements, as it was impossible to navigate to the field using a keyboard “TAB”. In the scheme of things, this is probably an extremely small percentage of your audience.
- However, there is a second reason why you may consider providing place-holding text. Place-holding text provides context, without cluttering up your design with examples of the type of data expected for each field.
The place-holding text is contained within the value attribute of the element. For example, you could provide place-holding text for an input element as follows:
<input type="text" size="15" value="search" id="search" name="search" tabindex="7" />
So that’s excellent! We have a means of providing context information, without cluttering our wonderfully laid out design. But…
The downside of place-holder text
Place-holding text will result in your form working in older user agents, and also provide context information. It also means that when a visitor navigates to the field, they have to delete the content that’s been provided as place-holding text. Our main reason for adding place-holding text was to aid accessibility, but it requires more work for the visitor. Surely this can’t be correct?
JavaScript Alert!
Fortunately, JavaScript offers a neat solution. It should be noted that overcoming a problem of dealing with place-holding text using JavaScript would obviously not work should JavaScript not be supported. There are many reasons as to why JavaScript may not be enabled, from not being supported by the user agent, to being disabled deliberately by a security conscious visitor. However, in general, JavaScript does provide an efficient means of dealing with place-holding text, and we can use it in a way that doesn’t cause any problems for non-JavaScrpt browsers.
Your place or mine?
There are two methods that can be seen in action on many sites that use place-holding text. The first method is to delete the text as soon as the user navigates to the field. This is done using the onfocus event for the element. J avaScript contains an object called “self”, which always refers to the element where it is defined. In an edit box, or a text area element, “self” refers to that element. Through the “self” object, you can change the any of the properties that are entered manually. If we specified the value property, we could overwrite the existing value as follows:
<input type="text" size="25" value="[Enter search term]” id=”search” name=”search” tabindex=”7″ onfocus=”this.value=”;” />
When the visitor navigates to the field, the value of the field is replaced with the content of the single quotes. In this example, the quotes are empty, meaning the content is deleted. For a search field, that could be considered acceptable, as it would be fairly obvious to most users what to enter. If you’re providing conceptual clues as place-holding text, you will not want to delete the content when a visitor navigates to that element, as they won’t have a chance to read it. Luckily, the elements contain a select method. Using a select method will leave the text in place, but highlight the place-holding text. As it’s highlighted, it will be deleted as soon as the visitor starts to type, with no extra work required. We have the benefit of the place-holding text for context information, but it doesn’t hinder the accessibility of that control. This is even more useful should the place-holding text be suitable for a default value. The user can change it effortlessly, or just skip over that element if the existing value is appropriate. The following example illustrates the use of the select method to highlight the place-holding text of an edit element.
<input type=”text” size=”30″ value=”[Why do you require this sample?]” id=”reason” name=”reason” tabindex=”8″ onfocus=”this.select();”/>
Two places at once.
The examples so far have been applied to an edit box, but may be used exactly the same for the text area element. The following example illustrates the use of the select method to highlight the place-holding text of a text area element.
As well as ensuring your content is available to the widest possible audience, place-holding text can provide invaluable context information. JavaScript provides an efficient means to handle the place-holding text for JavaScript enabled user agents. The two methods of handling the place-holding text will depend on your requirements, but from a context point of view, the select is the safest method to use. Protect your visitors from the frustration of having to guess what you mean the next time you put together a form in HTML.