WebAIM - Web Accessibility In Mind

E-mail List Archives

RE: Re: Anti-spam email links in Javascript

for

From: John Foliot - WATS.ca
Date: Apr 15, 2004 10:27AM

Mike, et al,

I suspect we are now in a situation where we are dealing with opinion. In
some people's opinion, proving a form-mail page is not sufficiently a
"suitable equivalent" as prescribed by the WCAG, whereas others (myself
included) feels that it is - not perfect, but acceptable.

I once implemented a "form-mail" page for a local city councilor (Ottawa,
Ontario, Canada) who had similar concerns about indiscriminate exposure of
email addresses yet non-the-less wished to leverage the ability of his
constituents to contact his office. (http://dougthompson.ca/contact.html)
The <select> box in the second fieldset ("Are you writing about...?")
actually works with the back-end script to "pre-sort" the emails to the
appropriate staff member in his office. We did provide a "general" email
address as well, but encourage visitors to use the form instead. Is this
"the best" solution? For him (and myself) it is an acceptable, accessible
solution, and there has been no negative feedback since it's implementation,
almost 2 years ago.

The bottom line here is that there are good, better and best answers to this
vexing problem, but the final outcome *must* include something of a
political decision. The "task masters" at your institution should be fully
informed of the different solutions available to them, with the possible
pros and cons of each, and then *they* should make the final decision.

If it is a "legal" opinion you seek, unfortunately one does not exist (that
I am aware of). The WAI - WCAG is a Best Practices document which
unfortunately is all too often looked to as being a "policy" document; the
problem of course is that it is not written in the language of Standards or
Policies and so exposes itself to interpretation.

So: are mail-forms accessible? Generally, yes, provided they are well
constructed (and as I have outlined previously, work with all the Adaptive
Technology that I am aware of). Does providing an alternative (an email
address) make access to the recipient more accessible? Yes, but with it
comes the potential for the types of problems you are seeking to avoid.
Should this be the end users problem? No, but life is about making choices
and that includes this situation; the "harm" of not providing all email
addresses is offset by the harm exposing them causes your organization.
Does providing *only* a mail-form make the ability to contact the entity
inaccessible? I would say no - under certain circumstances and possible
scenarios it may prove more difficult or problematic, but there reaches a
point of balance, and this is what your taskmasters must decide. You
*could* also provide a telephone number, but what if the end user does not
have access to a telephone, is unable to speak due to medical or other
conditions, etc. , etc. , etc. In my opinion, if you have
expressed/demonstrated best effort in your duty/obligation to accommodate,
then for the odd individual who cannot, for whatever reason, use the tools
you have provided what is the answer? And *that* more than anything else is
the nucleus of this discussion - how far is far enough?

Mike, I hope that the discussion has given you enough ammunition to go back
to the decision makers with enough for them to make an informed decision.
You asked in a subsequent email for a vote - I vote option 2 - use the form.

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



>
>
> On Wed, 14 Apr 2004, Mike Brockington wrote:
>
> > To re-iterate; the reality is that I WILL NOT be allowed to expose
> > email addresses without sensible obfuscation.
>
> Didn't you say there were some _requirements_ to make address information
> available? It sounds like your organization is seriously
> self-contradictory. Sorry, I can't help you with that.
>
> > THEREFORE if I am to provide email contacts at all then I NEED to find
> > some other/additional solution.
>
> Then
>
> > The only one that has been proposed so
> > far is to use a form-mail page.
>
> Do you expect that no spam will ever come through such an interface?
>
> >. On the other hand there is significant incentive for
> > 'assistive' browser manufacturers to bring their software in line with
> > 1990's technology levels by supporting Javascript
>
> Why should they take people back to the 1990's? In a World Wide Web where
> JavaScript is so often used to create annoying popups or to spread
> viruses, many people just have to switch it off. Besides, many people have
> no choice, since the company's firewall filters out JavaScript, or the
> company police makes sure browsers have JavaScript off.
>
> > this whole issue is
> > in fact nothing to do with User Disability, and everything to do with
> > Browser disability.
>
> Sorry, but that's simply nonsense.
>
> > Please don't misunderstand my intentions - I fully support the idea of
> > accessible design, but
>
> I've heard such statements before.
>
> In this case, accessible design is _very_ simple.
>
> > Again though, that brings me back to the point that what the WAI says
> > is NOT 'do not use' but 'provide an alternative'.
>
> Well, you can put the simple content - E-mail address - inside
> <noscript>. _That_ would be an alternative. But naturally it would just
> show that the obfuscation is the problem.
>
> > My original question
> > was whether a form-mail page was a 'suitable equivalent'
>
> Of course it's not. It is not an equivalent alternative.
>
> > I should also spell out here that I am talking about a large number of
> > email addresses, not just one or two webmaster addresses, so the
> > potential impact of exposing them all would be significant.
>
> Then implement spam filters in the mail server.
>
> --
> Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/
>
>
> ----
> 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/