- From: Gregg Vanderheiden <gv@trace.wisc.edu>
- Date: Mon, 27 Jan 2003 19:23:51 -0600
- To: w3c-wai-gl@w3.org
- Message-id: <006601c2c66b$eaf74870$ac17a8c0@TOSHIBATABLET>
Hi All,
I think the following items should be resolved prior to posting to TR.
Suggested solutions are provided for all issues to facilitate this.
ISSUE #1:
3.2 bullet 2 reads
* - A separate Core Techniques document that will provide
information that is too specific for WCAG but not related to a specific
technology must be included.
We had discussed that core techniques would be included in the technology
specific docs - and that a separate core checklist (and therefore techniques
doc) was not probably correct. If you look at all the items carefully you
will find that they are inconsistent unless there is no core techniques doc.
For example
- if all checklist items are also in the techniques doc.
- And all success criteria are addressed in a checklist
- Then there are NO success criteria that are addressed by anything
outside of a techniques doc.
So there can't be a core techniques doc - or at least not one that addresses
any success criteria.
If there is some common language that would be "core" and appear in all the
techniques docs as a section, then perhaps we should call it "core module
for techniques docs". Also should remove the word "separate".
Hmmmm
Which success criteria would fall into this core module?
If the core techniques doc is just advice on how to do things (that are NOT
success criteria, then perhaps it should have a different name than "core
techniques". Maybe it should be "Implementation advice" Doc and have such
things as "how to write good alternate text formats or visual descriptions"
etc. Section 3.4 talks about this type of thing.
SUGGEST:
We do one of two things.
1) Either remove of this bullet. If we determine that there is a way or a
need then we can always create a Core Techniques module. But unless we can
address the above issues, I think we should remove the bullet for now.
OR
2) Reword the bullet as follows.
* Some techniques would appear in all (or most all?) technology
documents. A "core techniques" module or source document could be
maintained to draw common techniques from for incorporation into the
different technology specific techniques docs.
ISSUE #2
The middle of this sentence does not make sense to me.
* Techniques must state to which versions of the technology they
apply, that is, describe a practice to avoid or that will have a positive
accessibility impact. They may specify all versions, all versions prior to
or later than a particular version, or enumerate particular versions
SUGGESTION: Delete "that is, describe a practice to avoid or that will have
a positive accessibility impact"
ISSUE #3
I don't think we can go with the following approach. If you follow the
logic through, you can have a page meet the technology specific checklist
and not be accessible (not meet the guidelines).
* For a given technology, it is not necessary to provide Techniques
for every Checkpoint if the Checkpoint is not applicable to the technology,
either because the technology is designed to be used with another technology
(e.g., HTML and CSS) or because it is not possible to achieve full guideline
conformance with the technology. In place of a Technique there must be an
indication that states whether the technology is intended to interact with
other technologies to provide full guideline conformance, or whether it is
not possible to achieve guideline conformance for the technology for that
Success Criterion. In the latter case, outputs must prominently state that
full guideline conformance is not possible with the technology.
This can be fixed by adding the following to the first sentence,
* "But the technology specific checklist must include a checklist
item for every success criteria of every checkpoint, whether the technology
supports or requires the technique or not."
ISSUE #4
The 6th bullet under 3.2 reads
* Techniques may describe practices that are not yet supported by
user agents, authoring tools, etc. in order to provide guidance for tool
developers. When possible Techniques should also describe practices that
work in contemporary tools.
I agree that it would be good to include techniques not yet supported.
However, I am confused as to how we could put out guidelines that don't
include techniques that could be done today. If we don't list any
techniques for accomplishing them today then we need to say quite
specifically that "WCAG 2.0 cannot be met with this technology at this
level." (Whatever level the item under discussion falls.) This should be
added to the bullet to make it clear that techniques that can be done today
will be provided for all checkpoints that can be met today by that
technology. (see also ISSUE #3)
Perhaps something like:
* Techniques may describe practices that are not yet supported by
user agents, authoring tools, etc. in order to provide guidance for tool
developers. Techniques must however describe practices that work in
contemporary tools. If techniques do not exist that will work with this
technology and contemporary tools, then the Techniques doc and Technology
specific Checklist will clearly state there are no techniques known by the
authors for meeting WCAG 2.0 at the XX level with this technology.
ISSUE #5
In section 5 checklist requirements there is a Note that reads..
* Normally, a Checklist view will include content drawn from
multiple Techniques document sources as described in
<file:///C:\Documents%20and%20Settings\vander.TRACECTR\Desktop\wd-wcag2-tech
.html#scope#scope> 3.2 Scope of Documents. Each Success Criterion would be
met by Techniques drawn from one or more of the source documents but not
necessarily all. For example, a Checklist describing HTML and CSS may
indicate that some Success Criteria are met by HTML and others by CSS.
This seems to imply that there will be an HTML techniques doc and a CSS
techniques doc. Since the checklists are derived from (and contained in)
techniques docs, this would imply that there is a CSS techniques doc with
checklist items in it - but not checklist items for all of the success
criteria (at each or any level) . I don't believe we can have a CSS
checklist (and therefore should not have a CSS techniques doc). CSS is part
of HTML just like GIF, and JPEG etc. It should not be thought of as separate
since you cannot make it accessible.
If we start having 'checklists' that draw from different techniques docs, we
will make it possible to have a checklist for a technology that cannot be
accessible but points to other technologies in order to meet specific
checkpoints - when that does not work in reality.
Suggest removing the bullet comment for now.
ISSUE #6
SECTION 5 BULLET 3 READS
* Checklists should be constructed such that all items in the
checklist for a given success criterion must be marked true in order for the
content to conform at any conformance level.
The phrase "for a given success criterion" should be " for a given
conformance level" and "any" changed to "that " so it reads
* Checklists should be constructed such that all items in the
checklist for a given conformance level must be marked true in order for the
content to conform at that conformance level.
ISSUE # 7
Suggest adding two more bullets in section 5 that read
* Technology specific checklists may be derived from the Techniques
Doc (or both from a source doc), but the TS Checklists should be
downloadable as a separate, short document containing only the checklist.
* Technology specific checklist documents would be available (and/or
viewable) that show:
o only checklist items for Minimum success criteria,
o only checklist items for Minimum and L2 success criteria
o checklist items for all success criteria
so that authors can obtain a checklist document that contains
only the checklist items for a given level if they so choose.
Appendix A might also include a bullet that says.
- Checklist docs by conformance level
COMMENT #1
IN SECTION 5 BULLET 4 THERE IS A NOTE THAT READS
Editorial note: Michael Cooper 2003-01-15
This relates to the open issue in 3.2 Scope of Documents that we haven't
decided whether to permit Techniques documents to be created for
technologies that cannot be WCAG conformant.
This looks like it refers to an issue in section 3.2 that has been removed.
SUGGESTION: we pull the note
Whether we allow techniques documents to exist that do not meet WCAG or not,
others will use our format and they may do them for techniques that do not
meet all the WCAG minimum. So we should keep this in our rules to prevent
the creation of misleading techniques docs following our model.
Thanks for pulling this all together Michael.
Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.
Professor - Ind. Engr. & BioMed Engr.
Director - Trace R & D Center
University of Wisconsin-Madison
-----Original Message-----
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On Behalf
Of Michael Cooper
Sent: Friday, January 24, 2003 8:38 AM
To: WAI GL (E-mail)
Subject: [techs] Techniques Requirements v0.5
Attached is the Techniques Requirements updated to reflect the discussion on
January 23, we'll get it posted to the same URL as the previous drafts soon.
I believe this incorporates all the resolutions from the discussion on
Thursday. Thank you everyone for the productive meeting, I think this
document is in much better shape now.
According to our plan, this document is open for review until Tuesday,
January 28. At that time if we don't receive any serious concerns we will
begin the process of publishing the document to TR as a Working Draft. This
will allow us to set the Requirements aside and begin working on the next
stage of Techniques development.
Beyond substance comments, I also welcome editorial comments. If I get
energized I may make some editorial changes, such as making consistent the
use of "will", "shall", "must", etc. I promise not to intentionally change
substance and if I do make these changes I will distribute the revised
version on Monday so there's a brief time to catch any issues created. If
you prefer that we not take the risk of making editorial changes on this
short timeline, please let me know.
Michael
Michael Cooper
Accessibility Project Manager
Watchfire
1 Hines Rd
Kanata, ON K2K 3C7
Canada
+1 613 599 3888 x4019
http://bobby.watchfire.com/
Gregg
-- ------------------------------
NOTE: TRACE IS MOVING TO NEW ADDRESS
(Same Email and Phone)
Trace R & D Center
2107 Engineering Centers Bldg.
1550 Engineering Drive
MADISON, WI 53706
------------------------
Gregg C Vanderheiden Ph.D.
Professor - Human Factors
Depts of Ind. Engr. & BioMed Engr.
Director - Trace R & D Center
University of Wisconsin-Madison
Gv@trace.wisc.edu < <mailto:Gv@trace.wisc.edu> mailto:Gv@trace.wisc.edu>, <
<http://trace.wisc.edu/> http://trace.wisc.edu/>
FAX 608/262-8848
For a list of our listserves send "lists" to listproc@trace.wisc.edu <
<mailto:listproc@trace.wisc.edu> mailto:listproc@trace.wisc.edu>
Received on Monday, 27 January 2003 20:23:55 UTC