W3C Web Accessibility Initiative

WAI Authoring Tool Guidelines Working Group

WAI AU Teleconference - 1 September 1999


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


Review of Latest Draft

The Latest Draft is dated 25 August, available at http://www.w3.org/WAI/AU/WAI-AUTOOLS-19990825.



Action Items and Resolutions


CMN The editorial stuff seems to be well sorted out on the list - can we take it out of that?

Resolved: So be it

Checkpoint 6.3 - Configuration

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

Checkpoint 6.6

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.

Order of Guidelines

Note: Positions to be put, discussion period, then vote. Max 20 minnutes


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 are

Judy 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.

Copyright  ©  1999 W3C (MIT, INRIA, Keio ), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.

Last Modified $Date: 2000/11/08 08:11:51 $ by Charles McCathieNevile