WebAIM - Web Accessibility In Mind

E-mail List Archives

Thread: Accessible web forms: default text in edit boxes and text are as

for

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

From: Catherine Brys
Date: Thu, Feb 24 2005 9:13AM
Subject: Re: Accessible web forms: default text in edit boxes and text are as
No previous message | No next message

Thanks, Ben, Jukka, Jim, Tim and Mike, for answering my question on default
text.

I would just like to mention that the WCAG 2.0 are currently being drafted
and that comments are invited. See http://www.w3.org/WAI/ for details.

Using both the for attribute and wrapping the label around the input field
has probably become in use following the example in the WAI Techniques
document: http://www.w3.org/TR/WCAG10-HTML-TECHS/#forms-labels which I think
was confusing indeed.

Thanks again!

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


-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: 23 February 2005 21:34
To: Catherine Brys
Subject: WebAIM Discussion List Digest 23.02.2005.


WebAIM Discussion List Digest 23.02.2005.
------------------------------------------------------------------------
From: = EMAIL ADDRESS REMOVED =
Subject: Prototype Web Accessibility Visualization Tool
Date: Tue, 22 Feb 2005 16:15:15 -0700

A student group at the University of Illinois at
Urbana/Champaign has developed a prototype web accessibility
visualization tool. The purpose of the tool is to generate
graphical views of accessibility problems.

I ask people to try the tool and provide me or the students
feedback on how useful you think the tool is and how we can
make it more useful. There is a comments link on each
page of the analyzer. The students are only going to be
working on the project for a few more months, so please send
comments as soon as possible

Link:
http://devserv.rehab.uiuc.edu/accwebsim/beta/

Look forward to you comments,
Jon


Jon Gunderson, Ph.D., ATP
Director of IT Accessibility Services
Campus Information Technologies and Educational Services (CITES)
and
Coordinator of Assistive Communication and Information Technology
Disability Resources and Education Services (DRES)

Voice: (217) 244-5870
Fax: (217) 333-0248

E-mail: = EMAIL ADDRESS REMOVED =

WWW: http://cita.rehab.uiuc.edu/
WWW: https://netfiles.uiuc.edu/jongund/www/

------------------------------------------------------------------------
From: = EMAIL ADDRESS REMOVED =
Subject: Re: Prototype Web Accessibility Visualization Tool
Date: Tue, 22 Feb 2005 21:31:16 -0700

Just get a bunch of errors on this link:

Warning: pg_connect(): Unable to connect to PostgreSQL server: FATAL:
Non-superuser connection limit exceeded . in
/home/accwebsim/webanalyzer-beta4/functions/session.inc.php on line 5

Warning: pg_query(): supplied argument is not a valid PostgreSQL link
resource in /home/accwebsim/webanalyzer-beta4/functions/session.inc.php on
line 32

Warning: session_start(): Cannot send session cookie - headers already sent
by (output started at
/home/accwebsim/webanalyzer-beta4/functions/session.inc.php:5) in
/home/accwebsim/webanalyzer-beta4/functions/session.inc.php on line 116

Warning: session_start(): Cannot send session cache limiter - headers
already sent (output started at
/home/accwebsim/webanalyzer-beta4/functions/session.inc.php:5) in
/home/accwebsim/webanalyzer-beta4/functions/session.inc.php on line 116


jeb

John E. Brandt
Augusta, Maine USA

= EMAIL ADDRESS REMOVED =
www.jebswebs.com



-----Original Message-----
From: jongund Tool [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Tuesday, February 22, 2005 6:15 PM
To: WebAIM Discussion List
Subject: [WebAIM] Prototype Web Accessibility Visualization Tool


A student group at the University of Illinois at Urbana/Champaign has
developed a prototype web accessibility visualization tool. The purpose of
the tool is to generate graphical views of accessibility problems.

I ask people to try the tool and provide me or the students feedback on how
useful you think the tool is and how we can make it more useful. There is a
comments link on each page of the analyzer. The students are only going to
be working on the project for a few more months, so please send comments as
soon as possible

Link:
http://devserv.rehab.uiuc.edu/accwebsim/beta/

Look forward to you comments,
Jon


Jon Gunderson, Ph.D., ATP
Director of IT Accessibility Services
Campus Information Technologies and Educational Services (CITES) and
Coordinator of Assistive Communication and Information Technology Disability
Resources and Education Services (DRES)

Voice: (217) 244-5870
Fax: (217) 333-0248

E-mail: = EMAIL ADDRESS REMOVED =

WWW: http://cita.rehab.uiuc.edu/
WWW: https://netfiles.uiuc.edu/jongund/www/

----
To subscribe or unsubscribe, visit http://www.webaim.org/discussion/

------------------------------------------------------------------------
From: = EMAIL ADDRESS REMOVED =
Subject: Accessible web forms: default text in edit boxes and text areas
Date: Wed, 23 Feb 2005 03:55:12 -0700

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: = EMAIL ADDRESS REMOVED =
Subject: Re: Accessible web forms: default text in edit boxes and text areas
Date: Wed, 23 Feb 2005 04:09:37 -0700

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<input type="text" name="search"
id="search">

regards
ben

------------------------------------------------------------------------
From: = EMAIL ADDRESS REMOVED =
Subject: Re: Accessible web forms: default text in edit boxes and text areas
Date: Wed, 23 Feb 2005 04:13:31 -0700

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: = EMAIL ADDRESS REMOVED =
Subject: Re: Accessible web forms: default text in edit boxes and text areas
Date: Wed, 23 Feb 2005 04:46:08 -0700

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

-----Original Message-----
From: morrison.ben [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Wednesday, February 23, 2005 5:10 AM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Accessible web forms: default text in edit boxes and
text areas


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<input type="text" name="search"
id="search">

regards
ben

----
To subscribe or unsubscribe, visit http://www.webaim.org/discussion/

------------------------------------------------------------------------
From: = EMAIL ADDRESS REMOVED =
Subject: Re: Accessible web forms: default text in edit boxes and text areas
Date: Wed, 23 Feb 2005 04:59:01 -0700

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
>
> -----Original Message-----
> From: morrison.ben [mailto: = EMAIL ADDRESS REMOVED = ]
> Sent: Wednesday, February 23, 2005 5:10 AM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] Accessible web forms: default text in edit boxes and
> text areas
>
> 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<input type="text" name="search"
> id="search">
>
> regards
> ben
>
> ----
> To subscribe or unsubscribe, visit http://www.webaim.org/discussion/
>
> ----
> To subscribe or unsubscribe, visit http://www.webaim.org/discussion/
>
>

------------------------------------------------------------------------
From: = EMAIL ADDRESS REMOVED =
Subject: Re: Accessible web forms: default text in edit boxes and text areas
Date: Wed, 23 Feb 2005 05:07:18 -0700

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: = EMAIL ADDRESS REMOVED =
Subject: Re: Accessible web forms: default text in edit boxes and text
areas
Date: Wed, 23 Feb 2005 05:55:38 -0700



"jkorpela" < = EMAIL ADDRESS REMOVED = > wrote
on 23/02/2005 12:07:18:

> On the other hand, for input type="radio" and input
type="checkbox",

> it is better to put the <input> element inside the <label>
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.



Does IE ignore the "for" attribute, then?



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.



Regards,



Tim


Institute of Physics
Registered charity No. 293851
76 Portland Place, London, W1B 1NT, England

IOP Publishing Limited
Registered in England under Registration No 467514.
Registered Office: Dirac House, Temple Back, Bristol BS1 6BE England

This e-mail message has been checked for the presence of computer viruses.


------------------------------------------------------------------------
From: = EMAIL ADDRESS REMOVED =
Subject: Re: Accessible web forms: default text in edit boxes and text
areas
Date: Wed, 23 Feb 2005 06:27:09 -0700

On Wed, 23 Feb 2005, tim.beadle wrote:

> Does IE ignore the "for" attribute, then?

More or less, yes.

> 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.

The specifications don't actually mandate any particular behavior; the
"for" attribute specifies just a semantic relationship. The safest way is
to use the "for" attribute _and_ wrap the element inside the
element.

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

------------------------------------------------------------------------
From: = EMAIL ADDRESS REMOVED =
Subject: Re: Accessible web forms: default text in edit boxes and text areas
Date: Wed, 23 Feb 2005 06:34:50 -0700


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: = EMAIL ADDRESS REMOVED =
Subject: Re: Prototype Web Accessibility Visualization Tool
Date: Wed, 23 Feb 2005 06:59:04 -0700

There is a problem with the visualization tool right now.
Please do not try until the students have a chance to fix the
problem. I will let you know when it is available to try again.

Jon


---- Original message ----
>Date: Tue, 22 Feb 2005 17:15:12 -0600
>From: "jongund" Tool
>Subject: [WebAIM] Prototype Web Accessibility Visualization
Tool
>To: "WebAIM Discussion List"
>
>
>A student group at the University of Illinois at
>Urbana/Champaign has developed a prototype web accessibility
>visualization tool. The purpose of the tool is to generate
>graphical views of accessibility problems.
>
>I ask people to try the tool and provide me or the students
>feedback on how useful you think the tool is and how we can
>make it more useful. There is a comments link on each
>page of the analyzer. The students are only going to be
>working on the project for a few more months, so please send
>comments as soon as possible
>
>Link:
>http://devserv.rehab.uiuc.edu/accwebsim/beta/
>
>Look forward to you comments,
>Jon
>
>
>Jon Gunderson, Ph.D., ATP
>Director of IT Accessibility Services
>Campus Information Technologies and Educational Services (CITES)
>and
>Coordinator of Assistive Communication and Information Technology
>Disability Resources and Education Services (DRES)
>
>Voice: (217) 244-5870
>Fax: (217) 333-0248
>
>E-mail: = EMAIL ADDRESS REMOVED =
>
>WWW: http://cita.rehab.uiuc.edu/
>WWW: https://netfiles.uiuc.edu/jongund/www/
>
>----
>To subscribe or unsubscribe, visit
http://www.webaim.org/discussion/
>


Jon Gunderson, Ph.D., ATP
Director of IT Accessibility Services
Campus Information Technologies and Educational Services (CITES)
and
Coordinator of Assistive Communication and Information Technology
Disability Resources and Education Services (DRES)

Voice: (217) 244-5870
Fax: (217) 333-0248

E-mail: = EMAIL ADDRESS REMOVED =

WWW: http://cita.rehab.uiuc.edu/
WWW: https://netfiles.uiuc.edu/jongund/www/

------------------------------------------------------------------------
From: = EMAIL ADDRESS REMOVED =
Subject: Re: Accessible web forms: default text in edit boxes and text areas
Date: Wed, 23 Feb 2005 07:12:49 -0700

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

-----Original Message-----
From: morrison.ben [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Wednesday, February 23, 2005 7:32 AM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Accessible web forms: default text in edit boxes and
text areas



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

----
To subscribe or unsubscribe, visit http://www.webaim.org/discussion/

------------------------------------------------------------------------
From: = EMAIL ADDRESS REMOVED =
Subject: Re: Accessible web forms: default text in edit boxes and text areas
Date: Wed, 23 Feb 2005 07:55:48 -0700

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: = EMAIL ADDRESS REMOVED =
Subject: Re: Accessible web forms: default text in edit boxes and text areas
Date: Wed, 23 Feb 2005 08:40:00 -0700

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: = EMAIL ADDRESS REMOVED =
Subject: speech output tools for scanned documents
Date: Wed, 23 Feb 2005 14:30:53 -0700

Our library is looking into programs that will convert printed documents
into speech output. They are currently looking at OpenBook from Freedom
Scientific, TextBridge Pro 11, and Omnipage Pro 14.

The ability to save the audio files or import the text into Microsoft Office
programs is attractive to the library staff, but budget is limited. I would
like to know of any recommendations and preferences that you could share.

Thank you,
Beth


Beth Call
Academic Technology Coordinator
Center for Teaching, Learning & Technology
300N. Applied Science Bldg.
Murray State University
Murray, KY 42071

= EMAIL ADDRESS REMOVED =
(270) 762-3996 (voice)
(270) 762-3159 (fax)