Minutes for July 5, 2001 conference call

Web Accessibility Initiative
Web Content Accessibility Guidelines Working Group
Conference Call
July 5, 2001

JW; Jason White
KHS: Katie Haritos-Shea
CMN: Charles McCathieNevile
GR: Gregory Rosmaita
CS: Cynthia Shelly
MM: Matt May
PB: Paul Bohman
JI: Jeff Isom
GV: Gregg Vanderheiden

AGENDA: 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.)

ACTION ITEMS:
GV: review the sufficiency document and pull out the items that seem to be
rules vs. those that are more example-like.

RESOLUTIONS:
Incorporate the sufficiency criteria into the document and post it to the
mailing list for further discussion and debate.

// Minutes by Paul Bohman //


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 of
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.

Received on Thursday, 5 July 2001 17:21:44 UTC