raw minutes 23 april 2001 AU telecon

Authoring Tools (AU) Telecon 23 April 2001

==========
ATTENDANCE
==========
Present
  Marjolein Katsma (MK)
  Charles McCathieNevile (CMN/chair)
  Matthias Mueller (MM)
  Jan Richards (JR)
  Gregory J. Rosmaita (GJR/scribe)
  Heather Swayne (HS)
  Jutta Treviranus (JT/joined late)
Regrets
  William Loughborough (WL)


===========
RESOLUTIONS
===========
1. move Checkpoint 4.3 to Guideline 1

===========-
ACTION ITEMS
============
-=--------------
NEW ACTION ITEMS
-=--------------
1. CMN: announce that AU F2F will transpire in Amsterdam at
CWI the week of June 18 and confirm venue, etc.
2. AU WG: Review UAAG Last Call Cubed Draft, located at:
  <http://www.w3.org/TR/2001/WD-UAAG10-20010409/>
and the associated Techniques document, located at:
  <http://www.w3.org/TR/2001/WD-UAAG10-TECHS-20010409/>
and comment on list; any issues raised will be discussed at
next AU telecon on April 30, 2001
3. MK: provide wording for new 6.3 describing dedicated
section that explains process of producing accessible
content
4. GJR: provide wording for new 6.3/react to MK's proposal

------------------------
OUTSTANDING ACTION ITEMS
------------------------
1. JT: sent text for 1.3 to AU list

----------------------
COMPLETED ACTION ITEMS
----------------------
1. CMN: was in Amsterdam for PF F2F and traveling back to Oz;
all action items carried over

=======
MINUTES
=======

-----------------------------
ITEM ONE: HOUSEKEEPING ISSUES
-----------------------------

1A. Face2Face in Amsterdam

  YES: CMN, GJR, JT
  NO: Heather Swayne (HS)
  PROBABLE: MK, JR
  UNKNOWN: MM (will follow up with Macromedia)

CMN: ER, WCAG, HTML, and XForms will all be meeting at CWI
the same week in June; ATAG would like to meet in concert
with each

// ACTION CMN: announce that AU F2F will transpire in
Amsterdam at CWI the week of June 18/confirm venue, etc. //

1A. Review of UAAG

GJR: have we decided on a process by which we as a group
will review the Last Call Cubed draft of the User Agent
Accessibility Guidelines?

who has read UAAG?
     YES: GJR, CMN

who needs to review UAAG?
     MK, MM, JR, HS

CMN: my issues are mainly editorial

GJR: do we have a list of issues from the last 2 last calls?

CMN: will dig up both personal and WG comments and will
double-check any past comments logged by group

GJR: no issues right now; those I raised which feel have
cross-over with ATAG have been tabled for discussion of UAAG
2.0

JR: will review document within next week and make comments
if have any

MK: I will try!

CMN: will send comments to AU list

  // ACTION AU WG: Review UAAG Last Call Cubed Draft,
  located at:
    <http://www.w3.org/TR/2001/WD-UAAG10-20010409/>
  and the associated Techniques document, located at:
    <http://www.w3.org/TR/2001/WD-UAAG10-TECHS-20010409/>
  and comment on list; any issues raised will be discussed
  at next AU telecon on April 30, 2001 //


-----------------------
AGENDA ITEM 2: ATAG 2.0
-----------------------

JR: where did we leave off?

CMN: we had gotten all the way through GL2

JR: ok, picking up with GL3: "Support creation of accessible
content" -- didn't change 3.1 and 3.2, save for insertion of
question marks to indicate whether or not should have sub-
text

HS: prompt used in 3.1, definition still requires user or
author input; thought prompt was informative, allowing
author to do something

JR: defection of prompt needs to be changed for this version

HS: problem is global definition for all working groups

JR: not one-definition-fits-all, but central

CMN: overall goal--unify definitions; first goal, clarify
what definitions are and how they are being used; can't
change document that already has TR status to change the
definition; logged as erratum

HS: will definition be changed in ATAG2?

CMN: is a noted erratum for ATAG1; definition will change in
ATAG2

CMN: do we need sub-text for 3.1 and 3.2

JR: yes, controversy around prompt and other ambiguities;
once get good definition of prompt nailed down, could use a
brief synopsis as basis for sub-text; same for 3.2

CMN: ok

JR: section 3.3 -- removed and combined with 1.4

   3.3 "Ensure prepackaged..."
   1.4 "Ensure all pre-authored content..."

brings templates and multimedia objects together

     MK, GJR, CMN: good
     HS, MM: no comment

JR: generalized old 3.4 and renumbered 3.3

     GJR, CMN, MK: good

JR: new 3.4 (old 3.5) -- no change

MK: references to techniques still point to techniques for
old checkpoint numbers; will you be fixing correspondence?

JR: yes; this is just a first pass--expect a lot of changes

JR: GL4: Checking and Correcting; 4.1 "Check for and inform
the author..." changed sub-text to: "at a minimum, prompt
author to manually check" -- emphasizes what needs to be
done basically and what is ideal;

MM: good change--like emphasis on automation

JR: checkpoint 4.2 -- added second sentence to sub-text to
bring in parallel with sub-text for 4.1 (same structure)

CMN: not quite sure why, but am ambivalent for need for
matching structure; don't have

MK: structure same as 4.1, but sense of 4.2 different

JR: wanted to get term "automated tools" in there--not
wedded to wording or structure like to see words "automated
tools" in there somewhere

MK: what about words to the effect: "could be augmented by
automatic tools..." to what is already there

CMN: yeah, ideally integrate automated repair tools

JR: ideally, repair should be as automated and painless as
possible

CMN: so we should state: "ideally, integrate automated
repair tools..."

JR: 4.3 eliminated (Respect markup) felt adequately covered
by 1.2 (preserve markup during transforms)

CMN: don't want to remove this checkpoint; 2 basic
differences: idea of "don't mess around with markup if
explicitly ask you not to do so"--tool should not feel free
to remove markup unless author gives ok (can be done with
configuration setting); other deals with transformation
between markup languages; make 1.2 more explicit that covers
content of the markup and that 4.3 about the markup itself

JR: ok; although doesn't need to be in GL4; maybe should
move checkpoint 4.3 to GL1

CMN: sounds fine to me

  // RESOLVED: move ATAG1 4.3 to GL1 //

JR: checkpoint 4.4 unchanged; checkpoint 4.5 removed (felt
covered by 3.2)

CMN: agreed

JR: GL5: "integrate into overall look-and-feel" -- minor
editorial changes to 5.1 (made more specific); 5.2 and 6.1
unchanged; 6.2 editorially tweaked (

MK: good--examples are a techniques!

JR: checkpoint 6.3 -- favor of removing and making a
technique for 4.1

MK: needs to be integrated into overall documentation

JR: people may not be looking for separate section
describing accessible authoring practices

CMN: 6.2 requires integration; as a lower priority feature,
this is something that is a P3 and is useful

GJR: people want and need this; shouldn't be dropped

MK: as technique--I'd rather have a separate index that can
guide author towards creating accessible content

  // JT joins //

CMN: don't think should remove--lower priority than 6.2

GJR: a) priority level not grounds for deletion; b) need for
a dedicated section that explains how to create accessible
content, not on the microscopic or over-general level, but
guidance that actually assists authors in making the most
appropriate choices for the mechanisms they will employ to
deliver content and the functionality they build into their
pages/docs/sites; it should be something that provides the
author with assistance in making implementation decisions,
not just on a per element or per-page basis, but on a site-
wide basis; this is where I would hope to find meaningful
discussion of and descriptions of how to provide proper
schemas in an XML authoring tool, as well as the
ramifications of whatever design options I may be
considering (or, if I am a manager, which I am considering
having my drones implement)

JR: you're talking about 2 different things--element by
element assistance and what you need to do to ensure overall
accessibility

CMN: is dedicated section less important than integrated
help?

GJR: no--without question, per element and per attribute
documentation must include accessibility info, but that is
for those who have already decided to provide functionality
X with solution Y; 6.3 should provide soup-to-nuts guidance-
-outline design considerations and
accessibility/interoperability ramifications before
implementation decisions are made

MK: would prefer it contained general info on what is
accessibility and how can you use this tool to achieve it

  // ACTION MK: provide wording for dedicated section that
  explains process of producing accessible content //

JT: this checkpoint came out of GL7 historically--described
keyboard shortcuts and other accessibility features of tool
qua tool

GJR: mixing concepts of the accessibility features of the
tool qua tool and the accessibility features of the markup
languages supported by tool

JT: shouldn't cover both--GL6 accessible content GL7
accessibility of tool

GJR: then wording needs to be changed to strip legacy of GL7
out of 6.3

  // ACTION GJR: provide wording for new 6.3/react to MK's
  proposal //

JR: 7.1 -- changed "use all.."  to "follow all..."; 7.2 --
added to sub-text; combine 7.3 and 7.5; renumber old 7.4 new
7.3

CMN: would subsume into 1.1 -- reflects 7.1 and 1.1

JT: old 7.4 edit all properties of each element, old 7.5
easy navigation through content as authored; use structure
while navigating, edit via structure, edit properties

MK: if tool allows navigation by structure, that should be
available in accessible way

JR: editing via structure still there

MK: requiring a feature that not all tools may have

JR: true

MK: it should read "If the tool supports navigation via
structure, allow editing..." or something to that effect

CMN: would argue that we already recognize that not all
tools support structured editing, but did want to make this
explicit requirement because functionality so important

JR: 7.3 and 7.5 both covered by 7.1

CMN: no--nothing about editing structure inherent in 7.1

JR: are we in effect saying that an authoring tool must have
this feature?

JT: no, the purpose of 7.3 and 7.5 are to point out
principles and needs that may not be obvious to someone
attempting to implement ATAG

CMN: may be non-existent

JR: to make tool accessible, need to allow things to be done
that don't allow anyone to do?

CMN: tools that don't allow editing properties are appalling
tools anyway; don't know if covered in 1.1

MK: requiring navigation by structure is good, if have it
should be accessible, but not having functionality in tool
for anyone doesn't mean tool isn't going to be able to
produce accessible content

JT: this is about the user of the tool and the ability to
use the tool; for a tool to be used by someone who can't use
a mouse, uses a single-switch, etc. need to have a faster
navigatable way of going through structure

MK: what about search through structure as a means of
providing equivalent access to properties without native
support for structured navigation?

CMN: propose it on list; we're out of time, and I need to
break off for another telecon

// meeting adjourned 1pm U.S. E.D.S.T //
// next meeting: 30 April 2001 12pm U.S. E.D.S.T. //

----------------------------------------------------------------
ACCOUNTABILITY, n.  The mother of caution.
                     -- Ambrose Bierce, _The Devil's Dictionary_
----------------------------------------------------------------
Gregory J. Rosmaita:  oedipus@hicom.net
Camera Obscura: http://www.hicom.net/~oedipus/index.html
VICUG NYC: http://www.hicom.net/~oedipus/vicug/index.html
Read 'Em & Speak: http://www.hicom.net/~oedipus/books/index.html
----------------------------------------------------------------

Received on Monday, 23 April 2001 15:21:47 UTC