raw minutes

With thanks to Jim for taking these. will be posted from the site later today

Charles

Attendees
Jim Allan
Charles McCathieNevile
Dick Brown 
Gregory Rosmaita
William Loughborough
Ian Jacobs
Wendy Chisholm
Jan Richards
Bruce Roberts

Definition section
cmn: trim defs in guidelines, expand def in techniques
additional proposal from gregory

cmn: use definition of rendered view

resolved: use gregory definition if cp 2.2 is accepted
editing view- editing window view
rendered view- displayed by tools - webpage view

GR:  Transformation definition
CMN: add include process of cahnging a document element to another element
within same dtd, ie change table into a list. use it amaya frequently
gr: tried to make def more general, accept cmn: addition
cmn: address defs in guidelines first, add any additonal to the techniques,
proposed cutting some defs in gls, and add to techniques
gr: need to pin defs down, need to be more specific, wendy added transform
to 2.2.1, does current def cover it
wc: yes
cmn: add new change
Jan: can you change to a non-equivelent element
gr: added equiv. to make sentence stand on itself
cmn: can send techniques and clarification to list, e.g. table with summary
and caption, change to def list, take summary and caption - make it title or
text that goes with list,
import gif to html doc, embedded title with gif, tool should take title and
use it as alt or title as appropriate
cmn: should we have orig transform def with cmn: addition, should be defined
gr: used in another TR, not defined in XSL doc

Resolved: gr: transform def with cmn: addition in next draft with discussion
on list

BR: def of priorities 1.3 goals, 2 goals, problem with second goal the word
"will", user can turn off accessibility features, likes "tool creates
accessible content"
Jan: authoring tool with promote and not itself produce accessible content.
WL: these are goals
cmn: it is a goal, tool can confrom and be able to create inaccessible
content
jan: make it more neutral - authoring tool with assist the author in writing
accessible content
wl: add "authoring tool with assist the author in writing accessible
content" to public list

resolved: add 3rd goal  "authoring tool with assist the author in writing
accessible content" to public list (with public discussion)

cp 2.1.2 , 3 , 4,
cmn: proposal from gr:
cmn added proposal 212 second wording from gr, "edition view, no change"
combine 213 and 214 into
can edit elements in 241
br: can these be techniques for making the ui accessible, concern for
platform specifics
db: share concerns,
cmn: these are requiremets, in techniques say these are requiremnets but
also follow platform specific guidelines
gr: these are identified problems with existing tools, consensus of group -
reference standard ui documents, the cps must be addressed
db: what am I supposed to follow
cmn: check off the box, by following your guildelines, you can refer back to
wai guidelines
if they conflict with platform guidelines, then platform guidelines are
wrong
gr: this is a concern, is there an example
br: app and os guidelines, accessibility is important, user adjustability,
getting at properties, might conflict or possibility of following more that
2 sets of guidelines, producing accessible output, many groups making
requirements for makeing the tool accessible,
cmn: look a techniques at 2.1.1 follow existing guidelines, provided
references. in all cps one of basic things - if this is covered in some
document - this is not a unique requirement.
only place see conflict, you dont have to make all properties accessible,
conflict arises if you don't agree with principals of guidelines, need
example case
jan: use in house rules, follow them, now what can I check off the augl,
group is trying to make cps broad and vital that they can't conflict.
cmn: one side-what if there is a conflict, other side-new os with no
guidelines, then what
gr: general broad principles, that are immutable, interoperable, corporate
guidelines are changing, w3c doc won't change often.
jan: some people don't follow their own guidelines
cmn: some guidelines misssing stuff
ij: w3c create vender neutral guidelines based on consensus.
cmn: 2 questions
should requirements be in if there may be a conflict
given cps is there some reason they do go in, are we requiring something
that will not help accessibility
should they be in the guidelines.
make the case that the cp is wrong
br: more work to to map conform between os guidelines and w3 guidleines
gr: should be no conflict
cmn: is the cp wrong
br: no one will say that
dan: all of 2.1 does it need to be in this document, output more important
than the toool being accessible
cmn: in charter that they are equal
dan: apply to specific tools
cmn: no, apply to word processors etc.
dan: much bigger problem with this, too broad,
cmn: its in the charter, w3 voted on by members,
dan: don't know about that process
cmn: must address the questions to meet charter
br: cp meet platform standard, are we doing  a through job, should the apply
to all application, much bigger undertaking
cmn: not a business plan issue, is it important to make the tool accessible,
br: do we fell that this a complete enough list beyond the platform
guidelines, need lots of people to look at it, like the trace folks
cmn: wendy? thoughts?
wc: scope-should apply to all tools that make web pages
this group is about making guidelines, what are you asking for
br: defines how to make an application accessible
ij: minimal guidelines set to make tool accessible, sufficient, not
complete, first defer to platform specific guidelines, then here are things
we must have
cmn: verification, go down check list, if I can't say it passed platform
specific guidelines then I failed,
e.g. linux, minimal, then check off platform specific cp, now move to augl
tool specific requirements,
cmn: put in techniques, to comply follow platform specific guidelines.
br: point to other guidelines out there
cmn: yes, we list guidelines from ms, ibm, lotus, sun, etc.
if you read techniques should be enough information, should be figure it
out, our job is not to write guidelines 1 to 1000 to cover all bases.
br: anybody disagree with follow platform guidelines
db: beginning process, many applications develop web content, too general,
may not follow same sets of guidelines as others
gr: conform to windows logo program, then conform to augls
db: ua group is expert in tool accessibility
cmn: yes, listing what you need to do to make the tool and output
accessible, based on charter, apply to frontpage, and mozilla editor, only
apply to web content development tools,
are the guidelines complete to ensure this is the case, they say follow
applicapble guidelines, agree this is vague, can't define it to nth degree,
(or we go to excruciating detail, then we go to 2 documents), applicable
guidelines are there and cover our needs,
our guidelines are a derivative of trace guidelines
db: guidelines are specif ic for making any application accessible
cmn: yes, can apply to any application, we are only concerned with authoring
tools, so is this a sufficient set
wl: concerned with are they necessary
cmn: necessary first then sufficient
db: cp cover all applications, if guidelines that are out there cover the
basic accessibility guidelines then why are they in the list
jan: useful as a slice,
db: then doing guidelines for all applications
ij: apply to authoring tools, may be rudundant, take the best of and
necessary, make it vendor neutral
db: authoring tools is very broad
cmn: word is used as a content tool,
wl: exclude other tools at our peril
db: can't say more, made my points needed
db: look at accessibililty of tool and content, already many guidelines that
address accessibility of the tool,
db: steering committee, w3 should have guidelines to make things easier to
use, many red flags
cmn: we are chartered by w3c, voted on by members, now we are executing the
charter, can't choose task, then must recharter the working group
wc: db is not saying recharter, we don't need to recreate tool accessibility
guidelines.
what about specific authoring tool guidelines, we highlight these to bring
them to forefront.
db: persuade company to add missing items to corporate guidelines
gr: not trying to cover all accessibility, looking at specific class of
tools
cmn: propose-recognize concern expressed about what is in document (editors
note), in next draft assume put stuff in (open issue) invite review, stir up
hornets nests to get review, based on responses then will have better
information, and a basis for decision making.
db: most people on group feel ok with current status, (db and wendy leave)
cmn: do we have agreement
wl: no, concerns are that we are engaging in a turf war, we are not
gr: this issue has passed

Resolved will have checkpoints 2.1 in next draft (still open to comment)
highligh 2.1 as a specific area for review.

cmn: proposal - 2 seperate checkpoints, combined common elements of cmn and
gr proposal, take gr proposal 2 staements and  make  one statement
gr: don't like "in an accessible way"
jan: don't like "identify"
wl: whats wrong with 2 seperate short ones, cmn
cmn: seem like a whole lot of redundancy,
jan: accessible way of doing something
cmn: to make life easier, replace some object with some graphic, be able to
swap and choose your identification mechanism
wl: 2.1.4 is neccesary
cmn: do we need 2 checkpoints
gr: cmn proposal seems fuzzy, make the check point have 2 sentences
wl: make 2.1.3 a technique
cmn: yes
cmn: must be able identify the object
gr: concerned with dropping 2.1.3, author

resolved 2.1.3 becomes a techniques, with cmn combination, (gr: objections
and concerns)

cmn: make 2.1.6 a technique
wl: ok
gr: ok

resolved remove  2.1.6, make it a technique

cmn: def of priorities, currents resolution to make 3 goals in next draft an
put on the list for discussion.

Jim Allan, Statewide Technical Support Specialist
Texas School for the Blind and Visually Impaired
1100 W. 45th St., Austin, Texas 78756
voice 512.206.9315    fax: 512.206.9453  http://www.tsbvi.edu/
"We shape our tools and thereafter our tools shape us." McLuhan, 1964

Received on Thursday, 10 June 1999 14:37:24 UTC