E-mail List Archives
Thread: Default Text [Was Access Keys]
Number of posts in this thread: 3 (In chronological order)
From: ben morrison
Date: Wed, Aug 17 2005 10:20AM
Subject: Default Text [Was Access Keys]
No previous message | Next message →
On 8/17/05, Glenda Watson Hyatt < = EMAIL ADDRESS REMOVED = > wrote:
> Thanks John! Yes, it was a deliberate decision not to use them. If that
> and not including default text in text boxes makes my site "incompliant", oh
> well! I'd rather it was accessible and usable than compliant.
I have always ignored the default text in input boxes, although i did
come accross this yesterday:
http://www.blackwidows.org.uk/wpress/?p=34
any thoughts?
ben
From: Jukka K. Korpela
Date: Wed, Aug 17 2005 11:40AM
Subject: Re: Default Text [Was Access Keys]
← Previous message | Next message →
On Wed, 17 Aug 2005, ben morrison wrote:
> I have always ignored the default text in input boxes, although i did
> come accross this yesterday:
>
> http://www.blackwidows.org.uk/wpress/?p=34
Use of default text (initial context) for explanations, or for anything
but providing a useful default value, was always a bad idea.
I'm sad to hear that (some) Braille users have problems with empty input
fields. The solution is to fix the software they use, not to break
everyone's form, causing trouble to almost all other users.
Even if we started messing around with misleading default texts, most text
input fields in forms on web pages don't contain that, and won't contain.
So the error in user agents must be fixed anyway.
The proposed method, using a default text of one space, might seem
relatively harmless. But can we know that _all_ defective
software that cannot handle an initially empty input field (a _very_
common ingredient on web pages) can handle one with a space?
Moreover, the initial space is distracting, especially to people who look
carefully and start wondering what's going on, and get suspicious.
What would happen on _good_ nonvisual user agents that, upon focusing on a
text input field, informed the user about the initial value? Surely it
would explicitly mention the space, since it _could_ be relevant to the
user to know about it. After all, who would set up such a default value
without really wanting something special?
--
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/
From: L
Date: Thu, Aug 18 2005 4:00AM
Subject: RE: Default Text [Was Access Keys]
← Previous message | No next message
Ben Morrison wrote:
"I have always ignored the default text in input boxes, although i did come accross this yesterday:
http://www.blackwidows.org.uk/wpress/?p=34
any thoughts?"
The article states:
"More recently, it has come to light that there is one group of users that still rely
heavily upon place holding characters within forms inputs.
Users of Braille readers.
Unless a form text input contains at least one place holding character, Braille readers will not allow focus on that particular input. Which means that, if you do not include place holding characters within your online forms, Braille reader users will not be able to complete them."
Jaws and Window Eyes are not susceptible to this problem, both being capable of identifying empty edit fields on a web page.
I can't say for certain how long this has been a feature of either, but for Jaws it has been in evidence for at least the past 3 or 4 versions.
Jaws produces the Braille symbols for, "ed", to indicate an edit box. It can do this in either grade 1 or 2 Braille, as the user prefers.
Window Eyes behaves similarly, producing the symbols for, "eb" instead.
Both readers supply information on the type, data and name of any given control and both can be configured to adapt that information to the user's preference, for example just giving the type of the control, but not the name.
I don't know how other readers work in this regard, but with the two market leaders working in this way, the case for abandoning place holding characters looks promising. Certainly, a quick straw poll of Jaws and Window Eyes users suggests that place holding characters are not desireable for either speech or Braille output users.
L