Place Holding Text In Form Inputs
There has been a general consensus of opinion, until now, that Priority 3 Checkpoint 10.4 of the WCAG 1.0 Guidelines can be safely disregarded. The checkpoint relates to the use of place holding characters within text input areas.
10.4 Until user agents handle empty controls correctly, include default, place-holding characters in edit boxes and text areas.
As screen reader software advanced, it became obvious that, rather than contributing towards the accessibility of forms, place holding characters could actually be, at best, a nuisance and , at worst, an accessibility barrier for people with visual impairments. Using place holding text such as Enter name here meant that all users, including screen reader users, had to remove the place holding text first before entering their own information. In some cases, screen reader users were completely unaware of the place holding text, resulting in forms being submitted with entries such as:
Name hereFred Smith
There are JavaScript solutions available, which are intended to clear the place holding text as soon as the focus moves to the input box but, obviously, these solutions depend upon the user being able to access JavaScript. Since some estimates of non-JavaScript users are as high as 10%, this may still not be an ideal solution. The obvious answer, in light of the available evidence, appeared to be to abandon this particular checkpoint.
More recently, it has come to light that there is one group of users that still rely heavily upon place holding characters within forms inputs.
Users of Braille readers.
Unless a form text input contains at least one place holding character, Braille readers will not allow focus on that particular input. Which means that, if you do not include place holding characters within your online forms, Braille reader users will not be able to complete them.
So, obviously, Checkpoints 10.4 cannot be ignored. But how can you implement it without causing problems for screen reader users?
Rich Pedley of the Guild of Accessible Web Designers came up with a solution: a single white space character. A single space is unlikely to cause problems for screen reader users, it will not force users, generally, to empty the text box before adding their own information and it will address the problem faced by Braille reader users. Even if form inputs are submitted with the place holding single space intact, this can be easily stripped out during the form validation process.
So , checkpoint 10.4 is back on the menu – providing you use the right place holding character.
I am trying to create a form where textareas are ‘required’ by the user but if I include defaulted text within the box (W3C Priority 3 accessibility guideline) or as noted by Rich Pedley, include a white space, the ‘required’ part will no longer work, which means the user can just select ‘submit’ and I won’t get the information I need from them.
Any suggestions?
Thanks – Lisa
Carry out a specific check on the required input. If the input equals null or your default text, display an error message to the user and direct them back to the form again.
I tend to use something like:
/* Check that a required input has been submitted
$text = the user's input
$default = your placeholding text
$msg = the error message you want displayed to the user
Call the function using:
list($flag, $display) = checkField($text, "Please enter your comments", "You left the Comments field blank!");if($flag==false) echo $display;
function checkField($text,$default,$msg){
$result = array();
// Has something been submitted?
if(($text=="") | ($text == $default))
{
$result[0]=false;
$result[1]="".$msg."";
return $result;
}
else
{
$result[0] = true;
return $result;
}
}
If you can edit the code that processes the submitted form data, all you need is something along these lines:
if(strlen(trim($formdata))
err… silly html error. like this:
if (strlen(trim($formdata)) < 1) then user left the field empty