- From: Bruce Bailey <bbailey@clark.net>
- Date: Wed, 2 Jun 1999 13:54:52 -0400
- 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. When > 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), it > fails badly, and an awful lot of Javascript makes precisely those kinds of > assumptions. I haven't managed to work out how to distinguish between such > 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 make > 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 squillion > 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 - certainly > 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 of > the task when you consider how many mutually incompatible versions of > Javascript are out there. > > Meanwhile, removing all Javascript solves the problem of Javascript-related > error messages. I did try and retain some Javascript, but all that ended up > happening was that I retained the ablility to ensure a flurry of Javascript > errors on almost every page that contained undeleted Javascript. So, bye 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 for > 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 guidelines > 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 being > 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, 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. > > ... I'm afraid I don't agree that checking form data with Javascript *is* a > reasonable thing to do. Javascript may be turned off, or may simply not be > present, and then that checking - if it is indeed important - will have to > be done again in the CGI. If it's already being done in the CGI, it doesn't > 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