W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > October to December 2000

How to convince businesses to be accessible...

From: David Woolley <david@djwhome.demon.co.uk>
Date: Wed, 25 Oct 2000 00:33:57 +0100 (BST)
Message-Id: <200010242333.AAA13791@djwhome.demon.co.uk>
To: w3c-wai-ig@w3.org
> 
> and JavaScript links, so I switched to Netscape, to discover that all
> the images were broken (status 404 - not found), which meant I was still

I finally got the images in the office, and it wasn't just the paper
instruction sheet, however it was only one product, and was either there
to test the market for flash instructions or to provide a sample to give
the general impression.

I'll take one point out of sequence, in case it gets lost...

Not strictly an accessibility issue, in the sense that it affects
everyone, but I believe it arose for the same sort of reasons that 
accessibility problems arise, is that the site is abysmally slow.
This is not a case where paying for a fast client and a T1 line will
help; the problem seems to be server side.

What they seem to have done is taken a site that is basically static
HTML and static graphics, and forced all the HTML to be loaded from
the same underpowered server, on every request, including repeat 
requests in the same session.

They have done three things that frustrate caching, the last of which is
normally only done to frustrate caching which is so aggressive that it
violates the protocol.  All the pages are dynamic, ASP, pages, which means
they don't get the information that enables a cache to test for changes,
so caches have to re-fetch every time.  They have ? marks in the URL;
this wasn't meant to prevent caching, but abuse of it for non-repeatable
content means the current advice is to inhibit caching.  Finally, they
have Cache-Control: private, which essentially tells ISP and company
level caches not to cache the page under any circumstances - only the
browser can, but the current browsers don't cache that aggressively.
(Cache-Control: private is intended to prevent mixing of different users'
personal data.)

The only reasons I can think of for doing this is that they consider
100% complete market research data (click trails) much much more important
than adequate responsiveness.  At a guess, they have been told this is
what they need for the click trails, but not told the down side.

I actually have the CD rack version of the product.  Unfortunately I think
I left the instructions under the base, so I can't look at them, but my
impression is that the animation left the same questions unanswered
(which way round to put certain pieces, and exactly where to put the
tacks, I think) as the paper version.  The only real benefit was that
one didn't have to match up a code letter with the that on the manifest
of pieces.  The great disadvantage was that you couldn't lay it on the
ground near where you were working.  On paper, you can see all the detail
balloons at once.

There were quite a few omissions in the animation, e.g. only one set of
dowels got hammered, how you got the side onto the dowels and how you
got the first side on.

Other accessibility problems are that even the Java animation page produces
a blank screen (some JS gibberish on the first line with Netscape) with
scripting off.  You also get a blank screen in both modes with the 
WebTV emulator, even though, when you hit Download Shockwave, you get told,
with a working demonstration, that Flash actually works for WebTV!  (I'm
not sure whether the UK products that provide set top box, or TV based
web access support Flash.)  My estimation would be that there would be
quite a strong overlap with the WebTV type market in the UK.
Received on Wednesday, 25 October 2000 02:52:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 19 July 2011 18:13:50 GMT