Sufficiency criteria proposal by JW. (The second item, the Techniques document by MM, was discussed well on the list, so was skipped in this meeting.)
CS: Will chase up the earlier work done on the future of web-technology (flow charts), done by Jason, Cynthia and Lisa Seeman. Cynthia will make suggestions as to where this information would be best in the document. Introduction, server-side techniques or elsewhere?
GV: Review Jason's Sufficiently Criteria to see what can be moved to the requirements and what can be dropped.
Resolution: Incorporate the sufficiency criteria into the next draft of WCAG 2.0 (due out end of July) document. Repost to the list Jason's proposal, get one round of comment, discussion and debate, then put them into the document to see them in context.
JW:Opening comments. Discussion of sufficiency criteria (from F2F meeting). I have decided that it is time to move from discussion to proposal. See the distribution to the list. This is my proposal, despite its current weaknesses. The AT group has moved down a similar track in their own work, so this is not unprecedented.
CMN:The user agents group did it first, and we got it from them.
JW:Any strong reactions? Or not-so-strong reactions? At the checkpoint level?
CS: It's easier to understand specifics than generalities. Charles posted something about the Wombat format. Are we going to incorporate this format?
CMN: I'm trying to work on the "old stuff".
CS: I think that using the Wombat format would be a splendid idea.
GV: Did you put the sufficiency criteria in the normative document?
JW: He did.
GV: If there is such criteria, that's different than compliance criteria.
CMN: The normative doc has the minimum.
GV: Sounds like the sufficiency criteria are checkpoints. Or are there "either or" scenarios?
CMN: Some are "either or".
GV: If those are required elements, they would not be sufficiency criteria. They would be the minimum requirements. They would be checkpoints. When I think of sufficiency, they are items that may not be required. They are examples of things that satisfy. Some of the sufficiency items could be well above the requirements.
JW: What I wrote was more along those lines, but some of them could be taken as required.
GV:You don't have to do these things, but they are known ways of accomplishing the goal. The problem with putting them in a sufficiency document is that they are taken as normative.
CMN: The AT group is to establish these things as the bar you must cross. They are normative. Then we have another part of the document that talks about how a good tool would accomplish the task (as opposed to a barely good enough one). The techniques document has more details. We have an evaluation techniques document to determine whether or not you have met the requirements.
JW: Let me point out that I wrote them in a hurry, which is why they're rough. I used the word "must" rather carefully. There is some indication of which way the different items should fall, but these ideas are preliminary. We have some issues to decide. Do we regard them all as "sufficiency" or "minima" and do we want them included in the document? Then we have issues surrounding the specifics.
GV: I think it's a good idea, but I don't think it should be in a normative document, but I'm not sure where it should go. Having it normative prevents you from adding additional items as they come up. Some items are difficult to define a sufficiency criteria.
JW: If a requirement is the only way of knowing about compliance, should they be marked as normative?
CS: Some things are "unstable" in the techniques document, while some other things are more stable.
JW: We don't want to say that these methods are the only way of accomplishing the goals, but they may be the only known ways at the moment.
CS: It seems that some of these things are stable enough to be in a normative document.
JW: That was the intent.
CS: Did you have specific items, Gregg, that you were concerned about?
GV: Just a generic concern. There is no mention of the word "sufficient" in the UA or AT guidelines. They use the term "minimum requirements." We have to make sure that the word "sufficient" is not misunderstood. Even our own workgroup has trouble understanding what that term means.
JW: Issue 1: Should they go in our document set somewhere? Issue 2: Whether they should be viewed as examples or requirements.
GV: I would like to say very strongly that they are not requirements. I think that a good home might be in the guidelines if it doesn't make them too long. My reasons: it serves to make it clear what you're talking about. It provides illustrations and examples. Also, it allows us to put in examples of solutions. If our solution doesn't work for them, they can come up with their own. Additionally, it allows us to put in more specific language. This technique allows us to keep a generic guideline, and at the same time provide a solution that we like, but it isn't written in stone.
GR: At the F2F I suggested that we very clearly mark the technological assumptions for each solution and technique. When giving guidelines about images, we tell them about the "object" tag, and how to use it, and where the tag is supported. At the techniques level people are making decisions about where and when to use the particular technique.
JW: This is a little bit off topic. We'll keep it in mind for future discussions. At the checkpoint solution are specific to technologies and so forth, but at the checkpoint level they are not. In some cases it wasn't obvious what the solution should be, so I wasn't able to draft things the way that I wanted.
CS: I think you did a good job. In several places it has conditional statements that leave things open for interpretation and discussion. It's easier to evaluate things in context, rather than separate.
GV: We are supposed to publish one to the public at the end of July.
GR: I think we need a draft up soon.
GV: I think we should stick the comments in so that people can find them and see how it flies.
JW: Gregg, do you want to fix the obvious shortcomings or wait 'til Wendy gets back?
GV: Let's make a post to the list that says we'll be putting these in for evaluation, but ask for comments from the list, so that we can get one round of cleanup. Sometimes it's necessary to stick them in the document before anyone gives any comments.
JW: I'll do that this morning after the call, with the note attached. Cynthia likes them, so that's a good starting point. OK. we'll invite everyone to review them on the list and beforehand. Everyone will have a chance to look at them. Cynthia, were there any that you would want to fix?
CS: I only read through it once, and nothing looked particularly problematic. I liked the reading level part.
JW: That will be controversial
CS: We need to define the thresholds
JW: I might ask for suggestions in that area when I put it to the list.
CS: I think we need to clarify 1.5 and 1.4 and how they related to server-side solutions and/or techniques. It seems to imply that everything has to happen client side. This merits further discussion.
JW: There was a previous proposal to write our view of how the processing and the client-server relationship would effect accessibility, and the effect o the relationship.
CS: Let me take another look at that and see if I can incorporate the ideas in the server-side documents.
JW: Something of that sort deserves a place somewhere. Look at it, Cynthia, if you can find it.
CS: I still have it in my mail somewhere.
JW RESOVLVED: we'll put the sufficiency criteria out to the list, and incorporate them into the document for further discussion and debate.
GV: Some of the items seem to be rules restated. You said checkpoint 1.1. "requirement", and 1.2 you said "sufficiency criteria". Sufficiency criteria are different from sufficiency examples. These seem more like criteria.
JW: We need to decide for the next draft how to treat those.
GV: I think we ought to provide more examples with descriptions, rather than requirements. These seem to be sub-requirements, as I read them. The reason I bring this up is because it may be good to have examples, but if what is written here are absolute requirements, do we want to leave them here or make them examples.
JW: Yes, that remains to be decided.
[Cynthia leaves the call]
JW: For many of these things, I consider them necessary in order for a person to consider himself as complying. I don't see any other way to comply without meeting these criteria. But some of them were not requirements. When writing this draft, I used the words "must" and "should" rather deliberately to distinguish these items.
GV: Then we ought to walk through these and pull things out of the sufficiency category and stick them into the rules. Some of your others are clearly sufficiency items, when you say "do one of the following", for example. We need to sort them out and label them.
JW: Do you have the time to look at these?
GV: Don't give me an action item, but I will look at them.
JW: Anyone else want to look at these things?
GV: I'll take it as an action item.
JW: We'll put it as an action item with no time limit.
CMN:Let's put a 2 week limit on it.
GV ACTION ITEM: review the sufficiency document and pull out the items that seem to be rules vs. those that are more example-like.
JW: We can label them appropriately when they go into the draft. Wendy might have time to look at it before putting it into the draft too. Any other issues with this?
[none]
JW: The AT document can be looked at for more ideas.
CMN: The AT work is all public, and comments are welcome all the time. We hope to put out a public working draft in the next couple of weeks.
JW: I think we've covered what we need to. Adjourned until next week.
Thursday, July 12th, 2001 @ the usual time. (20 hours UTC (4:00 to 5:00 PM ET))
Telecon Details: All WCAG 2.0 conference calls are on the Longfellow bridge
+1-617-252-1038.
Meetings are held Thursdays from 4:00 to 5:00 PM ET (although may run
until 5:30 depending on the discussion).
Last Updated: $Date: 2001/07/06 18:30:53 $
by: Katie Haritos-Shea@Work or Katie Haritos-Shea@Home