Re: Head in the sand, driving a car

How about a public wiki?

it's time w3c joined the modern world

Jonathan

On Friday, June 6, 2003, at 02:08  am, Quinn, Anthony wrote:

> 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...
> >
>