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

RE: compatibility

From: John Foliot - bytown internet <foliot@bytowninternet.com>
Date: Tue, 16 Jul 2002 10:38:40 -0400
To: "Tom James" <tom.james@digitext.com>, <w3c-wai-ig@w3.org>
Message-ID: <GKEFJJEKDDIMBHJOGLENKEAKCJAA.foliot@bytowninternet.com>

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 10:38:45 UTC

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