Categories
A11y

Testing Accessibility of Pre-populated Input Fields

It’s becoming increasingly common for web pages to include input fields, especially search fields, that prompt the user with placeholder text inside the input field, rather than a separate visible label. The main argument I’ve heard for doing so is to conserve scarce screen real estate.

I’ve seen this implemented in a variety of ways, some more accessible and usable than others. This blog post is my attempt to test a few of these methods, and identify a best practice for how to do this in a way that works for everyone.

You can access all the example pages together on my Form Test home page, or access each example page individually by following links in context below.

Example 1

Example 1 Test page

The simplest method for pre-populating an input field is to simply add content to it’s value attribute, like so:

<input type="text" name="search" id="search" value="Search" />

However, there are problems with this approach.

First, the default value does not disappear when the user clicks on the field. Therefore the user could accidentally append their own text to the default text, and submit that mess as their search query. If they’re aware of the default text they might delete it before typing their own text, but this is burdensome for the user.

The above problem could be addressed by using Javascript to clear the default value when the field receives focus (I’ve done this in subsequent examples). However, if we use Javascript at all, it isn’t going to work for users without Javascript enabled. Therefore we should pre-populate fields only for Javascript users, rather than burden non-Javascript users with a half-broken solution.

Another potential problem with this example is that there is no <label> element. In fact, the pre-populated value is often used by developers as a substitute for a label. Is this ok? Let’s consider it for a moment. The applicable success criterion in the W3’s Web Content Accessibility Guidelines 2.0 is SC 2.4.6, a which says "Headings and labels describe topic or purpose. (Level AA)". In the WCAG 2.0 Glossary, the definition of term "label" says (in part) "The term label is not limited to the label element in HTML." Therefore, some might argue that providing a label within the value of the input text satisfies this criterion. But does it work?

Current versions of JAWS, Window-Eyes, NVDA, and VoiceOver all read the value, just as they would read a label, when the field receives focus. So far so good.

However, if the user deletes the prompt or replaces it with other text, and then navigates elsewhere on the page and returns later, the prompt is no longer available. Given this, my position is that pre-populated input values should not be used as a substitute for HTML <label> elements. If there’s no space available in the design for a visible label, and the purpose of the field is obvious based on its position and context, the label could be positioned off-screen so it’s only visible to screen reader users.

Also, if the field is pre-populated using Javascript (as recommended above), then users without Javascript would receive no prompt whatsoever unless a label is present.

Example 2

Example 2 Test page

This example differs from Example 1 in several ways:

In the HTML markup, a label has been added (and explicitly associated with the input field), and there is no value by default (it’s added later using Javascript).

<label for="search">Search:</label>

<input type="text" name="search" id="search" />

Using Javascript, we wait until the window has fully loaded, then call a function that initializes the form by:

  1. populating the input field with a default value
  2. adding an event listener that clears the default value when the user clicks on the field.

This example is ok for most users. If mouse users click on the field (or even on its label) that has the desired effect of clearing the field. Also, when keyboard users tab to the field in any browser, the value is automatically selected and will disappear as soon as they begin to type.

However, this example does not work for screen reader users, at least not in Windows. Here’s what happens for them:

  • JAWS users can navigate to the first (next) form field using the shortcut key "f". JAWS announces the field, its label, and its default value. Users can then give the field focus and enter forms mode by clicking with the mouse button or pressing Enter. However, doing so does not trigger the click event. Therefore the Javascript that clears the field is not activated.
  • NVDA users can also navigate to the first (next) form field using "f". When they do so, they jump directly into the form field, ready to enter text. Again, the label and value are announced. And again, the click event is not triggered. Therefore the default text does not disappear.
  • For Window-Eyes users, the "f" key jumps to the first (next) form, then users must hit "c" to navigate to the first control within that form, and Enter to give that control focus. Again, this does not trigger the click event and the default text does not disappear.

The solution is to use the focus event rather than the click event.

Example 3

Example 3 Test page

This example uses the focus event to trigger the clearing of the default value, and adds a blur event to restore the default value if users leave the field without entering new text.

The HTML for this example is the same as in Example 2, but the Javascript is different. Here’s the entire relevant Javascript block:

function init() {

  var defaultSearch = ‘powered by Google’;

  //add default value to search

  document.getElementById(‘search’).value=defaultSearch;

 //when either search field gets focus, remove the pre-populated text (if it exists)
  if (document.addEventListener) { //browser supports addEventListener
    document.getElementById(‘search’).addEventListener(‘focus’,function (e) {
      if (document.getElementById(‘search’).value==defaultSearch)
        document.getElementById(‘search’).value=””;
    },true);
  }
  else if (document.attachEvent) { //browser is IE
    document.getElementById(‘search’).attachEvent(‘onfocus’,function (e) {
      if (document.getElementById(‘search’).value==defaultSearch)
        document.getElementById(‘search’).value=””;
    });
  }

  //when either search field loses focus (e.g., user tabs away)
  //if field has no value, restore default value
    if (document.addEventListener) { //browser supports addEventListener
      document.getElementById(‘search’).addEventListener(‘blur’,function (e) {
      if (document.getElementById(‘search’).value==””)

        document.getElementById(‘search’).value=defaultSearch;
    },true);
  }
  else if (document.attachEvent) { //browser is IE
    document.getElementById(‘search’).attachEvent(‘onblur’,function (e) {
      if (document.getElementById(‘search’).value==””)
        document.getElementById(‘search’).value=defaultSearch;
    });
  }
}
window.onload=init;

This example seems to provide maximum accessibility and usability for all users. However, as always I’m open to feedback and suggestions.

10 replies on “Testing Accessibility of Pre-populated Input Fields”

These findings are the same as what I've witnessed. Of note is that in Example 1, the title attribute can be used as a substitute for the off-screen label, though I don't like relying on the arbitrary presentation of the title attribute for such things. If the information is necessary for accessibility, I prefer off-screen labels. The title attribute is defined as being for advisory information, not vital-for-accessibility information.

The HTML5 placeholder attribute is designed to function precisely as your scripted Example 3. However, HTML5 specifies that the placeholder is not an alternative for a label – so a label (possibly off-screen), aria-labelledby, or title attribute is still necessary.

Many thanks for sharing this research. While not directly about about pre-populating input fields, I would like to throw another suggestion for handling search inputs into the mix. What about we don't pre-populate a search input and don't use a label? Instead we give the input a title attribute of "site search" (or whatever is appropriate) and use the word "search" as the label for the submit ('go') button. I think most screen readers will report the input title when there is no label and for sighted users the button label would communicate the intention of the input.

@Jared thanks – I've added a fourth test page that uses the HTML5 placeholder attribute instead of all that Javascript. It's not supported yet in IE8 or Firefox 3.x, but current versions of most other browsers seem to support it (works in Chrome, Opera, and Safari), as does Firefox 4 beta 9. No apparent support from Windows screen readers though. VoiceOver does support it (tested on my iPhone and iPad).

@Roger thanks – I've added a fifth test page that implements your recommendation, and it does seem to be a viable alternative. You're correct that most screen readers report the input title in the absence of a label – I just confirmed that with current versions of JAWS, Window-Eyes, NVDA, and VoiceOver.

This is a very interesting topic and as always points out that so much about accessibility is in how you code it. However, i have a slightly different angle for you along the same topic. Lets say you have a web app, the fields have labels and they're correctly associated, you're using HTML 4.01 in IE8, lets say the code is perfect. If i prepopulate some fields with data based on a couple of assumptions from other data filled in by the user, is that usable for users of assistive technologies? Will it make sense to them? If there is nothing stopping them from changing those prepopulated values technically, is it obvious that they can edit them?

@Tammy yes, I think what you're describing is fine and expected behavior in most cases. If the form fields are populated with data on the server side before the form is written to the DOM, then sure – this won't be a problem. When screen readers encounter a field they typically announce the label, type of field, and default value if one is present.

If field values are altered dynamically using Javascript based on user input, accessibility depends a lot on the web app's user interface. If the altered fields occur later in the form, so screen reader users haven't gotten to them yet if they're moving sequentially through the form, then screen reader users are not likely to have a problem with this. However, if user input results in changes to form fields that users are likely to have already read, that becomes a more challenging interface to make accessible (though not impossible – you would just need to think very carefully about how to communicate to users that the form has changed).

Thanks for working through the different examples and posting them. This will be a very helpful resource. I confess that I'm not sure that I find the argument about conserving scarce real estate very compelling except for viewing on mobile devices, but that's a different discussion, of course.

Terrill,

Do you know if there is any usability/accessibility research on pre-populated form fields? It came up in a Twitter discussion today.

@Deborah I haven't seen any usability research on pre-populated form fields, but I haven't done an exhaustive lit review. If any research exists in this area I'd love to know about it.

A couple years ago Chui Chui Tan wrote an interesting article based on her eye tracking study on web forms. Pre-populated fields were discussed a bit in the comments, but they weren't addressed in the study itself.

Comments are closed.