W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > April to June 2003

Re: Accessible counter

From: David Woolley <david@djwhome.demon.co.uk>
Date: Thu, 24 Apr 2003 22:25:59 +0100 (BST)
Message-Id: <200304242125.h3OLPx804381@djwhome.demon.co.uk>
To: w3c-wai-ig@w3.org

> I have an interesting question concerning counters. On a counter that 
> projects the number of hits as an image normally you would put an alt text 

Are you sure that you really want a counter?  They normally indicate
a hobby site, rather than a serious one.  They also inhibit caching of,
at least, the counter image, and would inhibit caching of the whole
page if provided with alt text..

> in the markup that says counter right? How do you make the alt text reflect 
> the actual number, though instead of just saying there is a counter there. 

The normal way of generating counters fundamentally requires that the
counter be an image and that the page itself be constant.  If the page
could be variable, and one still wanted a counter, one would just use
a pure text counter.

They are typically used on sites that don't have enough control of the
server to allow the home page to be generated dynamically (not that
this is desirable).  They are provided as a third party service, that
maintains a database of the number of accesses to each image from a 
particular referer (or using a particular parameter on the image URL).
They are done as images because that is the only reliable way to get 
external content integrated into a page client side (a good implementation
of object, or, at a push, iframe, might allow plain text or HTML insertion,
but that cannot be relied on even now, and couldn't when counters 
became popular.

Image counters only count the number of times the image is fetched, which
will typically under-represent the true accesses due to aggressive caching
and people with images off, or not image capable.

It should be possible to generate inline counters using server side
includes, but that requires that the page be reloaded end to end each
time.  A lot of sites seem to like making perfectly static pages
uncachable, but doing so will slow down the page.  You don't need
to do this even if you want 100% access statistics (you only need to
force revalidation, not reloading of the page) and an ethical level
of access analysis can be done with occasional sampling.

SSI is probably not OK if search engine robot accesses are a signicant
proportion of your hits, as you probably cannot filter out on User
Agent.  You may need to use fully fledged ASP, CGI, PHP, etc.,
processing.
Received on Thursday, 24 April 2003 17:45:01 GMT

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