Re: Agenda - Late Regrets

Regrets for today's meeting.  Putting the pieces back together and summers
off will make my involvement a bit scattered this summer (summer where I
am).  Hopefully, I'll be with you all next week.  Take care.

Doyle Burnett

Special Education Service Agency
www.sesa.org

----- Original Message -----
From: "Jason White" <jasonw@ariel.ucs.unimelb.EDU.AU>
To: "Web Content Guidelines" <w3c-wai-gl@w3.org>
Sent: Tuesday, June 03, 2003 4:23 PM
Subject: Agenda


>
> Thursday, 29 May, 2000 UTC (4 PM US Eastern, 10 PM France, 6 AM
> Eastern Australia) on +1-617-761-6200, passcode 9224.
> IRC: irc.w3.org 6665, channel #wai-wcag
>
> Background: the purpose of the next two meetings is to prepare a draft
> of the reorganized 2.0 guidelines for publication on the W3C's
> Technical Reports page, in order to solicit public comments. Your
> Chairs and editors have identified the following major issues as
> requiring attention before a draft can be published:
>
> 1. Classification of checkpoints flagged by question marks in the
>    current draft, into "core" or "extended" categories. The presently
>    accepted principles
>    for determiing whether a checkpoint belongs in "core" or "extended"
>    are summarized at
> http://lists.w3.org/Archives/Public/w3c-wai-gl/2003AprJun/0187.html
>
> 2. For purposes of the TR draft, what should we include in the
>    "conformance" section? A proposal is expected to be posted to the
>    list before Thursday's meeting, based on the conformance section of
>    earlier drafts, but with adaptations to take account of the new
>    categorization scheme.
>
> 3. Any other issues.
>
> Note that for purposes of circulating a draft for public review, it is
> less important to achieve consensus regarding which items belong in
> "minimum success criteria" vs. "best practice". Nevertheless, if there
> are any obvious problems or inconsistencies that can be resolved
> easily, they should be addressed.
>
> For reference, here are the working principles by which the group has
> agreed to be guided in classifying checkpoints, success criteria and
> "best practice" items. It was acknowledged at last week's meeting that
> these principles may be amended in the future should the need arise,
> but only as a result of conscious deliberation on the part of the
> working group.
>
> The following are taken from Gregg's summaries:
>
> A checkpoint belongs in the core if the following requirements are
> met; otherwise it becomes an extended checkpoint:
>
> GP1 - the checkpoint doesn't prescribe the default presentation or
> expression of the content.
>
> GP2 - the checkpoint could be applied to all types of content and sites
>
> - (we don't want to have a required (core) checkpoint that
> can't be met by some types of sites or they will not be
> able to claim any conformance.)
> - (in some cases we put in exceptions so that the
> guideline (with the exception) could be met by all.
>
>
> Minimum success criteria vs. best practice vs. techniques:
>
> - All minmum items must be testable.
> - All minimum items on the CORE checkpoints must be doable on all sites.
>
> - The minimum items for the Extended checkpoints would not necessarily be
> doable on all sites, but it would probably be good - so that sites could
> strive for meeting them all.
>
> - The Best practice items do not need to be reliably testable.
> However, we want to track the different items and mark them as [TESTABLE]
if
> they are testable.
>
> - it was not clear to the group if there should be just two levels
(minimum
> and best practices) or if there should be three (with a second testable
> level after minimum).   We are therefore holding this issue open and using
> the [TESTABLE] marking technique so that we can go back later and examine
> this issue after we have reviewed the reorganization and all of the items.
> The concern is that if we put everything in best practices (that cannot be
> claimed in conformance) then it is less likely that they will be picked up
> in 'required' practices (since they will not be testable or reportable).
>
>
>
> TECHNIQUES VS BEST PRACTICE ITEMS.
>
> - There is also a question of the line between the 'best practice' lists
and
> the techniques docs.    I think we will need to have some in but don't
know
> where the line is.   Maybe we don't put techniques in except where there
are
> no hard guidelines or much more than a general guideline possible. So the
> techniques are needed to provide guidance and clarity.
>
> Perhaps we could say that an item goes in "best practice" rather
> than techniques if all or most of the following requirements are met:
>
> 1. Following the "best practice" item would significantly enhance the
>    quality of implementation of the checkpoint, or substantially
>    improve the accessibility of the content.
>
> 2. The "best practice" item is always, or almost always applicable
>    whenever the checkpoint is - in other words, it is relevant in most
>    circumstances under which the checkpoint is to be implemented.
>
> 3. The "best practice" item is not technology-specific.
>
> 4. The "best practice" item would only be used in content targeted to
>    the needs of a particular audience, that is, it carries
>    implementation of the checkpoint to the highest standard.
>
>
> This questions is still open and we currently are holding this until we
can
> review the re-org
>
>

Received on Thursday, 5 June 2003 14:55:01 UTC