W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > July to September 2002

Re: compatibility

From: David Poehlman <poehlman1@comcast.net>
Date: Tue, 16 Jul 2002 10:58:57 -0400
To: John Foliot - bytown internet <foliot@bytowninternet.com>, Tom James <tom.james@digitext.com>, w3c-wai-ig@w3.org
Message-id: <013d01c22cd9$4ff86740$19e03244@DAVIDPOEHLMAN>

do you in fact know just how hard it can be to "upgrade" software???

It often means tearing out entire infrastructures needlessly, and the
cost of acquiring ownership can be more daunting than you might be able
to imagine.  I'm not saying that everything is frozen but let's not make
lite of these issues for the sake of "progress".

----- Original Message -----
From: "John Foliot - bytown internet" <foliot@bytowninternet.com>
To: "Tom James" <tom.james@digitext.com>; <w3c-wai-ig@w3.org>
Sent: Tuesday, July 16, 2002 10:38 AM
Subject: RE: compatibility

Tom, you have succinctly paraphrased my points.  Adding the "suggestion
upgrade" message can be done with tact and decorum; we don't
need to hit people over the head with a brick.

But just as you outlined that a little bit of carrot and stick works
the powers that be, so too with the end users... if we start telling
that they have both a choice and a responsibility to upgrade their
and that truly it is not that hard to do, then why not?

> -----Original Message-----
> From: w3c-wai-ig-request@w3.org [mailto:w3c-wai-ig-request@w3.org]On
> Behalf Of Tom James
> Sent: July 16, 2002 10:18 AM
> To: 'w3c-wai-ig@w3.org'
> Subject: RE: compatibility
> John Foliot recently wrote:
>  They [The Web Standards Project - TJ] include the following
> > piece of code on
> > their web site:
> >
> > <div class="oldbrowsers">
> > <strong>Please note:</strong> This site's design is
> > only visible in a
> > graphical browser that supports Web standards, but its
> > content is accessible
> > to any browser or Internet device. To see this site as it was
> > please <a href="http://www.webstandards.org/upgrade/" title="The Web
> > Standards Project's BROWSER UPGRADE initiative.">upgrade to a
> > Web standards
> > compliant browser</a>.
> > </div>
> >
> This issue was recently discussed at some length on this list: see
> http://lists.w3.org/Archives/Public/w3c-wai-ig/2002AprJun/0755.html
> posts following in the thread "Standards Compliant = No support for
> My opinion, and some data points: I work for a web design firm, but in
> fortunate position that much of our work is for intranets, so we are
> designing to a more or less standard browser and OS environment.
> Many of our
> clients (by which I mean the people who sign the cheques, not
> the people we deal with day-to-day :-) have a subtle visual bias: they
> buying something that looks "nice", rather than something that is
> more accessible / usable, but plain. Of course our clients have
> pressures of
> their own: typically, they have to demonstrate, in a limited
> amount of time,
> their new baby to someone even higher in the organisation, who
> probably will
> never use the system but will have a strong opinion if the links
> quite the correct corporate red-on-green... Excuse me if I sound a
> cynical! (BTW my specific accessibility issue: I'm colour blind)
> So where does accessibility fit in, and what does that have to do with
> standards? Well generally, when you explain to a client what
> is all about (possible with a little carrot / stick type persuasion
> the business and legal cases), then in my experience they are
> quite receptive, with two caveats:
> 1) It still has to "look nice" - or at least, people don't want a
> Nielsen" visual design
> 2) For an intranet at least, there also has to be an authoring
> process that
> is simple to implement but doesn't throw away the accessibility gains.
> Solving point 2 is one reason that companies use consultants such as
> (rather than, say, a more overtly "designy" sort of agency).
> Solving point 1, in my opinion, is possible using the full
> built into HTML4 / XHTML and CSS - especially with modern GUI
> Users with non-GUI or non-modern browsers I would generally split into
> classes: browsers such as Lynx will generally benefit from an
> site, provided that the code structure is logical (because these
> users will
> not see the visual structure, so the code structure becomes the
> order). This is possible using e.g. simple layout tables or
> CSS-positioning.
> Users with old browsers such as Netscape 4: well, I'm inclined to
> standards compliant code in a sensible code structure, and hide the
> style sheet from these browsers (using e.g. @import or similar). All
> content is still available; the code structure ensures that the visual
> structure (to a NN4 user) is still logical, if not as aesthetically
> pleasing. So I would go with points 1 and 2 of the WaSP idea (as
> outlined in
> my email
> http://lists.w3.org/Archives/Public/w3c-wai-ig/2002AprJun/0762.html).
> Whether I would go with the third point - about adding a warning
> of the type
> mentioned above about using a non-standards-compliant browser, well I
> open to persuasion either way. But in general I think the way forward
> accessibility is to use the full set of features given by the latest
> and allow NN4 users to upgrade, rather than just go back to all manner
> dodges and workarounds to get it to work across horrible non-compliant
> browsers - but probably break in other niche browsers we haven't
> targetted.
> Ultimately, I believe forward compatibility is more important
> than backwards
> compatibility.
> Just my 0.02 euro...
> Tom
> Dr Tom James
> Senior Consultant
> ===============================================================
> Digitext - Online Information at Work
> Telephone: +44 (0)1844 214690
> Fax: +44 (0)1844 213434
> Email: tom.james@digitext.com
> Web: http://www.digitext.com/
Received on Tuesday, 16 July 2002 11:01:41 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 13 October 2015 16:21:19 UTC