Accessibility of pre-filled input fields

In the last few days 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?”.

Example 1 - Search form with pre-filled text input

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:

Example 2 - Search form with label

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 us your experience on the subject because I’m sure that something interesting could come up!

Leave a Comment

Larry Roth said

Great analysis. I agree with your point. At first, I was thinking of arguing back that pre-filled fields can aid usability, but your comment about making more descriptive labels helps solve that.

One thought…If you use Javascript to empty the text field, you can use javascript to populate it in the first place. This would be more onerous on the developer, but you wouldn’t have to worry about screen readers or people with JavaScript turned off. Right?

wrote on April 8, 2009 @ 7:50 am

Andrea - CSSGlance Staff said

Hi Larry, thanks for your interesting reply.

Adding a default text onload using JavaScript might be a possible solution indeed, especially in those cases where you cannot actually use a label because you don’t have enough space. I’m thinking of inline fields, put in a single line one after the other, like month and day.

On the other hand, as far as I know, some screen readers might have problems handling this kind of pre-filled text, even if JavaScript is turned on. This because they might not clean up the field properly when onfocus.

I’m really keen to hear the opinion of someone who has made or can run some tests with different screen readers.. they might have the answer!

Andrea

wrote on April 8, 2009 @ 10:33 am



News and Articles

@media 2009 London

One day to go! What is considered one of the most intriguing and awe-inspiring web events around, will take place in London on Tue 25th and Fri 26th.

12 examples of mind-blowing websites

Web designers struggle every day to create impressive and usable websites, but what makes the difference between a good and functional product and a mind-blowing one?

News and articles archives

Recommended Books

Bulletproof Web Design

Bulletproof Web DesignStandards-based strategies for building designs that provide flexibility, readability, and user control--key components.

Web Standards Creativity

Web Standards Creativity10 web design lessons from 10 of the worlds best web designers: cutting-edge XHTML, CSS, and DOM scripting techniques.

Recommended books archives