One great relief to screen reader users may come into being when web authors realise that WCAG 2.0 has no requirement whatsoever to provide place-holding text in form fields.
The old guidelines, WCAG 1.0 only mentioned this technique as a Priority 3 requirement, and prefixed it with the "Until user agents ... " provision. It's been several years since user agents couldn't handle empty form controls correctly, and for about as long, we have recommended that the practice be discontinued.
Out with the old
Checkpoint 10.4 (priority 3) in the WAI Web Content Accessibility Guidelines 1.0:
"Until user agents handle empty controls correctly, include default, place-holding characters in edit boxes and text areas."
This is one of those checkpoints that was always meant to be an interim solution to a problem that existed at the time the Web Content Accessibility Guidelines were written. In fact, place-holders can actually cause problems for some users because of how some browsers and screen readers interact when handling place-holder text.
The problem
Contrary to normal Windows behaviour, some browser / screen reader combinations don't automatically select the text in an edit box when the element receives focus. This seems to be most common in screen readers that have a "Forms Mode", because while in a reading mode, the focus isn't actually on the page, but on the screen reader buffered version of it.
So when the user enters the edit box or textarea, the cursor arrives in the form field, but the focus is still in the buffer copy. Switching to Forms mode doesn't have the same effect as tabbing into the field, so the place-holding text isn't highlighted. It stays put while the user types their input, which is added to the place-holding text.
For example, consider a simple text edit box labelled "Date" and pre-populated with the prompt "Enter start date". The user moves into the box, is unaware that there is text already there, so simply types "09 September 2009". Now the box contains "09 September 2009Enter start date".
This is the type of problem that may cause invalid form submission, if the date format is to be checked. But the screen reader user can only discover it prior to form submission if they actively direct their screen reader to select and read the content of the edit box for some reason, such as to check if they have entered the correct date.
The solution
We strongly recommend avoiding the use of place-holder text.
However, some designers like to use place-holder text as an additional prompt to the user. This is fine, but we recommend using JavaScript both to select the place-holder text when the text entry box receives focus, and to insert the place-holder text in the first place when the page is loaded, so that the form field is empty if JavaScript is disabled or not supported.
Bim Egan
Senior Web Access Consultant
September 2009