Re: 2nd in Series - Problems

> 	c.  if we are asking authors to solve a problem that should be
>           handled by ATs or UAs 

I agree for UA: we should avoid markup guidelines that can be
implemented by UA, like "put your link on separated line". I know it's
not ideal, since some screen reader will get screwed, but it's part of
my model of what W3C should normalize vs.  what the WAI can work on in
addition to the normalization process.

For AT, it's a different problem. GL is the main input for AT, so I
don't see anything dropped from GL into AT. GL is really about what
goes *in* the markup file, whoever (page author) or whatever (AT) has
generated it.

> we have made an initial pass through the guidelines called, "deconstructing
> the guidelines."  you can see what we've done at
> http://trace.ie.wisc.edu/wai/analysis/

Very nice document.
I wish we could all get in a room and go over it in a couple of days
and be done with this work :-)
 
> 2.  Do we want to continue to recommend or require changes that place
> burden on authors when it is an AT or UA problem, assuming ATs or UAs will
> solve the problem in the future?  If we continue to include guidelines that
> are particular to a single point in time or for a particular browser/AT
> combination, then the guidelines are not timeless and will require frequent
> updating (with each new release of a new ua/at).  In other words, this
> version might already be antiquated by the time it has passed through the
> whole w3c process.

Exactly my point: let's concentrate on things that we know or believe
are not going to be deprecated anytime soon: use structure
appropriately, provide textual version of image/video/audio; let's
make sure all pages can be _serialized_ and still make sense when read
and navigated in that form.

Received on Thursday, 11 June 1998 09:27:52 UTC