RE: Head in the sand, driving a car

Hi Michael,

That sounds like a sensible approach but I would suggest that it is
implemented in a way that makes any such lists easy to update and edit - a
little future proofing. 

Cheers

Anthony

-----Original Message-----
From: Michael Cooper [mailto:michaelc@watchfire.com]
Sent: Friday, June 06, 2003 12:44 AM
To: 'Charles McCathieNevile'; Jonathan Chetwynd
Cc: w3c-wai-ig@w3.org
Subject: RE: Head in the sand, driving a car


Just so you know what the techniques group is up to, we are indeed thinking
of issues around browser support. For techniques that are only supported in
certain user agents, or that go awry in certain user agents, that
information will be stored with the technique. It should be possible to pull
up lists of techniques that work on certain setups or that you should avoid.
We've also identified a potential need to create techniques that are
specifically workarounds for user agent problems. How we'll do that exactly
is not yet determined and it could be an endless task, so we'll probably
narrow it down by restricting it to moderately recent versions of
technologies, but hopefully that addresses the issue you're raising. As far
as architectural materials go, that is likely to be minimized in the
techniques themselves, but we will explicitly link to relevant resources. So
the information should be available in context even though it's not part of
the substance of the techniques themselves.

Michael

> -----Original Message-----
> From: Charles McCathieNevile [mailto:charles@sidar.org]
> Sent: Tuesday, June 03, 2003 9:23 PM
> To: Jonathan Chetwynd
> Cc: w3c-wai-ig@w3.org
> Subject: Re: Head in the sand, driving a car
> 
> 
> I actually think it would be valuable to have a discussion in 
> the WCAG 
> techniques about ways to work around things the technology 
> does badly. 
> That should include workarounds even if they are only useful in some 
> cases (like Flash being able to work on one platform with a couple of 
> screen readers, but not necessarily being accessible in general).
> 
> That information should also include, as a matter of course, 
> discussion 
> of the relevant architectural principles for the web. If there is a 
> workaround that lets some people move forward now, but will hold back 
> the development of the web as a whole (text alternatives as a single 
> attribute, or default text in form fields, for example) in 
> the future, 
> then that should be noted and people should be warned about the fact 
> that at some point they should expect to remove a work-around because 
> the manufacturers have tuned their software better...
>