W3C Web Accessibility Initiative

WAI Authoring Tool Guidelines Working Group

WAI AU Teleconference - 25 August 1999


Chair: Jutta treviranus, <jutta.treviranus@utoronto.ca>

Date: Wednesday 25 August 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 18 August, available at http://www.w3.org/WAI/AU/WAI-AUTOOLS-19990818



Action Items and Resolutions


Seach Requirement

CMN In Marja's review she asked if we wanted a bunch of things, including search. I thought we had included it and dropped it (from memory), but I looked and couldn't find it ever being there.

JT I agree

DD Isn't it a UA requirement?

GR No - if you want to look for something that you wrote it is useful.

WL is there an example of a tool which doesn't have one?

nobody can think of one

CMN If you use an editor that has no UA component, you still want to search

DB We are only going to say search, without qualification?

Resolved: Agreed to include a search requirement

IJ Don't we want it as a separate checkpoint?

CMN Yes.

WL, GR Sounds OK.

IJ So why isn't it in UA?

CMN because the tool is not necessarily a user agent

IJ So it should be specific to editing view

Proposed wording: Allow the author to search within editing views.

JT Is it clear what editing view means?

CMN It is in the glossary.

Resolved: Adopt a new checkpoint with proposed wording.

CMN I think it is P2.

IJ It is P2 in UA.

Resolved: P2 - to be placed in the right order in Guideline 1.

Checkpoint 3.1 wording

CMN I proposed a shorter wording and a longer one. I now lean towards the longer wording - it explains what is wanted

IJ I am not sure exactly what it means. What about something more terse, such as ensure that the user can use

JR I prefer the terser "support.."

CMN I think the longer version makes it explicit, which is valuable.

JR I don't think the proposed phrase makes sense

IJ What about changing "defined for" to "documented for, or known for"

GR Provide the user with the means to implement all documented accessibilty features defined for the tool

IJ Ensure that the user may carry out all known accessible authoring practices for the ...

WC All known could be too general. I would say agreed upon

CMN agreed upon seems worse

JB What about saying "accessible authoring practices"

DB Are we more or less saying we want people to be able to follow guidelines...?

CMN Yes?

DB What's the difference between this and 3.2 - WCAG

JT one referes to being able to use the practices -availability. 3.2 Is producing content that conforms to..

WL So 3.1 belongs under checkpoint 1?

JT No - for an author it means that those practices are available

DB I don't understand teh difference

JT There is content production done by the tool which is not involving the author

CMN JBs review suggested there was confusion between markup, which the tool makes, and content

JB There is no guarantee that a tool can direct the content produced by the tool.

JT There is an action to look carefully at the use of the words "content", "structure" and "markup".

JB Excellent. Overall I think there needs to be a little more precision.

WL I think the definition of the word "content" is a broader problem

DB I still have a difficulty with the difference.

/* JB leaves

GR the difference is between active and passive

CMN 3.1 is about making sure that there is a way to do each thing that is defined. 3.2 says "produce markup which is consistent with WCAG"

WL 3.1 is broken if the author can't apply a style sheet. 3.2 is broken if it uses style elements but does not use style sheets.

DB So for longdesc, is it OK to be able to add one through an HTML editing view?


GR My understanding. 3.2 says if you colour somthing, do it with a style. 3.1 allows you to put a title in a hyperlink. 3.2 is active, and 3.1 is simply providing the means. Covers not only those which are recognised by the tool

DB The techniques don't say that.

JR, GR, CMN Agree.

DB There are a coupleof things - the user has to be able to do it. Second part is, when they do it the tool mustn't choke on it. What it really means is that we want to enable accessible authoring practices, and we want to support them once they are in.

WC If you look at 3.4, you could modify it to say "preserve all content through conversion and changing views"

DB does editing apply enough?

WL through the entire authoring process

JT So the requirement that things are not rejected should be in 3.4

DB So what we are saying in 3.4 is make sure the tool can show the content

CMN No - it just says don't throw it out.

JR The four things say "make sure you don't lose it".

/* KB joins

JT Are you proposing that we put recognise into one of these

JR I am thinking 3.1 should require more than just a text editor

CMN 3.1 does't stop you using a text editor, although in some cases 5.1 might

DB I like the idea to add "authoring" to 3.4 We just want to make sure that it is preserved.

Proposal: 3.4: Preserve all accessibility content during authoring, transformations and conversions.

GR Wouldn't your concerns about views be allayed by 1.2?

CMN I think that's a side track.

Resolved: Adopt wording for 3.4

Prpopsed: Ensure that the author may carry out accessible authoring practices for markup languages supported by the tool

GR Means nothing to me. I propose provide the user with the means to implement

CMN I prefer ensure the author can

WL Porposed: Implement accessible authoring practices

/* PJ joins

CMN "Ensure the author can implement accessible authoring practices for markup lanuages supported by the tool."

Resolved: Adopt that wording for 3.1

Checkpoint 6.3

CMN Basically to move checkpoint to techniques or make it into two priority 3 checkpoints

PJ allow the user some control over the accessibility alerts. When I thught about it more my second suggestion was a refinemnt of the first, and the techniques should give some examples.

CMN I think that it is not a necessary requirement, it is just oftena a good idea, and in some cases the requirement is the opposite

JT It is interesting to look at the spirit and development of this - it was added in answer to developer concerns about scaring away users. The spirit was to make sure you are not putting off the author.

PJ Right. Do accessibility alerts, but we are not prescribing the timing, nature - that is part of the techniques and the individual tools' design

JB Whenever I am talking publicly about the guidelines the concern about user configurability comes up - when I say the guidelines address it as a requirement the blood pressure goes down. My understanding is that it is a number of other places at the checkpoint level

JT No - this is the only one

WL 6.5

JB I kept wanting to add "user configurable" into the Guideline level statement.

JT 6.5 only refers to summary

WL The header for guideline 6 used to have this

CMN I would prefer to have it in the guideline header than in a checkpoint

JR As long as there is a strong statement that configurability is important goes into the guideline text I would be happy with that.

JB On a practical level I can imagine a shop wanting to have no configurability - a shop satisfying a particular requirement. What might be looked for as a feature is an ability to set a global, locked configuration

CMN Having such a tool, that cannot be turned off, might be acheap way of achieveing your solution.

JR If you don't allow any configurability, users will be put off by the tool and type nonsense text -that was one of the things we want to address.

PJ I propose "allow the users to have some control over the nature of the alerts", and then make some suggestions in the techniques

CMN I am talking about a small percentage case which is legitimate, but which having a checkpoint disallows. I propose that the configurability be emphasised as a good idea in multiple checkpoints and in the Goal 3 disappears.

GR I don't want to lose the thing about configuring media-specific alerts.

CMN I agree. But I think that it is better in checkpoint 1.1

JT We don't want to get rid of goal 3

PJ I agree, but I think it is not at the same level as the other goals

WL Every time I have heard people in the business they have wanted this

PJ This came from a developer

GR All the configurations I have used provide configurability

PJ The developer will put some in, but doesn't want to be told what.

WL The question is should it be a goal that the tool is configurable?

PJ But you can have a tool that does everything right and has no configurability. To require them to add complexity of configurability is not going t oimprove meeting the goals

JB If the developer is adding prompting, validation, alerting, doesn't that mean that the configurability expectations would be getting more comlex?

PJ Yes. Sometimes they will do that by making things consistent

JB So they would be rolling this in with other configuration options

PJ If we allow the user some control and give examples we're done.

CMN I can live with PJ's proposal, but not at last call.

GR I would like a re-proposed 6.3 that allows for relative priority

JT The goal of this checkpoint is to make sure that we are not annoying the autohr with alerts and prompting.

WL put configurability into guideline 7?


DB I don't understand.

WL Configurability promotes accessibility...

Objection to removal of 6.3..

JR It is important to the production of accessible content to have some configuraility. I would like to see it in the guideline text.

WL I think it still ought to be a checkpoint getting rid of the nature and timing

JR I would go with PJ's wording

JT Do we want PJ's wording

CMN I would go with that, but record the dissent that I think that makes it a worthess and unverifiable checkpoint

PJ I agree with CMN. The techniques would expand, and discuss making it configurable - it wouldn't be lost in the importance

IJ If it is very important it should go into rationale text

CMN I propose it should be in rationale text.

JT This is for the developer to ensure them that you do not need to make a horrendously unfriendly tool.

CMN I object to the fact that they must be configurable

PJ That is what the developer said to me...

DBWe want to make sure that we are not saying you must have an uncofigurable tool. What we have now says you must make it configurable. We should make clear that it is ok to be configurable

JR I would say there should be there should be an intro para in the guideline

Proposal: Put wording into guideline intro suggesting that configurability is a good idea, and drop checkpoint 6.3, and put it into all relevant techniques.

JB I would be interested in re-reading it if we don't mention it in the checkpoints

JT Are you suggesting that we look at putting some wording in checkpoints.

PJ Do we have consensus that we want to allow but don't want to require configurability?


CMN Face to face meeting is on. Allaire is host - announcement to go on list after this meeting. Please work really hard on list - if we slip the last call past next wednesday then we will be unlikely to finish it before the face to face meeting, which will make life really difficult.

JB After last call, it may be helpful to have extra time for scheduled meetings after last call, in order to get some schedule

PJ I thought the 5 weeks review is adequate if not too long - will only four weeks reduce the quality of the comments?

JB There was an internal recommendation for 5 weeks - there is a lot of work for people to do, and it would be good to give them extra time. I wuld encourage you to have at least four weeks.

DB Got to go. Fine to shift guideline 1 to the end...

Move guideline 1 to guideline 7

CMN I prefer not to, but I am happy to live with that. It is my line in the sand though...

IJ No objection

PJ No objection

WL I don't think it makes any difference

GR I object.

PJ Would the document be more easily accepted if we move the guideline to 7.

WL No. It won't be easier. It will stop an argument.

DD It is the opposite. The guideline about making the content accessible will get the focus then.

PJ I agree. Focussing on content is the unique thing here. They are both equal priority. If the primary audience is authoring tool vendors we ought to present it in such a way that it will be more readily accepted.

GR I would argue that 1.1 is the mosst overarching of all checkpoints

PJ Why?

DD Why?

GR If you are starting from first principles that is the first principle.

CMN I think this is mostly a "religious", or immaterial point. Putting it at the back of the bus is what we are doing. I am happy with that

PJ Putting what has been done elsewhere smacks of rehashing other stuff that has been done. If you don't pass the last test, you lose.

JB The possiblity of changing the position doesn't have to do with acceptance, but rather with potential confusion about the focus. I looked back at WCAG and it start with equivalent alternatives, which is the heart of the argument. Guideline 3 here is the core of the document that is unique. Maybe generate standard markup needs to come before, but guideline 3 is absoltutely essential, and is central to orientation.

GR I am not championing one over the other - the key word is and. So it makes sense to me then to start with making the tool accessible itself.

CMN It is not an important issue for me - there are lots of ways of doing it, and I can live with them all - the current one is just my preference.

WL I agree that it is not important, but I like it how it is because having the tool be accessible has not been seen as a priority in the past.

PJ That is not my impression

JB My experience is that it is difficult to find an authoring tool with simple levels of accessibility - I cannot find a tool that produces acceptable markup and is accessible to me - which is not a problem i have had in other areas

PJ I agree with you in the area of WYSIWYG simple editing.

JB With the exception of Composer I have not found a tool that has full keyboard support, and the markup it does is terrible.

PJ Could WL or GR articulate how vendors will understand it better if we have it as number one instead of number 7

WL Why would a PWD want to write a web page - that is a very pervasive attitude.

to be continued....

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