A revised Technology Requirements Document will be posted tomorrow.
Comments are due by the end of the day on Tuesday, Jan. 28.
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