WebAIM - Web Accessibility In Mind

E-mail List Archives

Thread: Anti-spam email links in Javascript

for

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

From: Mike Brockington
Date: Thu, Apr 08 2004 9:36AM
Subject: Anti-spam email links in Javascript
No previous message | Next message →

I have been asked to produce a public-facing page containing email links. The user wants to avoid spam, but also wants to have AAA accessibility, which appears to be mutually exclusive. The page is produced by JSP, so I can write whatever HTML / Javascript I like, but I can't see how to get around the problem that a browser which does not have Javascript enabled will not be able to display the email address.
Is it acceptable to use a <no-script> tag to say something like: "email address obscured due to spam" ?
This would seem to me to go against the general principle of providing alternate versions of non-accessible content.
The only other option that I have been able to think of is to have the <noscript> section provide a link to a form-mail page. Do you think that this counts as 'equivalent' to a mailto: link?

Mike




Check planning applications from your office or home
www.edinburgh.gov.uk/planning
Pay for on-street parking in central Edinburgh from your mobile phone
www.edinburgh.gov.uk/mpark
More at www.edinburgh.gov.uk/onlineservices
**********************************************************************
This Email and files transmitted with it are confidential and are intended for the sole use of the individual or organisation to whom they are addressed. If you have received this Email in error please notify the sender immediately and delete it without using, copying, storing, forwarding or disclosing its contents to any other person. The Council has endeavoured to scan this Email message and attachments for computer viruses and will not be liable for any losses incurred by the recipient.
**********************************************************************


----
To subscribe, unsubscribe, suspend, or view list archives,
visit http://www.webaim.org/discussion/

From: Jukka K. Korpela
Date: Thu, Apr 08 2004 11:37AM
Subject: Re: Anti-spam email links in Javascript
← Previous message | Next message →

On Thu, 8 Apr 2004, Mike Brockington wrote:

> I have been asked to produce a public-facing page containing email
> links.

Fine.

> The user wants to avoid spam, but also wants to have AAA
> accessibility, which appears to be mutually exclusive.

There's no way to avoid spam except staying out of the Internet.

You get spam no matter what you do, sooner or later. Some day this might
be fixed by effective legal actions, but now it's a fact of life.
Just don't make life any harder for that reason to people who already have
their own difficulties.

That is, deal with spam with whatever means you choose, typically spam
filters. Don't make your spam problem your visitors' problem.

> I can't see how to get around the problem that a browser which does not
> have Javascript enabled will not be able to display the email address.

That's _part_ of the problem _you_ would cause.

> Is it acceptable to use a <no-script> tag to say something like:
> "email address obscured due to spam" ?

I lack words to describe how foolish that would be. In any case, it surely
would not comply with accessibility guidelines.

> This would seem to me to go against the general principle of providing
> alternate versions of non-accessible content.

The first principle is to make content accessible - please remember that.
In this case, you would _deliberately_ make accessible content (an E-mail
address) inaccessible.

> The only other option that I have been able to think of is to have the
> <noscript> section provide a link to a form-mail page. Do you think that
> this counts as 'equivalent' to a mailto: link?

It's not a matter of subjective evaluations. It simply isn't. It could be
an improvement to have a form as an _alternative_, but _replacing_ an
email address with a form would reduce accessibility, no matter how good
the form is (most forms on the Web are awful, with their stamp-side
textareas and with their reset buttons). Think about a user who knows how
to use an E-mail program but cannot use a form interface, since only his
E-mail program contains the assistive technology he needs.

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


----
To subscribe, unsubscribe, suspend, or view list archives,
visit http://www.webaim.org/discussion/


From: Mike Stenhouse
Date: Thu, Apr 08 2004 12:13PM
Subject: RE: Anti-spam email links in Javascript
← Previous message | Next message →

Hi Mike

<snip>
The page is produced by JSP, so I can write whatever HTML / Javascript I
like, but I can't see how to get around the problem that a browser which
does not have Javascript enabled will not be able to display the email
address. Is it acceptable to use a <no-script> tag to say something
like: "email address obscured due to spam" ?
</snip>

I think you can do this without resorting to javascript. Check out
entity encoding at
http://www.robertgraham.com/tools/mailtoencoder.html... I'm not exactly
sure where this stands with all the browsers but it might be worth a
little research before risking a <noscript>.

Cheers

Mike
Web developer/designer
www.donotremove.co.uk



----
To subscribe, unsubscribe, suspend, or view list archives,
visit http://www.webaim.org/discussion/


From: John Foliot - WATS.ca
Date: Fri, Apr 09 2004 10:17AM
Subject: RE: Anti-spam email links in Javascript
← Previous message | Next message →

> It's not a matter of subjective evaluations. It simply isn't. It could be
> an improvement to have a form as an _alternative_, but _replacing_ an
> email address with a form would reduce accessibility, no matter how good
> the form is (most forms on the Web are awful, with their stamp-side
> textareas and with their reset buttons). Think about a user who knows how
> to use an E-mail program but cannot use a form interface, since only his
> E-mail program contains the assistive technology he needs.
>

I beg your pardon? You're saying that a form is *less* accessible than an
email address? How can that be?

As pointed out (within this thread), users who may be accessing your content
through a public terminal, or who's user agent does not have (or support) an
email client, cannot contact the site owners through a simple mailto: link.

A properly developed form, on the other hand, is just more HTML, and users
of AT who can access your page content should be able to access your form as
well. Now, it's true that many (most?) developers don't know how to do
forms correctly - no argument there - but to suggest that an email link is
more accessible than a form, is, IMHO false. Jukka, I'll meet you half way
(they are equal), but cannot accept your statement as written.

Advantages to forms:
- properly done, can be navigated through quickly, even more so when coded
with the < fieldset> and < legend> attributes. These attributes also group
similar or like informational concepts, in accordance with WAI Priority 2 -
12.3 "Divide large blocks of information into more manageable groups where
natural and appropriate."

- *most* form scripts also allow for immediate feedback to the sender; a
"Thank you we have received your note" type response page. This type of
positive re-enforcement aids those with cognitive disabilities (it confirms
to them that they were successful), as well as enhances general usability
(because just about everyone wants to know they have been successful when
submitting requests, information, etc.) Developers can even echo back
tracking numbers, etc., again aiding in usability, as well as enhancing
client confidence.

- all functionality is server side as opposed to client side - this topic
could encompass a whole other discussion, but consider: WAI Priority 1 - 6.3
"Ensure that pages are usable when scripts, applets, or other programmatic
objects are turned off or not supported. If this is not possible, provide
equivalent information on an alternative accessible page." One *could*
stretch the interpretation of "programatic object" to encompass an email
client - a stretch for sure, but not unfeasible. If you do not have access
to an email client, you cannot contact the web site - period.

- as noted within this thread, using forms reduces the need to publicly
post an email address, thus reducing spam (which *HAS* to be a good
thing!!!)

- using a form helps the submitter to succinctly deliver their message, as
you are "helping them" by asking the leading questions. What is your name?
what is your email address? what is your comment? does it pertain to any of
the pre-determined topics? (this also helps site admins who generally
receive this type of information, as the subject line can be pre-determined,
allowing the recipients to filter and sort their correspondence from the
site)

- having a feedback form on an HTML document also allows developers to
directly link to any privacy policy the site owners may adhere to (whereas a
simple email has no assurances of any privacy protection). In this day and
age, with digital privacy becoming more and more important, this too is an
advantage (although outside the realm of accessibility).

Just my $0.02 (or roughly $0.03 Canadian)

JF
--
John Foliot = EMAIL ADDRESS REMOVED =
Web Accessibility Specialist / Co-founder of WATS.ca
Web Accessibility Testing and Services
http://www.wats.ca 1.866.932.4878 (North America)



----
To subscribe, unsubscribe, suspend, or view list archives,
visit http://www.webaim.org/discussion/

From: Jukka K. Korpela
Date: Fri, Apr 09 2004 11:43AM
Subject: RE: Anti-spam email links in Javascript
← Previous message | Next message →

On Fri, 9 Apr 2004, John Foliot - WATS.ca wrote:

> I beg your pardon? You're saying that a form is *less* accessible than an
> email address? How can that be?

People usually know how to use E-mail. Forms are more difficult. Besides,
there assistive technologies for E-mail, whereas forms have primitive
implementations in browsers. Did you ever see browser that has a
spelling checker for the text you type into a form?

> As pointed out (within this thread), users who may be accessing your content
> through a public terminal, or who's user agent does not have (or support) an
> email client, cannot contact the site owners through a simple mailto: link.

Surely. That's why I mentioned a form as an _enhancement_. But if you
_replace_ an E-mail address by a form - which is what this was about -
you certainly reduce accessibility.

> A properly developed form, on the other hand, is just more HTML,

No, it's also a browser's implementation of forms, which is generally
poor.

> Now, it's true that many (most?) developers don't know how to do
> forms correctly

Quite right. This is important to practical accessibility. And people who
know how to write forms properly don't use them as the only means of
contact.

> no argument there - but to suggest that an email link is
> more accessible than a form, is, IMHO false. Jukka, I'll meet you half way
> (they are equal), but cannot accept your statement as written.

Of course they aren't equal. Surely one's favorite E-mail program is
easier to use than a typical browser's implementation of a typical form.

> Advantages to forms:
> - properly done, can be navigated through quickly, even more so when coded
> with the < fieldset> and < legend> attributes.

Irrelevant. We're discussing the issue of sending simple feedback.

> - *most* form scripts also allow for immediate feedback to the sender; a
> "Thank you we have received your note" type response page.

Worse than useless. It isn't even true. The feedback just says that the
script sent the data. There is no guarantee that it will actually be
delivered, still less that it will be received and read.

> This type of
> positive re-enforcement aids those with cognitive disabilities

Are you serious? It's typical pseudo-feedback. Any decent E-mail program
gives better feedback about sending E-mail.

> - all functionality is server side as opposed to client side

Again, regarding feedback forms, they just add a _new_ component, which
could be dysfunct at times.

> - as noted within this thread, using forms reduces the need to publicly
> post an email address, thus reducing spam (which *HAS* to be a good
> thing!!!)

What has the page author's assumed comfort got to do with accessibility?
I thought I already explained why it is seriously wrong to make your spam
problem your visitors' problem.

I repeat: What about people who can use an E-mail program because it has
suitable assistive technology but simply cannot use a form? You would
create an absolute barrier by simply refusing to tell your contact
address. This is foolish enough, but calling it accessibility is
grotesquely absurd.

> - using a form helps the submitter to succinctly deliver their message, as
> you are "helping them" by asking the leading questions. What is your name?
> what is your email address? what is your comment?

Oh really. When an E-mail program is used, it automatically inserts the
name and the address, once configured.

> - having a feedback form on an HTML document also allows developers to
> directly link to any privacy policy the site owners may adhere to (whereas a
> simple email has no assurances of any privacy protection).

What? Do you mean that a page containing an E-mail address cannot contain
another link, or a direct statement of a privacy policy?

(And I reallt fail to see how this relates to accessibility. The real
accessibility problem with such policies is that they are pointless
administativese, which is virtually incomprehensible to most people.)

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


----
To subscribe, unsubscribe, suspend, or view list archives,
visit http://www.webaim.org/discussion/

From: Karl Groves
Date: Sat, Apr 10 2004 5:33PM
Subject: RE: Anti-spam email links in Javascript
← Previous message | Next message →

http://webaim.org/discussion/#unsub



Karl L. Groves

-----Original Message-----
From: Smith-White, Shermainne [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Saturday, April 10, 2004 6:16 PM
To: = EMAIL ADDRESS REMOVED =
Subject: RE: Anti-spam email links in Javascript



Please unsubcribe my e-mail, = EMAIL ADDRESS REMOVED =



-----Original Message-----
From: John Foliot - WATS.ca [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Fri 4/9/2004 11:04 AM
To: = EMAIL ADDRESS REMOVED =
Cc:
Subject: RE: Anti-spam email links in Javascript

> It's not a matter of subjective evaluations. It simply isn't. It could
be
> an improvement to have a form as an _alternative_, but _replacing_ an
> email address with a form would reduce accessibility, no matter how
good
> the form is (most forms on the Web are awful, with their stamp-side
> textareas and with their reset buttons). Think about a user who knows
how
> to use an E-mail program but cannot use a form interface, since only
his
> E-mail program contains the assistive technology he needs.
>

I beg your pardon? You're saying that a form is *less* accessible than
an
email address? How can that be?

As pointed out (within this thread), users who may be accessing your
content
through a public terminal, or who's user agent does not have (or
support) an
email client, cannot contact the site owners through a simple mailto:
link.

A properly developed form, on the other hand, is just more HTML, and
users
of AT who can access your page content should be able to access your
form as
well. Now, it's true that many (most?) developers don't know how to do
forms correctly - no argument there - but to suggest that an email link
is
more accessible than a form, is, IMHO false. Jukka, I'll meet you half
way
(they are equal), but cannot accept your statement as written.

Advantages to forms:
- properly done, can be navigated through quickly, even more so
when coded
with the < fieldset> and < legend> attributes. These attributes also
group
similar or like informational concepts, in accordance with WAI Priority
2 -
12.3 "Divide large blocks of information into more manageable groups
where
natural and appropriate."

- *most* form scripts also allow for immediate feedback to the
sender; a
"Thank you we have received your note" type response page. This type of
positive re-enforcement aids those with cognitive disabilities (it
confirms
to them that they were successful), as well as enhances general
usability
(because just about everyone wants to know they have been successful
when
submitting requests, information, etc.) Developers can even echo back
tracking numbers, etc., again aiding in usability, as well as enhancing
client confidence.

- all functionality is server side as opposed to client side -
this topic
could encompass a whole other discussion, but consider: WAI Priority 1 -
6.3
"Ensure that pages are usable when scripts, applets, or other
programmatic
objects are turned off or not supported. If this is not possible,
provide
equivalent information on an alternative accessible page." One *could*
stretch the interpretation of "programatic object" to encompass an email
client - a stretch for sure, but not unfeasible. If you do not have
access
to an email client, you cannot contact the web site - period.

- as noted within this thread, using forms reduces the need to
publicly
post an email address, thus reducing spam (which *HAS* to be a good
thing!!!)

- using a form helps the submitter to succinctly deliver their
message, as
you are "helping them" by asking the leading questions. What is your
name?
what is your email address? what is your comment? does it pertain to
any of
the pre-determined topics? (this also helps site admins who generally
receive this type of information, as the subject line can be
pre-determined,
allowing the recipients to filter and sort their correspondence from the
site)

- having a feedback form on an HTML document also allows
developers to
directly link to any privacy policy the site owners may adhere to
(whereas a
simple email has no assurances of any privacy protection). In this day
and
age, with digital privacy becoming more and more important, this too is
an
advantage (although outside the realm of accessibility).

Just my $0.02 (or roughly $0.03 Canadian)

JF
--
John Foliot = EMAIL ADDRESS REMOVED =
Web Accessibility Specialist / Co-founder of WATS.ca
Web Accessibility Testing and Services
http:/

From: Mike Brockington
Date: Thu, Apr 15 2004 9:09AM
Subject: RE: Anti-spam email links in Javascript
← Previous message | Next message →

Folks,
Hopefully this is all the relevant parts of the spec:
My company provides IT support etc. to The City of Edinburgh Council.
We are currently re-developing the 'A - Z of Council Services' database. Essentially this a content-management system, written in JSP, with a SQL backend.
Many of the records contain contact information for that specific service, such as phone numbers, fax, minicom and in this new version, email addresses, for members of the public to get in contact.
The Council has spam filters applied to its email servers, however experience shows that these will always block a small proportion of genuine messages, and also allow through some undesirable messages. From intimate knowledge I can assure you that both of these situations are inevitable until such time as legislation becomes effective.
For some of our users it is unacceptable to miss a legitimate email from the public, and therefore, despite the drawbacks, have unfiltered email. Regardless of this, the shear wieght of spam currently poses a significant problem for us.
Therefore, my client WILL NOT allow me to expose email addresses directly. We both understand that there is a risk that the obfuscation may be compromised.
I am currently waiting for my client to make a decision, but the choices seem to be:
1. Mailto: link, obfuscated with Javascript.
2. Form-based page, where the link uses an ID reference to my database.
3. Both, with option 2 within a <noscript> tag
4. Both, side-by-side
5. No email contact.

Can we please try and cut out the rhetoric and possibly give a vote/score on the above? (I am fairly confident that if there were any other alternatives I would know of them by know - but feel free to correct me.)

Mike



Check planning applications from your office or home
www.edinburgh.gov.uk/planning
Pay for on-street parking in central Edinburgh from your mobile phone
www.edinburgh.gov.uk/mpark
More at www.edinburgh.gov.uk/onlineservices
**********************************************************************
This Email and files transmitted with it are confidential and are intended for the sole use of the individual or organisation to whom they are addressed. If you have received this Email in error please notify the sender immediately and delete it without using, copying, storing, forwarding or disclosing its contents to any other person. The Council has endeavoured to scan this Email message and attachments for computer viruses and will not be liable for any losses incurred by the recipient.
**********************************************************************


----
To subscribe, unsubscribe, suspend, or view list archives,
visit http://www.webaim.org/discussion/


From: julian.rickards@ndm.gov.on.ca
Date: Thu, Apr 15 2004 9:26AM
Subject: RE: Anti-spam email links in Javascript
← Previous message | Next message →

Mike:

I suspect that from your intro that option 5 would not be an option for your
client whatever we have to say so you can strike that from the option list.

1, 3 and 4 depend on obfuscation which I would vote against. JS obfuscation
may create accessibility issues. Secondly, if a person were to try to
copy/paste an obfuscated email address into either a web-based email form
(such as Hotmail), would the email address remain obfuscated or would it be
converted? I don't know but someone else might.

I like 2 because (assuming a properly coded form) it can provide
accessibility and it hides the email in the backend. However, the advantage
of an email link is that the user has the option of saving their sent
message whereas a form may not. If you haven't considered it, you might want
to include an option (or a requirement) to insert the sender's email so that
they can have a copy of the message they sent and the address of the person
they contacted so that they may then email directly should their message
require a response.

My vote: 2 with a CC option/requirement.

---------------------------------------------------------
Julian Rickards
Digital Publications Distribution Coordinator
Publications Services Section
Ontario Ministry of Northern Development and Mines
Phone: (705) 670-5608
Fax: (705) 670-5690


> -----Original Message-----
> From: Mike Brockington [mailto: = EMAIL ADDRESS REMOVED = ]

> I am currently waiting for my client to make a decision, but
> the choices seem to be:
> 1. Mailto: link, obfuscated with Javascript.
> 2. Form-based page, where the link uses an ID reference to my
> database.
> 3. Both, with option 2 within a <noscript> tag
> 4. Both, side-by-side
> 5. No email contact.
>
> Can we please try and cut out the rhetoric and possibly give
> a vote/score on the above? (I am fairly confident that if
> there were any other alternatives I would know of them by
> know - but feel free to correct me.)


----
To subscribe, unsubscribe, suspend, or view list archives,
visit http://www.webaim.org/discussion/


From: John Hamman
Date: Thu, Apr 15 2004 9:39AM
Subject: RE: Anti-spam email links in Javascript
← Previous message | Next message →

Has anyone considered programming a cloak for this? And just block email
catchers from the site?
john

-----Original Message-----
From: Mike Brockington [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Thursday, April 15, 2004 10:59 AM
To: = EMAIL ADDRESS REMOVED =
Subject: RE: Anti-spam email links in Javascript

Folks,
Hopefully this is all the relevant parts of the spec:
My company provides IT support etc. to The City of Edinburgh Council.
We are currently re-developing the 'A - Z of Council Services' database.
Essentially this a content-management system, written in JSP, with a SQL
backend.
Many of the records contain contact information for that specific service,
such as phone numbers, fax, minicom and in this new version, email
addresses, for members of the public to get in contact.
The Council has spam filters applied to its email servers, however
experience shows that these will always block a small proportion of genuine
messages, and also allow through some undesirable messages. From intimate
knowledge I can assure you that both of these situations are inevitable
until such time as legislation becomes effective.
For some of our users it is unacceptable to miss a legitimate email from the
public, and therefore, despite the drawbacks, have unfiltered email.
Regardless of this, the shear wieght of spam currently poses a significant
problem for us.
Therefore, my client WILL NOT allow me to expose email addresses directly.
We both understand that there is a risk that the obfuscation may be
compromised.
I am currently waiting for my client to make a decision, but the choices
seem to be:
1. Mailto: link, obfuscated with Javascript.
2. Form-based page, where the link uses an ID reference to my database.
3. Both, with option 2 within a <noscript> tag
4. Both, side-by-side
5. No email contact.

Can we please try and cut out the rhetoric and possibly give a vote/score on
the above? (I am fairly confident that if there were any other alternatives
I would know of them by know - but feel free to correct me.)

Mike



Check planning applications from your office or home
www.edinburgh.gov.uk/planning
Pay for on-street parking in central Edinburgh from your mobile phone
www.edinburgh.gov.uk/mpark
More at www.edinburgh.gov.uk/onlineservices
**********************************************************************
This Email and files transmitted with it are confidential and are intended
for the sole use of the individual or organisation to whom they are
addressed. If you have received this Email in error please notify the sender
immediately and delete it without using, copying, storing, forwarding or
disclosing its contents to any other person. The Council has endeavoured to
scan this Email message and attachments for computer viruses and will not be
liable for any losses incurred by the recipient.
**********************************************************************


----
To subscribe, unsubscribe, suspend, or view list archives,
visit http://www.webaim.org/discussion/



----
To subscribe, unsubscribe, suspend, or view list archives,
visit http://www.webaim.org/discussion/

From: Michael R. Burks
Date: Thu, Apr 15 2004 11:02AM
Subject: RE: Anti-spam email links in Javascript
← Previous message | Next message →

All,

One would hope these proposed solutions would accessible to people with
disabilties.

Sincerely,

Mike Burks

-----Original Message-----
From: Mike Brockington [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Thursday, April 15, 2004 10:59 AM
To: = EMAIL ADDRESS REMOVED =
Subject: RE: Anti-spam email links in Javascript


Folks,
Hopefully this is all the relevant parts of the spec:
My company provides IT support etc. to The City of Edinburgh Council. We are
currently re-developing the 'A - Z of Council Services' database.
Essentially this a content-management system, written in JSP, with a SQL
backend. Many of the records contain contact information for that specific
service, such as phone numbers, fax, minicom and in this new version, email
addresses, for members of the public to get in contact. The Council has spam
filters applied to its email servers, however experience shows that these
will always block a small proportion of genuine messages, and also allow
through some undesirable messages. From intimate knowledge I can assure you
that both of these situations are inevitable until such time as legislation
becomes effective. For some of our users it is unacceptable to miss a
legitimate email from the public, and therefore, despite the drawbacks, have
unfiltered email. Regardless of this, the shear wieght of spam currently
poses a significant problem for us. Therefore, my client WILL NOT allow me
to expose email addresses directly. We both understand that there is a risk
that the obfuscation may be compromised. I am currently waiting for my
client to make a decision, but the choices seem to be: 1. Mailto: link,
obfuscated with Javascript. 2. Form-based page, where the link uses an ID
reference to my database. 3. Both, with option 2 within a <noscript> tag 4.
Both, side-by-side 5. No email contact.

Can we please try and cut out the rhetoric and possibly give a vote/score on
the above? (I am fairly confident that if there were any other alternatives
I would know of them by know - but feel free to correct me.)

Mike



Check planning applications from your office or home
www.edinburgh.gov.uk/planning
Pay for on-street parking in central Edinburgh from your mobile phone
www.edinburgh.gov.uk/mpark
More at www.edinburgh.gov.uk/onlineservices
**********************************************************************
This Email and files transmitted with it are confidential and are intended
for the sole use of the individual or organisation to whom they are
addressed. If you have received this Email in error please notify the sender
immediately and delete it without using, copying, storing, forwarding or
disclosing its contents to any other person. The Council has endeavoured to
scan this Email message and attachments for computer viruses and will not be
liable for any losses incurred by the recipient.
**********************************************************************


----
To subscribe, unsubscribe, suspend, or view list archives,
visit http://www.webaim.org/discussion/



----
To subscribe, unsubscribe, suspend, or view list archives,
visit http://www.webaim.org/discussion/

From: Paul Norman
Date: Thu, Apr 15 2004 3:46PM
Subject: Re: Anti-spam email links in Javascript
← Previous message | Next message →


On 9-Apr-04, at 10:29 AM, Jukka K. Korpela wrote:

> On Fri, 9 Apr 2004, John Foliot - WATS.ca wrote:
>
>> I beg your pardon? You're saying that a form is *less* accessible
>> than an
>> email address? How can that be?
>
> People usually know how to use E-mail. Forms are more difficult.
> Besides,
> there assistive technologies for E-mail, whereas forms have primitive
> implementations in browsers. Did you ever see browser that has a
> spelling checker for the text you type into a form?

I use Safari, and have spell checking on all text areas and most other
form elements.


----
To subscribe, unsubscribe, suspend, or view list archives,
visit http://www.webaim.org/discussion/


From: Terence de Giere
Date: Fri, Apr 16 2004 9:47AM
Subject: RE: Anti-spam email links in Javascript
← Previous message | Next message →

Besides obfusticating an email address in various ways, some of which
are not accessible, there are other ways of handling spam, although a
slight inconvenience or an annoyance for those wanting to contact you
may be a side-effect the first time they try to contact you.

There are applications like Zaep that check for valid e-mail addresses
before accepting an e-mail; if it is valid, it sends out an e-mail
message (which you can customize) with a software key to the person
contacting you for confirmation that they actually sent you a message
from that address. If they reply the system then lets email from that
particular address through from that time on. Ranges of IP addresses can
also be specified as safe for receipt of e-mail. Messages blocked are
archived and sorted until deleted and statistics generated.

There is the cost of licensing software, which can be done on a
CPU-by-CPU basis. And the main drawback is some users are annoyed when
receiving an e-mail message that tells them their e-mail will only be
delivered to you if they respond to the verification e-mail, which
typically involves visiting a site from a passkey link in the e-mail.
Once they visit the site, they see a web page confirming that their
email will then be allowed from then on. It would appear that this
particular system involves the software vendor's server to display the
confirmation message page and send the passkey to the anti-spam
application on your computer to unblock that e-mail address.

As with any system there could be unanticipated problems, or problems
with the users network which does not allow visiting the confirmation
web page.

If JavaScript is used to obfusticate e-mail addresses, somewhere from 5
percent to 10 percent of users will not be able to communicate with you,
as they do not have it, or have it turned off.

Terence de Giere
= EMAIL ADDRESS REMOVED =



----
To subscribe, unsubscribe, suspend, or view list archives,
visit http://www.webaim.org/discussion/


From: Cheryl D. Wise
Date: Fri, Apr 16 2004 1:20PM
Subject: RE: Anti-spam email links in Javascript
← Previous message | No next message

I suspect that those using verification required autoresponders sending
codes may in turn either be blocked by other people's spam filters or that
the recipients will not respond with the appropriate confirmation.

I tend to be in the latter group. I get requests for "verification" and
usually can them. I simply don't trust them. Too many reports that some of
the verification systems (especially free ones) have sold the "verified"
email addresses. Many businesses also limit internet access for their
employees, allowing only "approved" sites, frequently cached versions. Which
would eliminate their ability to be verified. I know a couple of
corporations that to that.

Personally I prefer either a form which has the added benefit that those
using a public computer and online email as opposed to pop/imap mail can
still easily send a response or a plain unadorned email address that can be
run through spam filters. Yes, no matter what you do you risk missing some
people which is why a telephone number and/or snail mail address is still
important.


Cheryl D. Wise
Certified Professional Web Developer
MS-MVP-FrontPage
www.wiserways.com
mailto: = EMAIL ADDRESS REMOVED =
713.353.0139 Office

-----Original Message-----
From: Terence de Giere

Besides obfusticating an email address in various ways, some of which are
not accessible, there are other ways of handling spam, although a slight
inconvenience or an annoyance for those wanting to contact you may be a
side-effect the first time they try to contact you.

There are applications like Zaep that check for valid e-mail addresses
before accepting an e-mail; if it is valid, it sends out an e-mail message
(which you can customize) with a software key to the person contacting you
for confirmation that they actually sent you a message from that address.

<snipped>

And the main drawback is some users are annoyed when receiving an e-mail
message that tells them their e-mail will only be delivered to you if they
respond to the verification e-mail, which typically involves visiting a site
from a passkey link in the e-mail.
Once they visit the site, they see a web page confirming that their email
will then be allowed from then on. It would appear that this particular
system involves the software vendor's server to display the confirmation
message page and send the passkey to the anti-spam application on your
computer to unblock that e-mail address.


----
To subscribe, unsubscribe, suspend, or view list archives,
visit http://www.webaim.org/discussion/