Re: draft text for ATAG2.0 Techniques-my action item

Thanks for reviewing this submission.   My replies in line:

Best wishes,
Tim Boland NIST

At 05:06 PM 11/15/2005 -0500, you wrote:
>Hi Tim,
>
>Thanks for this work. My comments:
>
>re: "Sufficient" techniques: Probably a good idea (currently our use of 
>"Strongly Suggested" is closer to the sense of "Necessary" which is why 
>it's not used that much). I'm not quite sure how we make it clear that 
>several techniques might be sufficient when used together. For each 
>success criteria, would we provide a paragraph describing which techniques 
>used together would be sufficient?

Yes, I think we would provide a note referencing other sufficient 
techniques in the list (or possibly in another list).    I think that it 
may not be necessary to combine several techniques together for 
sufficiency, depending on how the techniques are worded.   I think that it 
would be simpler to just list the sufficient techniques for each success 
criterion if possible, without any regard to grouping,
but if it is necessary to group, then appropriate notes should be added.
(NOTE: The WCAG Guide Documents describe options or scenarios, which then 
reference
sufficient techniques, but I'm not sure this is necessary for our work? 
(adds another layer?))


>re: Technique format:
>
> > Technique Title (possibly referring to stated success criterion)
>
>I'm not sure how well this would work with our one or two line techniques. 
>Unless we expanded all of the descriptions, the titles will be as long as 
>the descriptions.

I was thinking of something really short (for example) for success 
criterion A.0.1, just titling the first technique in the list "Technique 
A.0.1-1 (or something like that to uniquely identify the technique and 
allow for filtering/searching - maybe also an identifier for sufficiency, 
like A.0.1-1s?)


> > Technologies required by the technique and technology features for 
> which the technique is applicable
>
>So is this the tool function(s) that we already have or something different?

The AUWG could discuss this (WCAG has baselines, which are comprised of 
technologies - WCAG definition).   I think we would need to include any 
prerequisites/requirements necessary in order
to successfully accomplish the technique (may relate to the AUWG 
discussions on definitions of terms?).


> > Description (using -ing language to emphasize their informative nature?)
>
>OK
>
> > Examples
>
>OK - do you see keeping the iconic labels for tool function on these?

The AUWG could discuss.   What unique purpose (not served by anything else)
do the labels serve?   Are there any disadvantages to use of such labels?
Would they be confused with icons?    QASpecGL talks about labels for each
part of the conformance model (ATAG2.0 has Levels A, AA, AAA)


> > Resources
>
>OK - I'm assuming this would appear at our discretion since it could get 
>very repetitive - remember, we have a lot of techniques compared to WCAG 
>HTML techniques document.

Yes, at our discretion.  I think that to successfully accomplish a 
technique, if an offerer wants to find out more
information in relation to such accomplishment, and such relevant 
information (approved by the AUWG according to criteria set) is available, 
then that information should be referenced from that
technique.


> > Testing Information relating to this technique
>
>OK - this will be valuable
>
> > User Agent Notes
>
>The explanation says: "Which user agents could support successful
>accomplishment of this technique" - but aren't the vast majority of 
>techniques more or less user agent independent.

The AUWG should discuss - I think a goal for "general" techniques is to 
make them independent of any such requirements (wider applicability?), but 
if there are "technology" (user agent or other) limitations/constraints 
applicable to a technique, we should make those known (technology-specific 
technique?)


> > See Also
>
>Maybe Resources and See Also could be rolled together?

Sounds good.


>Cheers,
>Jan
>
>
>Tim Boland wrote:
>>Following is: (1) a very rough draft of introduction text to ATAG2.0 
>>Techniques Document (my action item from Nov 7 AUWG teleconference), and 
>>(2) a proposed example techniques format for consideration (I believe 
>>techniques should to some extent have a consistent format).   Both of 
>>these proposals are modeled along the lines of the current WCAG approach 
>>to referencing supporting documentation for WCAG2.0.   Comments 
>>welcome.   Perhaps we could use the following as a guide when 
>>reviewing/creating the techniques to accompany the "reworked" ATAG2.0?
>>Notice that the word "conformance" is not used anywhere in the text 
>>following, to emphasize that these documents are informative.
>>Motivation is partly that we may take advantage if appropriate of 
>>discussions that have already occurred in the WCAG WG, and differ only 
>>when we need to..
>>------------beginning of Introductory Text proposal------
>>ATAG2.0 Techniques Introduction:
>>This informative document lists techniques considered by the AUWG to 
>>support both the (link) normative ATAG2.0 success criteria and authoring 
>>tools accessibility.   The techniques in this document are just listed, 
>>in sequence, without any particular ordering or ranking within a 
>>particular category.
>>For techniques to support the ATAG2.0 success criteria, (it is a goal 
>>that) for each ATAG2.0 success criterion, at least one related technique 
>>is listed that has been determined by the AUWG to be
>>"sufficient" to be included as a description of how the authoring tool 
>>meets that ATAG2.0 success criterion (ref. #5 of sec 2.2.2 ATAG2.0 
>>WD).    Such inclusion does not imply that said description will be 
>>verified or is verifiable; "sufficient" means that, in the consensus 
>>opinion of the AUWG, demonstrated successful accomplishment of that 
>>technique(s) (possibly in combination with other techniques) can be used 
>>as evidence of satisfaction of that success criterion, in the sense 
>>mentioned previously.   There is no requirement (nor suggestion implied) 
>>to use any of these techniques for such purposes.   The purpose of 
>>listing these techniques is to give additional information (options) for 
>>consideration to those authoring tool developers that wish their 
>>authoring tools to satisfy the stated ATAG2.0 success criteria but may be 
>>unsure as to how to get started in attempting to achieve such satisfaction.
>>Other techniques (not in this document or known by the AUWG) may also be 
>>"sufficient" to meet the ATAG2.0 success criterion, in the sense 
>>described previously.   A technique does not need to be known or 
>>documented by the AUWG in order to be "sufficient" in meeting ATAG2.0 
>>success criteria, and any authoring tool developer can claim any 
>>technique (or combination of techniques), as sufficient to meet the 
>>ATAG2.0 success criteria    The AUWG encourages these other techniques to 
>>be submitted for possible inclusion in this document as "sufficient" 
>>techniques in a future version of this document.
>>In addition to "sufficient" techniques mentioned previously, additional 
>>advisory techniques or other information could be listed that goes beyond 
>>what is required by the ATAG2.0 success criterion but may support 
>>authoring tool accessibility.  These techniques or other
>>information would be clearly identified as advisory and would be 
>>separated from any "sufficient" techniques.
>>  Thus, for
>>each ATAG2.0 success criterion, there could be two categories of 
>>techniques:  "sufficient" techniques, and advisory techniques or other 
>>information.    (**NOTE: Optional?: Each of these categories may have in 
>>turn two parts: generic (technology-independent) techniques, and 
>>technology-specific information (techniques).   Generic techniques are 
>>strategies for authoring tools that are technology-independent, but are 
>>realized (implemented) in technology-specific techniques applicable to 
>>combinations of specific authoring tool technologies.**)
>>In this document, each technique is described as follows:
>>Technique Title (possibly referring to stated success criterion)
>>Technologies required by the technique and technology features for which 
>>the technique is applicable
>>Description (using -ing language to emphasize their informative nature?)
>>Examples
>>Resources
>>Testing Information relating to this technique
>>User Agent Notes
>>See Also
>>(NOTE: This sounds like metadata, doesn't it?).    Perhaps we should use 
>>metadata terms to describe
>>the techniques.
>>-
>>Technology-Independent (General) Technique for Success Criterion A.0.1
>>      "Sufficient" Techniques:
>>       Advisory Techniques and Other Information:
>>Technology-Specific Techniques for Success Criterion A.0.1
>>       "Sufficient" Techniques
>>       Advisory Techniques and Other Information
>>(NOTE: There may be some redundancy in the previous.. Perhaps 
>>"technology-independent" and "technology-specific" items can be collapsed 
>>somehow, as this may be too much?)
>>---------------------------------End of Introductory Text 
>>Proposal--------------------------
>>-------------------------------Beginning of "reworked example technique" 
>>proposal----------------------------
>>Example of Technique Format (taking "Technique A.1 as an example?)
>>Title: Technique A.1 (rename to fit applicable success criterion?)
>>Technologies Required: ?
>>Description: Following the guidance of ISO16071.  NOTE: May want to 
>>indicate why this is considered "sufficient" for meeting SC A.1.1?
>>Examples: taken from ISO16071 points?
>>Resources: complete reference to ISO16071
>>Testing information related to this technique: to be provided?
>>User Agent Notes: Which user agents could support successful 
>>accomplishment of this technique?
>>See Also: any other information pertinent to this technique?
>>-------------------------------end of "reworked example technique" 
>>proposal----------------------------
>>
>>Thanks and best wishes
>>Tim Boland NIST
>
>--
>Jan Richards, M.Sc.
>User Interface Design Specialist
>Adaptive Technology Resource Centre (ATRC)
>Faculty of Information Studies
>University of Toronto
>
>   Email: jan.richards@utoronto.ca
>   Web:   http://jan.atrc.utoronto.ca
>   Phone: 416-946-7060
>   Fax:   416-971-2896
>
>

Received on Wednesday, 16 November 2005 14:51:54 UTC