Re: Banning and Guidelines V Techniques

> think the issue can can be solved.  I believe most web designers when told
> to be wary about using scripts and given examples of how to use them

My impression is that more than half of web designers don't actually
really understand what they are doing and simply cut and paste from
other sites or from "web design" cook books.  Many of the rest are
probably already aware of the issues, but know that they are wage
slaves and that the person paying them doesn't understand the issues,
but does have very strong ideas as to how a site should look and feel.
The people you have to educate are not the web designers, but people who
don't want to understand the technology, but "know" from experience what
it can do, but with knowledge based on experience of very bad design.

> correctly and examples with factual based documentation on why some
> scripts break the accessibility issues, would do the correct approach.
> 
> Do we want to ban scripting in the guidelines?  I think that artifically

Although it may seem that I am absolutely against scripting, I'm not.
I don't, however, want to be forced to use scripting before I can use
a web resource, and I would rather not have cosmetic only scripting.

> closes the door.  I think the guidelines should say something such as
> "Scripts should be USED WITH CAUTION and must degrade gracefully in

Unfortunately businesses want MUST clauses, because they then know where
they stand legally, without having to take a risk.

> regards to the information presented/attained."  And leave it to that.

This feels subjective, and those businesses which don't err too far to
the safe side, for legal reasons, will probably interpret the need very
liberally.  The problem with "degrade gracefully" is that many authors
will see it as permission to drop content as well as presentation, when
it is almost always possible to drop presentation but retain content.
More importantly, remember most of the web is advertising and most
advertising is not about information.

If one does have conditional permissions, they need to start from the premise
that, except where there is a fundamental need for scripting (server turnround
times are not fundamental, except for some cases of animation, for which
HTML is the wrong medium anyway; an application that will intrinsically 
always be run offline - I can't think of any - might also qualify), pages
should be designed as though written without scripting and then scripting
had been added without removing the access available without the scripting and
only to make the page easier to use, not to provide additional information.

For priority one, one could allow the scripted page to be separate
from the non-scripted page, and could permit client scripting only
solutions where there would be undue hardship to the content providers
(I'm thinking here of non-commercial sites that want to provide some sort
of calculator function (although they ought to describe the algorithm,
anyway [1]) and doing so server side might mean changing from bundled web
space to bought commercial space).  I can't, at the moment, think of any
application that is appropriate for HTML where not having "instantaneous"
feeback would make the site unusable.

Another constraint that I would want would be that scripting should attempt
to verify the actual object model available.  This should be done by 
feature testing, and never by trying to match the user agent string.
(Basically, I don't want the situation were a web site can end up locking
out the user interface when run on Netscape 6 because any attempt to get
to the browser controls triggers a scripting error as the Netscape 4 
object model was used - this is a real life problem, although I forget
the site - I think it was the major UK high street electronics retailer.)

Scripting should not be allowed to subvert restrictions imposed by the
user agent guidelines.

As informative text, I think people should be warned that scripting can
make pages very unstable when presented with an environment that differs
from the test environment.

> 
> NOW I think the techniques should be the crux of the work for the WCAG WG
> where they can document AS MUCH AS THEY POSSIBLY CAN on best practices, ok

You have to get these practices into web design cook books on the book
shop shelves.  The people you need to reach are unlikely to go beyond the
basic check list to make sure they are legal and probably wouldn't buy a
specific accessibilty book.  Most of the authors of these cookbooks have
no brief for the ideals of HTML but simply supply techniques for doing
what people WANT to do.  If the book fails to provide a code sample for
using scripting to create marquees on non-marquee browsers, they may well
not buy it, even though that was done because it is bad for accessibility.

> I think the time spent debating whether or not to ban this or that is a
> waste.  I think if you get enough examples of good and bad solutions to

Possibly, but it does represent a fundamental split in the community,
roughly the split between broad accessibility and narrow (formal
disability, with no financial constraints, only) accessibility.

[1] if the algorithm is proprietary, then server side scripting is the
only option to preserve the intellectual property.

Received on Friday, 4 June 2004 15:50:25 UTC