Minutes from AUWG telecon, 2 June 2003
Attendance
jr Jan Richards
jt Jutta Treviranus
hk Hazel Kennedy
kb Kynn Bartlett
mm Matt May
pj Phill Jenkins
Minutes
Kynn's strawman proposal
kb: I did an ATAG review of my blogging tool. While doing that, I thought about reshuffling the document. I looked at the WCAG 2 January draft. I'm looking at this in terms of how we can structure the ATAG draft.
kb: I expect this to be a strawman to stimulate discussion, not to be adopted outright. I noticed that Guideline 4 ended up disappearing because it was commentary on how to deal with the other guidelines.
jt: At one point we considered removing G4, but the reason we separated it was specifically for evaluation criteria. It's one thing to do an item, and another thing to evaluate it.
kb: I took the WCAG concept of various levels of conformance. It's interesting to note that some checkpoints are progressions, and others are not.
pj: For example Checkpoint 2.2?
kb: Yes. On a simple level, concepts like maintaining a registry of alt text. Some are advanced along those lines that we call P3, and some that are not. The author has to be able to put that text in, and you have to help by filling it in where possible, and ensuring that it's correct.
pj: I think the WG thought about that a bit in the first draft, but not quite the way you're proposing. A question: Are you proposing that everything has a minimum checkpoint?
kb: I think that's one of the weaknesses of this type of approach, because you sometimes have to create weak requirements in between.
pj: We have some requirements that are major, like including evaluation and repair.
kb: It's hard to draw a line and say that Tool A doesn't have to do this, but we think Tool B does.
jr: We have groupings of tools that define these.
kb: So if the author of Kung-Log says, author your content, then run Bobby, is that good enough?
mm: We have a section that states "make sure that accessibility is a natural part of using the tool".
kb: Some of these items are non-trivial. Does everything have to match up with A-Prompt on an integrated level?
jt: You're looking for further applicability statements?
pj: Under checking, is repair a P3 extension of that axis, or where?
kb: Does ability to edit source count as repair?
jt: It's "assist authors in creating", so I wouldn't say that's assisting.
kb: So, a tool that will identify errors will need to do something more than say "edit this part"?
pj: Has to be more than just user-initiated help. I think we made that statement.
kb: Another problem that we have on WAI documents is that sometimes we focus on things that we see as atomic, but aren't. Sometimes we hide the fact that they're a tree of concepts. It may be easier to think of checkpoints in that way. I think we have to make sure we don't create requirements that vendors jump through only to satisfy ATAG.
jt: Given that these are printed documents, we have some constraints on how they're presented. Any ideas?
kb: Better ways to group the checkpoints together.
jt: Any that you think aren't grouped properly? Orphans?
kb: In the case of 3.4, it seems to come almost out of nowhere. It may go better after 3.5. At the very least, referencing pre-authored content should go after it.
jr: It's kind of splitting hairs, because 3.5 talks about managing alternatives where 3.4 does not.
pj: It's a way of saying, "we mean this, but we don't mean that." That happens in some documents.
kb: Sort of derails things, but it's okay.
pj: If there's a way to summarize the checkpoints to explain why they're ordered in that way.
kb: If I inserted "however, do not do x", that helps me to understand how this is connected with the rest. Important for understanding the relationships between checkpoints and guidelines. You don't expect 3.4 to be a commentary on things that go before or after it.
pj: 3.1-3.3 build on each other. Then 3.4 says, "but don't do x". Could be good to have a "how to use this document" section.
kb: That would be valuable to the developer, since developers like thinking in logic trees.
pj: Then you can say that if you've done this, then you've done these checkpoints.
kb: About 3.5: Consider generalizing it a bit?
pj: Could make it another relative priority. (laughs) It'd be nice to be able to say, apply the same logic to the next table as you did the last one.
jr: That's asking more than this asks them to do.
jt: Another repair strategy?
pj: More for reusing content.
jr: I see your point. I think we should be clear that this is something that would be great, but isn't a part of current practice.
jr: 3.5 links with 2.6 on preauthored content.
kb: For 1.1, I had a hard time figuring out if the app met the OS guidelines. I don't know at what level checkpoint 1 was or wasn't satisfied.
jr: That's a tricky one.
pj: I was going to propose that we adopt one policy, like 508.
kb: TOC needs links.
jr: We're going to do a reference document to WCAG which will define what we mean by our priority.
mm: Need that level of abstraction because of existing policies regarding WCAG 1/2, and to make sure we can progress even if WCAG is not.
kb: Is "accessible authoring practices" defined?
jt: It has a definition, but may need to be defined further.
kb: 2.1, what does this mean? It seems like it belongs lower in the logical tree.
jr: If you're making an authoring tool, you decide what you want to output first, so it makes sense in that context.
kb: You may want to talk about "output", instead of "use". "Use" is too vague.
jt: There are W3C Recs which don't necessarily dictate output.
kb: Are we saying in here that HTML 4.01 should go away in favor of XHTML 1, since it's been out for 3 years?
mm: I think HTML 4 and XHTML 1 will be coexisting for the next 8-10 years.
jr: Perhaps we should say that if you cover the older spec, that you should cover its revisions as well?