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

Re: Handling JavaScript

From: Bruce Bailey <bbailey@clark.net>
Date: Wed, 2 Jun 1999 13:54:52 -0400
Message-Id: <199906021757.NAA06465@smtp-gw.vma.verio.net>
To: "WAI ER IG List" <w3c-wai-er-ig@w3.org>
Thank you Wayne and Len.

I agree that filtering out javascript IS a reasonable thing to do.  My
objection is more that betsie lets through the "create" button -- even
though she can't handle the results!

I agree that (bad) javascript violates the WAI.  My understanding is that
betsie is a tool for repair, and therefore badly designed are its target!

I think that betsie is valuable as an option, but I think it makes the most
sense the way the BBC offers it -- as alternative view of their own pages. 
I really don't have an appreciation for what betsie can do that the
currently available Lynx emulators don't do.  I would like examples of
sites that are more useable with betsie than with the real version of Lynx.
 Do such sites exist?

Thank you.

> From: Wayne Myers-Education <wayne.myers@bbc.co.uk>
> To: WAI ER IG List <w3c-wai-er-ig@w3.org>
> Subject: RE: Handling Javascript [was Re: New(ish) Test Version Of Betsie
> Date: Wednesday, June 02, 1999 12:49 PM
> Um... yeah. Javascript is a problem.
> The main reasons I made the decision to have Betsie remove all Javascript
> are approximately as follows:
> Betsie messes around in a very serious way with the HTML in the page.
> Javascript in a page is making assumptions about what else is going to be
> there in the page (especially images, and especially image roll-overs),
> fails badly, and an awful lot of Javascript makes precisely those kinds
> assumptions. I haven't managed to work out how to distinguish between
> Javascript and other Javascript that makes no such assumptions and would
> therefore work fine in theory under Betsie. Building a Javascript
> interpreter into Betsie seems fairly pointless until it is possible to
> that distinction reliably, at which point it may prove to be easier to
> simply rely on the user's browser's Javascript interpreter.
> Also, in practice, and certainly on the test suite of however many
> pages I have tested Betsie on, both on the BBC site and elsewhere, I have
> found the general standard of 'found' Javascript to be no higher than the
> general standard of 'found' HTML - it's hard enough to find and fix
> syntactically correct Javascript after the Betsie HTML mangling, but when
> people make mistakes in it anyway it becomes almost impossible -
> in a Perl CGI that is already quite large due to the amount of mucking
> around with HTML it does. Maybe a CGI written in C/C++ could encapsulate
> enough oomph to do the job, but this only introduces other problems
> associated with the much smaller pool of people who are going to be happy
> with installing such CGI scripts, to say nothing of the sheer magnitude
> the task when you consider how many mutually incompatible versions of
> Javascript are out there.
> Meanwhile, removing all Javascript solves the problem of
> error messages. I did try and retain some Javascript, but all that ended
> happening was that I retained the ablility to ensure a flurry of
> errors on almost every page that contained undeleted Javascript. So, bye
> Javascript, until we can distinguish between Javascript worth keeping and
> Javascript that needs throwing out. Any ideas?
> In any case, while there is a problem with pages that rely on Javascript
> key functionality, I don't think it's Betsie's problem, or, indeed, an
> appropriate problem for a repair tool. After all, the WAI content
> state quite clearly in point 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. [Priority 1]." So relying on Javascript
> present for anything is an accessibility error up there with omitting ALT
> attributes in an image. Hence, although Len writes...
> > This [checking form data with Javascript] is a reasonable thing to do,
> 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.
> ... I'm afraid I don't agree that checking form data with Javascript *is*
> reasonable thing to do. Javascript may be turned off, or may simply not
> present, and then that checking - if it is indeed important - will have
> be done again in the CGI. If it's already being done in the CGI, it
> need to be done in the form. If it doesn't really need to be done at all
> if it doesn't matter whether or not it's being done - why do it at all?
> I would point out that 'click here' is also a common idiom.
> Cheers etc.,
> Wayne
> Wayne Myers
> Interactive Software Engineer
> BBC Digital Media
> http://www.bbc.co.uk/education/
> 0181-752-6116
Received on Wednesday, 2 June 1999 13:57:17 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:01:28 UTC