W3C home > Mailing lists > Public > w3c-wai-au@w3.org > January to March 1999

Rough minutes

From: Charles McCathieNevile <charles@w3.org>
Date: Wed, 3 Mar 1999 09:58:07 -0500 (EST)
To: WAI AU Guidelines <w3c-wai-au@w3.org>
Message-ID: <Pine.LNX.4.04.9903030956180.2395-100000@tux.w3.org>
Raw minutes from Tuesday's meeting. These will also be converted to HTML
and linked from the Group page as soon as possible


--Charles McCathieNevile            mailto:charles@w3.org
phone: +1 617 258 0992   http://purl.oclc.org/net/charles
W3C Web Accessibility Initiative    http://www.w3.org/WAI
MIT/LCS  -  545 Technology sq., Cambridge MA, 02139,  USA

   start 8.55
   WL: less intro text would be good
   action editors to write 2.3 intro covering content, structure, management
   GR Not having section intros allows faster technical interpretation
   WL: can these general principles go into abstract
   IJ you need some intro to each set of checkpoints
   CMN Charles Oppermann was keen to have more intro to checkpoints
   WL It's in the abstract
   IJ, no it isn't all there
   JT Where should text now in 2.3 go?
   DD should be shortened and kept
   JR should professianlly written go into a checkpoint?
   WL can the intro notes be distinguished from the checkpoints?
   CMN already happens in the 'official (= online)' version
   KB, JB arrive 8.55
section 2.4

   DD: I woul like to merge 2.4 with either 2.2 or 2.5
   WL: It is logical under 2.2
   DD: Supporting things includes the emphasis on doing it right.
   CMN: I agree with daniel
   DD: It is a lower priority version of the same
   IJ: Why would it go here?
   CMN: Because providing encouragement is part of supporting the accessibility features
   DD: It helps to reduce the number of guidelines
   JT: We don't want to lose anything
   WL: Discouraging bad practise is part of supporting accessible practise
   JR: is it?
   CMN/WL Yes
   JR: You can provide technical support without encouraging.
   CMN: Yes, but it doesn't split as far as a guideline
   //little section of minutes from Ian

   WL: Publishing differs from saving (don't interrupt
   saving, interrupt publishing).

   KB: 2.5.2 seems like stating the obvious. 

   MD: Might be a plausible for leaving this in the document:
   common sense not widely distributed. Structured editing,
   for example - usability nightmare, but some people
   decided philosophically that this was a good thing. The
   situation with accessibility is analogous: not allowing
   saving an inaccessibility nightmare is a usability problem

    //thanks Ian
   md; common sense ain't common. it is a good idea to have editors which wouldn't let you construct incorrect programs. this
   caused a serious reuseability problem. it is not the case that you have a better tool if you can't save an inaccessible
   dd; i want to keep this, but move it to configuration - there we should say that fundamental operation should be
   controlled. or maybe in the checking.
   wl; i want to second what he said about innoculation. this illustrates that we are not proposing draconian measures to
   mess up the environment. at the same time there should be something i the language which emphasises why this should not be
   published. - your own space and public space are different
   dd; they are not different
   jb; in some casses a person gets a 95per cent finished document and publishes it. I don't think there is a difference
   JT: we're going in circles. So we move this to checking or configuring.
   checking? 4 configure? 4
   JB: should be both...
   RESOLVED: move checkpoint 2.5.2 into both 2.7 and 2.8
   GR: "or postponed"? How is this different from asking if you want to save changes? There are times when something will pop
   up and honk at you.
   KB I don't think a prompt is the same as 'postponing'.
   MD I want to have the feature, but I want it to be configurable?

   what do we mean by highest priority?
   IJ are we talking about 2 different accessible solutions? Isn't it already a no-no to present inaccessible options
   DD I thought this was more to ask for the alt text immediately, rather than hiding it. So maybe there shothis should split
   in two. Make accessible practise visible, and promote highest priority.
   IJ are the specific practices which should be checkpoints eg when you insert an image get ALT text
   BK maybe should be techniques
   IJ Maybe, but there are some things which seem like techniques, but are so important that they need to be checkpoints.
   Most visible isn't clear
   KB: Example: image editor - first dialog has height, width, filename, and then you need to click 'advanced' for Alt text
   IJ: Yes, but the wording is still not verifiable
   GR: Ensure that there is a place for accesible features on the main screen
   BK rather than buried under dialogues or something
   GR: Ensure that options presented include accessibility options
   IJ: This sounds good - it is verifiable
   JR you are assuming a dialogue box or something
   IJ not yet.
   GR: This can happen in anything.
   JT: Should be one of the first things you see - should be at the top,
   JB say 'prominently include aceesibility options.
   CMN: Wherever options are presented, accessibility ones should be there
   WL at the same level
   IJ what does 'the same level mean'
   GR: Means that these are base functionality features.
   KB I don't see why this doesn't presently meet the criteria?
   IJ I don't know what most visible means
   JR: example: in frontpage you can use font, or CSS to change colours. in frontpage, the toolbar option uses font. to use
   CSS you have to go through a process.
   IJ that is an example that doesn't apply, because one is inaccessible. Where there are a comparable set, you can order
   them. perhaps: Include both required and optional accessibility features in interface components.
   JT: doesn't make a checkpoint
   IJ needs wordsmiting.
   JT this got at the emphasise and make it easy to do.
   GR: i think it might be easier to make checkpoints for each of the three strands than trying to get this encapsulated.
   JT 3 things: needs to be few steps. needs to be visible. needs to be at the top of the list of choices
   ACTION kynn - rewrite this and send to list. Add default configuration.
   GR: having 3 checkpoints makes it easier to get all the steps implemented.
   IJ: between same semantics, choose the most accessible first
   WL: does it say that I have to put alt before filename?
   IJ: No. only deals with order where there are two ways to do the same task.

   RESOLVED 2.6.1 goes
   JR: 'these processes are hidden form the users view and may create inaccesible content' - same thing
   IJ: and RTF is a markup language
   BK suggest we rename the guideline itself. I see it as having to do with HTML produced by a conversion
   JT: I think it is for anything that removes acessible structure
   JB I thnk there are a few things where the name of the guideline doesn't match. I think we should talk about structure or
   content. There are 3 things. don't strip stuff out, don't add junk, and don't alter. should we look at specific examples?
   WL 2.1.2 ends on wrong word
   CMN I think 2.6.3 is the crux, and should be generalised boyend accessibility
   KB: We could express this as positive
   IJ generally i prefer positive
   DD in this case I prefer negative - Never remove is stronger than Always preserve.
   JR: maybe we should reword the intro to encompass changing and importing.
   GR: do you want to cover both here Daniel?
   DD I think we can cover both. Sylvain might have an example, because Domino translates on the fly from a lotus format -
   apparently the native format has accessibility info, but the conversion doesn't use it.
   JT I think the guideline is clear and succinct, and there are lots of instances where ths happen. Can we express that in
   the introduction.
   IJ 2.2 says do the right thing. 2.6 says 'don't do the wrong thing'. Can they be merged?
   JT I think we need to be clear about this.
   DD As much as i like less guideline, I like this guideline
   JT I think we need to have a principle
   KB I agree that we need it because this goes back to what is the problem? It addresses a big problem that a lot of editors
   RESOLVED: change intro to cover the various bits
   JT Should we change the checkpoints, to have Judy's don't add, don't strip, don't alter
   GR: Should we include changing the DTD?
   KB 2.6.3 sounds like it should tell you about that. Changing DTD is a structural change
   GR: I don't think it would hurt ot explicitly state something like
   CMN: I don't think we need to say don't add. DTD is in techniques
   DD: don't strip is part of don't alter
   KB How about changing a 3.2 DTD to a 4.0?
   JB: Key is notification
   KB: 2.6.2 - should preserve any markup because it might be necessary for accessibility but not recognised
   DD: I think we need to understand these issues. If I create the perfect tool it does HTML 4.0. If I keep it for HTML 5.0,
   do I apply 2.6.2, or do I extend DTD?
   KB: The problem is that we are identifying specific things and everything else can be removed
   IJ we will have a set
   KB we have a set for now, but next year it may not be complete.
   JR: How about only removing structure you know is not for accessibility?
   IJ: How do you know if it is not for accessibility? Where possible we should be able to refer to a common set of things.
   JT: Clarification - this is not User Agent, and we have talked about what we mean by accessibility features, but Kynn's
   point is that if that changes, there are things that are not covered by this.
   KB Even if it looks wrong, then it shouldn't touch it
   DD: HTML 4.0 we changed the map content model. in HTML 5 it will be different - it will be better If I use HTML 5 model
   and validate on HTML 4, it won't validate. I know better, so I should have the last say.
   JT: I don't want to have an editor stopped from removing junk I don't want.
   KB: I am saying that it won't know what accessibility needs
   BK: we shouldn't be encouraging changing markup - it is impssible to make an authoring tool that knows everything
   IJ eg I write HTML 4, and your 3.2 tool strips out stuff editing it to validate it as 3.2. I wouldn't ask the HTML 3.2
   tool to know about html 4.0
   DD: I think the tool should validate - it modifies the markup to make it valid.
   CNM: There are two ideas here:
   1) We don't want the tool to remove markup without asking.
   2) we do want a tool that takes crap and produces css plus html 4.0.
   kynn's point is valid - we can't define the set of things a tool should not change.
   a tool should not change structure or markup representation without checking
   with the author.
   kb - remove automated from 2.6.3 add to 2.6.2 to give 'never automatically remove or modify structure that is necessary
   for accessibility
   CMN: we don't have an exhaustive set. we have 2.2 to cover accessibiltiy. So the need for this guideline is to talk about
   not making the changes under the hood - ask the user if they want to make them
   JT: But the user may not know what are accessible changes
   KB that's what context-sensitive help
   GR: I don't have a problem tih doing this
   JT are you assuming that all authors are going to know what are the access bits are, or that they are going to read all
   GR: I don't see that it is an either/or question
   IJ: User Agents ignore what they don't recognise. Can we ask authoring tools to change this behaviour? We are asking them
   to change for the future, which is what is contrary to the way that forward-looking languages are developed.
   JR: You make a good point. Problem is that many Tools ignore what they don't know. Maybe we should have a checkpoint which
   says ignore what you don't know.
   IJ there are tools which we want, which can convert bad to good. The rest, to survive, need to ignore.
   JR if you can have a bad to good then you can have a doesn't matter to doesn't matter
   GR I thik it would collect all the unknown elements, and present you with a summary of changes
   JR we are trying to use automation, not gathering stuff.
   GR I as an author would prefer the information
   JT so what is the default
   DD - leave it in. Configure to fix broken stuff.
   cmn - perhaps have a checkpoint - ignore what you don't understand.
   that's an important part of this checkpoint, but we also ask that you
   work to a valid dtd. Leaving in bad stuff is mutually exclusive with
   a valid dtd.
   JT: suggested by Kynn: rather than referring to content for accessibility, we say never remove content. We cannot defince
   the structure for accessibility, but we want to be able to improve accessiblity. You can prompt the user to say yea or
   nay, but that takes the emphasis from developer to user.
   IJ with WCGL we had two sections - one big and one small. Here we have the same - I propose we should put them in a single
   section. We discussed the two topics in the intro to the section (see WCGL intro) and then we had the single run of
   DD I wanted that for WCGL but I don't want it here.
   //Ian minutes from here:
AU Face-to-Face at Lotus
2 March 1999
Chair: Jutta Treviranus (JT)
Team Contact: Charles McCathieNevile (CMN)

Jan Richards (JR)
Kynn Bartlett (KB)
Gregory Rosmaita (GR)
William Loughborough (WL)
Judy Brewer (JB)
B. K. DeLong (BKD)
Sylvain Galineau (SG)
Ian Jacobs (IJ)
Daniel Dardailler (DD)
Mark Day (MD)

 WCGL (Web Content Guidelines)
 UAGL (User Agent Guidelines)
 AUGL (Authoring Tool Guidelines)
11am Ian on notes.

/* All guideline/checkpoint numbers refer to intermediate
document produced on 2 March for Working Group */

Re: Guideline 2.6

WL: Most of what we've been talking about is
more in the realm of techniques than checkpoints.

IJ: Don't leave information up to reader when you can
be specific. W3C Recs should not be ambiguous
or leave open to interpretation when it's possible
not to.

Resolved two checkpoints for 2.6:

    a) Don't remove markup that is
       known to promote accessibility.
    b) Don't remove unrecognized markup without alerting
       the author.

/* Discussion as to whether "a" is obvious/necessary */

Also: Summary of structural changes, formerly 2.6.3 is
          a technique of how to alert the author.

Still required: list of techniques.

Guideline 2.7

DD: Delete Note in this section and refer to Guideline 2.8.

CMN: Proposed: Switch 2.8 and 2.7  [No.]

DD: Guideline 2.7 text: Provides ways of checking and 
                        correcting all inaccessible markup

/* Can we talk about "inaccessible markup"? */

IJ: I think that it's difficult to say "inaccessible
markup is not what's in the WCGL". 

CMN: A rough definition is "what breaks the WCGL".

KB: Inaccessible markup includes at least that which breaks
the WCGL.

Please note that the definition of "inaccessible markup"
refers to a definition in the WCGL, which doesn't exist.

Action Ian: Redefine inaccessible markup. Link from
instances of "inaccessible markup" to the definition.

KB: Propose changing "inaccessible  markup" to
"inaccessible content".

2.7 Resolved:
  Provide methods of checking and correcting inaccessible


- 2.7.1: Remove "See the sections ..." and make it a note
         for 2.7

- Remove "according to a user-configurable schedule" since
  part of the definition of prompts and alerts.

/* Reminder: definitions of prompt and alert include
according to a configurable schedule */

- 2.7.2.

DD: Checking without reporting is pointless. The two
  are bound together.

CMN: Proposes:
  2.7.3 and 2.7.4 are subsumed by 2.7.1

DD: I'd like to see three checkpoints related to checking:
  asynchronous, synchronous (on demand), on open/save.

CMN: Any scheduling feels like a technique to me. The
key is the alerting. The configuration guideline talks
about the details of scheduling.

GR: "Provide a mechanism to alert the author."

DD: When is user-configuration.

CMN: Checking is partially configurable: on open and on
save. Author also has the possibility of being alerted 
during edited. Open and save should not be negotiable.

MD: Everything is negotiable. Forcing alerts is the
kind of thing that kills you in a review.

WL: Provide a hook so that the functionality of checking
can be used in non-UI circumstances, namely programmatic
control (in and out).

JT: You want to check at other moments than on save:
you want unobtrusive notification. Correction is
crucial to an authoring tool that promotes accessibility.

CMN: I'm not saying we don't do those things (they are
covered by the author having a schedule). The issue
is: is there a particular point when the document MUST
be checked. My suggestion is that if so, this be
a checkpoint.

DD: We discussed merging 2.7 and 2.8. Should we
revisit that possibility? 
Also, we need to refer to two kinds of alert
(obtrusive, unobtrusive) from checkpoints.

KB: I don't like the idea that you MUST have
something even if the user wants to turn them off.
** For 2.8, we need a guideline that says that the
default configuration must promote accessibility.
It should not be easy to turn off accessibility checking,
but it should be possible.

JB: I am also uncomfortable with a phrase from
earlier: "it doesn't matter how much of a sales
problem it is". The author has to be able to
configure the tool to different levels. Not everyone
will be using tools in a compliant situation.

MD: Please note that a "checking" process may be
time-consuming. If applied on every open or save,
may be too time-consuming.

2.7.1 Resolved:
          Check for accessibility and validity problems and alert
          the author of them on a configurable schedule.

Issue: Should 2.8 and 2.7 be merged?

KB: I think there are other configuration besides

Resolved: Don't merge guidelines 2.7 and 2.8

DD: Two kinds of checking: valid HTML and accessible HTML.
CMN: These are techniques of checkpoints discussed 
elsewhere. We can point to existing tools.

- 2.7.2.

IJ: Proposed changing "know the details of the markup"
    to something based on the tool, not the author.

Proposed: Two checkpoints:
a) Assist correction
b) Don't require direct markup editing.

CMN: Doesn't a include b?

JT: We want assistance to resemble the authoring tool
mode: when markup edited directly, assist that way.
When manipulated through an interface, assist that way.

KB: Barrier to authors if we require them to know
all the accessibility features of HTML, CSS, etc. They
don't want to know the inner workings. 

CMN: I'd like "a" only. Implementation of "b" 
allows product differentiation. These are therefore
techniques, not checkpoint-level issues.

JR: I kind of agree. We can't assume that just
because most of the tool is WYSIWYG, the access
functionalities will be, too.

JT: Perhaps "a" only with a link to the checkpoint/guideline
about "integrate naturally".

KB: I want more than "integrate naturally". I don't want
to know the details. It's so important, it needs to be
a checkpoint.

GR: The point is well-taken, but I think it should be
a technique.

2.7.2 Resolved: (one checkpoint).
   Assist authors in correcting accessibility 
   and validity problems in a way consistent 
   with the authoring interface.

- 2.7.3 

IJ: Add "on a configurable schedule". Otherwise MS Bob
  will be telling me "Way to go!"

KB: I don't love this checkpoint. I think it's
condescending. This would be a good technique for teaching
people, but should not be the authoring tool's role
to pat me on the back.

WL: The point is not to congratulate, but provide a status

CMN: I do use software that tells me how far I've gone.

IJ: What's the measure of your progress?
Tool developers don't like to do look-aheads since costly
to calculate (e.g., after edits). Are there status
reports of spell-checking?

JR: There are binary ones in Word: no errors/some errors.

2.7.3 Resolved:
  Provide summary information of document accessibility on
  a configurable schedule.

/* 12:30 - 13:30 Lunch */

/* Bruce Roberts (Lotus) joins the meeting */
/* Judy Brewer, Mark Day, B.K. leave */

Guideline 2.8: "Allow authors to configure accessibility mechanisms"

WL: Should this guideline appear earlier in the document?

DD: I don't think the order will matter that much since
few guidelines in the end.

Also: Refer to earlier checkpoints that refer to
configuration (e.g., of help files).


- 2.8.1

  Resolved: Delete "for a given set of options".
  Also link "alert" to definitinon of alerts.
  DD: What about when printed?

- 2.8.2

  Resolved: Delete the parenthetical expression.

2.8.3 Resolved: Delete

Proposed CMN:
  The default configuration should promote accessibility.

Resolved new checkpoint: [priority 1]
  Include alerts for (WCGL) priority 1 checkpoints
  in the default configuration.

Don't restrict what can be done for configuration. There
are more pieces to configuration than just accessibility.

KB: Browser should be configured out of the box to
promote accessibility. Authors shouldn't have to
change settings.

BR: Wording of new checkpoint fine to me.

Proposed checkpoint:
  Fundmental operations such as saving, closing, and pasting
should not be canceled or postponed due to he existence of
accessibility problems.

JT: Judy felt we should keep this.

JR: Guideline 2.8 (being at the end of Section 2) is
saying "We're not crazy; we don't want to make life
for users or developers difficult." 

DD: Move to intro text.

CMN: If it's necessary for accessibility, make it a

DD: What is the risk if you don't have this checkpoint?
Who won't do it?

KB: This is not a checkpoint for accessibility. Move
to intro of section 2. This is an instruction to
the developer. This checkpoint doesn't increase or
decrease product or markup accessibility.

GR: I agree: common sense, not a checkpoint. Belongs in
abstract, or 2. intro, or 2.8 intro. 

 a) Put in abstract
 b) Put in section 2 intro text.

Resolved new checkpoint:
  Select accessible options in the 
  default configuration of author preferences.

CMN: Propose moving 2.8 to 2.4 (and 2.5 combined).
This would even make the document more readable. 
Does the look and feel include the default? Putting
them in the same place makes it obvious they do.

Resolved: Delete 2.8. 
  Move 2.8.1/2 -> 2.7
  Move new checkpoint -> 2.5
  Move 2.8 intro text to 2.7

/* Some editing done on section 2.7 */

Resolved 2.7 Checkpoints:
 - Check for an alert the author accessibility and validity
 - Allow authors to control both the nature an timing of
   accessibility alerts
 - Assist authors in correcting accessibility 
   and validity problems in a way consistent 
   with the authoring interface.
 - Provide summary information of document accessibility on
   a configurable schedule.
 - Allow authors to choose different alert levels based on
   the priority of authoring accessibility recommendations.
 - Include alerts for WCGL Priority 1 checkpoints in the
   default configuration.

Guideline 2.9 

Resolved 2.9: Promote accessibility in help and documentation.

Intro: "The issues surrounding accessibility are often
unknown to Web authors. Help and documentation should
explain accessibility problems and examples of solutions."

Resolved 2.9.1: delete

- 2.9.2 

KB: 2.9.2 sounds like it could be a technique of
a more general checkpoint along the lines
of "Provide help for accessibility-related issues."
2.9.4 Too touchy-feely.

BR: In our product, the author is divorced from the document
language. They access the features through the user interface.
Don't talk about "document language" since too techy.

Summary of main checkpoints for this section (after
which we'll choose checkpoints):

Resolved checkpoints (except for exact wording):

 - Integrate applicable accessibility features 
   throughout help and documentation.
 - Document accessible authoring practices
   supported by the authoring tool. 
   [This is a slice of the documentation.]
 - All help examples must promote accessibility
 - Provide rationale (e.g., benefits to
   other groups, mobile access, site management,
   download times, etc.) for accessibility features.

Resolved: Move following checkpoints to techniques: 
2.9.2 - 2.9.8

/* Break 15:30 - 16:00 */

Resolved: For checkpoints that don't have established
priorities, put "Priority X".

/* Review of discussion about Chuck's concerns */

- Priorities won't be listed in the document
  unless the WG has reached consensus.

- The priorities will be negotiated after
  (in general) the checkpoints are enumerated.

- The WG has done work to name problems and
  find solutions to them. The WG doesn't have
  a clear requirements document, however. 
  JB: It would be a useful test periodically to
      elucidate the requirements. If the document
      can't stand up to such scrutiny, there
      is a problem.

DD: To me, the requirements are close to the guidelines.

JB: To me, the requirement is the unmet need. They
enumerate why things go wrong.

JB: Essential problem is that people put inaccessible
   documents on the Web. Break this down into:
   a) They are unaware.
   b) The tool removes accessible features
   c) The tool makes it difficult to get to accessible
      authoring practices.

  These are met by the basic strategies of this document:
  alerts, prompts, configuration, etc.

JT: We have requirement lists in archives and older

JB: Then it would be good to isolate and name
(and verify it).

ACTION Jutta: Dig them up and ask questions about
them on the list.

/* Conference call time */

 - US Pacific, US East Coast, Western Europe.
 - 1.5 hours bi-weekly

 Sylvain: Any time but Wednesday

Proposals: Every other Monday, 15:30 - 17:00 ET.
           Every other Wednesday, 15:30 - 17:00 ET.

           IJ: Wednesday 16 - 17:30 better for me.

Next teleconf: 8 March 15:30 - 17:00 ET.

JB: Possible conflict with PAGL WG on 22 March.
/* Section 3 */

Note earlier resolution: We will put intro text here that
summarizes (tersely) both the software and user agent
accessibility guidelines.

/* Jutta reads from 8 Feb 1999 email entitled
   "Regarding Accessibility of Authoring Tools".
   Considered a kind of list of requirements   
   for section 3.

3.1 Resolved: Ensure independence of authoring and
publishing environments

/* Editor: Need to rewrite intro text to 3.1 */

One objection to 3.1 guideline wording: you can't
force an authoring tool also to be a browser. Also,
the intention isn't that you need to provide
a WYSIWYG view.

 - We aren't talking about multiple user interfaces here.
 - Delete 3.1.1
 - Fix wording 3.1.2: Ensure that styles used
   while authoring (e.g., large fonts)
   are independent of those in the published 

(New checkpoints follow)

DD Proposed: Provide a structural view of the document.
  For example, you insert a frame but don't want to 
  see the rendered frame - you want to know that a frame
  is being used.

CMN: You want to provide information about the structure
of one or more documents (hinting at site map). You also
want to provide information about included objects.

DD: I distinguish multimedia (with descriptions) and
structural markup.

JT: Note that these checkpoints help satisfy the
navigation requirement in an authoring environment.

GR: Needs to be author-configurable which information
about document parts is available. Want to identify
elements as you go.

DD: Techniques include:
  For images, file name.
  For tables, ...

DD: This is a textual description (voice, braille, screen

Resolved: Allow the author to display a textual equivalent
of content while editing. 

DD: (Note that textual equivalent
includes more than a longdesc or alt (e.g., can included
file name).

GR: Does 3.2.2 or some variation belong in guideline 3.1?

JR: site map is used twice. Once for producing content. Once 
for working in the authoring environment

JT: therefore we need to rename the guidelines. There are,
in 3.2, pieces which will never appear in the published content.

DD: it is one feature of interface that is common, often
implemented by file management.

JT: one of the most popular wasa hyperbolic view which was
completely inaccessible.

DD: proposed to flatten the structure of this section for
the moment. 

CMN: help / documentation must be accessible.

JT: it is in UA GL

JB must be here or it is ignored

GR must be reiterated

JB referred from the intro?

JT yes


/* 17:30 Meeting Closed */
Received on Wednesday, 3 March 1999 09:58:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:39:42 UTC