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
text, or from the
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.
Posted by Douglas Clifton on
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
Posted by Gez on
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.
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
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.
Posted by steve faulkner on
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
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.
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]
Posted by Gez on
Some good news: Place-holding characters in empty controls (deprecated).
And a proposal for an erratum for WCAG 1.0.
Posted by Gez on
I've put together some notes and a bit of a test page for placeholder text. Thought it was worth flagging here.
Posted by dotjay on
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