- From: Charles McCathieNevile <charles@w3.org>
- Date: Thu, 10 Jun 1999 14:37:22 -0400 (EDT)
- To: WAI AU Guidelines <w3c-wai-au@w3.org>
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