RE: Key results and recommendations from Face to Face

Hi Neil,

I think we are on the same page.  The missing piece is that we can't put out
guidelines that can't be met (W3C rules - we need implementations).  So one
of your options (to put it in even if it can't be done) isn't an option we
have.  (and I'm not sure you meant it seriously either) 

So we can't put in a guideline as required for conformance that can't be
done at this time.   This brings us to the tricky question of "what can't be
done".  And we will have to discuss and work this one through very
carefully.  

Thanks for the comment.
 
Gregg

 -- ------------------------------ 
Gregg C Vanderheiden Ph.D. 
Professor - Ind. Engr. & BioMed Engr.
Director - Trace R & D Center 
University of Wisconsin-Madison 


-----Original Message-----
From: Neil Whiteley [mailto:neil.whiteley@tag2.net] 
Sent: Saturday, March 26, 2005 4:59 AM
To: 'Gregg Vanderheiden'
Cc: w3c-wai-gl@w3.org
Subject: RE: Key results and recommendations from Face to Face

Hi Gregg,

I hope that you don't mind me commenting but perhaps the following might be
a solution:

Firstly, a "requirement" is a "requirement", irrespective of whether it is
currently possible to satisfy. A requirement that cannot be satisfied yet,
for whatever reason, cannot be eliminated, only deferred.

So what do you do with a guideline (SC) that is impossible to satisfy in the
current environment? You need to find a way to defer it until such time as
it becomes possible to satisfy. 

The techniques doc should only offer techniques that are possible. At least
one technique should be offered per SC in order to *show* that it is
actually possible to satisfy the SC and to demonstrate *how* it might be
done. If there is no current way to satisfy the SC, the SC must be deferred.
Theoretical techniques will only be confusing to stakeholders.
It is not necessary (or desirable I would imagine) to document every
possible technique for every SC. As you say, it's not the techniques that
are required.

Deferred guidelines do not need and cannot have techniques because there
aren't any yet.

How do you defer a guideline (SC) because there is no current technique to
satisfy it? Possible solutions might be:

1.	Remove them from the current version and re-instate in a later
version as and when the barriers are removed. This would require a separate
set of documents that shows which SCs are deferred and why.

2.	Create a level 4, just for deferred SCs, and promote them as the
barriers are removed. This way, you can have a techniques document for level
4 SCs that is just informative. As long as it is clearly stated that this
level is included for completeness only, it would be acceptable IMHO.

3.	Leave them in the guidelines (where they are) knowing that authors
will not be able to satisfy the requirements and write techniques that are
not possible to implement.

Neil





Neil Whiteley
--------------------
Tag2


-----Original Message-----
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On Behalf
Of Gregg Vanderheiden
Sent: 26 March 2005 06:45
To: jasonw@ariel.its.unimelb.edu.au
Cc: 'John M Slatin'; 'Al Gilman';
Subject: RE: Key results and recommendations from Face to Face


Hi Jason,

More confused now.

    The discussion below starts with assuming that we require something that
can't be done.  Then define a technique in the techniques doc to do it.  But
it still can't be done yet because User Agents don't support the technique.
But because there is nothing else - this is the only way to do it so it is
normative. 

    I'm sure I did this wrong but that is what I got.   

Let me explain some things and see if it helps focus the discussion.

    First - we can't put something in guidelines that can't be done.  But
perhaps you mean it can be done with one technology but not another. So lets
work with that.  

    If it can't be done with this "second" technology - then the way to
advocate for it would be in papers or other standards. Or working with user
agent manufacturers.  We shouldn't put something in the techniques doc as
required if it can't already be done.   

    If we did put something in techniques that isn't already a standard, it
would be advisory.  Because the techniques cannot make something 'the
standard way'.   It can only list it as a suggestion.  And the guidelines do
not require that you follow the techniques.  the techniques help you
understand what the guidelines require and give you some techniques for
doing it.  It cannot require any technique be used.  If there is only one
way that satisfies the guideline (SC) then the techniques doc can inform
authors of it.  But it cannot require it.  And if there is another technique
that is not in the techniques doc that would satisfy the SC then it still
would satisfy the SC even if it is not in the techniques doc.  That is - the
techniques doc can neither make something 'required' by including it or make
it not acceptable by omitting it. 

   Does this make sense now?

   Do you see a hole I don't see?


    


 
Gregg

 -- ------------------------------ 
Gregg C Vanderheiden Ph.D. 
Professor - Ind. Engr. & BioMed Engr.
Director - Trace R & D Center 
University of Wisconsin-Madison 


-----Original Message-----
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On Behalf
Of Jason White
Sent: Friday, March 25, 2005 6:39 PM
To: Gregg Vanderheiden
Cc: 'John M Slatin'; 'Al Gilman'; w3c-wai-gl@w3.org
Subject: RE: Key results and recommendations from Face to Face


Gregg Vanderheiden writes:
 > Hi Jason,
 > 
 >  I still don't follow your thoughts.   Help me here.
 > 
 >   If there are several acceptable methods then there are several
acceptable
 > methods. 
 > 
 >   If there is only one - then there is only one.
 > 
 >   What is in the techniques doc does not change that fact.   Being in the
 > techniques doc may make one approach more known.   And it may give the
user
 > of the technique more evidence that it is a good technique.  And it may
be
 > used more.  (is that what you mean by de-facto standard?).   But it does
not
 > make it normative.  And it does not require the user to use it to
conform.

Perhaps an example would help to clarify the distinctions. Suppose we
decided that we wanted a means of distinguishing "layout" tables in HTML
from genuine data tables. The HTML spec doesn't provide for this, and in
order to be practically useful the chosen technique would have to be adopted
by authors and authoring tools. It would also have to be recognized by user
agents and assistive technologies.

What is needed, then, is an agreed upon technique that content and software
developers could implement, each under the expectation that the other
parties would support it. The question, then, is how this technique would be
chosen, given that there are various ways (consistently with the HTML spec)
of glossing the semantics of table markup.

Now if WCAG techniques were to step in at this point and recommend one usage
as the norm, then we would be trying to set a standard in the techniques
rather than recording established facts, with the expectation that software
and content developers would follow what was in the techniques. Of course it
might be argued that the techniques would just be making one of these
methods better known; but the problem is that there aren't really, in this
case, two or more acceptable methods; the technique will only work if it's
adopted by tool and user agent developers. Having an agreed upon technique
is almost more important than what the technique is. The issue I understood
Al to be raising is how these issues would be settled at the
technology-specific level if WCAG didn't provide normative requirements at
this level. Such a problem is distinct from the so-called "baseline" issue,
but it does raise important questions.

Received on Saturday, 26 March 2005 18:54:10 UTC