Summary

Why does WCAG 1.0 checkpoint 10.4 require that authors include default place-holding characters in edit boxes and text areas? Is this checkpoint still relevant today?

Author: Gez Lemon

Checkpoint 10.4 of the Web Content Accessibility Guidelines (WCAG) 1.0 requires authors to include default place-holding characters in edit boxes and text areas. This is a priority 3 checkpoint that I assumed was no longer relevant. There appears to be little understanding as to why this checkpoint ever existed. There is an urban legend that the checkpoint exists for an old browser (probably Netscape 2) and a screen reader at the time (probably Outspoken for Mac). According to the legend, Outspoken was unable to set focus on edit boxes and text areas unless there was place-holding text. There may well be some truth in this legend, and if you know, I would really appreciate some more information about it.

This particular checkpoint came up today on the WCAG interest group's mailing list, where someone asked a question loosely related to checkpoint 10.4. In amongst the discussion, David Poehlman gave a response to Patrick H. Lauke that sheds a little more on the background for this guideline.

[Patrick], if the form is being brailled, you need something to note that a blank is there to be filled in. The braille form will not be filled in but used as a representation thus it needs not only a place holder, but the length of the field to be filled in. Remember fill in the blank? the blank was a blank block. In braille, it was noted with a dashed line running the length of the field.

That's really useful to know, and the first time I've ever heard that explanation. The problem is obviously with the Braille output device, as they should be able to get the information from markup either using the size attribute for input elements whose type is text, or from the rows and cols attributes for the textarea element. It would be interesting to know whether the problem is limited to a specific Braille output device, or whether it applies to all Braille output devices. All of the checkpoints that relate to guideline 10 of WCAG 1.0 are concerned with making up for shortfalls in user-agents by content developers. One would hope that after all this time, user-agents would at least be as concerned as content developers that all relevant information is conveyed to the user.

If you have any information at all about how default place-holding text improves real-world accessibility, I would very grateful to hear your views.

Category: Accessibility.

Comments

  1. [default-place-holding-characters.php#comment1]

    I would be interested in examples of this as well. If I recall correctly, you used to have placeholders in your forms, and now they no longer seem to be present. I was curious about this. I'm still using them, and with some very simple Javascript, the text therein is erased as soon as the input gains focus. Looking forward to more feedback on this topic... ~d

    Posted by Douglas Clifton on

  2. [default-place-holding-characters.php#comment2]

    First of all, checkpoint 10.4 does not require placeholder text. It says, "Until user agents handle empty controls correctly, include default, place-holding characters in edit boxes and text areas." I think it would be hard to find a user agent that doesn't know how to handle such elements, thus this checkpoint, in my mind, is outdated and shouldn't be applied.

    Place-holder text within a text input is read by most (all?) screen readers when focus is placed on the form. It was always my thought (though likely incorrect) that this would provide a description of the text box for assistive technologies that didn't support the label element. Because most user agents now also support the label element, we can notch up another reason why this checkpoint is antiquated.

    Posted by Jared Smith on

  3. [default-place-holding-characters.php#comment3]

    Hi Doug,

    If I recall correctly, you used to have placeholders in your forms, and now they no longer seem to be present.

    I decided not to keep placeholder text in forms because I couldn't see the need for it, and am interested in making sure the content here is truly accessible rather than just following guidelines without knowing why. It seems to me that this particular checkpoint creates more usability problems than it solves. If the checkpoint exists for screen readers that don't understand labels, then clearing the text with JavaScript negates the purpose for having it there in the first place. If the checkpoint is for old screen readers to place focus on the control when tabbing through the form collection, then clearing with JavaScript would work, but it could cause confusion to people who didn't get a chance to read it, and may think it's important. The only time I can see a need for placeholder text is in circumstances where the value could be used as the default option for the form, and/or to give a clue as to the format required. For example, when asking when membership is to commence from, it might be a good idea to provide placeholder text of today's date in the format required, such as: 2005-07-13.

    Posted by Gez on

  4. [default-place-holding-characters.php#comment4]

    Hi Jared,

    First of all, checkpoint 10.4 does not require placeholder text. It says, "Until user agents handle empty controls correctly, include default, place-holding characters in edit boxes and text areas.

    This is one of the problems with guidelines that state, "Until user agents ...". The guidelines have not been updated, so no official consensus has been reached by WAI about whether or not this checkpoint is still relevant. Like most others, I would also say that this guideline is no longer relevant. As far as reaching level AAA compliance for WCAG 1.0 (ignoring the fact that it's probably not possible), then this guideline is still relevant as there's no official consensus to say otherwise for WCAG 1.0, and therefore a requirement for AAA compliance. I think WAI have learnt from this, as they're desperately avoiding terms like "until user agents", but we're stuck with them as far as WCAG 1.0 is concerned.

    It was always my thought (though likely incorrect) that this would provide a description of the text box for assistive technologies that didn't support the label element.

    That sounds like a reasonable assumption, although that's what I thought checkpoint 10.2 was supposed to help with by placing the prompt correctly with the form control. That does make sense for early screen readers that made no attempt to associate form controls with prompts, so maybe that is the real reason as to why this checkpoint exists. Without knowing for definite why the checkpoint exists, then there's no way of knowing for sure whether or not it's still relevant.

    Posted by Gez on

  5. [default-place-holding-characters.php#comment5]

    From my experience observing screen reader users, on many occasions the presence of default text in a text input has actually hindered users. The reason being that a user will start typing into the input unaware of the default text which becomes tacked on to the end of whatever the user has typed in, this was particularly apparent for search inputs.
    I think the addition of a javascript function to remove the default text on focus is a reasonable way around this, but it must be remembered to include a check to ensure that only the default text is removed onfocus not user input(for example: if the user returns to the input after tabbing past it).

    Posted by steve faulkner on

  6. [default-place-holding-characters.php#comment6]

    It seems to me that this is a user agent problem. The information is there, but the software isn't using it to the advantage of the user. Now, what I'd be interested to know is whether this is down to default settings not providing that information to users, or a general failing in the software.

    Idealisms aside, if this is really a problem now, what harm would a default value of, say, a space pose for any user? And would this fix any such problems?

    Posted by dotjay on

  7. [default-place-holding-characters.php#comment7]

    Hi Jon,

    It seems to me that this is a user agent problem.

    It is a user agent problem, but no one seems to know for definite what it is. To be a priority 3 issue, it's most likely to have caused a usability problem that disadvantaged people with assistive technology, but didn't necessarily cause an accessibility barrier.

    Idealisms aside, if this is really a problem now, what harm would a default value of, say, a space pose for any user? And would this fix any such problems?

    Arguably, no priority 3 errors should cause major problems. They should all be more about usability specifically aimed at people with disabilities. The problem with this particular checkpoint is we're not sure what we're working around.

    If the problem is just that an old user agent with an old screen reader cannot give focus to form elements without place-holding text, then a space would be adequate. If Jared is correct that old user agents didn't associate labels with their form prompt, then a space is clearly inadequate. Similarly, if the place-holder text is supposed to be used as a guide for Braille output devices to determine the length of the field, then again, a space is clearly inadequate for form controls that could be printed. If the form control is an interactive element that wouldn't make sense when printed, then place-holding text wouldn't be required at all for Braille output.

    Without knowing the real reason as to why the guideline exists, there isn't a workaround short of putting place holder text in all form controls that clarify the prompt:

    Forename: [Enter your forename]

    To adhere to WCAG 1.0 level 3, place-holder text is a definite requirement. For true accessibility, I very much doubt that place-holder text is required at all, but I obviously cannot be sure of that, as I don't know why it ever existed. Adding minimal place-holder text or removing place-holding text with JavaScript is really just a means of working around accessibility validators with no thought to the real problem. It places the emphasis on the superficial result of getting a good validation score, rather than catering for people who may well need it, and putting a usability barrier in front of those that definitely do not need it.

    Posted by Gez on

  10. [default-place-holding-characters.php#comment10]

    dotjay: regarding adding a space as a default place-holder, I've tried this in the past and it's deemed acceptable by things like Bobby, though I imagine that's not a conclusive result. Adding 'value=" "' does the job.

    Posted by paul haine on

Comments are closed for this entry.