raw minutes from 19 june 2001 AU F2F

aloha, y'all!

apologies for not getting these out in a more timely manner (read: in june),
but i was unable to send them from the f2f meeting, and have been wrestling
with my laptop ever since, attempting to extract them from it...  this
morning, i finally liberated them from my laptop, so i am posting them in a
very raw form -- the lists of action items, resolutions, proposals, and open
issues which precede the minutes have not been checked for internal, let
alone external, consistency...   i'm not sure if wendy chisholm has already
sent the minutes of the day's final session to chaals or the list...  again,
i apologize for the unavoidable delay...

gregory.

-- BEGIN MINUTES --
Authoring Tool Accessibility Guidelines Working Group
Face to Face Meeting, Day 2
  Date: 19 June 2001
  Venue: CWI Amsterdam

=========
ATTENDEES
=========
  Jutta Treviranus, JT (chair)
  Charles McCathieNevile, CMN
  Gregory J. Rosmaita, GJR (scribe)
  Katie Harritos-Shea, KHS
  Marjolein Katsma, MK (as independent invited expert)
  Chris Ridpath, CR
  Carlos Velasco, CV
  Giorgio Brajnik GB
  Jan Richards, JR
  Daniel Dardailler, DD
  William Loughborough, WL (by phone/IRC)
  Heather Swayne, HS (briefly by phone)
  Phill Jenkins, PJ (briefly by phone)
  Graham Oliver, GO (by phone)
  Wendy Chisholm, WC (afternoon)

======================
SUMMARY OF RESOLUTIONS
======================
1. add 5.x following old 5.1 and number as 5.2; adjust other
checkpoint numbering as necessary
2. move second sentence of 1.1 "at minimum" to Techniques
3. leave 1.4 as is for now
4. change Guideline 3 text to "guide the author to produce"
5. move the second sentence of Checkpoint 3.3 to Techniques
6. use the term "explicitly associated" in Checkpoint 3.3
7. adopt CMN's further tweaks to Checkpoint 3.3 verbiage re:
explicit association
8. effect CMN's changes to 3.4
9. add GJR's verbiage (from minutes to 18 June 2001 F2F) to
checkpoint 3.2

=======================
SUMMARY OF ACTION ITEMS [incomplete?]
=======================
1. CMN/JR: work on wording for 4.1
2. CMN: publish new WOMBAT draft by 23 June 2001
3. GJR: provide example warning text ("you are about to
save...")
4. JT: create rationale text for 1.2 using the terms
conversion, transformation, import and export
5. JR: rephrase 6.2 so that it doesn't sound like it belongs
in GL5
6. JR: propose restructuring of GL6 on list

====================
SUMMARY OF PROPOSALS [incomplete?]
====================
1. CV: merge GL5 and GL6

======================
UNRESOLVED/OPEN ISSUES [incomplete?]
======================
1. "at minimum" text for 2.1
2. is an "at minimum" for necessary for checkpoint 2.2?

=======
MINUTES
=======
-----------
The New 5.1
-----------

JT: still have 4.1 discussion in mind, so want to continue
with discussion on 4.2; JR asked if we could review all
checkpoints to ensure that content states what we intended
it to state

CMN: completed action item, and posted to AU list; don't
have local copy

// CMN types up proposal for projecting purposes while the
rest of the WG has coffee //

CMN: [reads checkpoint proposal] note that this is a P1
proposal; references similar P2 checkpoints

MK: obvious or clearly identifiable

JR: why 3.2?

CMN: one of the ones we came up with yesterday; 3.1 and 3.2
are fairly similar beasties for different special parts of
an authoring tool;

JR: and 4.2?

CMN: 4.2 is simply, follow on from 4.1 -- think it would
make sense

DD: what about a parenthetic, 2 word explanation of what the
referenced checkpoints refer to so you don't have to follow
them to find out

GB: for 3.1, if the tool opens up an inspector/wizard with a
text input field to provide alt text, would that suffice?

CMN: not quite, partly because doesn't include LONGDESC, and
partly because it has to work with various other kinds of
alternatives--OBJECT, NOSCRIPT

GB: can we add this to the discussion of techniques

CV: old 5.1 already mentions integrating so why the new
checkpoint--may be a conflict in priorities

JR: could change priorities so that P1 to do 3.1, 3.2, 4.1 -
- or roll into 5.2 with a change of priority

JT: a checkpoint with a dual priority?

CMN: would like to avoid that

JR: not a great solution, but a solution; sole function of
new checkpoint is to modify the priority level and the
visibility of things for other checkpoints -- new tack for
the WG

CMN: reason we want it is to give us a way of saying, yes,
you can do it yourself, rather than auto-initiated by tool,
but has to be readily accessible; like to keep these pieces
separate

CV: doesn't quite make sense -- implication is need 2
buttons: one to satisfy the P1 requirement and one to
satisfy the P2 requirement

JT: new 5.2 is "naturally integrated"

CMN: let's call new one 5.x

JT: talking about naturally integrated, as opposed to
visible and obvious

CMN: P1 requirement is to make critical things obvious; as
sit down to do an evaluation, if those are obvious, that
gets you through the GL5 at level A; have to go back to get
double A

CV: demanding an extra button, which doesn't make sense

JR: could be the same button

CMN: if meet 5.2, have met 5.1 -- need another "see also" to
clarify/make explicit; if you do this work, part of it
include doing this

JT: might want to reorder checkpoints so that the old one
immediately precedes or follows the new one

JR: should put it in and try it out -- should we put 5.x
first?

JT: might get comments that that is contradictory

MK: no, clear case of reusing

JR: make sure you use the same interface for both

MK: yes; menu item called "accessibility" is naturally
integrated, and front-and-center if all checkers/features
are available through the menu

// RESOLVED: add 5.x following old 5.1 and number as 5.2;
adjust other checkpoint numbering as necessary //

--------------
Checkpoint 4.2
--------------

JT: we should finish with 4.1 before moving to 4.2

CMN: proposal contained in:
<http://lists.w3.org/Archives/Public/w3c-wai-au/AprJun/0175.html>

GB: would like to add that this functionality can be delayed
by the user

CMN: that's implicit--functionality has to be available,
user doesn't have to use it

CG: always displayed doesn't sound optional

CMN: still have to run utility/initiate routine, but when
you do so, it only brings out the relevant checkpoints

JR: meant to mean always displays a certain type of question

// ACTION: CMN/JR: work on wording for 4.1 //

CR: who's to judge if it simplifies the process of checking;

JR: this is just an at minimum -- techniques will define
more

CMN: question is, is a particular UI useful (implementation
detail) or does it check

JT: "assist the author" is the key bit

CMN: if the thing doesn't check against all WCAG
checkpoints, can't pass

CR: not part of checkpoint?

JR: explanatory text

CR: if have an accessibility checker, but users don't like
interface, would they fail, because users don't like
complexity?

CMN: can't fail if UI sucks

JT: wouldn't be assisting the author

CR: but they think they are

CMN: some tools have great interfaces and others don't --
some people love wizards, and others love command line
thingies; what the subtext says is that the tool helps the
author check for accessibility problems, rather than leaving
it all up to the user

CR: as long as there is any utility

CMN: only if meets minimum

MK: good point about usability

JT: if naturally integrated, then whole UI may suck

CMN: different strokes for different folds

DD: why is "at minimum" for all checkpoints and not just P1
or relative priority; if want to be level, do all level a,
so why the "at minimum"?

CMN: minimum should say, every checkpoint for the priority
level claimed

DD: ok

MK: is there any indication of when we switch to referring
to WCAG2?

CMN: no idea; in principle, can go all the way through with
WCAG1, but hoping that they will finish faster than us so we
can reference WCAG2

JR: this checkpoint requires the tool to provide the author
with tools that support the process of checking

CR: allows rather than supports?

JR: anything is allowed--support is active; add "check each
and every WCAG P1 checkpoint" to the at minimum

GB: has to be designed so that when it is used, it always
displays the relevant questions

// CMN announces that the AU WG has been re-chartered -- WE
EXIST ONCE AGAIN!!! //

// and there was much rejoicing... //

--------------
Checkpoint 4.2
--------------

CMN: don't think I had any comments about 4.2 -- did I?
[reads checkpoint aloud] -- sounds good to me

JT: comments?

GB: what is context sensitive help

CMN: identify the problem and link the help to the problem

JR: always do same thing to get the help, but when invoked,
goes to the relevant part of help

CMN: just say that help has to be linked to problem -- no
implicit or explicit mechanism implied; provide a line
number and what needs to be fixed, a ToolTip type popup help
message as appear in windows and MacOS

JT: proposal that we review each of the additional text
(checkpoint sub-text) to ascertain if they correspond to the
model agreed upon yesterday; start at the top of Wombat

TOPIC: Review of Checkpoint Sub-Text in current Wombat draft

// CMN displays Wombat on the projector //

JT: note that there are a few at minimums that aren't in the
current Wombat draft -- each should contain:
  1. Rationale
  2. Context Statement
  3. Minimum Implementation
  4. Advanced Implementation
  6. See Also (includes links to techniques)

// ACTION CMN: get new draft out by end of the week //

MK: couldn't we just have a link to the definition of some
of the terms

CMN: just putting in all the words right now; probably all
the stuff in brackets will disappear, but that links this
draft to the last, so people can trace evolutionary path

JT: phrase "one common way to minimally satisfy this..."
should be dropped

CMN: yeah
JR: yeah

JT: that statement isn't a functional statement

CMN: not a minimum requirement, either -- fairly clear about
that

MK: "one common way to satisfy..." is a technique

JT: let's move it to the techniques

// RESOLVED: move second sentence of 1.1 "at minimum" to
Techniques //

JT: other edits?

// NO //

JT: moving on to 1.2 -- comments?

JR: this may not be reversible?

CMN: if take something and convert it, you may not be able
to convert it back to what it originally was; point is that
the minimal conversion -- stuff with structure dumped into
plain text, can't get structure back -- that's the
irreversible bit; in an advanced implementation would track
changes so could be undone

DD: if save as ASCII, going to lose structure; should be a
message to the user such as that in Word that warns that you
will lose information -- suggest use verbiage from Word

GJR: can provide text that pops up when attempting to save
Unicode to ASCII using NotePad in Win2k Pro -- it's of the
"some of the characters will not be able to be stored
correctly/retrieved"

JT: please propose something based on that

// ACTION GJR: provide example warning text //

CMN: so where not reversible, author should be informed

DD: read in an HTML file with accessibility markup, the tool
shouldn't strip it out

GB: why transformation and conversion tools?  Aren't' they
synonymous?

CMN: have a definition of transformation and a definition of
conversion that say they are the same; having both in
checkpoint text caters to both factions and those who think
that there is a difference between the two

JR: seems silly to have 2 terms that are synonymous; just
going to foster confusion, not bring more clarity

CMN: which do you want to take out?

CV: Tablin is a transformation--why not use it and end the
sentence?

JT: a lot of people use conversion in developer community

CV: I use neither -- import and export are what are most
commonly used

MK: could work one word into sub-text

JT: no rationale statement -- could use that to use all the
terms -- import, export, transformation, and conversion

// ACTION JT: create rationale text for 1.2 using the terms
conversion, transformation, import and export //

JT: [reads at minimum for 1.3]

MK: can be a lot of decisions made by tool that don't have
any relevance to accessibility; what about "any decisions
made by the tool that impact accessibility"

CMN: don't think it is necessary

JT: functional enough?

CMN: yeah
JR: yeah

--------------
Checkpoint 1.4
--------------

JT: [reads 1.4 in toto]

CMN: minimum built into the checkpoint already

MK: can't have an at minimum apart from the checkpoint text

CMN: yeah -- "just do it"

JR: restate in at minimum

JT: the at minimum is the clarifying statement, so move what
follows "For example...." to the "at minimum" field

CV: relative priority -- if claim double-A, should be double-A

CMN: good catch!

CV: don't know why separate multimedia, applets, images, and
scripts -- everything must be accessible is simpler

CMN: example stuff is just an example--a selective example

JR: edit top part and move to rationale -- that's where
examples should go

JT: it does clarify the checkpoint

CMN: not all of it does

JT: do want to highlight templates, so I would leave it
there; example could be turned into the at minimum statement

CMN: not sufficiently inclusive

// RESOLVED: leave 1.4 as is for now //

--------------
Checkpoint 1.5
--------------

JT: [reads checkpoint 1.5 in toto]

CMN: second sentence in there has caused a lot of confusion;
basic idea is that it is perfectly acceptable for a tool to
say either I'm going to crunch this markup or I'm going to
reject this document; tool must be able to reject a document
if it wants to change the markup

CV: please repeat

CMN: author might say "don't change my markup, no matter
what" and the tool may sue for alienation of affection

MK: some tools may simply refuse to open documents that are
in a particular format/ML

JR: if the author declines to make a change, it may not be
possible for the author to effect the change

CMN: how about "It is acceptable for a tool to reject a
document"

JR: does that need to be in the "at minimum" text?

CMN: I think so

MK: you at least want to know what is happening

GB: we need techniques for this checkpoint

CMN: look under 4.3 -- this checkpoint moved in Wombat from
GL4 to GL1

MK: technique: highlight all those things it cannot process
to indicate to the user what will/may be lost when document
saved

--------------
Checkpoint 2.1
--------------

CMN: [reads text of 2.1]

JT: at minimum is "W3C specs have undergone review..."

GJR: that's rationale, not an at minimum

CMN: I'll move it

CV: what constitutes "appropriate for a task" -- what's the
minimum and the meaning of "appropriate for a task"

CMN: it is actually useful -- PNG isn't good for large
masses of text

JR: use W3C stuff -- if you really want to use pictures of
text, use SVG fonts

CMN: the "appropriate" thing is really an "out" for
developers

JR: the "at minimum" is "just do it"

CMN: question that at minimum has to answer is: when is
something available?  When is XHTML Basic available and when
is it appropriate for a task; at what point does an AU have
to implement XHTML Basic?  now?  in a year?  in ten years?
one of the things this checkpoint says is, "the latest
version of the HTML recommendations are various XHTML
recommendations" -- must those be available in order for the
AU to pass, and how does one make the decision when to
support a particular markup language or suite of markup
languages

MK: the question, then, that immediately occurs to me, is
"available in the wild, or in the tool?"

KHS: could use a term such as "widely supported"

// AT MINIMUM TEXT FOR 2.1 MARKED AS OPEN ISSUE //

--------------
Checkpoint 2.2
--------------

JT [reads checkpoint in toto] -- no "at minimum", but a
rationale

CMN: propose "inform author if markup is not valid" as a
minimum; pretty weak, but better than nothing; a tool need
not force validation; an author may say, I'm writing
something that conforms to an unpublished version of HTML

GJR: or to my personal extensions to XHTML

JR: this checkpoint refers to the markup that the tool
generates on its own

MK: tool could say, then, I know its invalid, but I'm going
to do it anyway

CMN: ah, that's the fatal flaw in my argument--at least
we're all awake and paying attention

MK: don't think the checkpoint needs an "at minimum"

JT: that's the second case we've come across where no "at
minimum" is necessary

JR: 1.3 is similar and has an "at minimum" (author override)
-- should we grab that one and tweak it?

CMN: any markup produced by the tool must be valid, even if
it uses personalized extensions, because they need to be
added according to spec; propose that keep in for now --
issue is, do we need it?

// OPEN ISSUE: IS AN AT MINIMUM FOR 2.2 NECESSARY? //

--------------
Checkpoint 2.3
--------------

MK: if tool only supports a sub-set of a markup language,
that would be ok if that bit is valid

CMN: that's covered

GB: this checkpoint doesn't cover templates?

CMN: templates are covered by 1.4 -- they're not
automatically generated

MK: yes, but what about tools that generate templates?
HomeSite generates templates in response to user input, but
it's HomeSite that generates them

JT: then it is covered because it is the tool creating the
markup

JR: we say that "pre-authored" content have to conform to
WCAG, but doesn't have to be valid

CMN: actually, WCAG demands validity

JT: complying to WCAG implies validity

JR: if WCAG requires validity, do we have to?

JT: possibly not

GJR: "first step to creating accessible markup is creating
valid markup" is a mantra that runs through all WAI/W3C work
-- part of the adherence to standards argument, and PF's
raison d'etre

===========
GUIDELINE 3
===========

------------------------------------------:
Is the Guideline text "all that it can be"?
------------------------------------------

JT: [reads guideline text] -- the bottom line is, "assist
the author"

CV: same problem as before

CMN: guiding the author to produce accessible content is far
different from allowing an author to produce accessible
content

// RESOLVED: change to "guide the author to produce" //

--------------
Checkpoint 3.1
--------------

JT: [reads text of checkpoint 3.1 in toto]

MK: shouldn't that be "alternative text"?

CMN: we have a thread on this from the list
<http://lists.w3.org/Archives/Public/w3c-wai-au/2001AprJun/thread.html#0141.
html>

JT: where's the stuff we put into it yesterday?

ALL: in the minutes!

// GJR suspends minuting in order to post minutes from 18
June 2001; minuting subsumed by live editorial session in
which CMN tweaked document //

// resume GJR minutes //

--------------
Checkpoint 3.4
--------------

GB: learned that last week that there is a tool that can
describe a chart; user might want to use that tool to
generate description of the chart

CMN: how does that not get covered by 2nd sentence in
checkpoint?

GB: doesn't allow for what I'm trying to do -- import text;

JR: put an "or" in place of the second "do not"

GB: ok

CV: replace confounded with plain English, please

// ACTION CMN: wordsmith rationale for checkpoint 3.3 //

GJR: propose

CMN: prefer to have widest review possible

GJR: want to preclude a whole set of issues from arising;
make sure that the document is extensible--we've put effort
into making the English the clearest and simplest possible--
it's time we put our efforts to the test; we need to ensure
that as we move forward, we do so in tandem with those who
will eventually translate Wombat when it stabilizes; if we
want the widest review possible, we should make sure that,
whenever possible, benchmark drafts are issued in more than
one language, and the only way to ensure that is to get the
translators to follow the document's evolution

// ACTION GJR: contact translators to organize a pre-public
review of Wombat to ensure that verbiage is translatable //

JT: how about "impeded" rather than "confused"?

MK: some text should be moved to techniques

CMN: drag out example and put in examples

MK: second sentence is a technique

JT: put in techniques

// RESOLVED: second sentence of checkpoint 3.4 will be moved
to Techniques //

CMN: fact that should be offered only if human-authored or
explicitly associated with the object

// RESOLVED: use the term "explicitly associated" //

JT: still doesn't have a minimum

CMN: this is a thing to not do, so minimum is "how many
times and under what circumstances does this happen or not
happen"

// RESOLVED: adopt CMN's further tweaks to verbiage about
"explicitly associated" //

--------------
Checkpoint 3.4
--------------

JT: comments on list?  thought there was a mis-numbering and
a comment

CMN: comment was just "these are misnumbered"

[JT reads text of 3.4]

JT: required or encouraged in rationale?

CMN: remove and replace with new bit I just wrote

// RESOLVED: effect CMN's changes to 3.4 //

JT: at minimum statement?

// CMN checks minutes of 18 June 2001 meeting //

// RESOLVED: add GJR's verbiage (from minutes to 18 June
2001 F2F) to checkpoint 3.2 //

GB: want to use the FONT element--first time I use it, I'm
told, use CSS to do this; if I want to keep going, does the
prompt reappear each time I put in a FONT?

CMN: 1.3 and 5.2 says, when you want to do presentational
stuff, prompt to do accessibly

DD: problem with prompting

CV: covered in another GL

DD: all prompting must be configurable

JT: a lot of stuff to support prompt -- even an entire
appendix

CMN: propose we leave for now and review in context when new
draft published

-------------
AGENDA REVIEW
-------------

JT: at 1:30pm we are going to have Graham and Phill calling
in for the Lotus evaluation; still have to discuss EARL and
ATAG; need to work on evaluation techniques very badly; need
to fit EARL into discussion; CV leaves at noon--is there
anything specifically you want addressed?

CV: will follow on list--GL5 and GL6 might be combined to
make document stronger; traditionally in HCI they are all
considered part of the interface

JT: people seem to think that GL6 applies to the
accessibility of the authoring system, which is part of GL7-
-if integrate GL5 and GL6 as per CV's suggestion, that will
make the distinction clearer

// PROPOSED (CV): merge GL5 and GL6 //

JT: problem--things in GL6 that may be perceived as
inherently contradictory with GL5

MK: help documentation is something separate from the UI

CV: I disagree

MK: sufficiently different aspects of the UI to be
delineated

GB: don't understand why merging would be problematic

JT: natural integration addressed in GL5; part of GL6 is
about a "dedicated section", which contradicts GL5

MK: difference is GL5 is more about how UI appears to user
whereas GL6 addresses content of documentation

JT: checkpoint 6.2 could be moved to GL5 -- that might be a
cause of confusion

MK: difference between what needs to be there and how it
needs to be made available

JR: would prefer it stays where it is; ensuring that all
examples have all required accessibility features

JT: strongest point of 6.2 is make examples accessible; made
more general and lost that succinctness when generalized;

JR: rephrase 6.2 so that it doesn't sound like it should be
in GL5

// RESOLVED: rephrase 6.2 so that it doesn't sound like it
belongs in GL5 //

JR: "ensure that all examples use accessible and valid
markup"

CMN: are you reading the checkpoints for GL6?  There are 3
or 4 messages on the topic

JT: not yet, just discussing the proposed merger of 2 GLs;
point to make in 6.2 is not the naturally integrated, but
that all of the help and documentation should in and of
itself be accessible; that it needs to be part of the whole
thing is an ancillary part of the requirement

GJR: modified JR's proposal to state "ensure that all
materials intended to provide the author with guidance
utilize accessible and valid markup"

JT: need to include authoring practices; all roads should
lead to Rome

JR: document inaccessible things your tool allows the author
to do

JT: primary thing is the examples

GJR: "ensure that all materials intended to assist the
author in the creation of content utilize accessible and
valid markup"

JR: why a dedicated section?

JT: originated in GL7 so that people could find
accessibility features of the tool

MK: if you can't manage to have integrated rewritten help,
at minimum, have a dedicated section

JT: yes, 6.3 could be a minimum to 6.1

JR: minimum for 6.2

JT: as it is currently phrased

JR: or is 6.2 an advanced solution for 6.3?

MK: that's what I'm trying to get at bidirectionally; help
content may not specifically describe how to do it; current
version of HomeSite has an HTML reference in it that comes
from a third party -- it doesn't address the tool, just
provides general guidance

JT: but still get to the info through the tool

JR: new 6.x "document the process of producing accessible
content"; 6.y "document how to do it in this tool (minimum:
in dedicated section, describe..."; advanced: naturally
integrated into documentation/UI

CV: requiring that every tool has a tutorial addressing
accessible web design

JR: make a lower priority -- already in ATAG as P3

CV: wording says document process of producing

CMN: current wording says "list things you can use"; JR's
wording implies, include a tutorial

MK: dedicated section as an at minimum is that a lot of
tools reuse third party tutorials

CV: I read 6.3 as dealing with guidance on how to create
accessible content WITH the tool, not in general

MK: can't say that as an at minimum--a more advanced
solution

CMN: this is a P3 checkpoint, so can say what the very best
tools will have

CV: specific to the tool

DD: also overlap with prompting -- strict, loose, by
priority

CMN: no need for a dedicated section

JT: otherwise, 6.1 6.2 and 6.3 can all be rolled together

CMN: 6.3 is document the process

MK: could be a dedicated section as a minimum -- can add to
it, but can't change what you've licensed

CMN: 6.3 doesn't need to be in a dedicated section; needs to
be there; integration lower priority, a separate section
also a lower priority

JR: first proposal makes that a technique; WG said, leave it
in as a requirement

DD: yes, because it is a P3 thing; higher priority is to
have accessibility addressed wherever appropriate/necessary

MK: if describes how language works well, may describe
accessibility, so then you can add

JR: dedicated section on how to write HTML plus an addendum
on how to create accessible content

DD: think of it as a tutorial

CV: leave integration to the developer

CMN: what we have at the moment are 3 different
requirements; 1) list of features you can use to create
accessible content (P1); 2) stuff about creating accessible
content permeates help and tutorials--that is a P2; the
third is explain how to use the tool to create accessible
content; propose have a fourth requirement at P3 which is to
collect all into in a dedicated section, noting that you
must first meet 5.2 (integration); rationale: many authors
want to learn specifically about accessibility because they
already know how to use the tool

JT: then why have 6.3 and 6.4?

CMN: meet 6.2 and 6.3 you have to read the whole manual;
caters to advanced/experienced users versus beginners

JT: what's the difference?

CMN: one addresses features and one the process

CV: don't think should be a conformance requirement

GB: include in meaning of documentation, links and
references to additional material must be available as well;
2) give me the outline of a possible tutorial

GJR: [unminuted]

GB: tell them how to use features while telling them how to
crate the page

JT: that's 6.2

GB: talking about describing the process; producing
accessible content is the same as authoring

JT: ideally as telling a user how to author, tell them how
to author accessibly--that's the intent of 6.2;

GB: then don't need 6.3

MK: I'm talking about a separate section and CMN is talking
about a separate section for 2 different reasons

JR: and doing 2 different things; still only see 2 things
here and a bunch of minimums and advanced

MK: my point comes from the very real and practical point
that want to include HTML reference that isn't quite up-to-
date, but is quite good--big whole is doesn't address
accessibility; want to keep it and add another section about
accessibility

JR: failing a P2 checkpoint to satisfy a P3 checkpoint

MK: better than just throwing the whole thing away; CMN's
point about new and existing users is valid--advanced users
just need to learn about accessibility, not the tool itself

DD: maybe MK's suggestion is really a technique

MK: then dependent upon being integrated

JT: what is 6.3 adding?  What is the distinguishing point?

DD: dedicated section

JT: main point of 6.3 that isn't covered in 6.1?

CMN: partly covered, but that is why it is a P3 under a P1;
6.1 could be a simple list of things, 6.3 explains their use

JR: going to do my own rewrite

// ACTION JR: propose restructuring of GL6 on list //

JR: anyone else who would like to do so, please do

// ONE HOUR BREAK FOR LUNCH //

-----------------
TOPIC: EVALUATION
-----------------

// Graham Oliver (GO) joins //
// once around the room with introductions //
// William Loughborough (WL) joins //
// William switches to IRC //

JT: waiting for PJ to join--wait one more minute before we
start; start with evaluation and move directly to evaluation
techniques

// CMN pings PJ //
// DD fixes(?) the phone //

JT: GO, CMN sent your evaluation to the AU list and WG was
asked to review--please give a summary of your findings and
then comment on the process and make recommendations for
making the process easier or the guidelines better

GO: can do; although want to do it the other way around;

JT: ok

GO: sent summary to the list; 22 hours of solid work in 3 or
4 hour chunks; sixteen hours dealing with CMN's feedback on
my original report; GL 5,6,7 much easier because most of the
questions there weren't relevant to Domino; found it a bit
of a frustrating process--not understanding some of the
questions was my main problem, but that could be due to my
own ignorance of the area being asked about; technique to
help would be to give one or 2 examples to go along with the
questions

JT: questions are evaluation tech questions

GO; yes; example: "when an extended graphics superset..." --
didn't know what that meant--had to ask CMN, who gave an
example, which allowed me to answer; have to assume a
certain level of base knowledge on part of evaluator

JT: did it help to go back to techniques when questions like
that arose

GO: no cross references in version of document I was using--
would have to be a link to a definition for that to work,
otherwise, too long a process searching for that for which I
was seeking an explanation; in order to get started had to
break up document into manageable chunks; only going to
evaluate for P1, so had to reformat document to do that;

JT: would it be helpful to have evaluation techniques in
different views

GO: definitely; chunking it would be something that would
have made it easier; actual process itself, if web based,
would have been easier; would have liked to have done it all
online; mucking around with HTML files and Word documents;
made things a bit tricky for me; ended up doing most of work
in Word, then converting to HTML; caused a few problems and
issues that had to deal with outside of main task;
administration of test and gathering of tools to record
results; web-based interactive form set may obviate that

JT: something the WG has talked about, but lack staff
resources

WL: tools for doing that are so bad that it is hard to do it
properly; using these kinds of tools to get on the web; when
convert from Word to HTML is a microcosm of what I'm trying
to say

GO: positive side, it increased my knowledge of the product-
-felt that I knew more about the product after performing
the review; aware throughout that Notes/Domino a bit of a
special case--not a web --site building tool from the ground
up--HTML capacity bolted onto it afterwards; very unlikely
that Domino in anyone's mind when came up with list of
questions; still able to tackle most of the questions, but a
lot weren't relevant to Domino--made my job easier, but
perhaps something that the WG should think about;

// Phil Jenkins (PJ) joins //

GO: just about finished talking about process; reasonably
satisfactory process--felt I was doing something useful;
intention was to produce something that might be of use to
Domino and the AU WG; don't know if I achieved that, but
felt as if I had done something useful

JT: summary: in terms of process document, need links to
supporting material, examples are helpful, interactive form
would also be helpful; positive side: despite fact that
Lotus not in our mind when ATAG written, still possible to
perform evaluation;

GO: had to decide to make P1 evaluation; limited it to P1
because that was too big a task; spent 22 hours or so just
on P1

JT: other thought would be sorting of checks according to
type of tool you are using (these apply to my tool
checklist)

GO: made a decision up front that Domino fell into 2 of the
4 categories;

GJR asks GO a question

GO: document I did the evaluation against isn't same as
current version; relatively easy for me to follow the path I
created once I created it--didn't need to jump outside to
other resources once I determined and blazed a path; like
that it allowed me to stay within the document

CMN: first section of Techniques document lists techniques
for implementation; final part lists what tests one can do;
describes testing process and desired results

GO: sections 4,5,6,and 7

CMN: no, bunch of Techniques according to GL, followed by
Techniques for Evaluating Authoring Tool Conformance; list
of tests you can do and whether checkpoint sufficient as
worded--did you use that?  My impression is that you went
through the techniques and said, does this, doesn't

GO: not quite understanding the question

JT: document that you used was not the one that is up there
at the moment?

CMN: used current rough draft of Techniques

JT: did you use the end section?

GO: not sure--example please?

CMN: two-thirds of the way down

GO: oh, boy--don't think I've looked at this; doesn't look
that familiar or friendly; similar stuff, right--rephrasing
of questions, right?

CMN: goal: states it as an evaluation process to make it
easier for you, but the fact that it intimidated you on
first sight, is good feedback

JT: tried to bundle questions according to content type--
thought was you could create an image and answer all
questions associated with that, so that the evaluation flows
better as you are using the tool

GO: can't talk about this part of the document; might work
for a standard web development tool, but not sure how much I
would have gained; document length -- these documents are
very very long--understand they need to be complete and
thorough, but why as individual documents?  One big huge
document harder to deal with -- would have preferred if
broken into chunks;

JT: format you would prefer?

GO: want small bites--little chunks; that's my preference

JT: web-based document divided into bits

GO: gives me a sense of accomplishment/progress to put
something behind me--just a personal preference

JT: well structured hypertext document

GO: talking specifically about length; formatting thing--
lots of individual pages which are smaller and easier to
digest, rather than one great big long document

JT: PJ has joined to discuss evaluation of Lotus--would you
go thorough that?

GO: my understanding was that we were going to concentrate
on process, not findings; lot of easy findings in my review-
-not applicable or not done, which made my job easier

PJ: one comment on the process--identify the version and the
environment that you are running Lotus on; need to make sure
that that information is provided in every evaluation

GO: absolutely; I was remiss in providing that

PJ: state class of tools up-front; mention categories it
doesn't apply to as well as those it does; purchasing agents
like that sort of thing

GO: sure, absolutely

PJ: just a comment back to the WG about need for info; need
a minimum set of background info before evaluations
published

JT: no disagreement--discussed before

CMN: asked for up front in front matter

PJ: do we allow things to be published that don't meet those
criteria

CMN: in general, no, our goal is to get useful info--if
enough info that is useful, going to ask them what platform
and version, etc. before I publish it; do try to update
stuff every so often and track and put notes in things
obsolete (this review is obsolete--the product has changed
or there is a new review, etc.)

PJ: we found it very useful to developers -- Domino designer
folks found feedback very useful

GO: glad to hear that!  Goal is to produce something useful
to somebody; basically, I've got a long established
commitment to notes and Domino, and I'm a fan of the
product; I also believe strongly in accessibility, and while
I acknowledge work gone into making R5 better, know that
when IBM decides to make something accessible, they do it
right; hope is that that what they have done may continue,
and that the feedback I provide is helpful to IBM; highlight
a few areas where output could be more standards compliant
and more accessible; point-of-view is of a user who wants to
have this

CMN: exercised editorial control over review process; not
useful just to say "this tool is inaccessible on all
levels"; value in partial basements is in illustrating
implementations, proof of concept, demonstrating problems in
ATAG documents; don't want to use AU web space simply to
trash trashy tools; important to see what happens as tools
move forward, rather than just nailing people to a post

JT: points which have been made support a formalized process

PJ: I did a quick summary back to the list--did you see
that?

GO: no--not subscribed to AU list, but will grab off the web

  message reference:
  <http://lists.w3.org/Archives/Public/w3c-wai-au/2001AprJun/181.html>

PJ: text equivalents for sound doesn't apply to Domino

GO: specifically said that; delighted that you didn't find
anything you fundamentally disagreed with; intrigued about
HTML markup debates; rather inelegantly named "doc type
sniffing" in IE6 -- are you aware of it?

PJ: I am, but not sure if Domino developers are

GO: would have thought that when IE6 comes out, the pressure
to be able to specify a DTD would increase, or so I would
have thought

PJ: other big issues?

GO: weren't many--3 major issues for me; fourth is a bit
left-field--when you insert images into documents or forms,
the ALT text should be input when the image is input

PJ: topic of discussion in WG; context sensitive--helps
author to define appropriate ALT text

GO: documentation -- would be useful to at least have
something that highlights how to make the HTML Domino
produces more accessible; lots of kludges, hacks, tricks
that I've stumbled across that aren't documented within the
product--think would be useful

PJ: thanks

JT: best if could find alternatives to the work-arounds

PJ: just commenting on 4.3 on list -- maybe as a minimum
could say "document a workaround" as an example or technique

JT: now part of GL6 -- distinction between authoring of
accessible content and the means -- your point lies in the
middle

PJ: think it belongs in the "how you use the tool" part

GO: sort of thing you get from PC magazines

PJ: in IBM speak it is called a Redbook

JT: could you send something to us telling us the version,
platform, etc.

WL: is there an executive summary that says that a person
with good intentions can use this tool to do good stuff?
Can you meet WCAG using that tool?

GO: in terms of P1, Domino's only barrier is the markup of
tables--can't identify table headers using the TH tag (can,
but only by hand, not using WYSIWYG tool); there is no
executive summary--would be more like an executive book,
rather than summary; using Domino to crate accessible HTML
is difficult

PJ: possible, but involved?

GO: yes

// Wendy Chisholm (WC) joins //

WL: consciousness/awareness level needs to be raised so that
people can be made aware that it is possible

GO: that's where documentation aspect enters into it for me

JT: we could help in terms of evaluation process;
interactive form could give a summary of what has been
filled in

GO: done reasonable amount of work for an article on the
topic--also includes how to create accessible web forms
using Domino

WL: could write a macro for Domino or Notes that would help
you replace things with TH

GO: no, you can't, as far as my understanding goes; some
bits that can't be implemented

PJ: have to defer to the developers on that

GO: some bits that you can't influence--the TH is one that I
highlighted

PJ: have to import your own HTML

WL: summary of the table's characteristics could be part of
the documentation

// GO leaves at 1:30am local time //

JT: on the agenda, have 3 things to cover--moving through
each GL to look at "at minimum" statements to see if they
comply with our criteria; EARL and ATAG; Evaluation Process

CMN: other item need to get to is future planning--where do
we go from here?  Should we look at that now, and then have
a break?

JT: try moving through checkpoints until 3:15

===========
GUIDELINE 4
===========

JT: [reads at minimums from 18 June and earlier today]

WC: fulfilled by the document?

JT: Document being evaluated

CMN: in generals always come up; the rest as applicable (if
found, ask, if not, don't)

WC: can check for a lot of the in generals

CMN: always have to do the in generals

JT: addresses question of whether it is sufficient to simply
link to WCAG and tell the author to check that document
applies

GB: text too strong still; "must always check when used
those questions pertaining to

CMN: when this utility runs, it must check

GB: example: Useablenet can be used by disabling rules

CMN: extension does not pass when checks disabled; if
environment allows for all checks to be done, it passes, if
a conflict where all checked and one where none checked then
the first passes, but the second does not; some of this is
covered by conformance statement

MK: danger in linking to WCAG directly--if expensive to be
online, they won't do it--can be helpful to use an external
resource that is available online

CMN: you'd have to say in conformance that "this tool only
applies when you are online"

MK: basic functionality has to be contained in the tool
itself

--------------
Checkpoint 4.2
--------------

JT: [reads checkpoint in toto] -- comments?

// NONE //

--------------
Checkpoint 4.3
--------------

JT: [reads checkpoint in toto] -- comments?

// NONE //

===========
GUIDELINE 5
===========

JT: [reads GL text]

--------------
Checkpoint 5.1
--------------

// Judy Brewer joins by phone by mistake and leaves //

CMN [reads new checkpoint text in toto]

MK: even if initiated by tool, user should still be able

JT: remove first sentence then?

CMN: gladly--any automated checking must be able to be
invoked manually easily

CMN: no minima for 5.2 and 5.3 -- isn't there a thread on
this?

// GJR suspends minuting in response to WC's gracious offer
to minute the remainder of the meeting //

Received on Monday, 16 July 2001 12:47:49 UTC