Re: minutes from last week published

Sorry I wasn't on the phone call.  I also forgot to send regrets.  For my
repentance I read the minutes.  Now I need to clarify a point or two about
the new IBM guidelines, the scope of the techniques document, and the
approach to comments on the techniques.

IBM guidelines:  For those of you who haven't read them, there are 5 sets
of guidelines, one for hardware, Lotus Notes, Java applications, Software
applications, and Web sites.  The only set that applies to the ATAG are the
ones on Software and Java applications.  IBM has no specific guidelines for
tool developers other than the ones on software and Java.  Only these two
would apply to ATAG 7.1 and actually were "filled out" by several tool
developers as they assessed themselves against the ATAG.

The IBM guidelines were written by myself, James Thatcher, Richard
Schwerdtfeger, Shannon Rapuano, Kim Stephens, Andi Snow-Weaver, and John
Steger.  They are not "pie-in-the-sky" because they actually have been used
by IBM developers, updated by us experts, re-used by developers, and again
updated by us experts.  We're getting it right and we're on version 2.1 of
the checklists.  Since we [IBM] don't have specifics guidelines on tools,
we don't have any ready made content for the ATAG Techniques Note. other
than 7.1.

Comments regarding "import from ERT" and "conformance evals":  The
relationship between the ERT, the "conformance evals", and the ATAG
Techniques Note need to be clarified.  I would not support importing from
the ERT anymore than importing from the IBM Java guidelines for ATAG 7.1.
Having a lot of links from the techniques to the ERT would be helpful.
Having a lot of links from the techniques to the "conformance evals" would
be helpful, and the same with Windows and Java applications guidelines.  So
that brings us to the unique purpose of the ATAG Techniques Note document.
In my mind it is unique in that it maps from the ATAG to the ERT and other
documents.  It's value is in the mapping.  If either the ERT, or the
Windows, or Java documents need help, those document should be helped and
not added to the techniques uniquely.  If there is an implementation
revealed in the "conformance evals" that we as a working group agree is
invalid or undesirable, and hopefully not in the ERT, then it could be
within the purpose of the techniques document to list what NOT to do.
These "DO NOT's" could be explained without specifically pointing to the
vendor(s) implementing them.  We would never know ALL the vendors doing the
bad or good things, so none of them should be listed in the techniques
document.

Comment regarding "subject lines" being "cool-o-matic": I'm confused.  Is
the latest two threads with the subject line "Techniques for 3.1 (get
alternative content)" and "techniques for 3.2 (separate structure/content
and presentation" the first two examples of the cool-o-matic approach?  And
when I want to talk about a specific technique that connects between ATAG
and the WCAG I would use the subject title "ATAG 3.2 WCAG 1.1" ?

Regards,
Phill Jenkins

[clip from minutes http://www.w3.org/WAI/AU/meetings/16feb00]

WL: been reading these type of GLs for 5 years, and most of it is
pie-in-the-sky;

CMN: yeah, but much which used to be pie-in-the-sky aren't anymore; as
historian trained to read documents and comparatively analyze them, so for
me (and maybe GJR) it is a rewarding and enjoyable experience

JT: what is best mechanism to populate Techniques document? import from
ERT?

WL: suggest that whoever wrote up notes at IBM be contacted to fill in some
blanks; same at Microsoft, Allaire, etc.

DB: could you repeat -- there was someone at the door

WL: need people who are writing guidelines for their company, show real
life examples of how ATAG satisfied by company's own projects

CMN: 2 approaches: do a conformance eval by sitting down with tool and
describing how it happens -- not a simple Yes or No, but how it does it or
how it fails to do it, and/or how it could do it consistent with the
"look-and-feel" of the tool; other thing is to sit down and run threads on
the AU list checkpoint by checkpoint -- would need to keep subject lines --
reply to message, so that they are automatically threaded in mail archive
-- makes tracking easier

WL: and vice versa -- if have new topic, create new subject line

CMN: yeah; running threads -- 4.2 WCAG 1.1, ATAG 4.2 WCAG 1.2; etc;

DB, JR, KB, WL, GJR: cool-o-matic

[end clip]

Received on Monday, 21 February 2000 12:34:22 UTC