WAI Authoring Tool Guidelines Working Group
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
The Latest Draft is dated 18 August, available at http://www.w3.org/WAI/AU/WAI-AUTOOLS-19990818
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.
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?
CMN Yes
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
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?
CMN No.
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...
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....
Last Modified $Date: 2000/11/08 08:11:51 $ by Charles McCathieNevile