23 Jan 2003 - WCAG WG Teleconference Minutes


Andi Snow-Weaver, Bengt Farre, Ben Caldwell, Jason White, Lee Roberts, Loretta Guarino Reid, Matt May, Michael Cooper,   Roberto Scano,


Avi Arditti, Doyle Burnett, Cynthia Shelly, Eugenia Slaydon, Greg Vanderheiden, John Slatin, Paul Bohman, Wendy Chisolm


In reviewing the open issues for the Techniques Requirements Document, we concluded that
- Technology checklists should include all relevant items (no indirect references to other documents)
- Developing technology checklists for technologies that cannot satisfy Level 1 requirements might be ok, but only if the document clearly and prominently states that it is not possible to satisfy minimum accessibility requirements.
- Technologies are required to include information about whether or not a technique has been implemented by some user agent. There will be optional fields for user agent issues. However there will be no attempt to maintain a comprehensive database of user agent capabilities.

A revised Technology Requirements Document will be posted tomorrow. Comments are due by the end of the day on Tuesday, Jan. 28.

Action Items

MC: Edit Techniques Requirements Document to reflect decisions from today's discussion amd post to the list tomorrow.
JW:  Check with W3C about whether there any policy issues with letting third parties use our checklist templates for technologies that cannot satisfy Level 1 conformance

Techniques Requirements Document

Agreed Goal: to have all the requirements for a technology in a single checklist.
MC: If you have an HTML checklist, it is only valid if you aren't using any other technology in your HTML page. Otherwise, you need to use a combination checklist.
JW: Can we make adjustments in the requirements wording to clarify this?
MC: This still leaves the question open about whether we want a CSS checklist, even though it is useless without HTML.
LR: For each technology, the techniques would include something about whether that technology can satisfy that checkpoint. This lets us point the author to the necessary additional information.
Action: MC to clarify in Requirements Document.
JW: It is still unresolved whether we want separate checklists for technologies that aren't complete. They only have partial checklists. Greg has been arguing that it is undesirable to have checklists that you can complete, but still not conform to the guidelines.
JW: The other clarification is that we will combine core + technologies checklist to produce complete checklists.
MC: Will we generate these combined checklists on the fly?
JW: We've talked about creating a tool to generate them on the fly. But there may be few enough of them that we should just go ahead and generate them.
BC: Can do this by applying XSLT
JW: We are going to aggregate items from different technologies to make complete lists. (Resolution)
MC: Should this clarification be in section 3.2 or section 5? My initial impulse is to do this in section 3.2. It might be worth stating in the introduction that output can be combined.

MC: Al Gilman's message, which I didn't totally understand, seemed to reflect a misunderstanding of our goals.
BC: He's looking at it in terms of a document you read from beginning to end and adopt as practice. There should be a document that is a primer for how to produce accessible contents, and he wants this to be that document. Something you could build your own best practices document from. There needs to be a narrative explaining what we mean. The document itself is reasonably opaque. We understand it. There needs to be some way to say this is what we mean, in plain English.
MC: We made some conscious decisions about this for the techniques requirement document, so maybe there is room for more clarification. We have already added clarification about the intended audience.
JW: EO will be preparing documents based on the contents guidelines and WCAG will have a role in reviewing them for technical accuracy.

MM: If you are going to have a forum where people can submit techniques, you want someplace where people can explain why.
MC: I'd like some mention of this in the requirements document, just so we don't forget it. Any suggestions for where it goes?

MC: Another broad issue is how we handle non-conforming technologies (those that can't be made conformant, even in combination with other technologies). We could permit the creation of technique documents which include items where we state that a given checkpoint can't be satisfied with this technology. Or we could say that we don't create technique documents for such technologies and discourage third parties from producing them. I lean towards the first approach, since then at least you can document what is possible. I know there is a strong sentiment to enforce complete compliance. We don't expect the initial documents to run into this problem, but as we get into areas like scripting, or if other organizations are going to adopt our methodology, this will be an important issue.
JW: I favor prohibiting them outright. There would be serious concerns about conformance issues, since people would take the existence of a techniques document as a recommendation for that technology. Otherwise, there should be a very prominent disclaimer stating that the technology can't be used to satisfy the requirements.
LGR: What about the user agent requirement, which is time dependent?
MC: This issue only applies to level 1 requirements. That requirement is not a level 1 requirement.
JW:  I think any techniques document we write will satisfy this, so this may not be an issue
MC: But I am concerned about other organizations using our format, and what we tell them. Other W3C groups may also run into this issue
JW: W3C may have policies on this kind of question. W3C policies may prohibit third parties from using our format but not conforming to our guidelines
JW: action item - check with W3C whether there is an issue here
LGR: I have mixed feelings, since I'd rather have something be more accessible, even if it is not completely accessible.
Poll: "Should we allow publication of incomplete technique documents for technologies that can't conform to the guidelines?"
MM: If we can find a way to state authoritatively that these are necessary but not sufficient, it would be valuable to have them. Like VPATs. It helps others more than it hurts us.
JW: You either prohibit them or allow them with explicit disclaimer?
MM: The two technologies that stick out are tied to authoring tools. There aren't many more formats than Flash or PDF that fall into this category. There are authoring tools, and the output mechanism determines whether the output is accessible.
LR:  Are we saying that it is ok for people to develop sites with content that is not accessible, using these technologies?
JW: We are't even contemplating that. This is a question about publishing techniques documents. We aren't planning to change 5.2.
JW: Proposal: It might be permissible to publish such technique documents with appropriate disclaimers
MC: both in prose and machine readable form.
LR: I think it would be a good step.

MC: User agent compatability. We wanted some require of user agent support for each technique. Earlier we thought we'd inventory every user agent, and it becomes a monumental task. Jason's latest proposal is that our requirement become that we indicate whether the technique is known to have been implemented in some UA. We can provide links to third party documents for user agent support. We aren't incurring the obligation to maintain an up-to-date database.
MM: Going back to the user agent guidelines, the issues section was more geared to whether there are implementation issues with one user agent vs another, e.g., CSS or alt="" vs alt=" ". This issue comes out in the Interest Group list but never gets captured, so it keeps coming out. This would give us a way to say if there is an issue like that.
MC: So from a requirement standpoint, there would be a mandatory UA field that contains optional UA information if it is particularly relevant to that technique.
MM: When people voluntarily run a test suite, they could report bugs they found in specific browser.
MC: This seems important enough to include in the techniques document, but not so comprehensive as to be overwhelming.
MM: And if there are experts on particular user agents, they could provide some of this information.
JW: The required part is whether there is a UA implementation. The optional part is for recording known problems, inconsistencies, etc.
JW: I'd also add an optional spot for links to User Agent information.
MC: Would the link be at the document level, technique level, or where appropriate according to the target.
JW: Probably needs to be according to the target.
MC: I'm just trying to determine how general to make the schema.

MC: My last thing is to propose that I make the revised document available tomorrow and if no objections are raised by end of Tuesday, we start the process to post to the TR page.

JW: Who wants to volunteer to go through a checkpoint or two of comments.
LR: I'll help.
JW: How can we make progress on this task?
MM: In another working group, we took a regular meeting and went through the comments. Some comments can be dealt with quckly and easily. Others can be kicked back out to the mailnig list.
JW: Greg, Wendy, and I wanted to dispose of the easy ones on the list, and save the teleconference for harder ones. Historically, we don't seem to resolve hard issues on the mailing list. However if no one can weed out the easy ones, we may have to spend teleconference time on this.

$Date: 2003/01/23 22:55:38 $ Loretta Guarino Reid