WAI Authoring Tool Guidelines Working Group
Chair: Jutta treviranus, <jutta.treviranus@utoronto.ca>
Date: Wednesday 1 September 1999
Time: 3.30pm - 5:00pm Boston time (1930Z - 2100Z)
Phone number: Tobin Bridge, +1 (617) 252 7000
The Latest Draft is dated 25 August, available at http://www.w3.org/WAI/AU/WAI-AUTOOLS-19990825.
CMN The editorial stuff seems to be well sorted out on the list - can we take it out of that?
Resolved: So be it
CMN The proposal is to take it out of goals and checkpoints, but put it into guideline intro and techniques.
WL I no longer object.
Resolved: Proposal adopted
/* Ian joins
CMN I propose to leave the checkpoint more or less as is, with examples to clarufy.
WL Propose to define element transformations somewhere
IJ If there are specific transformations which are most important make them the checkpoint.
CMN There are no special types.
IJ I have no idea what it would take to verify the checkpoint
JT This is one checkpoint where you might allow a single transformation
IJ This is similar to the question ofputting metadata int a document - I don't know when to start or stop - it is difficult to verify.
JT Do we want to be more specific about transformation types
IJ I think that structure/presentation related ones are useful.
CMN Ok. I can live with that.
IJ "Allow the user to transform presentation into structure, or into style sheets"
JT Do we want to be more generic?
CMN I think we are pretty clear about wanting to have presentation and content separated.
IJ "Allow the author to transform presentation markup used in place of structure to structural markup, and presentation markup used for styling into style sheets"
Resolved: Checkpoint 6.6 to be Allow the author to transform presentation markup used in place of structure to structural markup, and presentation markup used for styling into style sheets
JT Accessibility Content: "All of the markup and content which helps accessibility"
JB Document: The definition is a bit cryptic. A web document is defined by a technical language.
JT We now don't use document much.
JB Then you need a definition.
IJ From CSS definition. Document is a tree of elements.
JT In WCAG the definition goes into the distinction between information and presentation.
Action JT: Check definition of document.
Note: Positions to be put, discussion period, then vote. Max 20 minnutes
CMN JB WL GR
CMN Proposed to put the guideline at the end, tone down the intro language without removing the statement, leave it as first goal to have tool accessible
WL I would like to see the toning down before I go for it, but other than that I don't think the order is important
GR What worries me most is that the justification being advanced seems as much like a vote of no-confidence as an argument for re-ordering. It makes sense to me to start with accessibility, althugh i ma not particularly concerned - I think we have a strong document, whatever the order
JB Agree with Gregory that accessibilty is a part of the core design and should come first, but having the interface accessibility first could increase confusion about what is in the rest of the document. Disagree with keeping it in first position to prove a point. Also disagree strongly that it is not important to address accessibility in these guidelines - I would ahve an extreme problem if we did not address that problem. I think it will be more likely that organisations will try to rewrite these and drop the guideline if it is at the end. The most telling comment is what William has been saying - if we are talking about order lets talk about the order of the whole thing.
CMN It is easier not to reorder unless there is a really good reson to do so
JR We did resolve not to put the guideline into the middle. From an organisational point it should go first - it is easier to get the one guideline out of the way.
WL I don't think this is a separate thing (entirely) - for example guideline 5 has some relationship to accessibility of the tool. I think we have isolated it for a historical tradition.
JR They are different, and confusing them is a mistake
CMN I agree with WL, although I don't think that it makes a real difference, so I'm not voting for a position one way or the other.
JT Separate Introduction from order of goals and guidelines. Will ask everyone what order of goals, what order of guidelines.
Straw Poll:
CMN I think they should
Charles McCathieNevile - remain as they areJudy Brewer - would like foundation material up front including accessibility of tool. Should be as is. Will only compromise for consensusJutta Treviranus - Jim Allan - first and firstJan Richards - first and firstWilliam Loughborough - order of goals doesn't matter, accessibility guideline should be firstDaniel Dardailler - accessibliity of tool should last and lastDick Brown - last and lastGregory Rosmaita - as isKynn Bartlett - should be the same for goals and guidelines. favour first and firstWendy Chisholm - goals as is, have proposal for reordering a few if we are going to start reordering - 3, 4, 2, 5, 6, 7, 1Ian Jacobs - last and last
/* Phill joins
PJ Want to re-emphasis that my purpose is to get these accepted by developers. If we can do anything to present them in a better light so they adopt faster that is my goal. If changing the order of that will stop them from turning off then I would like to do that. So put 1 to the end. I understand the argument that putting accessibility ofthe tool first makes sense, I am just going by the reaction of developers - this will make it easier to get them to accept it.
JB I am concerned that there is a tendency to drop pieces out.
PJ You mean w3c people?
JB No - other people rewrite them, and leave things out, etc I feel like there is a vulnerability here that we are setting
WC are they more likely to butcher the end, the middle, or what
JB The things that have been butchered have been things around tables (in WCAG). It is complexity that causes
CMN I don't think developers are going to misunderstand. I agree that getting developers to implement is important enough to change the order.
IJ Agree
JT Concur, for the sake of acceptability, so long as it is in the beginning of the goals and in the intro
JR In developers comments, it wasn't "we'll do this if its at the end", it is "I don't want to see this at all
PJ If they see it first they will not read anymore.
JR It seems strange that people will implement halfway through
GR I don't understand the fear of making the tool accessible
DB It is not fear ofaccessibility, it is about efficiency
JB, GR I think it is both.
DB I'm not afraid, I'm just being practical. There is alreday a lot of work on accessibility. There isn't as much work on making the output accessible. I would focus on the output, because that affects more people
JB Microsoft is in a special position because they have had so much attention directed at their products.
JT The disparity of having reading tools versus writing tools should be closing in
DB I don't think you can compare them - there are many more people using the web than authoring for the web
WC There are many more people consuming than authoring.
JR How do you know that isn't because of the accessibility of the tools.
KB Regarding users versus producers. Our guidelines cover products which are used by lots of people, such as Office, who are mostly producers.
DB Good argument, but there will still be a huge disparity
IJ In WCAG there is a section on testing that is non-normative, but in the guidelines. We could do that the same way.
CMN, GR, JB That is an appalling proposal
Vote on the proposal - goals remain as is, guideline 1 becomes last.
Proposed last and last
Proposed as is
WC: Proposal - goals as is, order 3, 4, 2, 5, 6, 7, 1
JB I am in favour of this. When I was looking at WCAG they put a lot of energy into ordering - the first guideline gets you in the middle of the whoe equivalent alternative issue. I wanted to put guideline 3 first.
IJ There was a lot of focus about guideline 1. We didn't reorder the rest of them. I am glad we ordered User Agent. I don't know why the resistance is to have it first or last. Documentation then Interface doesn't make sense. Beinning to feel more comfortable for me.
CMN If we can't resolve this in this meeting I think we will reduce the usefulness of the meeting
DB I think there are two groups here, so I would suggest 3, 2, 4, 6, 1, 5, 7
JT difficulty is that 7 and 5 stress accessible authoring practices.
WC let's go to Dick's Proposal
GR This would not impact the introductory statement?
CMN I can suport this if the goals stay the same.
JR I would change my votes on other things rather than see this happen
DB My rationale was that there are two groups
JR 5 and 6 deal with the interface in a different way - they are not part of the group that 1 is in.
JB, WL, so?
JB This makes more sense to me than the other proposals. I think it is worth a vote.
JR Add to Jan's point. There are principles in the guidelines which are related to acessibilty of the too, but in the present guidelines we would ahve to change the order.
Dick's proposal, leaving goals as is
Wendy's proposal
JB Dick's proposal takes the issue out of the box. I think there is merit to thinking differently.
JT Then we need to change the wording
CMN, WC, WL I don't think so
JB Even so, it sounds like a fix that needs to happen.
CMN Propose adopting Dick's order, not change wording for sake of reorder, put them out as last call.
JR I object. There is a subtle difference between accessibility of the interfce (1) and 5 and 7. By mixing them up we lose the subtlety and cloud the point.
WL I think the removal of the separation is the best thing we have done
JT I don't think this is a political issue, it is an understanding issue. The parts of 5 and 7 that are relevant to 1 are already covered by reference. In here we are making a novel point that the authoring practices should be integrated, and help should support that. If we put them afteer accessible interface the type of response thet people think "these are things we know, and we can ignore them" will happen.
CMN I think that the difference will be clear from the wording.
DB The most important thing is the wording of the guidelines - the order is not that important. This seems a more natural order
PJ An amendment to Dick's is to have ordering 3,2,4,6,5,7,1
JR I would agree with that.
IJ This sounds like deciding to break it into two lists again.
IJ I think all subtlety will be lost, whatever we do.
GR If there is a natural ordering it will come out of last call. Propose we leave as is.
Phill's proposal - order of 3,2,4,6,5,7,1
DB I am happy to come to consensus and move on.
GR I am not happy about this. I could go with number 1 at 1
WL strong objection
KB About a half-strong objection
IJ I prpose advancing with this formulaton, adopting objections, go to last call
GR That is perfectly acceptable
KB, WL, Yes.
Resolved: Use guideline order 3,2,4,6,5,7,1
CMN Propose to publish, put out the draft, and if no objections are raised on list, I will publish as a last call draft.
Resolved: Publish draft, if no objections are raised publish as last call on Friday 3 september..
JB I think you've got to last call. Congratulations.
Last Modified $Date: 2000/11/08 08:11:51 $ by Charles McCathieNevile