[ic] Client side javascript and the [button] tag.

[Peter]

Ethan E. Rowe wrote:
> Also keep in mind that there are still plenty of users out there using 
> non-javascript-supporting browsers such as Lynx.  This is an issue that 
> comes up when you worry about accessible design (though the 
> accessibility guidelines tend to focus more on how you use HTML and CSS 
> stylistically); my employer (National Braille Press, Inc) primarily 
> serves the braille-reading community, and I've consequently learned that 
> there are a lot of visually-impaired computer users out there who prefer 
> the command line interface to the visually-oriented GUIs of Windows, 
> Mac, etc.  Such users will employ browsers such as Lynx, and it's 
> extremely frustrating for that community when sites are reliant on 
> Javascript.  Just yesterday I encountered a site that requires users to 
> register in order to access any significant features, and the 
> registration form uses an <a href="...">...</a> tag rather than a 
> standard submit button; the anchor tag's HREF points to a javascript 
> function that authenticates and submits the form.  Were the javascript 
> function called via the OnSubmit event of the <form>, that would be one 
> thing (Lynx would be free to ignore the OnSubmit); however, in this 
> case, the link just doesn't work in Lynx and consequently, the site is 
> not usable for a particular user community.
> 
> This is getting pretty picky, but perhaps it's of interest to you.  Web 
> design frequently gets into the sticky area of backwards compatibility 
> and it doesn't always make sense for a particular organization to try to 
> support older browsers.  However, considering the flexibility 
> Interchange gives you in form validation and error-reporting, the safest 
> choice for such things is to avoid javascript for critical functions 
> (unless you can absolutely guarantee that your users will run a certain 
> type of browser), and failing that, always back it up with server-side 
> validation/processing.

I agree with this, though I wasn't going to bother getting into it.  My 
way of doing Javascript is that I will first make the site look and work 
as well as I possibly can without Javascript, then use Javascript to 
enhance it, and always in such a way so that the site is still 
functional without it (just may lack some pretty feature that Javascript 
provides).

One example is that on a particular program I have a form that updates 
the list of states/provinces/regions whenever the country is changed in 
a drop-down menu.  The javascript simply submits the form from an 
onchange event but before I ever put that bit of javascript in I had the 
form tested and working with a submit button which just had to be 
clicked after the country was changed.  That submit button is still 
there but only people who don't have javascript need to use it.

Peter