WAI Authoring Tool Guidelines Working Group
Chair: Charles McCathieNevile, <charles@w3.org>
Date: Wednesday 9 June 1999
Time: 3.30pm - 5:00pm Boston time (1930Z - 2100Z)
Phone number: Tobin Bridge, +1 (617) 252 7000
The latest working group draft is http://www.w3.org/WAI/AU/WAI-AUTOOLS-19990602.
cmn: trim defs in guidelines, expand def in techniques additional proposal from gregory
cmn: use definition of rendered view
resolved: use gregory's 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 changing 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: as a general note we should address defs in guidelines document first, add any additonal to the techniques, proposed cutting some defs in guidelines document, 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
JR: 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's transform definition with cmn's addition in next draft. Further discussion on list
BR: definition of priorities: 2 goals, problem with second goal the word "will", user can turn off accessibility features, I like "tool creates accessible content"
JR: authoring tool with promote and not itself produce accessible content.
WL: these are goals
CMN: it is a goal, tool can conform and be able to create inaccessible content
JR: 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"
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
JR: 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.
JR: 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?, and assuming checkpoints 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 checkpoint wrong
BR: no one will say that
DB: 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
DB: apply to specific tools
CMN: no, apply to word processors etc.
DB: much bigger problem with this, too broad,
CMN: its in the charter, w3 voted on by members,
DB: don't know about that process
CMN: We must address the questions to meet charter
BR: with checkpoints to 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 these guidelines
DB: 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 specific 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 for them?
WL: concerned with are they necessary
cmn: necessary first then sufficient
DB: checkpoints cover all applications, if guidelines that are out there cover the basic accessibility guidelines then why are they in the list
JR: 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 look at accessibililty of tool and content, already many guidelines that address accessibility of the tool, 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. hat 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 for 2.1 in next draft (still open to comment) highlight 2.1 as a specific area for review.
CMN: proposal - 2 seperate checkpoints, combined common elements of CMN and GR proposal, take GR's proposed 2 statements and make one statement
GR: don't like "in an accessible way"
JR: don't like "identify"
WL: whats wrong with 2 seperate short ones?
CMN: seem like a whole lot of redundancy,
JR: 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's proposal seems fuzzy, make the check point have 2 sentences
WL: make 2.1.3 a technique
CMN: yes. must be able identify the object
GR: concerned with dropping 2.1.3, author
resolved 2.1.3 becomes a techniques, with CMN's combination, (GR: dissenting)
CMN proposed make 2.1.6 a technique
WL: ok
GR: ok
resolved remove 2.1.6, make it a technique
Last Modified $Date: 2000/11/08 08:11:51 $ by Charles McCathieNevile