homepage Welcome to WebmasterWorld Guest from 54.197.215.146
register, free tools, login, search, subscribe, help, library, announcements, recent posts, open posts,
Subscribe to WebmasterWorld
Visit PubCon.com
Home / Forums Index / WebmasterWorld / Accessibility and Usability
Forum Library, Charter, Moderators: ergophobe

Accessibility and Usability Forum

    
Compliant, accessible, spam-free forms
How do you do it?
encyclo




msg:3087518
 4:06 pm on Sep 18, 2006 (gmt 0)

Some of the discussion in the recent Target accessibility lawsuit thread [webmasterworld.com] has mentioned the difficulty of having a form which complies with W3C validation and accessibility standards, but also manages to reduce or eliminate spam.

Rather than starting by proposing solutions, I'l start with some questions:

- How are you currently handling forms?
- How does your method impact accessibility?
- Where do you draw the line between accessibility, functionality and spam-protection?

I'll post back later with some ideas. :)

 

KenB




msg:3087641
 5:31 pm on Sep 18, 2006 (gmt 0)

I standardly handle form fields in the following fashion:

<label for="field1" id="idField1"><strong>Your Email Address (required):</strong>
<input name="field1" id="field1" size="40" class="Border"></label>

When necessary I move the INPUT tag out side of the LABEL tag as the FOR attribute in the LABEL tag ties the label to the associated INPUT tag. The LABEL tag is very important for accessibility as it associates the description of a field with the field.

To combat form spam I use strings with no meaning in the NAME attribute and ID attribute rather than using logical/descriptive names. For instance, in the example above I used "field1" for the NAME and ID attributes rather than using "email" as would be typically used. These two attributes ARE NOT supposed to displayed to users under any circumstances so the naming convention used for these attributes is really at the discretion of the developer. While using illogical naming conventions for these attributes makes programming and debugging more difficult for the developer it also stops spam bots cold as those bots typically rely on the NAME attribute of a field to discern each field's purpose. When illogical names are used for the NAME and ID attribute, spam bots tend to leave said fields blank when submitting forms allowing the server to simply reject these forms during the server side form validation process.

I do not use graphical buttons for form fields unless absolutely necessary (e.g. an advertiser supplied affiliate ad). When graphical buttons are used I ensure ALT and/or TITLE attributes are used.

As much as possible I try to avoid any anti-spam technique that would negatively impact accessibility. Unfortunately some third-party software (e.g. vBulletin) still has a ways to go in providing CAPTCHAs that are accessible.

Currently my simple illogical variable names works just fine for stopping spam bots. If at some point in the future I find this tactic not doing the trick, I will implement some type of text based CAPTCHA system. For example I might provide simple mathmatically equasions that the user must answer.

Demaestro




msg:3087915
 9:23 pm on Sep 18, 2006 (gmt 0)

excellent topic for discussion.

I will answer your questions first.

- How are you currently handling forms?

I do some form of field cloaking as well as was outlined above for some of the more popular sites I run with forums, and it does seem to work well, however I have had some automated ads placed on those sites from that have the same value for all fields. A very very small amount of them though I must admit and I just issue an IP ban if they do sneak through.

However for ANY form that I have that has the side effect of sending an email I use image CAPTCHAs. I am too afraid of killing my email server, too much is riding on it.

- How does your method impact accessibility?

In my second use-case.... negativaly.

- Where do you draw the line between accessibility, functionality and spam-protection?

For me I would let the target audience/customers of each site decide on a site by site basis. It is hard to draw one line for dozens of different sites.

I very excited to hear some ideas for this. I have had my brain on it for a little while and I don't have much as far as solutions go.

[edited by: Demaestro at 9:27 pm (utc) on Sep. 18, 2006]

encyclo




msg:3088088
 1:25 am on Sep 19, 2006 (gmt 0)

Great answers, thanks! Using
label for... is vital - it is the best way of associating descriptions with the input fields. Is anyone using fieldset to group together form elements? Do you use title attributes?

If we check out some of the WCAG guidelines for accessible forms, how do you consider the following:

10.4 Until user agents handle empty controls correctly, include default, place-holding characters in edit boxes and text areas. [Priority 3]
For example, in HTML, do this for
TEXTAREA and INPUT.

[w3.org...]

Finally, how do you handle form validation?

KenB




msg:3088172
 3:28 am on Sep 19, 2006 (gmt 0)

Great answers, thanks! Using label for... is vital - it is the best way of associating descriptions with the input fields. Is anyone using fieldset to group together form elements?

I use FIELDSET when appropriate to group sets of form fields into logical groupings. Typically this is only needed on big forms.

Do you use title attributes?

When appropriate and if it would be useful to users (disabled or otherwise).

If we check out some of the WCAG guidelines for accessible forms, how do you consider the following:
10.4 Until user agents handle empty controls correctly, include default, place-holding characters in edit boxes and text areas. [Priority 3]

For example, in HTML, do this for TEXTAREA and INPUT.

[w3.org...]


I do not provide place holders. The WCAG were written seven or eight years ago and a lot has changed since then. It isn't too much to expect that browsers will have addressed this issue by now.

Placeholders can create usability problems for non-disabled users and I look at this as the responsibility of software venders to bring their software up to snuff. Accessibility is a partnership between website developers and software developers. At some point in time we have to be able to rely on software developers to hold up their end of the bargain.

Finally, how do you handle form validation?

In some cases I use both client side JavaScript and server side validation. On other sites I strictly use server side validation.

In regards to JavaScript and accommodating browsers that do not support JavaScript; it isn't too much to ask for browsers for the disabled to be able to support some basic JavaScript for things like form validation. Client side validation is very important to improve the usability of websites for all users. With that said, there are better ways of implementing JavaScript form validation such that browsers don't need to support JavaScript to still be able to submit a form.

DrDoc




msg:3094475
 10:57 pm on Sep 23, 2006 (gmt 0)

I personally make heavy use of fieldsets. I have found that it forces me to organize the form, give it a logical structure. It thereby also enhances the user experience and usability of the form by providing logical cues about the information asked for. A simple example is if you have multiple address fields on a page (shipping and billing, ship from and ship to, for example) ... grouping these within fieldsets is almost an absolute must to achieve accessibility.

As far as validation ... I do use some basic client-side validation in the lucky likelyhood that JavaScript is enabled. Whenever I do so, the validation is always upon key-up or upon leaving the form field. I avoid DHTML type indication, as this can be confusing and not noticed as easily. Instead I use a simple alert() to describe the problem, notifying them that the field will regain focus upon closing the dialog (this is important from a usability standpoint, as silently giving the field focus again can be confusing ... and so can not giving the field focus ... "where am I at?").

I occasionally employ silent validation ... such as removing non-digits from an "age" field, for example. But those instances are rare.

Finally, I always always use server-side validation. It is important that the validation captures all problems with the form at once. Preferably, the "error" page should have no other "fluff" on it, as it would otherwise be a nightmare for a person using a screen reader. Simple, error message ... And then I include the fields which need to be corrected ... and only those fields (as it will otherwise be difficult to navigate through a long form to find the fields which need to be "fixed"). I also offer a "back to form" type link in case the user wants to completely change the information previously entered.

Server-side form validation is an area where I feel most websites fail horribly.

Global Options:
 top home search open messages active posts  
 

Home / Forums Index / WebmasterWorld / Accessibility and Usability
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved