RE: Issue #6: Rationale and success criteria of 2.2

OK Jan, dropping "developers" is fine. After Monday's call, I began to think
it had been missing. Now... my first sentence, which you just changed by
removing developers plus a bit more, is also in the rationale. Shouldn't
that sentence be changed as well? Thus, your 

"A format is WCAG-capable when a WCAG techniques document that explains how
to meet each applicable WCAG checkpoint has been published and explicitly
referenced."

should appear twice in this section. Right?

regards, Karen

-----Original Message-----
From: w3c-wai-au-request@w3.org [mailto:w3c-wai-au-request@w3.org] On Behalf
Of Jan Richards
Sent: 13. februar 2004 22:36
To: w3c-wai-au@w3.org
Subject: Re: Issue #6: Rationale and success criteria of 2.2



Karen,

I agree with your re-wording of the rationale.

But regarding the def'n of WCAG-capable, I specifically left out who
published the WCAG techniques doc. I just specified that one must exist
and it must be public. 

KM: A format is considered WCAG-capable when its developers have
published a WCAG techniques document with explicit references explaining
how
to meet each applicable WCAG checkpoint. Formats that are WCAG-capable
enable creation of web content that conforms to WCAG requirements.

JR: A format is WCAG-capable when a WCAG techniques document that
explains how to 
meet each applicable WCAG checkpoint has been published and explicitly 
referenced. (LAST LINE FROM KM's APPENDED) Formats that are WCAG-capable
enable creation of web content that conforms to WCAG requirements.

Cheers,
Jan


Karen Mardahl wrote:
> 
> OK. This is my re-working - as promised - of Checkpoint 2.2
> 
> *  *  *  *
> 2.2 Give priority to formats that enable the creation of WCAG-conformant
> content. [Priority 1]
> 
> Rationale:
> Giving priority to WCAG-capable formats will increase the probability that
> they are used.
> A format is considered WCAG-capable when its developers have published a
> WCAG techniques document with explicit references explaining how to meet
> each applicable WCAG checkpoint. Some formats are "WCAG-capable" while
other
> formats are intrinsically not "WCAG-capable".
> 
> Success Criteria:
> 
> 1) When format selection is automatic, the selected format must be
> WCAG-capable.
> 
> 2) When format selection is performed by the author, the most prominent
> format(s) must be WCAG-capable.
> *  *  *  *
> 
> Then, in the glossary, we should have
> 
> Term: WCAG-capable
> Definition: A format is considered WCAG-capable when its developers have
> published a WCAG techniques document with explicit references explaining
how
> to meet each applicable WCAG checkpoint. Formats that are WCAG-capable
> enable creation of web content that conforms to WCAG requirements.
> 
> *  *  *  *
> Even though the term appears only in this one place, we don't know how
> readers of our documents read them or hear of terms we use. This is a term
> that could use explaining so I think it should be in the glossary so a
user
> isn't always forced to do a search in body text. Having our terms all nice
> and neat in our glossary makes it easier to add them to the big WAI
> glossary.
> 
> regards, Karen
> 
> -----Original Message-----
> From: Jan Richards [mailto:jan.richards@utoronto.ca]
> Sent: 2. februar 2004 19:44
> To: karen@mardahl.dk
> Cc: w3c-wai-au@w3.org
> Subject: Re: Issue #6: Rationale and success criteria of 2.2
> 
> Hi Karen,
> 
> You make some good points:
> 
> > Technical question: Do you want the definition in parentheses included
at
> > this point in the guidelines, or will the term "WCAG-capable" just have
an
> > href down to the Glossary?
> 
> Actually, I was wondering about this - I put it in the glossary as an
> afterthought. We could just do away with the new term and just sub the
> definition in to both of the success criteria.
> 
> > OK this is all just about prioritizing. If there are no WCAG-capable
> formats
> > available, then the available formats can be in any old order. The tool
> > simply cannot deal with 2.2 if it doesn't have a WCAG-capable format.
> Would
> > that then imply something about the overall accessibility of the tool?
> 
> Right, we're not trying to ban any formats. We just want tool developers
> to do make sure that for their tool's favoured formats, they have a
> publicly available techniques document in hand before they move ahead to
> other ATAG techniques that are going to require them to prompt,
> document, check, correct, etc. content on the basis of that techniques
> doc.
> 
> Cheers,
> Jan
> 
> Karen Mardahl wrote:
> >
> > Hi Jan
> >
> > I like your re-wording of 2.2, in general.
> >
> > Technical question: Do you want the definition in parentheses included
at
> > this point in the guidelines, or will the term "WCAG-capable" just have
an
> > href down to the Glossary?
> >
> > I guess what worries me about the definition of WCAG-capable is - I'm
> > worried there's a catch somewhere. Don't know why, just do! I just dived
> > into the CSS Techniques for WCAG 2.0
> > (http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-CSS-TECHS-20031219.html) and
> > could not find what I would call explicit references. I.e. checkpoints
or
> > guidelines didn't match - you have to do a Find. I expect more from your
> > definition than the other docs can provide. Does that then weaken your
> > definition? Guess that is my real worry.
> >
> > OK this is all just about prioritizing. If there are no WCAG-capable
> formats
> > available, then the available formats can be in any old order. The tool
> > simply cannot deal with 2.2 if it doesn't have a WCAG-capable format.
> Would
> > that then imply something about the overall accessibility of the tool?
> >
> > regards, Karen, the confused and puzzled! (Or maybe I am just pedantic
and
> > dense?!)
> >
> > -----Original Message-----
> > From: w3c-wai-au-request@w3.org [mailto:w3c-wai-au-request@w3.org] On
> Behalf
> > Of Jan Richards
> > Sent: 27. januar 2004 17:59
> > To: w3c-wai-au@w3.org
> > Subject: Issue #6: Rationale and success criteria of 2.2
> >
> > The wording in the most recent internal draft:
> > http://www.w3.org/WAI/AU/2004/WD-ATAG20-20040120/#check-prefer-w3c
> > is quite good. However, in the interest of clarity, I suggest the
> following
> > re-
> > wording:
> >
> > 2.2 Give priority to formats that enable the creation of WCAG-conformant
> > content. [Priority 1]
> >
> > Rationale:
> > Some formats are "WCAG-capable", enabling the creation of web content
that
> > conforms to WCAG, while other formats may intrinsically preclude this
> > possibility. Giving priority to WCAG-capable formats will increase
> > probability
> > that they are used.
> >
> > Success Criteria:
> >
> > When format selection is automatic, the selected format must be
> > WCAG-capable.
> >
> > When format selection is performed by the author, the most prominent
> > format(s)
> > must be WCAG-capable.
> >
> > (A format is WCAG-capable when a WCAG techniques document that explains
> how
> > to
> > meet each applicable WCAG checkpoint has been published and explicitly
> > referenced.)
> 
> --
> Jan Richards, User Interface Design Specialist
> Adaptive Technology Resource Centre (ATRC), University of Toronto
> 
>   Email: jan.richards@utoronto.ca
>   Web:   http://ultrajuan.ic.utoronto.ca/jan/richards.html
>   Phone: 416-946-7060
>   Fax:   416-971-2896

-- 
Jan Richards, User Interface Design Specialist
Adaptive Technology Resource Centre (ATRC), University of Toronto

  Email: jan.richards@utoronto.ca
  Phone: 416-946-7060
  Fax:   416-971-2896

Received on Friday, 13 February 2004 18:15:15 UTC