W3C Web Accessibility Initiative

WAI Authoring Tool Guidelines Working Group

WAI AU Teleconference - 23 June 1999


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

Date: Wednesday 16 June 1999

Time: 3.30pm - 5:00pm Boston time (1930Z - 2100Z)

Phone number: Tobin Bridge, +1 (617) 252 7000


Review of Latest Draft

The latest working group draft is http://www.w3.org/WAI/AU/WAI-AUTOOLS-19990621.



Action Items and Resolutions



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?

JT Yes.

/* DB joins

Resolved: Collapse these into single definition for guidelines document.

Removing checkpoint 4.3

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

Splitting checkpoint 5.1

IJ This sounded like a lot of information - they seem to be separate ideas

GR Higlight the most accessible solution sounds like a technique

WL Yes.

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"

Copy organisation section from WCAG

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

Abstract, Introduction and Scope

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.

Configurability as a goal

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.

GR Yes.

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"

Other Business

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?

So Resolved

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