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
to
upgrade" message can be done with tact and decorum; we don't
neccessarily
need to hit people over the head with a brick.

But just as you outlined that a little bit of carrot and stick works
with
the powers that be, so too with the end users... if we start telling
people
that they have both a choice and a responsibility to upgrade their
software,
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
interesting
> > 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
designed
> > 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
and
> posts following in the thread "Standards Compliant = No support for
NN4?"
>
> My opinion, and some data points: I work for a web design firm, but in
the
> fortunate position that much of our work is for intranets, so we are
often
> 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
necessarily
> the people we deal with day-to-day :-) have a subtle visual bias: they
are
> buying something that looks "nice", rather than something that is
perhaps
> 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
aren't
> quite the correct corporate red-on-green... Excuse me if I sound a
little
> 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
accessibility
> is all about (possible with a little carrot / stick type persuasion
about
> the business and legal cases), then in my experience they are
generally
> quite receptive, with two caveats:
>
> 1) It still has to "look nice" - or at least, people don't want a
"Jakob
> 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
us
> (rather than, say, a more overtly "designy" sort of agency).
>
> Solving point 1, in my opinion, is possible using the full
functionality
> built into HTML4 / XHTML and CSS - especially with modern GUI
browsers.
> Users with non-GUI or non-modern browsers I would generally split into
two
> classes: browsers such as Lynx will generally benefit from an
accessible
> site, provided that the code structure is logical (because these
> users will
> not see the visual structure, so the code structure becomes the
reading
> 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
write
> standards compliant code in a sensible code structure, and hide the
main
> style sheet from these browsers (using e.g. @import or similar). All
the
> 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
am
> open to persuasion either way. But in general I think the way forward
for
> accessibility is to use the full set of features given by the latest
specs
> and allow NN4 users to upgrade, rather than just go back to all manner
of
> 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 GMT

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