W3C Web Accessibility Initiative

WAI Authoring Tool Guidelines Working Group

WAI AU Teleconference - 9 June 1999


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


Outstanding Action Items:

Review of Latest Draft

The latest working group draft is http://www.w3.org/WAI/AU/WAI-AUTOOLS-19990602.



Action Items and Resolutions


Definition section

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

Definition of priorities

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"

Checkpoints 2.1.2, 2.1.3, 2.1.4,

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)

Checkpoint 2.1.6

CMN proposed make 2.1.6 a technique

WL: ok

GR: ok

resolved remove 2.1.6, make it a technique

Copyright  ©  1999 W3C (MIT, INRIA, Keio ), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.

Last Modified $Date: 2000/11/08 08:11:51 $ by Charles McCathieNevile