raw minutes from 18 june 2001 f2f

aloha, y'all!

1. apologies for not posting this before the commencement of this morning's meeting,

2. since there is a chance that the web based email client i am using will cause the lines of this post not to wrap in some displays, so i'm also going to include the minutes as an attachment

gregory.
-------------------------
Authoring Tool Face2Face Meeting
CWI Amsterdam
18 June 2001

ATENDEES
  Jutta, JT (chair)
  Charles McCathieNevile, CMN
  Gregory J. Rosmaita, GJR (scribe)
  Katie Haritos-Shea, HHS
  Marjolein Katsma, MK (invited expert)
  Chris Ridpath, CR
  Carlos Velasco, CV
  Giorgio Brajnik GB
  Jan Richards, JR
  William Loughborough, WL (by phone/IRC)
  Heather Swayne, HS (briefly by phone)
  Phill Jenkins, PJ (briefly by phone)

(VERY) RAW MINUTES

1. INTRODUCTIONS

// once around the room - names and affiliations

2. AGENDA REVIEW

JT: put things in afternoon at the request of those joining
us--evaluation topics, mainly

// CMN tries to get the agenda from the web, but has to rely
on his cache //

JT: agenda review:
  1.   structure and minimum requirements for Wombat
  2.   sub-text and intro text
  3.   minimum requirements - post checkpoint text for each
       checkpoint - refer to MK's post of 18 June 2001
  4.   evaluation techniques
  5.   review of current evaluations

CMN: Graham Oliver (GO) will be calling in at 1:30pm local
time, as will Phill Jenkins (PJ) and William Loughborough
(WL)

JT: GO will be reviewing Lotus review he performed-is it
available

CMN: published it to the web over the weekend

JT: additions to today's agenda?

JR: discussion of 4.1 and 4.2

JT: on agenda--discussion will be based on JR's posts to au
list

AGENDA ITEM 1: Structure of Document

JT: as move from ATAG 1.0 to Wombat, want to perfect
structure of document so can move to 2.0 easily; opportunity
to look at structure and come up with consistent structure

// CMN displays Wombat version of ATAG on projector //

CMN: go through issues one-by-one?

JT: want to start by reviewing existing structure; have GL
itself in as brief a form as possible (Support accessible
authoring practices); introductory text that introduces set
of checkpoints--intended as motivational and explanatory text
to clarify what fits into this category of checkpoints--no
real pattern to explanatory/intro text; within checkpoints,
have checkpoint itself, minimum statement an advanced
statement, and references to related checkpoints

// CMN gets connected //

GB: who will be using ATAG?

JT: developers of authoring tools; will be used by policy
makers, purchasers, and others, but primary audience is
developer

CMN: rough guide: these GLs with list of checkpoints that
relate to WCAG plus the things that authoring tool must do
in order to be accessible to PWDs

JT: not sufficient for building a checker tool, but how an
authoring tool can integrate checking into the look & feel
of the tool

// CMN shows current techniques document //

JT: question this morning is, is this the structure we want
to stick with?  How do people feel about the abstract nature
of the "at minimum" statements?  Have we reached the right
tone in regards the at minimum

CV: in relation to what?

CMN: the structure of the new document

JT: added recently "at minimum" and "advanced
implementation" statement along with related
checkpoints/guidelines; previously, didn't have much--just
some notes and explanatory text

CMN: general principle of "at minimum" is fairly helpful; in
discussion with developers, developerslike minimum; helpful
to make minimum satisfaction explicit

MK: also helps to be more specific; not just "good idea--now
what do I do?"

JT: that question should be answered by techniques

CMN: diff between reading GL and implementing it; ATAG small
enough--explanatory material mostly in techniques, to which
developerswill have to look

MK: access document with different views and in different
details

JT: responsible for growing the doc--had a very short GL
document and a very large techs document; wanted to give
reviewers of ATAG a bit more info so didn't need to keep
referring to techniques

JT: other objection -- with wide array of tools, there are so
many diff implementations, shouldn't be too specific in GL,
so as to allow developersto exercise judgment, creativity,
etc. -- have we gone too far or not far enough?

GB: are techs proscriptive?

JT: no-GL is, with exception of "at minimum" which does set
a proscriptive minimum; talk about functionalities author
using tool would need; from author's perspective, this is
functionality that should be there

CMN: bottom line--no matter what type of tool, minimum
requirements are "what is required to perform task X";
techniques are suggestions and further discussion/clarification

JT: more complicated; don't have much to go by when doing
complex evaluation

CMN: new techniques structure

// CMN illustrates //

CMN: techniques marked as "required" or "suggested"--basic
idea is, if you do some things, you will meet checkpoint, if
do others, may be good things to do, but don't satisfy
checkpoint; need to ascertain if we have drawn delineations
correctly

JT: required statements in Techniques make good candidates
for further descriptions in GL itself

GJR: requirements in Techniques bothers me

JT: do we need an "at minimum with every checkpoint?

JR: if don't then interpretation will be they don't know

MK: helps structure

JT: so need minimum & advanced

JR: advanced not always necessary due to variations in tools
we are addressing

CMN: thought search checkpoint was very clear, but with at
minimum and advanced implementation info, much much clearer;
plus, as JR said, helps saleability of doc

JT: put in advanced so that people wouldn't stop just at
minimum

JR: this checkpoint promotes/requires verbiage needs to be
discussed;

JT: describe

JR: construct plays diff role in diff situation; what needs
to be done; provides more context;

GJR: is bothered

CMN: in terms of requirements in techniques, idea isn't this
is required in a normative sense, so need to sort between
informative and normative; techniques informative--WG's
opinion of what can meet checkpoint--if don't get to this
level of functionality, haven't met checkpoint;  point is to
give guidance -- informative guide to what kind of techs need
to be implemented

GB: isn't GL a description of policy and techs a "hint" or
suggestion of how should be implemented; GL should be
concise and general and abstract so rarely change;
techniques should change and be updated often to reflect
emerging technologies

GJR: I understand the point of reorganization, but am
concerned about terminology

CV: use term "minimum requirement" -- why?

CMN: for specific example, 4.2 -- help author correct
accessibility problems; one dev (MS) said, having info about
how to correct in help section is enough; WG didn't think
that was sufficient

CV: be explicit in checkpoint, then

JR: other GL documents rely on sub-text and requirements

GJR:

CMN: what happens--write things up reasonably briefly in 2 or
3 pieces with redundancy or write one long thing that says
everything we are trying to say--better to have 2 or 3
statements that more or less say the same thing, than one
monolithic thing

CV: rationale between dividing GL 5 & 6 -- seem to be one GL
to me; so close together--one GL with 2 sets of checkpoints

CMN: most checkpoints are related to each other; most GLs
closely related to one another;

JT: GL 6 breaks GL5 to some extent -- one is concerned with
integration, the other is specific sections that address
accessibility

JR: entire document could be summarized as "make sure that
accessible content"

GJR: should be "make sure anyone can create accessible
content"

MK: GL5 and GL6 fits different styles of working--better for
end user of product

JR: GL3 a special case of other, broader GLs

MK: guidelines versus techniques -- ATAG is what product
manager uses to evaluate where tool stands--basis for work
orders; developers will use/rely on techniques

JR: part of my thinking--very minimums out of techniques and
into GL

JT: one risk is that it binds the document temporarily--are
we reaching the right abstractness

GJR: no

CMN: in some yes, in some, no--need to look at each
minimum--how long do we want this to last?  Five years?  Six
months?

MK: max lifetime should be 2 years at most

GB: what if tool doesn't do anything that the techniques
say?

GJR: wrong approach -- shouldn't stick specific verbiage into
-- blah blah blah

CMN: not entirely true--inherited structure from ATAG; need
to throw stuff on wall to see how works; as for longevity,
if rely on ATAG for 2 years, is that a significant risk--will
we have broken things found?  WG will be asked more specific
questions; doing what we're doing if keep ATAG 1.0 intact;
hasn't turned up a lot of howling errors--my goal is aim for
document that lasts 5 years, which means that it probably
won't live for more than 2 years; W3C process good at
weeding out bad design; broad enough to cope with range of
tools (illustrator, lotus notes, Amaya, video editors,
online courseware, archival software, etc.) and durability
of GL abstractions; functional requirements aren't such a
problem--can point out in techniques how to satisfy for
platform specific design; technique becomes--use OS
conventions; if put in requirements about things tool has to
do to a specific ML, then have problems; criterion for
minimum--is this good in every case?  If a case that this is
a bad thing to do, this should be highlighted in techniques

GJR: problem is access to walls -- who's throwing, who's
washing?

GJR: structure techniques descending order from this is best
to this is ok, but watch out for, and this sucks but you can
do it anyway?

// discussion of axes in techniques //

GJR: need better structure for techniques--hierarchy and
headers

CMN: critical for a checkpoint, easy to do, platform
specific stuff

JT: tentatively "at min" and "advanced" structure might
work, so Wombat is a test of that structure; going back now
to ascertain if worked and what further thoughts on
structure we have

GB: example of necessary techniques for 4.1 -- what would be
necessary?

JR: at minimum statement in Wombat [JR quotes proposal from
AU list]; others don't agree that any automation is
required;

CMN: why I want to get into specifics after break;
techniques capture assumptions and M.O.s; GL has to be short
enough for a project manager to read--if too long, won't
bother with it--has happened in the past; need a short enough
version that it passes that hurdle; in techniques, need a
lot of verbiage--not clear and concise like checkpoint text

JT: GJR, do you have any thoughts on proposed structures of
alternative ways of doing it

GJR::

JT: could put at minimum in techniques as first statement in
techniques document;

JR: that does mean that you have to switch documents

MK: product manager will just read GL

JR: could say in top of checkpoint document that the subtext
below checkpoint not part of document, but first technique
provided for explanatory purposes only

CMN: would like not to do that; have biggest possible
division between what is required by checkpoint and what is
explanatory material; in techs, these are things we think
you need to do, but this isn't the only way; if do this way,
we believe you have satisfied the checkpoint; minimums needs
to be actual requirement

GJR:  suggesting a three tiered document

CMN: concrete proposal: based on GJR's comments:

  1. Checklist ordered by priority (for sake of argument) is
  GJR's top--level document -- just checkpoint text, no at
  minimums, no explanations -- very short and lean
  
  2. current Wombat -- GLs, explanatory text per GL,
  checkpoints, for each CP at least checkpoint text,
  priority minimum requirement; all may/should have
  rational, and more advanced explanation; split
  
  Text
  Priority
  Minimum Requirement
  Rationale
  More Advanced (broad functionality suggestions, not just
  first technique--may be the same, but could be diff)
  
  3. Techniques -- each technique has an idea as to whether a
  technique will satisfy a checkpoint, or whether it in
  combo with another will satisfy checkpoint or if it is
  very good thing to do

GB: min requirement an interpretation of checkpoint -- what
tool should do and what isn't sufficient

JT: more advanced should be paired with at minimums

CMN: suggesting that we break up narrative sub-text into
point form chunks

JT: larger overview--retain 3 documents; move checklist to
executive summary?

CMN: checklist should remain the checklist; Wombat
checklist: listed  by priority and includes sub-text

JT: intended just as a checklist

CMN: only has priority info and checkpoint text; propose
that add ATAG introduction; page of narrative plus list of
requirements

JT: different document than had previously

MK: not sure about that

JT: different intent; worries me that taking checklist and
repurposing it to do something else

CMN: as I think about it, checklist is a thing that I look
at a lot; read document 27,000 times, and I want to look up
particular chapter and verse to find explanatory material;
want to give people GL document--does that suffice? Is it the
right level of document?

MK: as former PM, the at minimum are really important

JR: grab just GL text and GL intros and put those together
as executive summary

JT: need further explicit structure in GL document and
techniques document; top-level document--repurposing
checklist?  Extraction from current ATAG?

CMN: GL document and a techniques document enough to track;
save

CV: need a Schema for document, not just XSLT

GB: if want to set priorities, write content first, build
techniques, then think about implementation details

// 10:30 break //

FUNCTIONAL STRUCTURE OF GL and TECHNIQUES

JT: worry about executive document later after GL and
Techniques

// Karl Dubost joins //

KD: Quality Assurance activity--help people build better
guidelines and specifications, test suites, conformance
evaluations, etc.;

JT: start with Guidelines document; in  terms of structure
of LG document, at the moment have:

  1.   Guideline
2.   explanatory text (applies to most/all checkpoints)
3.   concise statement of checkpoint
4.   sub-text: minimum, advanced, explanatory text (this
checkpoint requires...)
5.   relationship to other checkpoints

JR: restatement of checkpoint, background, context

JT: do people agree with structure?  Additions,
subtractions, changes?

CMN: projecting an illustration of what we currently have;
changing checkpoint sub-text so that at minimum, more
advanced, rationale,

MK: start with rationale;

GB: why CP is important?

JT: rationale and/or context -- perhaps should be label for
field

MK: still rationale -- keep it

// agreed -- keep rationale //

CMN: "se also" -- techniques and other related checkpoints

MK proposes:
Checkpoint text, priority, rationale, at minimum, advanced,
pointers

JT: how should they be written: at minimum are functional

CMN: at minimum and advanced should be functional and user
orientated--what user will be able to do

MK: what, rather than how

JT: are each required or recommended for each checkpoint--in
some checkpoints, rationale tends to be redundant

CMN: require and at minimum in each checkpoint; rationale
and more advanced are shoulds; seems likely that will have
more advanced and rationale for most checkpoint; if put
techniques link into "see also" will have "see also" for
each CP

GB: why "more advanced"

CMN: better implementation

JB : why not call it a suggestion?

CMN: further set of functionality that you might add

JT: purpose was to balance the "at minimum"--reason for more
advanced was to encourage people to do more than minimum

MK: if can do this, would be really cool

GB: not addressed by techniques?

JT: describe same thing

CMN: at Project Manager level, may not read techniques

MK: GL should only address what; Techs address how;
separation should be absolute

CMN: added to "at min" and "more advanced" parenthetical
(required) and (suggested)

JR: advanced s what would be a really well done
implementation

CV: if required, why not just say it explicitly and not
parenthetically?

CMN: required and suggested as names?

CV: yes

JT: could not do minimum but could do maximum

GJR: why not "base functionality"--defining base
functionality, not a minimum requirement

CV: agree

CMN: would like to keep both sets of words there for the
moment, and reanalyze later

MK: usability testing of verbiage important--we know what we
mean

CV: basic functionality clearer from implementation point-of-
view

KD: basic as minimum -- Ruby has basic conformance -
really the minimum you can do to support Ruby; and the full
implementation

JR: at minimum have to do to barely pass; better
implementation might be different

GJR: why is it there, then if not normative?

JR: advanced doesn't necessarily build on minimum

GJR:

JR: in 4.1 at minimum, prompt author to manually check;
advanced technique is to automate all checking--no prompt for
check; advanced is not minimum plus

CMN: if the basic requirement isn't subsumed by advanced
reeq, haven't correctly distilled basic req; in 4.1 case,
basic requirement is each of these things are tested; basic
is hassle user every time, advanced makes easier; KD talked
about basic and full, but that breaks down with regard to
accessibility; advanced is "here is one way to take this
further"; at minimum should be normative--needs to be
expressed in way that is normative; have to work out exactly
what we want as functionality

JT: does everyone agree that base should be subsumed by
advanced?

GJR: yes

JR: not sure

MK: might need to reword some checkpoints

JT: not referencing what we have, but what we intend to have

// RESOLVED: at minimum should be subsumed in "advanced" //

CMN: should base functionality/minimums be normative

JT: if stated in terms of user functionality, then, yes,
normative

JT: do we want to structure further explanatory text that
follows each guideline?

// NO //

JT: should require what needs to be done and what is
required for purposes of ATAG

GB: should we cut "see also" up into sub-components?

MK: 2 headings: one which links internally within GL and one
that links to Techniques document

CV: "at minimum" or "base functionality"

JT: either label should work

CMN: at least for first draft, would like to keep "at
minimum (required)" and

CV: developers need to know what the basic functionality is

MK: like basic functionality or normative, rather than
required

CMN: for those things, they ARE required

JR: put basic functionality in parenthesis following "at
minimum" so that it is easier to trace history/evolution of
document

CMN: "at minimum (basic functionality)" and "advanced
(suggested functionality)

JR: things that wouldn't be acceptable as a minimum need to
be addressed

CMN: inclined to put in "insufficient" category

GB: put statement of what isn't satisfactory in "at minimum"
verbiage

CMN: preference is to keep examples in techniques

GJR: rather have negative examples in techniques

JT: to review:

  1.   checkpoint text with priority level
  2.   checkpoint sub-text, includes:
       A.   rationale -- OPTIONAL
       B.   at minimum (base functionality) -- REQUIRED
       C.   advanced/suggested functionality -- OPTIONAL
       D.   see also (links to other checkpoints and to techniques) 
            -- REQUIRED

JT: does everyone agree?

// YES //

TECHNIQUES STRUCTURE

// CMN displays a sample technique //

CMN: current structure of Techniques list:
Relative priority checkpoint
  1.   ATAG Checkpoint number; ATAG checkpoint text, ATAG
       priority, and link to checkpoint in ATAG
  2.   grab-bag of techniques identified iconically by kind of
       tool they apply to-4 diff types: markup editors, multimedia
       tools (sound, movies, video); content management systems
       (courseware? - new category?  Cross category?); programming
       environments (build applets, scripts); other suggestions:
       conversion tools (transform static content from one form to
       web-ready form); courseware;
  3.   for relative priority, lists relevant WCAG checkpoints;
       identify types of tools they are relevant to,  
  4.   require or suggest (organizational structure and inline
       declaration)

JT: filter techniques by tool category, required or suggested;

JR: removed AERT document from ATAG techniques

GJR: moved to an appendix or dropped?

JT: will be in Techniques

CMN: stripped out a bunch of stuff and resent to WCAG to
address

GJR: is there a public list with a URI

CMN: yes to first, no to latter

JT: structural suggestions?

CMN: if something is required or necessary, should have
explanation of why;

GJR: shouldn't that "why" be addressed in GL?

CMN: if expressed as a why, then gets into peoples' heads
quicker; grouped by "things to do" and "references"

GJR: is there implied or explicit hierarchy

CMN: things we think are necessary appear before things that
are good ideas

JT: used to have sample implementations

JR: fake tool examples

CMN: in some cases have examples from real tools, too, such
as HomeSite

GB: items marked as required are restatements of "at
minimum"

JR: no-things that we as WG thought you couldn't not do and
not comply; provide long descriptive text for clip art
collection

GJR: organize by functionality

GB: required to me sounds normative; required things belong
in guidelines; not hard and fast requirements

JR: agree as GJR pointed it, it is a bad label for a
techniques document

GB: if working with an AU tool, would go by tool category

CMN: label "required" needs to be changed-suggestions are
welcome-send to mailing list; going by category makes it
easy to generate something that drops irrelevant categories

// example Graham Oliver's evaluation of Lotus - said markup
editor and content manager, and addressed only techniques
labeled as such //

JT: changes? suggestions?  Change "required" if anything
marked "required" consider moving to guidelines document

GJR: modularize techniques a la WCAG?  Realize that many
tools cross categories

CMN: attempting to modularize via technology
(transformations); need more categories and more techniques;
what we have now caters to overlap-some relevant to only 1,
some to 3; development team chucking point of GJR, can't nor
should we try to, split up

GJR: blah blah blah

CMN: strip out all the stuff that didn't fit, thro

GB: organize the content of this document in XML format, and
then transform using XSLT, and use that to organize
modularization

CMN: the document is in XML to provide that type of
functionality; number 1 priority for techniques is to be
able to produce different documents through transformations

KD: document will be used by developers and evaluators, so
is good idea to have different views depending on use;
scenario filtering or separate document with checkpoints for
each category

CMN: what kind of tool are you working on? (checkboxes)
leads to what is relevant to those types of tools; can't
split out evaluation and developer stuff at this point

GJR: needs to be WG control over filtering-if used for dev
or eval, we need to filter out base functionalities that
need to be addressed

JT: evaluation techniques - part of this document or in
separate document

CMN: currently part of this document by sticking them on the
end - expedient, but not ideal; evaluation techniques are
much less mature than AU techniques; not very strongly
identified, test cases that haven't yet been developed, open
issues and questions

GB: evolution guidelines not as important as techniques
discussing now; need to have a tool before you can evaluate
it

MK: I agree-guidelines and techniques for implementation and
techniques for evaluation

JR: evaluation techniques could be used to bypass
implementation techniques

CMN: implementation techs in principle are reverse
engineering-here's the end point, here's how you get there

JT: evaluation document specific process used to evaluate
authoring tools

GJR: proposed: make evaluation section a different document
with example of EARL assertion

// ACTION GJR: talk with Sean Palmer about providing EARL
assertions about an authoring tool based on ATAG //

// ACTION CMN: NUMBER TECHNIQUES!!!  //

JT:  present structure:
  Techniques - required and suggested
  References
  Samples/Examples/Sample Implementations

JR: overlap between tools needs to be explicitly expressed

JT: should be taken care of when sorted by rules

JR: how are we going to signify strength of suggestion?

CMN: should and may

GB: why needed?

CMN: sufficient and suggested - a technique or group of
techniques is sufficient (WG says, if you do this, you have
met the base requirement);

JT: required things where you have to do X, Y, and Z, but
you can choose what you do thereafter

MK: collections of things that together form something
sufficient; also have things that are dependent upon each
other

GB: if normative or required, should go into guidelines

CMN: requirement is written in checkpoint; in technique,
state it is sufficient; implementation techniques as a
collection; combos of techniques that aren't sufficient

MK: rather than required or sufficient in techs, this is one
way of meeting the required checkpoint; tie back to what is
a minimum

GB: proposed: removed "required", when state "at minimum"
say "to achieve this minimum, you have to satisfy Technique
X, Y, etc."

JR: too much bloat, too many mappings

CMN: GB's suggestion is what we want to do, but should keep
it in techniques until individuals can filter guidelines
document themselves to get that sort of view

GB: re-propose when have more content-need to see what you
think is required

CMN: what I hear GJR saying, is that we need to be thinking
is there stuff in the techniques document that is an out-and-
out req, because those should be in the GL, not the Techs;
don't think that changes the discussion

GJR: unminitued comments on baselines and responsibility-we
are where the buck stops

CMN: think that this WG has a responsibility to say these
are the baseline requirements and what you have to do in
order to meet the requirements-we just have to provide the
whys on 4 or 5 different levels - if you don't, the tools
will be crap-need to provide sufficient level of support;
goal is to get implementation

KD: if I'm a developer and go to techniques and don't see
anything that helps me, what can I do - where do I turn?  No
info on feature I want to add, but no; techniques are not
complete in a sense, because don't know the future and new
developments; suggestions, not requirements; techniques can
never be exhaustive

JR: good point; can't ever say anything is sufficient

GJR: what is sufficient is provision of functionality,
implementation isn't our concern

MK: an author of a tool can have a type of tool we haven't
even considered, so in techniques should have explicit link
to mailing list for questions, suggestions

CMN: right up in what this document is about - read GL, read
techniques, ask working group; if get this far, we think you
have met this req-not the only way, but basic satisfaction
of this requirement; for those who are trying to meet
requirements, that stuff is really important; it does make a
difference how clearly it is stated what needs to be done;

GB: answer to that question has to be answered in document
for checking conformance; if just developed best authoring
tool, but no specific techniques-refer to conformance
document

GJR: last 2 items for each technique: link to list, I have
satisfied this requirement in a way you didn't imagine, and
here's the documentation of what I did, how, and why with
requirement that info be posted to AU list

CMN: in evaluation techniques, should have very strong
introduction to proper usage of documents - when you use
techniques, when you use checklist, when you use guidelines,
etc.

// BREAK FOR LUNCH (12:30pm to 1:30pm //

JT: in terms of discussion regarding structure, within
techniques the required/necessary statements - should they
go into evaluation techniques? Should distinction be
dropped?  Further thoughts?  Technology specific or
sufficient or part of a group

JR: like CMN's should be and may be implemented language

JT: but where should they go?

GB: guidelines - if normative, goes in GL

JT: and if not normative

JB/CMN: techniques

JR: if applies to a sub-set of tools, even if normative,
should be in techniques, so as not to overload GL

// RESOLVED: only cross-categories //

CV: why not "possible implementations"

JT: techniques: non-normatives = should

CV: feasible way to implement, but not the only one

JR: ATAG 1.2 - first technique is close to wording of
checkpoint; how could you not do this and not satisfy
checkpoint;

JT: so why in techniques

JR: migrated from older versions of ATAG; more you water
down a heading, from required to possible, the less weight
they have

CV: techniques should just be implementation hints

GJR: expresses concern about muddying waters between
guidelines document which says do X at an abstract level,

JT not exclusive categories-arbitrary; view model works well
for type of software we are discussion; not exclusive
categories

JR: main problem - how to deal with what appear to be
normative statements, but which aren't general enough to be
a checkpoint, but too specific to be a technique

CV: example

JR: [reads 4.1 ]

CV: is there not a checkpoint that already covers this - 1.5
in Wombat

JR: no Wombat techniques

GB: I've learned that we have at least 3 axes
   1. Normative or non-normative
   2. Technology independent or dependent
   3. Multi-media or editing tool
and all are independent as I see them; thought that GL
contained all normative info, but doesn't fit well with what
JR was saying; perhaps need another discussion of what goes
in GL, what in Techs, and what elsewhere; could be used to
determine what goes where; better for filtering

JT: so many classes of audience

GB: but first order of business is a usable document

JT: original understanding of techniques was: instructions
for implementation, not normative versus non-normative;
probably a lot of required things in Techs

CV: going back to GJR's point about a three tiered document

GJR unminituted explanation of WCAG2 evolution: executive
summary, guidelines document, checkpoint solutions,
technology specific view, and techniques document

KD: certain WGs have started to build test suites to test
implementation; Techniques are a kind of test suite -
recommendation on how to implement a specific part of GL;
DOM WG has a submission process that helps people submit new
techniques-someone responsible for testing, test passed by
the WG, put into test suite (dated and verified); think
Techniques very similar-not just evaluation techniques; is
it necessary to have a very frozen document, or could it
evolve in the future?

JT: Techniques document will evolve-GL has longevity,
Techniques evolve

CMN: 2 types of tech-evaluation techs along the lines of a
test suite; implementation techs are not directly test suite
material; ways of getting tool to achieve requirement;
perhaps should redirect energies towards making the
evaluation stuff as strong as possible, even for a given
tool type

KD: would it be difficult to manage so many separate
documents to synchronize?

CMN: more work, but possible

JT: suggestion?

CMN: shouldn't build another document on top; every new
document is a substantial increase in the amount of work
that doesn't get done; useful to have "if you meet this
technique you will satisfy this checkpoint" in the Techs;
need evaluation techniques-should raise priority as a
deliverable; one way of satisfying this checkpoint is to
implement techniques 1,4, and 5; another way is..."

GB: identify users of document-who is intended audience

JT: we've been through that

MK: might be good to remind ourselves

JT: intended for developers of tools

CMN: implementation techniques relevant to developersof
tools and people who have nothing better to do than read
specs; evaluation techs are useful for developersto see if
meet requirements; by QA people performing testing
(individual evaluations)-not sufficient currently; main
guidelines document for all of those groups plus product
managers-must be shot enough to be readable-something from
which you could derive the techniques document on your own

GB: for evaluators, knowing suggested techniques are
irrelevant

CMN: not irrelevant, unnecessary

JR: prose at top of checkpoint not going to work-too many
permutations, too many strands; turn a lot into if then
statements would be a better approach-that would inherently
decide if applicable - yes, no, doesn't apply

JT: stick into views

JR: could, but harder; first part of the "if" statement is
"if converting footnotes and endnotes..."

CV: many ways to do that-what do you tell developer?  Might
also have to put "if", "then", and "go tos"!

JR: a lot of techniques could be removed

JT: thoughts?

MK: profiling by use - project manager, evaluator, etc.

JT: not support for adding layers to ATAG; will have
evuation techniques and implementation technique documents;
should statements that don't apply to all technologies still
an open issue

// OPEN ISSUE: What to do with the "should" statements that
don't apply to all technologies still an open issue

// CMN shows example of techniques organization //

JT: only takes care of one class of shoulds

JR: too difficult to write combinations out

CMN: no more difficult than doing "required" and "suggested"
properly-that info is very useful, and this is a proposal to
address how to retain it and express it better

JR: like should and may better - if your tool allows docs
with footnotes to be coverted, you may include them as
inline content or through 2-way linking"

JT: "if/then statements with "should" or "may"?

JR: yes

CMN: useful functionality to keep is being able to say, "the
WG thinks that if you implement this tech or this combo of
techs, you will satisfy this checkpoint"; needed for cross-
tool applicability-some techniques are easier to implement
in one tool than another; dev looks at combo sets, and
chooses that which works best for their product and UI; here
are different combos we think will do the job

JT: should that be in evaluation techs, as per KD's
suggestion?

JR: the WG thinks X and Y are sufficient, but you should
also consider...

CMN: as developer, need a clear dileneation of what needs to
be done without learning irrelevant material/info

JT: we should move on; should or may good constructs; don't
want to lose combinations of techniques; makes document more
extensible

TOPIC: ACTUAL CONTENT FOR GUIDELINES

JT: satisfying 2.4 thread/posts -

CV: one question on 1.1 and GL3 - they are basically the
same;

CMN: GL3 is only a guideline, not a checkpoint; GL a broad
principle; only a requirement when becomes a checkpoint

CV: but 1.1 is covered by checkpoints in GL3

JR: important special case of GL3

CV: each GL should tackle a specific problem

JR: GL1 could state that all areas excet eqiv alternatives
which are covered in GL3

CMN: should special case notes into "see also" bit

JT: not the same; if interpreted as same, then not written
well enough; 1.1 is critical as are each piece of GL3

CV: developer feedback that 1.1 and GL3 are confusing

JT: operative word is "support" - steer the author towards
the creation of accessible content-not just that the author
can create

CMN: 1.1 is "make it possible"

CV: for those whose mother tongue isn't english, it is quite
confusing

// ACTION CMN: email list with proposal about clarifying
langague used in Checkpoint 1.1 and GL3 //

JR: 3.5 (ATAG1)/3.4 (Wombat) - argument built on ATAG1
techniques

MK: go along with argument, but only partly; a lot of
management of snippets about which I asked; realize now that
what triggered question was use of "database" in checkpoint;
has to have functionality of database, but could be a text
file that stores this information

JR: I agree

JT: don't have an "at minimum" for this

JR: sent one to the list [reads proposal]

JT: does JR & MK's tweaks close the issue?

JR: this might involve a large number of multimedia objects;
a semi-automated process, once a new object is used and an
alternative defed for it, that binding is stored somewhere

CMN: think this text is fine (2001AprJun/0401.html)

JT: need change?

JR: if causing misinterpretations within WG, then yes

CMN: JR's text and arguments are sufficient for me

JR: change word "database" in techniques to make less
technologically specific

// RESOLVED: Adopt text for 3.4 from JR's post and remove
word "database" from techniques //

CMN: 3 other checkpoints in thread
source: 2001AprJun/thread.html#0142

JT: discussed in telecon-does it need to be reexamined?

JR: Heather Swayne wrote something about use of "prompt" in
3.1 -

// JT reads from HS' post //

CMN: don't understand objection

JT: objected to intrusive dialog boxes

GJR: technology specific interpretation of the checkpoint

JR: interpreting "ask for" as throwing up

CV: use standard definition of "prompt" - many standard
definitions of it;

GJR: if international standard definition, then already been
reviewed f

// RESOLVED: change "ask for" to "prompt for" in sub-text of
3.1 //

JT: minimum requirement for 3.2 from HS is implement CSS

CMN: implementation technique and non sequitor

JR: HS' issue about relative priority note

CMN: list which apply, and which does not apply

GJR: how will it be implemented?

CMN: explain which relative priority checkpoints apply to a
specific ATAG checkpoint

GJR: point to WCAG 1 for Wombat only or in perpetuity?

CMN: WCAG2 not stable enough to reference; if happens before
Wombat finalized, we will switch to WCAG2 references; if we
are in PR and they are only in LC, then we will stick to
WCAG1; by working with WCAG1, we give ourselves more
flexibility by doing the work now-use WCAG's checkpoint
mapping to effect the change

GJR: should coordinate with UAAG list of structured elements
and other relative priority things-what have they identified
as meeting the criteria, how did they develop the criteria,
does it differ from ours, etc.

Checkpoint 3.2

MK: idea for a minimum is that tool should either label or
classify attributes as being structural or presentational

CV: not helpful-technologically dependent

JT: have a few techniques

CMN: hard one

GJR: PROPOSED: where a markup language supports presentation
by styling, use styling by default; if author chooses a
deprecated element or attribute, prompt him/her to use its
replacement in the ML defined for the page/section/fragment,
etc. only much more clearly, cleanly and well-stated

// ACTION GJR/CMN: post GJR's proposal to list and
incorporate //

CMN: proposed for a minimum "tool asks author each time"

JR: once for each or, for each thing, prompt - one prompt
for all or many for one

CMN: if tool pops up prompt and says "check all 68 WCAG
checkpoints"

JR: when does that pop up

CMN: 2 questions:  if pops up one dialog and says check all
of this (Bobby model) - while not useful, it is the bare
minimum; when it happens?  Tool must do it

CV: author should choose when; goes back to previous point
about prompting

CMN: one way of choosing when is buying the right tool --
everytime you save or everytime you are in mode X; if author
needs to ask for it, it changes what we meant; Macromedia
extension works, because it it integrated into menu and
happens when initiated by user

GB: tool must be useable; need to base minimums on reality
and what is useable; reword text so that signaling mechanism
is independent; tool has to make author aware that problems
exist

JR: user pulls down menu item and says check the doc?

GB: irrelevant - for things that need human intervention,
need to be very general

JR: break down into who initiates: author or user; second:
is there any automation required for things checked off once
by author?

JR: tool should ask

MK: have had this discussion before; some people will not
accept a tool that does this and will only use a
configurable or at-your-own-initiative tyep tool; had to do
a lot of explaning to people why HomeSite always produced
ALT when an IMG was defined; first answer is: it is a
requirement of the markup language, but still received
complaints from users

CMN: 4.2 much less contentious to me with JR's proposal; HS
said that having things in help is a minimum for 4.2; don't
agree

// 15 MINUTE BREAK COMMENCING AT 3:10pm //

JT: at minumum for prompting at the tool's initiative or the
author's initiative

JR: how is user given choice?

MK: something happens for the first time with a box that
says "don't warn me again"; if want to change, could go into
options and do so

JR: suggestion at save - "There may be some errors in this
page, would you like to check?"

JT: want to avoid a burried menu item or sub-menu item, so
has to happen by default

MK: automatic, but over-rulable

GJR: red herring - tools over-prompt by default

JR: want something difficultg to turn off, but unintrusive

GB: should be very easy to disable if interferes with normal
work flow of author

JT: rather than binary choice, can have "check later"

// WL joins by phone //

CMN: important that we allow a mechanism where user says do
this as way check happens, critical that those functions are
right up-front and center; GL5 says "make sure they are
clear" - perhaps need a checkpoint about putting 3.1 3.2.4.1
if are user intiated, P1 requirement that initiation of
those is front-and-center part of UI - proposing a new
checkpoing under GL5; must be omnipresent and obvious as a
P1 requirement

MK: easy to do, easy to find;

JT: when user has initiated is the new bit?

CMN: for checking/prompting functions that are user-
initiated, they must be front-and-center - P1 and refers to
mechanisms for 3.1, 3.2, and 4.1

JT: looking at minimum statements for 4.1 and 4.2 -
discussing who should initiate checking

KD: if prompt too annoying for user, what about a spell
check underlining; if image is called several times on a
page, don't reask each time

GJR: redundancy is the key-offer many ways to accomplish a
task

JR: at least once per session (defined as opening a document
and closing it), user must, at least once, be queried as to
whether or not they want to perform a check - could be part
of a dialog, its own dialog, a status line message

GB: a menu called "accessibility"

JT: authoring-tool initiated

MK: one mode that the user might choose-batch processing

JT: author have a number of choices, but one is on by
default

JR: if just see question, is that ok?

MK: yes

GB: tool should make the user aware that there are
accessiblity problems so that user can see them in context;
mnore than one way that can be initiated by users;

JT: part of at minimum is that the checking mechanism be
there!  2 aspects: who initiates and what functionality the
tool requires

CV: once a session too much

JR: change checkpoint to say "Assist the author..." at
minimum, say what GB said, in new checkpoint 5.x go into
details (multiple places, easiliy initiated)

JT: what about 4.2

CMN: may be initiated by tool or by author

JT: what functionality should the tool have at a minumum?

CMN: at minimum ok to put onus on author;

JT: link in an external checking tool

MK: make people aware that these tools exist

GJR: on a user defined schedule, and in a user-configurable
manner, allow the user to check a file for accessiblity -
functionality is: control over when, control over how,
control over what is checked (granularity of check)

JR: what about NotePad - GJR's definition would allow it to
pass 4.1/4.2

GJR: to say that NotePad and WCAG constitute an authoring 
tool is akin to saying that access to document source and a 
good imagination constitute a user agent

JT: 2 points: what is functionality and who performs it; who
performs it?

JR: check might be a sentence on screen or WCAG

CMN: tool must ask the author to chcck each WCAG
requirement; minimal satisfaction is go into accessibiloity
check and spits out a list of things to check

JT: has to be encompassed by more advanced tool

CMN: more advanced tool has a check for each WCAG checkpoint
which can be automatically checked and then asks for help
with those which can't be automated

JR: at minimum, tool must distill a number of checks from
WCAG - not sufficient to put all WCAG checkpoints on screen
asking user to check

CMN: sufficient to hand up WCAG's checklist, please check
these boxes

JR: that's inform; tool must automate answers

CMN: to pass 4.2

JR: no, 4.1

GB: as minimum requirement tool should be able to show the
WCAG checkpoints that are applicable le to the document
being edited; irrelevant checkpoints should be filtgered out
by tool; ask user to check manually

MK: don't need to ask for LONGDESC if no images

JR: large amount of automation required

MK: not too difficult to count tags - if IMG = 0, nothing;
if 1 applicable, if none then not applicable

CMN: WCAG checkpoint listed by priority; says "in general"
(has to have a test for this); "and if you use..." all can
be tested for very trivially; those that turn up null, leave
off list; very small requirement; acceptable minimum; more
advacned than ask every question

PROPOSED (CMN)
At minimum, the author must be prompted to answer questoins
leading to an assesement against WCAG at relevant priority
level for those parts of the WCAG checklist for the document
being tested

RESOLVED
4.1 addresses functionality of tool - at minimum, tool must
provide a list of questions relevant to the content being
developed by the author."

MK: in general easy and less annoying

GB: always false positives; should be able to filter out
questions about content guidelines

MK: if don't have IMG, easy to filter out

GB: a tool that would be able to avoid asking if the image
has an alt when there is no ALT would satisfy the minimum
requirement

GJR: all contained in the "in general" section of WCAG
checklist

JR: WCAG 1.1 contains at least 10 questions; who's going to
distill the manual questions?  Provide manual questions,
filter

GJR: organization by priority then by general (everyone
needs to address) and then "if you use..."

JR: least acceptable is one question per WCAG checkpoint

GJR: at minimum is, if can be automatically checked, then
must check using AERT techniques

GB: state of AERT and detail

CR: still being modified; great deal of detail; fairly
complex algorithm

GB: don't agree in taking AERT as being normative

CR: can't have an "at minimum" - algorithm always going to
be limited; going to end up displaying large chuncks of
WCAG; don't think there is an acceptable "at minumum"

MK: other extreme is reliance on automation

CR: some placeholder text is ok

JR: currently have AERT as a technique; at minimum, let
author know that there is a manual check; ideally, should
automate to gtreatest extent possible; better the checker,
the better the user experience

CR: choose top 5 accessibility errors as a minimum

GJR: would have to ensure that those 5 affect ALL users

CMN: WCAG - 7 Priority 1 items; 9 conditional items
(includes if all else fails) = 16 items; one important thing
is that the final part of any useful check is always manual

JT: check for all P1 WCAG checkpoints according to AERT?

CMN: never get developersto say yes to that

JR: top 2 or 3 things - get them to implement some sort of
checking functionality into the tool

CMN: first automation is strip out WCAG questions that don't
apply is: 1) easy; 2) better user experience; 3) leads to
manual checking gracefully; that piece of automation is as
unconctoversial as we can get, is low-cost, and provides
good buy in; provides a platfrom from which to start

JR: how to filter out?

CMN: "in general" can't be filtered out; the rest according
to the WCAG checklist secondary line of organization ("in
general" and "if you use...")

MK: count number of image tags, if number is 0, don't ask;
count IMG, TABLE, etc.

GJR: use UAAG as basis - list of structural elements that
must be traversable

JT: filtering out WCAG checkpoints that don't apply as an
"at minimum"

CR: going to end up displaying all of WCAG that way

CMN: right, but better tools will do it in a better, more
sophistiacted manner, and will be bought and actually used

CR: have to specify all the things you're looking for

CMN: basic and trivial if use WCAG checklist

// CV leaves //
// PJ makes his presence known on the phone, but cannot be
understood; he will join at 1:30pm Amsterdam time //

TOPIC: TOMORROW'S AGENDA

JT: tackle new checkpoint and then continue with agenda?

// RESOLVED: start with new checkpoint for GL5, at minimum
for 4.2, and then continue with pre-set agenda //

// ADJOURNED 5pm LOCAL TIME //
// NOTE: PRELIMINARIES FOR THE 19 JUNE F2F SESSION WILL 
   COMMENCE AT 9am NOT 8:30am //