phone: Bengt Farre, Andi Snow Weaver, Ken Kipnes, Wendy Chisholm, Cynthia Shelly, Matt May, Ben Caldwell, Lisa Seeman, Jason White, John Slatin
IRC: wendy, MattSEA, Ben, bengt, Zakim, rscano
Loretta Guarino Reid, Lee Roberts, Eudenia Slaydon, Patrizia Bertini, Avi Arditti, Gregg Vanderheiden, Doyle Burnett
WAC asks about long emails vs shorter
ASW like all comments/proposals for one checkpoint in one email
[MattSEA] +1 on fewer emails
CS a bit overwhelming. put in "Pile of long emails to deal with later"
I think that is best to have more mails with the reference in the object line, so we could archive it well...
general consensus is longer emails that group proposals are ok.
[rscano] for eg: if checkpoint 1.2 we could start the mail with [1.2] .....
cs if have a lot of discussion break into smaller.
wac asks why not too many responses on the list. busy? fear of responses? need more time?
wac if you prefer to send comments to me (or gregg or jason) personally, please send them to us privately.
wac we want to do more of the consensus building on the list and save the telecons for more contentious issues.
[rscano] I think that the problem is due that the mail are too long and is difficoult to follow all the argoments. If we split them in checkpoints and start the messages with the subject line [x.x] (eg. [1.2]) i think that most of us could focus in single point optimizing the results
wac if you have ideas or concerns about this approach, pls send to the list or one of us privately.
bf a technical question - i get responses from people saying "don't send me this email"
wac yes, there is an issue. i think an alisa was subscribed.
action wac: clean up the mailing list. send email to all people don't recognize and ask them if they want to be unsubsribed.
[bengt] I get email saying I have just subscribed to a chemical newsletter in England, as a reaction to posting to the list and it comes from a company in England.
[wendy] please send me a copy of the email
[bengt] sure
[rscano] i think that you have received an autoreply... i also have received this
jw plan to discuss 4.1 in a couple weeks. however, any initial reactions to avi's proposal?
ls brings up point of rdf and accessibility as related to making text less ambiguous.
ls wonders if that is a route we want to go. perhaps as an alternative for all checkpoints.
ls poses 2 questions: 1. do we want to promote developing of techniques? 2. how do we want 4.1 to relate to that?
jw proposes that metadata is a technique that can be used and that we write success criteria so that the techniqeus can be used when the technology is available.
jw wonders about relation to 4.1, but realizes need to keep options open.
jw wonders if there are any success criteria that may need to be rewritten?
ls thinks it is likely several will need to be rewritten.
ls posits that it might be easiest to have a top-level statement that describes the needs and considerations for metadata.
wac want to draft something?
jw suggests taking aa's proposal for 4.1 as starting point.
action ls draft something using 4.1 as a starting point that will address meta-data with a top-level statement.
jw advises getting it out in next week so that we can discuss it as part of 4.1 discussion on 19 december (we're still confirming this it the date due to people's availability)
js i have a training workshop that day. not likely to make the mtg.
[bengt] Its ok for me
[rscano] ok for me too
resolved: (proposed) discuss 4.1 on 19 december assuming avi is available that day (others who are primary to the discussion seem to be available).
bc resolution on success criteria vs provisions? (as suggested by ian)
bc 2 votes in favor of success criteria
bf "provisio" is correct work. provision is something you eat.
bf success criteria
mm speaks from perspective as team contact for both AUWG and UAWG. AUWG has no intention to use term "provision." UAAG is much more technical than both ATAG and WCAG.
asw success criteria ok
js has heard that people like the phrase "success criteria"...have expressed "relief" even.
kk like success criteria. but not a strong opinion.
[rscano] yes.. as i told in my e-mail... "Success" criteria mean an objective to reach...
jw also, success criteria. more concerned about substance than what they are called.
[rscano] "success criteria" is more clear for non-english people that will read the guidelines
asw will there be an issue when take to Rec?
jw there might be desire to harmonize language.
action wac: double check with judy, janet, and ian to see if use of phrase "success criteria" will be issue as we move forward. will there be a harmonization issue?
resolved: (proposed) continue using the phrase "success criteria" rather than "provision" as suggested by ian (unless an effort causes us to harmonize).
wac if no response on list for one week, ok to move it into a draft? i.e., does silence mean it's ok?
asw one week might not be enough.
cs for this set, can we have one more week since that rule wasn't in effect yet?
asw new draft every week?
jw that's the plan every week or two.
asw i like that.
bc ongoing editing helpful for me.
resolved: (proposed) drafts more often is a good thing.
[rscano] good... my suggestion to use for eg. [1.2] .... for the subject line for a well-organized discussion the different point ?
resolved: (proposed) proposals will sit on the list for a week and if no comments are received they will be incorporated into the next draft.
wac outlines issue with screen shots. 2 examples. one is accessible and usable, the 2nd might be accessible but not usable.
wac inspired by comments from SAP re: web apps.
wac many checkpoints focus on a single element not the "big picture" of funciton of whoel page or app.
js agrees it is an issue. wonders if we can address in introduction?
jw equivalent under 1.1 is "provide same info and function". thinks it covers the issue.
jw guidelines have to understood as an integrated whole.
jw agree that 5.4 has to do more than refer to UAAG.
[rscano] but user interface could be also, for example, a backoffice of a CMS and this involve the ATAG also
wac agree with js, comes to a design issue.
wac do not think 1.1 does enough about this.
js the text does not often replace on-screen information. (i.e., off-screen text and on-screen text are often different)
js can be redundancy, incoherence from two sets of text that should be integrated.
js thus, a design issue.
js with current technology, not practical. requires maintaining different versions.
jw they can be automatically generated.
js someone has to think about what is on-screen and what is off-screen.
wac thinks something needed at success criteria, perhaps just a note? some way to raise awareness?
asw worries that extra text gets in the way of people who don't need it.
wac thinks this is primarily related to instructional applications. perhaps a profile specific to that?
wac e.g. documentation for a user agent: mouse instruction covered separately from keyboard features.
jw agrees there is a need for diversity in presenting information, but no one requires or encourages it.
bengt - what was your point?
[bengt] what is actually seen ? or heard ? off-screen is that metadata encoded ?
js proposes: level 3 criterion - the material has been reviewed and believe that non-text material and text material work effectively together.
jw OR perhaps - the text equivalent and surrounding text...
wac wonders if others agree this is an issue?
asw does not believe it goes into the guidelines.
[rscano] js propose with the jw integration or the js propose?
kk agrees probably not part of this guideline, but an issue. oftentimes screen shots are used if writers can't describe something well.
delete well.
[bengt] I agree
kk suggests perhaps a different guideline - about writing good documentation.
jw suggests is it difficult to generalize from a couple specific examples.
js it doesn't say that all of the elements have to work together. the guidelines tend to address individual elements (images, tables, form controls, etc.).
js for heuristic reasons it is useful to say, "for image x supply y."
jw you would run into issues with guideline 4. the conformance to most of the guidelines are not on element by element basis - it's the whole content of the scope of the conformance claim.
jw thus, guidelines 3 and 4 ought to deal with it. perhaps a few extra criteria.
[bengt] documentation should be considered and be accessible and have a checkpoint 4.? 5.?
action: jw, js, wac propose a way to address the issue raised by SAP concerning screen shots and checkpoint 1.1 that lead to a design issue about the accessibility of the "big picture."
jw an issue is that cross-references between checkpoints is not explicit.
$Date: 2002/12/09 23:20:23 $ Wendy Chisholm