WAI Authoring Tool Guidelines Working Group
Chair: Jutta Treviranus
Date: Monday 29 November 1999
Time: 3.00pm - 5:00pm Boston time (1800Z - 2100Z)
Phone number: Tobin Bridge, +1 (617) 252 7000
The Latest Draft is the Proposed Recommendation draft dated 26 October, available at http://www.w3.org/TR/1999/PR-WAI-AUTOOLS-19991026.
Issues raised during PR review
Issue: Is it appropriate for these guidelines to be used as a basis for making procurement decisions?
GR: Can't regulate how they will be used.
WL: Current wording, w3c process sufficient
IJ:There is no language about Recommendations v. Standards. This is just Comm Team practice.
DB: I don't think we need particular information about this issue in the document.
WL: Just because we don't say they shouldn't be used for procurement decisions doesn't mean they should be.
JT: We should rely on people's intelligence. It may be a good idea to refer to ATAG for procurement some day.
WC: The EITAC already refers to the other two guidelines?
JB arrives
JB: The EITAC Report recommends that the access board, in their rule on section 508, refer to three of the W3C Recommendations (the guidelines). It recommends that it refer to them at the Double-A level. The EITAC report was submitted last spring. The NPRM has not yet been issued. That NPRM may or may not carry through the EITAC recommendations. Due to conversations of the past couple of weeks, I called the access board last week with some questions. The types of the authoring tool accessibility guidelines related to prompting, help, etc. are not as much a concern w.r.t. section 508; the primary concern is the user interface. It appears there might be a disconnect between what that particular US law would be looking for as a reference for that regulation, and what they would point to if they pointed to Level Double-A of the ATAG. I'd like to get confirmation in the next couple of days. This would be available as background for our group.
JB:
JB: We could ensure that the introduction includes information about how to use the document.
WL: I thought it was understood.
IJ: I think it's not about philosophically opposing the use of the guidelines in a procurement context (this has in fact, I believe, been part of the design from the beginning). So what's the motivation behind the request? Is it that it's too hard today? Let's choose language to address that.
Exit William, Enter Charles
JB: Other issues - will all AU Tools be ruled out if none complies?
JB: Perhaps language useful in the document about what the document is and isn't.
JT: More precisely?
JB: A sentence in the intro or conformance section. Not a major redefinition.
JT: Would a statement such as "these are goals, not the status quo" cover your requirements?
IJ: Proposed language (action item from last week):
The Working Group recognizes that the requirements of this document are ambitious in light of the accessibility of most authoring tools at time of publication. However, this document represents consensus in the WG on accessibility requirements for authoring tools today and tomorrow.
JT: Would like to limit a statement to goals, not talk about ambitiousness.
DB: What about a statement very directly that W3C does not control how these are used.
JB: Something like: "As with other W3C Recommendations, this specification represents requirements and goals, not status quo of authoring tools at time of publication."
GR: Something like "The purpose of these Guidelines is to specify base functionality for an accessible authoring tool." Keep it simple.
JB: I am siding with the proposal to emphasize the notion of "Recommendation", which we don't always do in other Recommendations.
JB: Clarification; the Guidelines are technical reports and full-valued Recommendations. They do differ from other language specifications from W3C, however.
CMN: We should be absolutely clear in the "Status of the document" section.
DB: Yes, we can add words to the effect of "W3C does not police or enforce, dictate use", etc.
IJ: I recommend that this WG do what it wants, then W3C will pick up on it if it wants it. WGs are encouraged to avoid boilerplate text in the status section anyway.
.Resolved:
Proposed:
Action Jutta: Send this proposal to the list.
Action Jutta and Charles: Draft a summary for the reviewer who raised this issue (1: not up to WG to say how guidelines will be used; 2: status section will contain all the pertinent information).
Matrix?
CMN: As expressed last week, I think it's not desirable to include a matrix in any case. It's probably also impossible.
JT: Yes, since relative to a specific tool. All of the checkpoints need to be supported by the tool in one way or another. Whether the support comes from the tool or the author depends on how close the author is to decision points.
IJ: Sounds like the "applicability" clause in UAGL. The notion of "applicability" is not present in the ATAG. One idea is to provide applicability as a stepping stone towards understanding what a particular type of tool might have to do.
JT: They all apply, since more general. But how they apply varies according to the type of tool. And how they are implemented varies with the user interface.
CMN: Perhaps we should include a half-paragraph in the conformance section that addresses:
IJ: But it doesn't sound like my proposal of "applicability" helps that much.
CMN: It helps a little to clarify how to do things right. I like Jutta's proposed text about positive examples.
Proposed:
Action Jutta: Create a few sentences that state how checkpoint interpretation is relative to tools.
Resolved:
WAC: How will they relate to the ER techniques document?
CMN: Very closely.
CMN: I could create a matrix for Amaya.
JT: Should we document how it should be done or how it is done by an existing tool?
CMN: Two sides of the same coin.
Action Charles: Create a matrix for Amaya.
Action Gregory: Create a matrix for Home Site.
Others: If you have time, contribute what you can.
Enter Judy
JB: Related issue to above resolutions. There are some issues about the clarity of how the checklist is presented. There are 9 Priority 1, then X relative priority checkpoints (horrific multipliers...).
CMN: Propose a note in the checklist "Relative priority testing of these must be done on a checkpoint-by-checkpoint basis with WCAG."
JB: If you think the priority levels will remain stable, then I recommend that you break it down further to give them a flavor for what to do.
Action CMN: Draft text for the checklist explaining that the relative priorities expand.
JB: Rather than trying to finish the document by this week, if you had an additional week, would that matter? Would it only matter if you had an additional three weeks?
CMN: I'd like to have the extra week. I think that three weeks would not be better.
Birds in Australia concur...
Discussion of REC release timing.
CMN: I intend to review/edit the issues list with current understanding, for review by WG.
Action CMN: Update the issues list with WG resolutions and apparent resolutions on the mailing list.
JB: Other layers of requirements: drafting replies to comments, Director message, etc.
Conclusion:
JB: Please note, however, that I can't commit to a release date yet, even if the WG is ready.
What level of skill in producing accessible markup can the developer assume on the part of the author?
JT: How skilled is the average user?
CMN: I suggest that we mean the "average targetted user" for the specific tool. If your tool is marketed to power users, that's who we mean. If your tool is for everyone, that's who we mean.
Action Wendy: Draft a sentence for the priority statement that reflects the following:
Resolved:
GR: I suggest looking at intro text to GL1. Use as starting point.
IJ: The average user is not the naive user who doesn't know how to use help, menus, etc. out of the box.
CMN: I think these have been addressed adequately by email.
Action CMN: Propose a resolution to the list and document from issues list.
CMN: I think these have been addressed adequately by email.
Action CMN: Propose a resolution to the list and document from issues list.
Last Modified $Date: 2000/11/08 08:11:51 $ by Ian Jacobs