Accessibility of pre-filled fields


Few weeks ago I found myself facing a tough question: are pre-filled input fields considered accessible yet? It took me some time, asking my colleagues and consulting accessibility experts, to find out a possible answer.

Let’s take a common search form as an example. For the input field which lets you type in the text you want to search, so far I’ve always been using a default pre-filled text, something like “Search the site”, “Looking for something?” or “Can we help you find something?”.

This was because Checkpoint 10.4 of WCAG 1.0 recommended that until user agents (such as browsers or screen readers) handle empty controls correctly, we had to include default, place-holding characters in edit boxes and text areas.

To avoid the inconvenience for the users to have to remove the default text before typing in their keywords, I used to add a small inline JavaScript to clean up the field as soon as the user clicks on it or the field gets the focus on. This was obviously only a partial solution because users who browse the page with JavaScript disabled would have to select the default text and delete it. That could be a nuisance indeed and would affect usability as well.

Things have changed since December 11th 2008, when WCAG 2.0 became W3C recommendation. Simply reading WCAG 2.0 you don’t find any reference to pre-filled text though. This could be a bit confusing and actually that’s what disoriented me when I was trying to get an answer to my question.

But, reading carefully the W3C documentation, I finally found my answer! Within the comparison of WCAG 1.0 Checkpoints to WCAG 2.0, you can find the following sentence referring to Checkpoint 10.4 of WCAG 1.0:

Checkpoint 10.4: Until user agents handle empty controls correctly, include default, place-holding characters in edit boxes and text areas. [Priority 3]. This “until user agents” condition has been met. Therefore, this checkpoint is no longer required.

WCAG 2.0 states that we do not have to include the default text anymore, because now user agents are capable to handle correctly empty fields. This helps to clarify a bit, but I think it’s not enough yet. In fact, it is not clear if we simply can avoid to use pre-filled texts or if we don’t have to use them at all.

Finally, I cleared my doubts chatting with a guy who is part of the W3C project and who usually runs usability and accessibility tests in CFIT, the Center for Inclusive Technology, based in Dublin, Ireland. He told me that users testing show that adding pre-filled text is no longer necessary for accessibility. Research, in fact, has shown that pre-filled text fields can cause difficulties for some modern screen readers, especially if JavaScript is disabled.

Based on these tests and on WCAG 2.0 we should definitely stop using pre-filled text inputs. Anyway, I think that having some explanatory text might improve usability. The easiest solution, in my opinion, is to replace pre-filled texts (as “Search the site” in search forms or “dd/mm/yyyy” in date input fields) with labels. Labels are strictly related to inputs fields, by the use of the FOR and ID attributes, and describe the input they refer to. This kind of helpful info should be added to the label text. Taking our example once again, I would replace the use of the default text in the input filed with the label as follow:

In this case we can be sure we comply with WCAG 2.0 and we can also sort out the accessibility issue that we would encounter when users browse the page with JavaScript disabled. Hope this article helps to clarify the matter. I’d like you guys to tell me your experience on the subject because I’m sure that something interesting could come up!

Posted on Friday 25 December 2009 at 14:59

Comments are closed.

Leave a comment

Please rate this article and help us plan future posts. Comments are moderated. Do not spam for any reason. Ever!