WAI Authoring Tool Guidelines Working Group
Chair: Jutta treviranus, <firstname.lastname@example.org>
Date: Wednesday 16 June 1999
Time: 3.30pm - 5:00pm Boston time (1930Z - 2100Z)
Phone number: Tobin Bridge, +1 (617) 252 7000
The latest working group draft is http://www.w3.org/WAI/AU/WAI-AUTOOLS-19990621.
CMN There are some redundant definitions for alternative content. Proposal is a single definition for alternative content that steals from WCAG.
IJ I'm for it.
WL Will the word content come under scrutiny?
/* DB joins
Resolved: Collapse these into single definition for guidelines document.
CMN This is now redundant with 1.3
JT This was here because we had nothing to allow editing of everything
WC Change 1.3 to "display and edit" rather than display an editable"
GR I agree
CMN Me too
WC This includes structure too
CMN They are in 1.4 and 1.5
Resolved: 1.3 to read "allow the author to display and edit all ..." and remove 4.3
IJ This sounded like a lot of information - they seem to be separate ideas
GR Higlight the most accessible solution sounds like a technique
IJ the word visible is unnecessary
DB We are saying that the features which produce the most accessible content are the most obvious?
GR for example, colour changes are most obviously done through style sheet rather than hard coding
JT Or for creating image map, the first option will be client side not server side.
DB My gut reaction is getting deep into telling people how to design applications.
CMN Propose second sentence to become technique
IJ Make it an example in the checkpoint
WL The stuff from the long example (image editors, sent by CMN) relevant should go in here.
CMN Basically the second sentence is taken out of the checkpoint
JT And change "visible" to "obvious"
DB I am not sure always how to make something the most obvious.
JT In most cases there are very few choices
CMN For example, in creating columns, you could do it by CSS as a default, and offer an option to do it by tables instead
/* KB joins
IJ So what if you divide it into two pieces - make sure it is easily initiated, and make sure that the most accessible comes first
CMN The first part is covered by 5.2. The concern is what happens when there are equally obvious options - does the tools pass?
DB That's one part of it. I'm also not sure that we should have this guideline, but if we have it then we should be sure that tools which are accessible and good will meet it.
WL The purpose is to promote the use of accessible solutions when they are available
DB So in an alpabetical list, do we have to bring things out of order?
JT Things are usually given by functionality.
CMN As a way further we could change the checkpoint as proposed, and note as an issue that we need to further investigate whether this is really implementable
Resolved: Second sentence to be dropped from main checkpoint text, "visible" to be changed to "obvious"
IJ in Web content guidelines definition of checkpoints, techniques, guidelines was not as useful as an explanation of what we have there already.
CMN I think it is a very good idea.
IJ For example in the techniques document we should be able to explain that there are techniques by checkpoint and some that are by idea.
WL The definitions to large extent are defined by the current intro paragrapgh to the section
JT There is a confusion about whether techniques need to be implemented. Does it cover that?
IJ Yes. It explains that conformance is about checkpoints, and the techniques stuff is a separate document.
WL I like it
JT Are we losing the point that guidelines are principles, checkpoints are checkable, and techniques are suggestions?
IJ WCAG shuffled some of that to introduction
CMN I think we should make that crystal clear in this section
IJ That is already done in the status section. I have no objection to tailoring it.
Resolved: replace section 1.2 with WCAG section "how the guidelines are organised", tailored to fit and clarify status of techniques
IJ Scope of these Guidelines didn't say what I expected. I propose covering all the stuff in a single section.
CMN I agree with the proposal. The current Scope section doesn't cover as much as the Introduction, but is more or les redundant with the introduction. The issue of whether an image editor velongs is noted - better discussed next week since people haven't had chance to catch up to the list.
JT There is value in having a specific scope section for people to look at - the introduction tends to be prose, and the Scope section is easily bulleted.
IJ You can cover it in the abstract. I think the definition of a tool belongs in deifintions
JT We could discuss the title. Where do you think this disucssion should go?
IJ We should mention it in the abstract, explore it in the introduction, and define it in the definitions. The intended audience doesn't belong with the definition of tools.
JT We agree that the intro needs reworking.
IJ The user agent and web content guidelines begin with an intro to accessibility issues, for people who have never encountered accessibility issues. This document may not need that.
Action IJ: Propose an introduction which uses WCAG text, our intro and our scope section.
IJ Do we prefer haveing a tool defined in the intro?
CMN in the intro have a brief editorial explanation of what we mean, and have it defined in the definitions section.
GR I would like to see 'by default' added to goal 2.
CMN Having not liked the "by default" when I first looked at it, I agree with Gregory that it should be clarified that we want accessible content produced by default.
DB "By default" implies when there is a choice between a couple of things.
GR For example, a toolbar changes fonts by creating a class rather than using the FONT element
CMN By default, a user will create accessible content.
DB For example, FrontPage2000 puts in alt text as part of the natural process.
JT An example might be conversion
CMN This is about goals. Our goal is to ensure that things are done the right way not the wrong way.
WC There are cases where people will want to use an inaccessible feature. You need to say something about that
CMN This is about what our wishes and desires for the guidelines are.
DB I think it is OK to add this
Resolved: Add "by default" to second goal
CMN The addition of user configurability as a goal seems important.
DB As well as striving for accessibilitiy, it is important that the user can control the tool.
JT I think schedule is a bad term
GR I agree
CMN The final wording was "The authoring tool should provide as much user configurability as possible"
IJ I don't like "as much as possible"
CMN It seems fine in a wish list statement of goals
DB We don't use it in other goals
Resolved: Add goal "the authoring tool is user configurable"
CMN There were a couple of other changes Ian suggested which I noted in my responses as issues for the list, but hadn't turned into agenda items yet.
JT Checkpoint 1.2 IJ proposed "ensure that the author may adjust the document presentation while editing without affecting the document presentation defined for publication"
WL I though editing view summed up a lot
DB Yes, present workup is clear
CMN I like current wording
GR In original proposal I had rendered view as well as editing view. I wanted to be extremely clear, because we come back to this again and again
DB What you're really saying is "allow the author to change the editing view without changing the way the document will be rendered when published"
CMN I think that is clear and easily understod.
GR Im holding out for "without changing the presentational markup"
DB presentational markup is unclear
How about "document markup"?
DB Why say markup and not "how it will look"
WC Because it night not be rendered in a way that looks like anything
DB I want to look at it the way I want, but not chagne the way the ends user gets it.
WL "...without affecting the markup".
IJ I agree with DB that you then lose the ultimate goal - how it looks. Not changing the markup is a piece of that
WL I though that the markup guaranteed 100%
CMN 150% - includes device-independent manner
IJ That is fine and good, but loses the real intent in the interpretation.
DB I think it is better to stick in "the way it looks"
IJ Another option is to make an editorial comment.
CMN I would like to see "the way it looks" in the comment, to improve its comprehensibility.
GR I am holding out for "publishing view"
CMN Can I take "... without changing the document markup" and add "the way it looks" as an explanatory comment, for the next draft?
Last Modified $Date: 2000/11/08 08:11:51 $ by Charles McCathieNevile