LS: What were the criteria for dividing into success criteria vs best practice? This isn't in the document
GV: We are still working out the exact principles. We are first trying to decide whether this organization is desirable. We thought the group ought to be sorting out what belongs where.
LS: I really like the structure. We might work on the wording "best practice", and there are specific items I want to discuss. But I like the overall organization
GV: There has not been a lot of discussion on the list. Either people like it in general, or people don't like it and aren't sure how to express that. Can we go around the group and poll the present company?
ASW: I've been comparing to the core and think we will uncover some issues, but I like the restructuring.
JS: I like the direction of the proposal; it has come a long way since the F2F in March. There are still specific issues, but this is the right direction.
KHS: I like it a lot. Better, clearer, very much in the right direction. My question is how this affects the priority levels and all that stuff?
??: It is being trapped in some of the old ways of thinking, just because we keep using the same language
MC: I had questions about priorities, as well. Most guidelines refer to best practices, but some talk about group 2. There are some details we'll need to iron out. What are the extended checkpoints?
GV: The Extended Checkpoints is identical to Group 2.
JS: And Group3 contains the original Group2 and Group 3.
GV: And we left to another time whether to break them up further. When we talk about priorities, we'll discuss this some more.
LS: The structure seems to work because we got rid of the fuzziness between priority level 2 and 3. It is easy to determine what is minimum. We've given ourselves more flexibility with extended checkpoints. But less fine tuning.
GV: It does make it easier to talk about.
CS: In general, I think the reorganization is good. I'm still concerned about the 2 groups vs 3 groups. Are the freedom of expression issues reflected in these choices? It seemed like several were trying to address this.
GV: We were trying to look at that. That is one reason the epilepsy checkpoint ended up in the extended checkpoints.
MM: I've looked at this and I really like this direction. I like the fact that there are fewer levels of conformance. Our experience when people say they are AAA is that it is open to much interpretation. Separating things that can't be objectively measured into a style guide is the right way to go. The conformance on individual resources can be done using the minimum checkpoint. We can put the rest together into "WCAG Style".
GSW: Are the minimum success criteria the things that can be tested and that don't change the default presentation of the content?
GV: All the the checkpoints have to be things that can be tested. Qualifications for the core were that they did not dictate how you did your material. You can't say it has no effect, since using accessible technologies will have some effect.
GSW: That is what I am most concerned about. We need to investigate whether that conforms with the spirit of the guidelines. I don't want to publish a second version of WCAG and find that it doesn't help a number of people with disabilities because we won't tell the author to alter their content. I think we need to discuss this further.
GV: So this isn't organization, but what is core vs extended. The question "Should we tell authors how to do their materials if it will make it more accessible" should be an open issue.
**GV addressing questions that emerged in this round**
GV: Core vs extended distinction is the way most of the W3C specs are written. Within each of the checkpoints, there are minimum success criteria, which are required. But there is often a lot more you can do, and they are listed as "best practice". We used that term to give more of a feeling that if you are really good at what you are doing, this is what you do. We can call them something else. But this term seemed more motivating.
GV: Group 2 is what we now call the extended checkpoints. There was a question about 2 vs 3 groups. When we tried to put them into this form, it was really hard to tell where the line was between 2 and 3. In some cases, there were very many more things in one group than the other. I couldn't figure out a clear division, so the first pass was to put them into one group and have us look at it. If you think of core and extended, what else is there?
GV: Conformance and conformance claims. We used to have A, AA, and AAA. It was pretty impossible to get to AAA, so it was nice that there was something beyond A. We discussed conformance + checkpoints as a way to get a finer gradation. I'm not sure how we would do conformance. But it was suggested that we were getting over-fixated on each tiny bit of improvement, and that we should just let people file their conformance claims.
GV: on the topic of epilepsy - people said there are also patterns that can trigger epilepsy. I've been doing more research. There are things that will pass on television but not on the CRT screen. Epilepsy went into the extended checkpoints because otherwise it was going to put strong restrictions on authors.
LS: It is so interesting, the parallel between what you were saying
with epilepsy and the other checkpoint about writing style. There is a
lot of commonality. It all depends on how we are going to define core and
extended. With core we can't think of a legitimate reason people can't
satisfy this. With extended, there may be reasons authors can't. With epilepsy,
there should at least be metadata with a warning. At least people could
browse the web without getting hurt.
GV: That is an excellent point. What if we had required, recommended, and best practice. If we moved epilepsy up to core, and what was required was that it needed to be marked in metadata or it needs to pass the test. You only need to mark it if it is bad. This doesn't require that they change their presentation. Under recommended, you can say don't do these things at all. Under best practice, you could avoid stripes, etc. And with that suggestion, epilepsy could be moved up.
MC: Let me check my understanding: the difference between core and extended is that checkpoints fall into these categories. Minimum vs best practices applies to success criteria, for each checkpoint. Are best practices still expected to be testable?
GV: I don't know the answer to that. It might be that best practice are not testable. We don't want to put techniques here, of course.
MC: As we write the guidelines, if it is possible that best practices are testable, all things testable don't need to be moved to minimum (that is, required).
GV: We did not make it be the case that everything testable is required.
GSW: On the issue of required, recommended, and best practice, aren't we going back to A,AA and AAA?
GV: If you are a country that is going to require certain things, one country may decide to adopt required and recommended, on a checkpoint basis. For conformance you must do the core, and we can decide whether to define other levels.
GSW: With the companies I've worked with, they aim for a certain level, and that has been a good point in working with developers who say this is too hard. We'll lose that leverage.
GV: We could designate 6 levels and lay out the profiles that we think makes sense.
GSW: what kind of profiles?
GV: 1. All the core, 2. All the core and the extended, ...
GSW: Would it be based on certain criteria? general population, or the visually impaired
GV: One of our early agreements was not to have conformance by disability. We can change that, but that is a separate discussion
MM: With respect to the flicker checkpoint, is the core level of WCAG more or less equivalent to 508?
GV: I don't think it will be equivalent, since 508 requires some specific techniques. It is a useful thing to look at, but we shouldn't structure it towards that unless we are going to consider all the other countries, too
MM: There may be a case for defining a compound conformnce, e.g., WCAG + 508. I was happy about seeing 2 levels of conformance, and I'm against the proliferation of levels in that it effectively dilutes the brand. If we are trying to push accessibility as a matter of good citizenship rather than policy, we need a compact, bumper-sticker-like case. If we give an infinite variety of choices, people will say this is not fully baked and wait until things settle out.
LS: How we can define success criteria, and how do we divide things into core, extended, etc. It is important to define them, but what really defines them is common sense. The first criteria is that we want things to be accessible to as many people as possible. The second criteria is that WCAG has to be adoptable. These are in tension,and that is what creates the gray area.
GV: I think you are saying we want to make it as accessible as possible, and the second criteria has to do with what "possible" means.
JW: Regarding Lisa's point, I think the distinctions are correct. It is important that we have the best definitions we can make for deciding whether an item is core or extended. We should also get clear definitions for what goes in minimum vs best practice. As we get further on in the process, the decisions we make about what goes where are going to be placed under pressure. Unless we have fairly good definitions to use as the basis for the discussion, this will be a lot more difficult to respond to. We might not have to divide the success criteria into 3 categories as a surrogate for putting something into core, if we are willing to let a checkpoint have a core portion and an extended portion (or 2 related checkpoints).
GV: Are you suggesting that we have the same checkpoint in core and extended?
JW: Not the same wording. The core part addresses that part of the issue that can be addressed with the constraints of core. The extended checkpoint would address the same issue in the areas that don't fit in core.
LS: I think that is an excellent idea.
CS: One of the things that I like about core and extended sets is that it is a good compromise between the things Matt and Gian talk about of having goals, and the frustrations I had with WCAG1 being so inflexible. It seems like a good solution between the tensions here. Question: were we envisioning any kind of conformance claim about best practices?
GV: In terms of reporting, we need an incremental something beyond minimum. We should have a discussion about this. I had no firm thought on this.
GV: I'd like to walk around and get a Yes or Has Reservations for everyone.
(Gian had reservations.)
GSW: My concerns are what I said before, that if we have a set of extended
and best practice, we don't have a way to push developers to do any more
than the core. The AA logo carries weight with business managers. I don't
see how we can continue this with the current suggestions.
GV: It shouldn't be hard to define AA as all the core and extended
GSW: Then how is it different from A, AA, AAA?
MM: AAA is, for all intents and purposes, unachievable for many sites. If you present varous achievable, coherent sets, you have a better chance at getting real accessibility improvements.
GSW: I remember one site I worked on recently where they had to use table for layout, and they used absolute units. The only way I got them to change that is by saying I would not approve AA since they were violating checkpoints.
LS: Can I make a suggestion? I think a lot of the tweaking we are talking about can be with the wording. We can handle a lot of this types of issues in the presentation. I thought Jason's idea of splitting a checkpoint like the epilepsy one was a good idea.
GV: I don't see that there are any fewer possibilities of having A, AA, and AAA in the new and the old.
GSW: How do we make that coexist with the + conformance proposal?
GV: You can define an A set and AA set, and you can let people define their own, custom conformance claims. We can establish them as we like.
GV: So after this discussion, is it unanimous with the people on the
call today that we move to the new reorganization? <<yes>> We'll
move this to be the new working document. Tentatively, would it make
sense to have required, recommended, and best practice? Then we can see
if it makes sense, and it may help in sorting out some of these conformance
JW: I'd like to see the distinction between core and extension as a major one, and the distinction between minimum and best practice, and I'd rather not complicate it with a third level
GV: Someone mentioned testability. There are a lot of things that it would be nice to add some non-testable items to best practice.
CS: Are these the group C stuff?
GV: No, a lot of that was testable, just hard to do.
JS: I think there will be confusion about why we aren't recommending best practices, etc.
CS: Be very careful in wording. But I think we need to look at specifics.
JW: I also think we should think about the duplicate core/extended checkpoints.
GV: I didn't do that because I think it will confuse people to have two different versions of the same checkpoint.
LS: Considering "Use clear and simple writing", we could divide the "clear" from the "simple", as an example.
GV: Please send any comments on any aspect, so we can try to address
big issues and clear them. Because this is quite different from what we
just posted to TR, we should probably try to clean this up as quickly as
possible and do another TR posting.
$Date: 2003/05/15 22:23:05 $ Loretta Guarino Reid