E-mail List Archives
Thread: e-mail addresses and proper forms labelling of their constituent parts
Number of posts in this thread: 3 (In chronological order)
From: Lori K. Brown
Date: Mon, Sep 15 2003 1:17PM
Subject: e-mail addresses and proper forms labelling of their constituent parts
No previous message | Next message →
Dear list:
I am reviewing a form for my company's product. In it, we have a form
that asks for an e-mail address. In this instance, the e-mail address is
not for a particular person, but is for setting up a pop client that
posts messages received by that account into a web-based piece of software.
Right now, the form requests the pop client address in two different
fields, with an @ sign in between them. This is our way of doing a
little brute force data validation, as we then concatenate the two
fields w/ the @ sign in between to build the e-mail address.
I have several usability / accessibility questions about this problem,
and this technique.
1) This is another one of those annoying cases where one data element --
an e-mail address -- is built from two form elements (and the @ in
between). Is there a proper way to label this so as not to be confusing
for screen reader users? In particular, are there specific names for the
front part of an e-mail address and the back part that are widely and
correctly understood?
2) Would an example, like ' = EMAIL ADDRESS REMOVED = ', be helpful?
3) Is there a best-practice solution to this problem? In particular, is
it preferred to just let users type their own complete addresses without
engaging in this kind of parsing operation?
Thanks in advance for any assistance.
Lori K. Brown
----
To subscribe, unsubscribe, suspend, or view list archives,
visit http://www.webaim.org/discussion/
From: Mary Utt
Date: Mon, Sep 15 2003 1:33PM
Subject: RE: e-mail addresses and proper forms labelling of their constituent parts
← Previous message | Next message →
Lori,
They are just going to say, "use one text field and error-check."
The problem in our case is that we have several long-standing
(as in before-my-time) admin forms that use the [ ]@[ ] format.
So I opted to go with that flow rather than retrofit existing
(non-templated) forms. Pros: consistency, self-documenting, less
error prone. Cons: 2 fields rather than 1, accessibility may be
a problem. To which I can argue, 1) admins are used to hard lives and
don't have to do this very often and 2) we never committed to making
the admin forms accessible.
So those were my reasons for doing that form that way.
Mary
>
From: Jukka K. Korpela
Date: Mon, Sep 15 2003 2:08PM
Subject: Re: e-mail addresses and proper forms labelling of their constituent parts
← Previous message | No next message
On Mon, 15 Sep 2003, Lori K. Brown wrote:
> Right now, the form requests the pop client address in two different
> fields, with an @ sign in between them.
There are many pros and cons here. Such a scheme may help people to enter
correct information, and in some cases it helps them to avoid the problem
"how do I type '@'?" (which can be a real problem at times, depending on
keyboard etc.).
But I think the cons weigh more. People are _used_ to typing their E-mail
address. This is the most important point here. Anything that deviates
from the normal practice causes problems to some people, and raises
suspicions.
> 2) Would an example, like ' = EMAIL ADDRESS REMOVED = ', be helpful?
Questionable. People might even take it as a real example. (Do you _know_
whether that particular address actually exists?) I think it is best to
specify in plain English that an E-mail address is to be provided, and
leave it at that. People who need help with the concept should try and
find some local help. You cannot possibly tell what they might need.
People who are not experienced with computers often have problems in
knowing which E-mail address to use and what their E-mail address is
really is. (For example, after changing ISP, people can get really
confused with all kinds of addresses and user ids and passwords.)
Any extra complexity in prompting for an E-mail address will probably
just add to the confusion.
--
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/
----
To subscribe, unsubscribe, suspend, or view list archives,
visit http://www.webaim.org/discussion/