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
concerns?
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