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

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

Received on Monday, 9 February 2004 15:29:21 UTC