W3C home > Mailing lists > Public > w3c-wai-er-ig@w3.org > June 1999

Re: Handling Javascript [was Re: New(ish) Test Version Of Betsie

From: Leonard R. Kasday <kasday@acm.org>
Date: Wed, 02 Jun 1999 16:08:32 -0400
Message-Id: <3.0.32.19990602160830.00765318@pop3.concentric.net>
To: "WAI ER IG List" <w3c-wai-er-ig@w3.org>
Here's results of an experiment I did on that page we're discussing, the
page you get to after clicking the "create" link on
http://www.prometheus.gwu.edu

This page has the form that's impossible to use with lynx because, instead
of a submit button, it has a button object with onMouseClick triggering
javascript that does some checking and then does a submit operation.  Lynx
doesn't know javascript of course.

I  deleted all the Javascript and replaced the button with a submit button.
 Yes, this is gross, ugly, simple minded.

But it mostly worked.  For example, If I omit all the fields I get

>Form Entries Incomplete or Invalid
>One or more problems exist with the data you have entered.
>You must enter your last name.
>You must enter your email address.
>You must enter your first name.
>You must enter your password.
>You must enter your username.
...

I get some other sensible error messages when I do other deliberate errors.
 What we're looking at here of course is cgi archeology, the remnants of
the old cgi script that was superceded by the javascript.  It didn't check
everything.  For example, it didn't check if the two passwords I typed in
match.  They must have added that after transitioning from checking in CGI
to Javascript.  

I've come across this use of javascript before, although I can't recall the
pages.

The moral is: you can get some milage by simply replacing unknown buttons
with "submit" buttons.  Yes, I know, it's gross.

It's slightly less gross to do this only if there's a .submit action in the
javascript linked to the "onclick"... ignoring all the if's, and's, and
other logic, just looking at function call sequences, so you're not
including a little Turing machine.

It's clean to do the subset of javascript I mentioned in earlier emails;
but more work.

Yes, it's very easy to come up with cases where this simple approach would
bomb out, especially the max gross version.  However, if you're faced with
a form that is absolutely impossible to use otherwise, wouldn't you want to
try that?  

The max gross version is just a line or so of Perl after all.

Klugily yours,

Len


At 11:36 AM 6/2/99 -0400, Leonard R. Kasday wrote:
>Thanks Bruce.
>
>Well I took a look at the page.  
>
>The problem is that the  button that submits the form isn't an HTML submit
>button.  Instead, it triggers javascript via "onClick"
>
> onClick="checkPassword(this.form)
>
>The code for checkPassword(data) has a bunch of checks ending in
>data.submit.  In other words, it does the checks and submits the form if
>it's OK.
>
>This is a reasonable thing to do, to check data on in the browser before
>sending it to the cgi script.  I've seen this before and my guess is that
>it's a common idiom.
>
>OK What to do?
>
>Presently, Betsie just omits Javascript.  That doesn't handle this situation.
>
>The full solution would be to build a javascript interpreter into betsie
>that would run the checks via cgi and submit the form.
>
>Here's one quick and dirty "solution"
>
>   Rule:
>    Whenever there is a button with onClick=function
>
>    search the javascript fot that function and, recursively, any functions
>    that are called
>
>    if you find .submit  then just replace the button with a submit button.
>
>The obvious problem is that this will send errors back to the cgi and who
>knows what the cgi will do.  Probably send back some inscrutable error
>message.  
>
>So the user would just keep trying to figure out what he or she filled out
>wrong.
>
>Well, arguably better than nothing.  
>
>Another solution,
>Provide an option to retain the javascript.  This will not help people with
>lynx, but perhaps it could still help people using screenreaders on
>graphical browsers that do use javascript.  So make "retain javascript" an
>option.
>
>Or, at least, hide javascript via <!-- and --> from browsers that don't
>handle javscript.
>
>The alternative, like I say, is to build a javascript interpreter into the
>repair tool.
>
>Hmmmm.  If there's an open source Javascript tool around this may not be
>that bad...
>
>Another Hmmmmm.  Another javascript idiom is to replace images when a mouse
>passes over them.  This is used, e.g., to cause text to highlight.  Or to
>cause a picture of a man's forehead, visible just above a horizon line, to
>pop up, revealing a smiling, disembodied face, whenever the mouse passes
>over the forehead, or passes over a link to yahoo further down on the page
>(cf. http://astro.temple.edu/~kasday  ). The latter page describes the
>effect via a D link.  A repair tool would include a link equivalent to
>"onMouseOver" and tell the user what happened, assuming proper ALT text
>with the replacement image.
>
>Len
>
>At 10:09 AM 6/2/99 -0400, Bruce Bailey wrote:
>>Actually the problem was latter on.  I should have explained this better.
>>
>>I explored both frames, and found the one with content.  This was no big
>>deal.  But then try going further.  Follow the link for "_create_ new
>>student account".
>>
>>Filling-in the few lines is no problem (Lynx or Betsie) but submitting the
>>form is another story.
>>
>>Lynx cannot activate the "Create" button (even though [BUTTON] is
>>displayed).  Betsie shows the button, but when it is selected just
>>generates a blank page.
>>
>>Please try this, you will not get to a validation screen until after this
>>step (use whatever text you want for the fields).
>>
>>I think the pages use poorly designed Java script.  As you saw, nominally
>>IE 4+ is required.  For the source of one page was a subroutine named "IE3
>>stinks" -- this can't be too professional work!
>>
>>Thank you for your efforts.
>>
>>Bruce Bailey
>>
>>----------
>>> From: Leonard R. Kasday <kasday@acm.org>
>>> To: Bruce Bailey <bbailey@clark.net>; Wayne Myers-Education
>><wayne.myers@bbc.co.uk>; WAI ER IG List <w3c-wai-er-ig@w3.org>
>>> Subject: Re: New(ish) Test Version Of Betsie
>>> Date: Wednesday, June 02, 1999 9:12 AM
>>> 
>>> Thanks bruce for observing that 
>>> 
>>> >Betsie also could not handle a page that is currently giving Lynx fits
>>at
>>> >URL: http://www.prometheus.gwu.edu
>>> 
>>> I took a look with lynx.
>>> 
>>> This page has two frames, one of which is actually blank, to wit (or
>>witless)
>>>    <HTML>
>>>    <HEAD>
>>>         <TITLE>Untitled</TITLE>
>>>    </HEAD>
>>>    <BODY BGCOLOR="#FFFFFF">
>>>    </BODY>
>>> </HTML>        
>>> 
>>> So we could add a repair rule: omit blank frames 
>>> 
>>> And as special case, if there's just one frame, release it from it's
>>shell.
>>> 
>>> Actually, I think WAG in effect did this by concatenating frames into a
>>> single page.... I'll have to take a look... gotta run now...
>>> 
>>> There's also some images with no alt text.
>>> 
>>> Otherwise reads OK.
>>> 
>>> Len
>>> 
>>> 
>>> -------
>>> Leonard R. Kasday, Ph.D.
>>> Universal Design Engineer, Institute on Disabilities/UAP, and
>>> Adjunct Professor, Electrical Engineering
>>> Temple University
>>> 
>>> Ritter Hall Annex, Room 423, Philadelphia, PA 19122
>>> kasday@acm.org        
>>> (215} 204-2247 (voice)
>>> (800) 750-7428 (TTY)
>>
>>
>-------
>Leonard R. Kasday, Ph.D.
>Universal Design Engineer, Institute on Disabilities/UAP, and
>Adjunct Professor, Electrical Engineering
>Temple University
>
>Ritter Hall Annex, Room 423, Philadelphia, PA 19122
>kasday@acm.org        
>(215} 204-2247 (voice)
>(800) 750-7428 (TTY)
>
>
>
-------
Leonard R. Kasday, Ph.D.
Universal Design Engineer, Institute on Disabilities/UAP, and
Adjunct Professor, Electrical Engineering
Temple University

Ritter Hall Annex, Room 423, Philadelphia, PA 19122
kasday@acm.org        
(215} 204-2247 (voice)
(800) 750-7428 (TTY)
Received on Wednesday, 2 June 1999 16:06:26 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.30 : Thursday, 9 June 2005 12:10:33 GMT