WebAIM - Web Accessibility In Mind

E-mail List Archives

Thread: Accessible web forms: default text in edit boxes and text areas

for

Number of posts in this thread: 18 (In chronological order)

From: Catherine Brys
Date: Wed, Feb 23 2005 3:55AM
Subject: Accessible web forms: default text in edit boxes and text areas
No previous message | Next message →

Hello,

The current Web Content Accessibility guidelines advise to put default text
in edit boxes and text areas. However, I have found that people who don't
use a screen reader tend to skip these fields. My guess is that because they
see a non-empty field, they tend to ignore it, assuming it doesn't need
their .

Using JavaScript to clear the field when you click it is not a solution
because people will not click in the field, they just skip it.

Greying out the default text is also not a perfect solution because visually
impaired people may see there is text there but may be unable to read it.

May question is twofold:
- Does anyone know exactly which problem screen reader users encounter if
you don't use the default text?
- Has anyone a solution for this problem?

Many thanks for your help.

Best regards,

Cath

Dr. Catherine M. Brys
Library Web Services Administrator
- Library Web Site Accessibility and Usability Project -
Glasgow University Library, Hillhead Street, Glasgow, G12 8QE, Scotland, UK
e: c.brys [at] lib.gla.ac.uk
t: +44 (0)141 330 6748
w: www.lib.gla.ac.uk/accessible

From: Catherine Brys
Date: Wed, Feb 23 2005 3:55AM
Subject: Accessible web forms: default text in edit boxes and text areas
← Previous message | Next message →

Hello,

The current Web Content Accessibility guidelines advise to put default text
in edit boxes and text areas. However, I have found that people who don't
use a screen reader tend to skip these fields. My guess is that because they
see a non-empty field, they tend to ignore it, assuming it doesn't need
their .

Using JavaScript to clear the field when you click it is not a solution
because people will not click in the field, they just skip it.

Greying out the default text is also not a perfect solution because visually
impaired people may see there is text there but may be unable to read it.

May question is twofold:
- Does anyone know exactly which problem screen reader users encounter if
you don't use the default text?
- Has anyone a solution for this problem?

Many thanks for your help.

Best regards,

Cath

Dr. Catherine M. Brys
Library Web Services Administrator
- Library Web Site Accessibility and Usability Project -
Glasgow University Library, Hillhead Street, Glasgow, G12 8QE, Scotland, UK
e: c.brys [at] lib.gla.ac.uk
t: +44 (0)141 330 6748
w: www.lib.gla.ac.uk/accessible

From: reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references;
Date: Wed, Feb 23 2005 4:09AM
Subject: Re: Accessible web forms: default text in edit boxes and text areas
← Previous message | Next message →

General consensus seems to be that default text is more of a hindrance.

A properly structured form using label elements should solve all proeblems:

Search

regards
ben

From: reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references;
Date: Wed, Feb 23 2005 4:09AM
Subject: Re: Accessible web forms: default text in edit boxes and text areas
← Previous message | Next message →

General consensus seems to be that default text is more of a hindrance.

A properly structured form using label elements should solve all proeblems:

Search

regards
ben

From: Jukka K. Korpela
Date: Wed, Feb 23 2005 4:13AM
Subject: Re: Accessible web forms: default text in edit boxes and text areas
← Previous message | Next message →

On Wed, 23 Feb 2005, c.brys wrote:

> The current Web Content Accessibility guidelines advise to put default text
> in edit boxes and text areas.

Ignore that. Or, rather, apply almost the opposite: never put any initial
text in an edit box or text areas, unless there are good reasons to expect
that the text would be a sensible default value.

It's simply a mistake in the guidelines. If you ask the W3G WAI group,
you'll get the answer that it's conditional under "until user agents..."
and that the checkpoint has become obsolete because current user agents
can handle initially empty fields well. But in reality it was a bad idea
from the beginning, causing trouble to the great majority (while
admittedly helping some people who used faulty user agents, long ago).

Unfortunately the WCAG guidelines are frozen. There's long process meant
to produce WCAG 2.0. Meanwhile, for years, WCAG 1.0 remain as once
written, and several authorities swear by them, usually without
understading much of them, or about their being out of date, in part.

> However, I have found that people who don't
> use a screen reader tend to skip these fields. My guess is that because they
> see a non-empty field, they tend to ignore it, assuming it doesn't need
> their .

That's one of the original problems. The initial content, if present, is
meant to provide a default value, not filling instructions. The very idea
of a default value is that it is expected to be suitable in many
occasions.

> Using JavaScript to clear the field when you click it is not a solution
> because people will not click in the field, they just skip it.

And because JavaScript might, and often should, be turned off.
And because the JavaScript code will also wipe out user input, if
the user later returns to the field to fix a typo, for example.

> Greying out the default text is also not a perfect solution because visually
> impaired people may see there is text there but may be unable to read it.

It's not a solution at all but creates a new problem: greyed-out text in a
field normally means _disabled_ input field.

--
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/

From: Jukka K. Korpela
Date: Wed, Feb 23 2005 4:13AM
Subject: Re: Accessible web forms: default text in edit boxes and text areas
← Previous message | Next message →

On Wed, 23 Feb 2005, c.brys wrote:

> The current Web Content Accessibility guidelines advise to put default text
> in edit boxes and text areas.

Ignore that. Or, rather, apply almost the opposite: never put any initial
text in an edit box or text areas, unless there are good reasons to expect
that the text would be a sensible default value.

It's simply a mistake in the guidelines. If you ask the W3G WAI group,
you'll get the answer that it's conditional under "until user agents..."
and that the checkpoint has become obsolete because current user agents
can handle initially empty fields well. But in reality it was a bad idea
from the beginning, causing trouble to the great majority (while
admittedly helping some people who used faulty user agents, long ago).

Unfortunately the WCAG guidelines are frozen. There's long process meant
to produce WCAG 2.0. Meanwhile, for years, WCAG 1.0 remain as once
written, and several authorities swear by them, usually without
understading much of them, or about their being out of date, in part.

> However, I have found that people who don't
> use a screen reader tend to skip these fields. My guess is that because they
> see a non-empty field, they tend to ignore it, assuming it doesn't need
> their .

That's one of the original problems. The initial content, if present, is
meant to provide a default value, not filling instructions. The very idea
of a default value is that it is expected to be suitable in many
occasions.

> Using JavaScript to clear the field when you click it is not a solution
> because people will not click in the field, they just skip it.

And because JavaScript might, and often should, be turned off.
And because the JavaScript code will also wipe out user input, if
the user later returns to the field to fix a typo, for example.

> Greying out the default text is also not a perfect solution because visually
> impaired people may see there is text there but may be unable to read it.

It's not a solution at all but creates a new problem: greyed-out text in a
field normally means _disabled_ input field.

--
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/

From: Jim Thatcher
Date: Wed, Feb 23 2005 4:46AM
Subject: Re: Accessible web forms: default text in edit boxes and text areas
← Previous message | Next message →

I agree with Ben, that default text is neither needed nor desirable. But
there is no need to include the input itself in the label element - it
confuses some screen readers (I have forgotten which):

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

Jim

Accessibility Consulting: http://jimthatcher.com/
512-306-0931

From: reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references;
Date: Wed, Feb 23 2005 4:59AM
Subject: Re: Accessible web forms: default text in edit boxes and text areas
← Previous message | Next message →

Ive been wrapping it around the input because I thought it helped IE
use the label as a clickable area. Ill amend that asap.


On Wed, 23 Feb 2005 05:45:45 -0600, jim wrote:
>
> I agree with Ben, that default text is neither needed nor desirable. But
> there is no need to include the input itself in the label element - it
> confuses some screen readers (I have forgotten which):
>
> Search<input type="text" name="search"
> id="search">
>
> Jim
>
> Accessibility Consulting: http://jimthatcher.com/
> 512-306-0931
>
>

From: Jukka K. Korpela
Date: Wed, Feb 23 2005 5:07AM
Subject: Re: Accessible web forms: default text in edit boxes and text areas
← Previous message | Next message →

On Wed, 23 Feb 2005, jim wrote:

> I agree with Ben, that default text is neither needed nor desirable. But
> there is no need to include the input itself in the label element - it
> confuses some screen readers (I have forgotten which):
>
> Search<input type="text" name="search"
> id="search">

On the other hand, for input type="radio" and input type="checkbox",
it is better to put the element inside the element.
This makes the association better known to browsers (including IE) so
that, for example, you can click on the label text to toggle the
radio button or checkbox setting - an important feature to people
with motoric disabilities or a poor mouse, since the radion button
or checkbox is fairly small.

--
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/

From: Jukka K. Korpela
Date: Wed, Feb 23 2005 5:07AM
Subject: Re: Accessible web forms: default text in edit boxes and text areas
← Previous message | Next message →

On Wed, 23 Feb 2005, jim wrote:

> I agree with Ben, that default text is neither needed nor desirable. But
> there is no need to include the input itself in the label element - it
> confuses some screen readers (I have forgotten which):
>
> Search<input type="text" name="search"
> id="search">

On the other hand, for input type="radio" and input type="checkbox",
it is better to put the element inside the element.
This makes the association better known to browsers (including IE) so
that, for example, you can click on the label text to toggle the
radio button or checkbox setting - an important feature to people
with motoric disabilities or a poor mouse, since the radion button
or checkbox is fairly small.

--
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/

From: reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references;
Date: Wed, Feb 23 2005 6:34AM
Subject: Re: Accessible web forms: default text in edit boxes and text areas
← Previous message | Next message →


I thought that having an adjacent label with a for attribute, and a
unique id on the form element, was enough to make the label clickable
and give focus to the form element. The above works in Mozilla-based
browsers.

after v quick testing works in IE6

From: Jim Thatcher
Date: Wed, Feb 23 2005 7:12AM
Subject: Re: Accessible web forms: default text in edit boxes and text areas
← Previous message | Next message →

Opera 7.54, Mozilla 0.9.3 and Netscape 7.2 all have the same behavior for
radio buttons, check boxes and text input WHETHER or NOT the label encloses
the control in addition to the prompting text. Only IE's behavior is strange
- when the label element contains the control, the focus rectangle includes
the control (for radio buttons and checkboxes) and if the label does not
contain the control, the focus rectangle does not include the control.

It is overkill to use both the for attribute and to enclose the control in
the label element. There is no good reason for doing both.

Jim

Accessibility Consulting: http://jimthatcher.com/
512-306-0931

From: Michael Moore
Date: Wed, Feb 23 2005 7:55AM
Subject: Re: Accessible web forms: default text in edit boxes and text areas
← Previous message | Next message →

This is another example of a level 3 guideline that doesn't really work
and one that I believe will be removed. I reiterate that level 3
guidelines are in the category of nice to do, not must or even should
do. Prior to employing techniques in level three, consider how
technology may have changed since the guidelines, whether the
recommendation really benefits any users in the specific instance that
you are considering using it, and whether that benefit is outweighed by
any problems that it may cause. In testing that we have done, we have
found that this practice does not benefit most users because the default
value is seldom what should really be in the field when the form is
submitted.

Mike

c.brys wrote:
> Hello,
>
> The current Web Content Accessibility guidelines advise to put default text
> in edit boxes and text areas. However, I have found that people who don't
> use a screen reader tend to skip these fields. My guess is that because they
> see a non-empty field, they tend to ignore it, assuming it doesn't need
> their .
>
> Using JavaScript to clear the field when you click it is not a solution
> because people will not click in the field, they just skip it.
>
> Greying out the default text is also not a perfect solution because visually
> impaired people may see there is text there but may be unable to read it.
>
> May question is twofold:
> - Does anyone know exactly which problem screen reader users encounter if
> you don't use the default text?
> - Has anyone a solution for this problem?
>
> Many thanks for your help.
>
> Best regards,
>
> Cath
>
> Dr. Catherine M. Brys
> Library Web Services Administrator
> - Library Web Site Accessibility and Usability Project -
> Glasgow University Library, Hillhead Street, Glasgow, G12 8QE, Scotland, UK
> e: c.brys [at] lib.gla.ac.uk
> t: +44 (0)141 330 6748
> w: www.lib.gla.ac.uk/accessible
>
> ----
> To subscribe or unsubscribe, visit http://www.webaim.org/discussion/
>
>
>
>

From: Jukka K. Korpela
Date: Wed, Feb 23 2005 8:40AM
Subject: Re: Accessible web forms: default text in edit boxes and text areas
← Previous message | Next message →

On Wed, 23 Feb 2005, mmoore wrote:

> I reiterate that level 3
> guidelines are in the category of nice to do, not must or even should
> do.

The priority 3 guidelines are part of the WCAG recommendation. The
classification of guidelines into priority levels is somewhat arbitrary
and questionable, but whatever we think about it, such classification does
not mean that part of a recommendation would not be recommended.

The guideline being discussed is simply wrong. Its priority level is not
the issue.

> Prior to employing techniques in level three, consider how
> technology may have changed since the guidelines, whether the
> recommendation really benefits any users in the specific instance that
> you are considering using it, and whether that benefit is outweighed by
> any problems that it may cause.

That's good advice, but it applies to all guidelines, irrespectively of
priority level.

--
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/

From: Mark Magennis
Date: Thu, Feb 24 2005 4:12AM
Subject: Re: Accessible web forms: default text in edit boxes and text areas
← Previous message | Next message →

We have seen default place-holder text cause usability problems many
times in user tests. A typical example is where a site has a Search box
containing text such as "Enter search keywords". Here are some real
queries that different users have entered during two recent user tests,
most of the time without realising it:

"equalityEnter your search keywords"
"EntDisability Biller keywords"
"Enter keywordsDisability Bill"

Mark

Dr. Mark Magennis
Director of the Centre for Inclusive Technology (CFIT)
National Council for the Blind of Ireland
Whitworth Road, Dublin 9, Republic of Ireland

= EMAIL ADDRESS REMOVED = tel: +353 (0)71 914 7464

From: Patrick H. Lauke
Date: Thu, Feb 24 2005 4:37AM
Subject: Re: Accessible web forms: default text in edit boxes and text areas
← Previous message | Next message →

jkorpela wrote:
> On the other hand, for input type="radio" and input type="checkbox",
> it is better to put the element inside the element.
> This makes the association better known to browsers (including IE) so
> that, for example, you can click on the label text to toggle the
> radio button or checkbox setting

maybe I'm missing something, but the behaviour you describe works
exactly the same way even if the input is outside the label, as long as
the input has been given a unique ID and the label's for attribute
points at it correctly.

--
Patrick H. Lauke
_____________________________________________________
re

From: Patrick H. Lauke
Date: Thu, Feb 24 2005 4:46AM
Subject: Re: Accessible web forms: default text in edit boxes and text areas
← Previous message | Next message →

morrison.ben wrote:
> after v quick testing works in IE6

I checked it, and it seems to work in IE6, 5.5, 5 and even 4.
Admittedly, I used the multiple IE trick to get those versions on my
Win2K machine, so the older ones may not behave exactly as the original,
but nonetheless there does *not* seem to be a problem with the "for"
attribute.

So, again...am I missing something here? Do the problems describes by
Jukka appear under IE/Mac, maybe?


--
Patrick H. Lauke
_____________________________________________________
re

From: Jukka K. Korpela
Date: Thu, Feb 24 2005 5:35AM
Subject: Re: Accessible web forms: default text in edit boxes and text areas
← Previous message | No next message

On Thu, 24 Feb 2005, redux wrote:

> I checked it, and it seems to work in IE6, 5.5, 5 and even 4.
> - - there does *not* seem to be a problem with the "for"
> attribute.
>
> So, again...am I missing something here? Do the problems describes by
> Jukka appear under IE/Mac, maybe?

No, I've actually never seen IE on Mac.

It seems that I have messed things up when writing on the basis of what I
remember from my old experiments. You are right, IE supports the "for"
attribute in the sense that it associates the label with the field.

--
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/