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, 2 February 2004 13:43:31 UTC