[thelist] Site check: Staples.com

[Juha Suni]

Ken Schaefer wrote:
> This wasn't a tables -vs- divs argument. The argument is whether the
> site is "broken", and whether a site owner needs to support every
> different user out there with every different possible level of
> functionality enabled. I'm arguing that it's only worth doing this
> /if/ there is a sufficient pay off in doing so.

This is one of the basic misunderstandings regarding accessible web design. 
Supporting all standards and all even marginally common setups requires _no_ 
or _very little_ extra work. Usually its the other way round. Currently they 
have spent extra money and extra work to make it _not work_ on some setups.

A competent developer can in most cases make accessible pages/sites in less 
time than inaccessible ones.

Now that the mistake has been done, and there is a problem with the site, it 
is of course important to think about the costs and payoffs, and act or not 
act accordingly. It just strikes me hard how could anyone intentionally or 
even unintentionally manage to build a site so dependant on javascript, even 
though it is certainly not required.

I mean come on, a blank page.

> a) If you already have an investment in a product (whether it be a
> CMS, existing content or whatever) then converting things costs
> money.

This is true, of course. The end result however is that there is a fault 
with the website that should not have been there in the first place (and I 
seriously find it hard to believe that any up to date CMS would actually 
implement such a critical dependancy on javascript with no option on turning 
it off. If this is the case, however, that kind of a CMS should not have 
been bought at all). I'm not claiming the webmaster(s) are the ones to take 
first blame, but I find it hard to think of anyone else, either.

> An enterprise web app (and this is small scale) that I've done some
> work with had over 50 servers (12 load balanced web servers, a
> clustered session state server, and numerous other boxes), over 60
> integration points with other systems (internal and external) and
> supported >1,000 concurrent transactions per second. It's an n-tier
> app that's supported by clustered 8-way DB servers. So, given a
> complex system like this, the owners always have to weigh up "what's
> the best place to spend my $ on".

But if the web app is made in any sensibly structured manner, changing 
things in the UI is certainly not going to cost $10,000, and is certainly 
going to be more cost effective than upgrading those 50 or even 10 servers. 
Actually I would argue that the bigger such an application gets, the more 
cost effective code and css optimizations become compared to hardware 
upgrades.

> Is it new servers? More bandwidth?
> Changing the layout of the pages? A more efficient middle-tier? Scale
> out the DB layer? Better monitoring software? New automated patch
> management solution?

Only problem is that one of these does not match the cost of others. If 
changing the layout requires as much buck as the others, there is a deeper 
problem.

--
Suni