WAI Authoring Tool Guidelines Working Group
Chair: Jutta Treviranus, jutta.treviranus@utoronto.ca
Date: 12 January 1999
Time: 3pm - 4pm Boston time (2000Z - 2100Z)
Phone number: Longfellow Bridge, +1 (617) 252 1038
It is expected that the new charter will have been approved by the time of the meeting. All members of the group must therefore request membership of the re-chartered group via the Call for Participants in the new charter, in order to remain members in good standing.
The latest working group draft is http://www.w3.org/WAI/AU/WD-WAI-AUTOOLS-19990101
Proposed by Jutta Treviranus - http://lists.w3.org/Archives/Public/w3c-wai-au/1999JanMar/0031.html:
Re-order sections to give:
and http://lists.w3.org/Archives/Public/w3c-wai-au/1999JanMar/0026.html
Move 3.1 (Ensure that users may configure accessibility mechanisms) and 3.2 (Integrate accessibility solutions naturally) into section 4
and http://lists.w3.org/Archives/Public/w3c-wai-au/1998OctDec/0111.html
Add explanatory material to accessibility of tool section of guidelines (section 3)
Proposed by Ian Jacobs - http://lists.w3.org/Archives/Public/w3c-wai-au/1999JanMar/0028.html:
Proposed by Charles McCathieNevile - http://lists.w3.org/Archives/Public/w3c-wai-au/1999JanMar/0027.html:
Demote 2.8 (offer text site map) to two techniques/checkpoints - one in sectin 2 and one in section 3 and http://lists.w3.org/Archives/Public/w3c-wai-au/1999JanMar/0009.html:
Define Accessible markup as 'Markup which conforms to the W3C Page Author Guidelines [ref]'
Proposed by Wendy Chisholm - http://lists.w3.org/Archives/Public/w3c-wai-au/1999JanMar/0002.html:
No actions.
Resolutions:
JB explains process surrounding charter approval.
Few comments from WG about AU Charter around Christmas. Then taken to w3c managements. Comments about dependencies, vocabulary discrepancies.
One substantive recommendation related to life after Recommendation: Extend the proposed charter's duration several months to allow for post-Rec follow-up. This would have the charter last until October 1999.
Intended milestones in charter also to be tweaked a little so that AC Representatives will understand more easily.
W.r.t. announcement process about the charter. Announcement should have happened last week, but didn't because of charter fixes. When it happens, we'll bounce the new charter back to the working group. The announcement will be accompanied by a call for participation (and all WG participants must re-request to participate). Chair will be maintaining a more formal list of active participants.
JB: This WG should do an initial assessment about how to follow-up on the guidelines Recommendation, then decide how to recharter. Similar behavior in other WGs (e.g., CSS). They "digest" their work, reassess and plan work based on that.
JT: What's the timeline for requesting to participate?
JB: People should asap and their participation accepted on a rolling basis.
Charter review period in AC will last 3-4 weeks.
CMN: Nothing in charter limits when one can sign-on. Nor a cap to number of participants.
JT: Premise that checking and correcting could be carried out at different times. Authors need to be able to configure. Are we losing the additional prompting and encouraging by collapsing these?
DD: I think that's an orthogonal issue.
WL: The option is addressed fully elsewhere. What's the difference between 2.10, 2.11, and 2.12.
JT: Different sources of content: author, tool, conversion tool.
WL: But still comes from the author (e.g., pushed a button).
DD: My goal is to have a smaller set of guidelines with more checkpoints.
JT: In UA WG discussions, we were encouraged to be more specific and create separate checkpoints rather than combine too much. Guidelines can't be too generic, otherwise we lose something. I think if we merge 2.10, 2.11, and 2.12 then we lose the distinction between author-added and automatically-added content.
CMN: The idea is the same, however: the resulting markup must be accessible. Maybe several checkpoints, but all the same guideline. Propose using 2.12 text: "Ensure that authoring tools produce accessible content".
JT: Clarification: 2.4 and 2.10 merged in terms of processes. Merging of 2.11 and 2.12 refer to specific instances.
CMN: I'd merge 2.11 happily. But 2.12 raises another point: don't remove existing structure. That should remain a separate guideline.
JT: In this collection of guidelines, we're merging different ways of creating markup (wysiwyg, conversion tool, wizard, ...) Do we need to distinguish them somewhere?
JT: Also, tool needs to (1) check for markup (2) provide a way to correct it.
IJ: Put prose at beginning of section (guideline) describing different sources of markup.
CMN: I think the distinction between identifying and correcting is valuable.
IJ: I agree for now.
BK: I ran across a problem last night. An inaccessible APPLET element. I was going to recommend OBJECT, but OBJECT not for java applets.
IJ: Question is: how do authoring tools know not only what's valid (it's defined in a spec) but what works (e.g., an element is supported).
Jan: We point to PAGL frequently.
/* CO joins here */
CO: I have a concern - what is defined as inaccessible markup.
IJ: Yes, what does "accessible" mean? (Same as in PAGL and UAGL).
CO: Disagree with 2.4.1 and 2.4.2 Not sure that this is necessary. Maybe a good idea, but is this a Priority 1?
JT: The check functionality is different from the schedule.
CO: Propose 2.4.1: "Provide a means for identifying and correcting inaccessible markup"
DD: Checkpoints would have different priorities (e.g., related to schedule). Need priority 1 on user demand.
CO: I want to ensure that I don't have to correct all HTML as I go.
See Jutta's proposal
JT's proposed order:
DD and WL: Point 3 relates to 2.
CMN: I think 3 is more long-term than 2. Would like to see 3. as a separate section.
JT: 3 and 2 both about accessible content. Number 4 is about the environment.
CO: Is 2. "promoting accessible design"? Then this is separate from three.
CMN: My perspective is a priority: accessible content is more important than accessible practices (encouragement).
BK: Designing for Web accessibility must be an integral part of any design practice.
CO: Promoting accessible design is different from people actually doing it. I would order these points as:
IJ: I agree with CO's ordering.
JT: Should "ensure" and "encourage" guidelines be merged?
No's - CMN, CO, IJ
DD: We could merge them into a section, but create specific guidelines for encouragement (lower priorities).
CO: The guidelines will be read by very different groups of people. Makes more sense for me since different people will respond to them.
/* CO leaves here */
WL: I still think that the problem is that the word "encourage" is confusing.
JT: I agree with DD that the document would be simpler if we had a content section vs an environment section.
IJ: Sounds editorial to me.
DD: I'm not sure. I think "ensure" and "encourage" are almost the same.
Last Modified 12 January 1999 by Charles McCathieNevile