14:55:19 RRSAgent has joined #wai-wcag 14:55:19 is logging to http://www.w3.org/2005/01/26-wai-wcag-irc 14:56:18 ben has joined #wai-wcag 14:57:15 ben has left #wai-wcag 14:57:24 ben has joined #wai-wcag 14:58:16 wendy has joined #wai-wcag 14:58:30 scribe: wendy 14:58:54 agenda: http://lists.w3.org/Archives/Public/w3c-wai-gl/2005JanMar/0303.html 14:59:33 agenda+ Requirements for General techniques http://lists.w3.org/Archives/Public/w3c-wai-gl/2005JanMar/0301.html 14:59:50 agenda+ Requirements for checklists & techniques & test files http://www.w3.org/WAI/GL/WCAG20/WD-wcag2-tech-req-20050125.html 15:00:07 agenda+ Applicability Conditions http://lists.w3.org/Archives/Public/w3c-wai-gl/2005JanMar/0062 15:00:26 agenda+ Finish review of alt text test files http://www.w3.org/WAI/GL/WCAG20/tests/checkstatus.html#alttests 15:00:40 agenda+ Assign reviewers to test files http://www.w3.org/WAI/GL/WCAG20/tests/ 15:00:53 Date: 26 January 2005 15:00:56 WAI_WCAG(techniques)10:00AM has now started 15:01:03 +??P20 15:01:10 +Michael_Cooper 15:01:10 Meeting: WCAG WG TTF weekly telecon 15:01:12 -??P20 15:01:13 +??P20 15:01:33 +Wendy 15:01:47 +John_Slatin 15:02:13 +[Microsoft] 15:02:32 zakim, [Microsoft] is Jenae 15:02:32 +Jenae; got it 15:02:42 +??P28 15:02:50 zakim, ??P28 is Ben 15:02:50 +Ben; got it 15:03:09 David_ has joined #wai-wcag 15:03:15 test 15:03:41 Regrets: Chris Ridpath, Ken Kipnes, Becky Gibson, Sailesh Panchang, Don Evans, Neil Soiffer 15:03:50 +[IPcaller] 15:04:01 zakim, IPcaller is Alistair 15:04:01 +Alistair; got it 15:06:02 zakim, who's here? 15:06:02 On the phone I see David_MacDonald, Michael_Cooper, Wendy, John_Slatin, Jenae, Ben, Alistair 15:06:04 On IRC I see David_, wendy, ben, RRSAgent, Zakim, Michael 15:06:11 agenda? 15:06:30 zakim, drop item 4 15:06:30 agendum 4, Finish review of alt text test files http://www.w3.org/WAI/GL/WCAG20/tests/checkstatus.html#alttests, dropped 15:06:54 zakim, take up item 1 15:06:54 agendum 1. "Requirements for General techniques http://lists.w3.org/Archives/Public/w3c-wai-gl/2005JanMar/0301.html" taken up [from wendy] 15:07:11 zakim, who's making noise? 15:07:21 wendy, listening for 10 seconds I heard sound from the following: Michael_Cooper (59%), Alistair (29%) 15:10:28 js: examples should build on each other (from SC through general through other techs documents) 15:10:36 js: reads through proposal 15:11:55 q+ 15:12:01 q+ 15:12:11 dmd: can we get to a 9th grade level? 15:12:28 q+ 15:13:04 js: chose that b/c of a canadian literacy counsel says, "things that present new info or new ideas should prsent 7-9th grade level" 15:13:11 js: don't know that we can get tehre, but want to try. 15:14:13 js: have been spending a lot of time with this wrt techniques for 3.1 15:14:25 ack wendy 15:15:04 AliG has joined #wai-wcag 15:16:24 wac: bridge between docs - describe more detail? relationship to tech-specific - providing base. relation to checklists and test suites? if really testable, need test files? 15:16:43 ack mich 15:16:49 mc: 1. 15:17:00 mc: creating one example for every tech will be difficult. 15:17:12 js: what does it say if we can't do it? 15:17:32 mc: 1 entry per SC - are some 100% tech specific? 15:18:13 js: (rephrasing) are there any SC that are tech-specific? 15:18:13 q+ 15:18:14 ack ben 15:18:41 bc: reading score - when it comes to technical terms at technology-specific level, how does the score... 15:18:47 js: this is a requirement just for general 15:19:01 js: would like to aim for that for other docs, but doubt it for tech-specifics 15:19:23 bc: may not want to set it as goal for self in req doc. 15:19:27 q- 15:19:38 q+ to say "purpose of requirements" 15:20:09 bc: same diverse audience? general techniques may be more appropriate for specific audience. each document in our collection seems to have slightly diff audience. 15:20:11 ack jenae 15:20:28 ja: thinking about examples - there are several in the guidelines, how will we deal with those? 15:20:53 ja: we haven't mapped the examples from the techniques and how to apply techniques to those examples. 15:21:21 js: that's exactly what i was thinking about. run example x from guidelines, through general, through html and css, etc. help bind the documents together. 15:21:28 ack wendy 15:21:28 wendy, you wanted to say "purpose of requirements" 15:22:11 q+ 15:22:19 wac: can include "must", "should", "may" but purpose is for at each stage in Rec track to explain how we met the requirements 15:22:39 ack ali 15:22:39 wac: doesn't mean we can't put things in, just have different "strengths" 15:23:07 ag: testability of general techniques - this idea of one example, could get tricky. 15:23:32 ag: show the gen as part of each tech-specifics. i.e., general incorproated into each of the tech-specifics to elaborate on examples. 15:23:41 js: html tech incorp. general? 15:23:52 ag: when you start to test those, you'll need tech-specific examples. 15:24:38 q+ to say maybe examples can be in a technology is necessary, but further elaborated at tech specific level 15:24:40 ag: html techniques with general applied 15:24:54 js: talking about documents, test files, checklists? 15:24:57 ag: techniques documents 15:25:26 js: what would such a document look like? sounds like saying that general techniques would not be a separate document. 15:25:39 ag: then provide html general techniques, that are testable 15:25:48 js: then replicate the same material in other documents? 15:26:11 ack michael 15:26:11 Michael, you wanted to say maybe examples can be in a technology is necessary, but further elaborated at tech specific level 15:26:34 mc: maybe we can consider acceptable for examples to be tech-specific in general techniques. 15:26:49 mc: those examples could be further elaborated in the tech-specifics 15:27:17 mc: reluctant to get rid of general techniques, because a lot of discussion went into having them and discovering the need for them. 15:27:42 ag: would need a tech-specific example for every tech you are addressing, could have 50 examples. 15:28:04 mc: not necessarily. all have to do is show examples of good and bad color contrast. in html and css show the coding that leads to that. could just show color swatches. 15:28:29 js: don't see anything wrong with refering to specific technologies in general techniques. 15:28:50 js: already, in 2.4 level 3, there is a SC that says images have structure that users can access. in general tech, it refers to svg. 15:28:52 q+ 15:29:24 ack john 15:30:13 js: readability - knew it would be controversial. partly don't care if we don't write it down, but the readability formulas look at sentence length and word length. 15:30:24 js: for english, measured in # of words and syllables/word. 15:30:53 +Jeremy_Carroll 15:30:55 js: it looks at averages. so, it's not that you can't have long sentences or long words. it's averages. 15:31:37 js: important to make the documents as readable as we can make them - to support translations, readers who aren't familiar, and readers who are familiar with WCAG 1.0. 15:31:41 Lisa has joined #wai-wcag 15:31:48 js: and we should make the document as accessible as we can. 15:31:50 q- 15:32:01 zakim, Jeremy is Lisa 15:32:01 +Lisa; got it 15:33:18 mc: obviously, questions about reading levels, testability (what it means for general techs) and examples. 15:33:47 mc: do we like the idea generally of the general techs and where they live (section w/in techspecifics) 15:33:49 ack dav 15:34:14 +Alex_Li 15:34:24 dmd: ag brings up a good point, there could be some ppl who see html example in general techs and think thse are the html techniques. 15:34:52 dmd: general techs is something that we pass through. not sure that we should have an example for each one to be dogmatic. 15:35:00 dmd: concern that people will read through extra stuff. 15:35:18 q+ 15:35:19 dmd: if we keep it separated out, then should link to examples in the tech-specific documents. 15:35:35 ack j 15:36:21 js: re:examples - my guess is that devlopers will spend less time on gen techs than policy makers or trainers. 15:36:46 js: ppl who want gen techs are those for whom not interested in tech-specifics 15:37:02 al: or where we don't have tech-specifics 15:37:05 ack a 15:37:11 q+ to say we have to assume some intelligence on our readers, if we say "tech-specific examples in general techniques are just examples" we should expect them not to take them as dogma 15:37:22 ag: testability - may be overcomplicating. 15:38:13 ag: would need test files 15:38:22 mc: right, do we have test files for gen techs 15:38:31 js: yes. how would that work? 15:38:46 ack m 15:38:46 Michael, you wanted to say we have to assume some intelligence on our readers, if we say "tech-specific examples in general techniques are just examples" we should expect them not 15:38:49 ... to take them as dogma 15:39:02 q+ to say, "maybe not test files, but testable statements?" 15:39:11 we have to assume some intelligence on our readers, if we say "tech-specific examples in general techniques are just examples" we should expect them not to take them as dogma 15:39:31 mc: we have to assume some intelligence on our readers, if we say "tech-specific examples in general techniques are just examples" we should expect them not to take them as dogma 15:39:48 ack d 15:40:11 dmd: it's not on the table that we inc gen techs into tech-specific, if we were to reexamine that... 15:40:30 dmd: have a central pool and the specific docs would pull from that pool, so that there isn't repetition of work. 15:40:52 ack b 15:40:52 ben, you wanted to say, "maybe not test files, but testable statements?" 15:41:05 bc: maybe not test files, but testable statements? 15:41:18 bc: the checklist will have a decision tree. 15:41:38 bc: perhaps some of the testable statements (for gen techs) are met by following tests at technology-specific level. 15:41:43 mc: agree 15:41:44 ack j 15:42:30 js: re:possibility of integrating gen into tech-specific: since these will ultimately be in xml, presume possible to write xslt that would pull into tech-specific. 15:42:34 mc: that is possible 15:42:57 q+ 15:44:19 mc: propose that we add a section for general techniques in the reqs for techniques checklists, etc. 15:44:33 mc: also propose then incorporate changes to john's proposal and incorporate into that doc 15:45:16 action: john and michael - incorporate changes to gen techs requirements and incorporate those into requirements for WCAG 2.0 Checklists, Techniques, and Test Files 15:45:21 ack a 15:46:52 mc: don't think we should change directions right away, but put an ednote in the req that there is possible issue of where gen tech fits) 15:47:11 ag: additional point - use of vocabulary. could replace general words with tech-specific. 15:47:48 ag: end goal is that they are useful and that people don't need to wade through lots of info. 15:49:37 zakim, close item 1 15:49:37 agendum 1 closed 15:49:38 I see 3 items remaining on the agenda; the next one is 15:49:40 2. Requirements for checklists & techniques & test files http://www.w3.org/WAI/GL/WCAG20/WD-wcag2-tech-req-20050125.html [from wendy] 15:49:46 zakim, take up item 2 15:49:46 agendum 2. "Requirements for checklists & techniques & test files http://www.w3.org/WAI/GL/WCAG20/WD-wcag2-tech-req-20050125.html" taken up [from wendy] 15:50:48 mc: section 6 - test file requirements 15:53:24 q+ to say "must/should" 15:53:26 ack j 15:53:31 ja: compatibility of test files? 15:53:38 ja: compatibilty against browsers/user agents. 15:54:05 ja: "this works in browser A but works in browser B, C, D" 15:54:33 mc: may need to have test cases for browser variations 15:54:42 ja: in metadata, this test will work in these browsers... 15:54:59 ja: result of running the test 15:55:27 mc: perhaps user agent info for techniques move to test files 15:55:30 ack w 15:55:30 wendy, you wanted to say "must/should" 15:56:06 wac: concern about must have 1 test case for each technique, because of getting through process 15:56:23 wac: might be better to say "should" so lack of test cases doesn't trip us up in Rec process 15:56:38 wac: we can continue to expand test suites after Rec 15:57:01 ack l 15:57:53 ls: granularity - that is vague, in some cases not necessarily helpful. ppl may get lost in granularity. agree that want where makes sense, but shouldn't replace good test case w/something more granular b/c it is priority. 15:58:04 ls: that could trip us up later. 15:58:37 q+ 15:58:42 ls: don't know that will have an absolute true/false for each test. is there a way to state limitations of a test. 15:58:54 mc: change granularity to a should? 15:59:02 ls: will do it when it is useful 15:59:10 ls: but if not, then we won't 15:59:27 ls: maybe have a place for limitations or provisos 15:59:30 mc: in metadat? 15:59:34 q+ 15:59:37 ack 15:59:38 ack a 15:59:52 ag: "test cases must support a testable statement or statements" 16:00:19 ag: in other techs write test statements first then forge test cases. 16:00:28 mc: a test file is a test case? 16:00:49 ag: you've had html test cases in advance, if you hadn't had those, would first have had test statements then found test cases. 16:01:01 mc: is the metadata associated w/test file or testble statement? 16:01:05 ag: test file 16:01:10 q+ 16:01:12 ack b 16:01:55 q+ 16:01:57 bc: gv suggested that for the first one, "must be provided for every required technique..." so that perhaps dont' worry about for optional techs. only worry about those in checklist. 16:02:01 q+ 16:02:08 ack mi 16:02:20 ack a 16:03:02 mc: test files support a testable statement. the metadata is assoc with testable statements. 16:04:14 AG agrees 16:05:45 -Jenae 16:06:00 +[Microsoft] 16:06:17 zakim, Microsoft is Jenae 16:06:17 +Jenae; got it 16:06:38 ja: ppl use diff terms. we justneed to deterine what means for us and define. 16:06:39 q+ 16:06:48 ack q 16:08:36 wac: testable statement is the "root node" and what flows from it are test files and everything else that is combined to form the test case 16:08:51 ack w 16:09:11 mc: perhaps define things better and will make clearer 16:09:58 action: michael write definitions for testable statement, test file, and test case. update draft based on. include other edits as discussed. 16:13:02 wac: each techniques must have a testable statement. each technique should have a test case. 16:13:18 ag: or perhaps don't need test files. 16:13:59 mc: propose that we merge general techs into this. believe that accepted. 16:15:06 http://www.w3.org/2004/04/wcag-charter.html#deliverables 16:15:24 zakim, close this item 16:15:24 agendum 2 closed 16:15:25 I see 2 items remaining on the agenda; the next one is 16:15:27 3. Applicability Conditions http://lists.w3.org/Archives/Public/w3c-wai-gl/2005JanMar/0062 [from wendy] 16:15:31 zakim, take up item 3 16:15:31 agendum 3. "Applicability Conditions http://lists.w3.org/Archives/Public/w3c-wai-gl/2005JanMar/0062" taken up [from wendy] 16:15:35 zakim, ping in 5 minutes 16:15:35 ok, wendy 16:15:42 -John_Slatin 16:15:43 -David_MacDonald 16:15:45 -Lisa 16:15:50 -Ben 16:20:10 +??P0 16:20:29 zakim, ??P0 is David_MacDonald 16:20:29 +David_MacDonald; got it 16:20:35 wendy, you asked to be pinged at this time 16:20:49 zakim, who's on the phone? 16:20:50 On the phone I see Michael_Cooper, Wendy, Alistair, Alex_Li, Jenae, David_MacDonald 16:20:53 +??P1 16:20:59 zakim, ??P1 is Ben 16:20:59 +Ben; got it 16:21:40 +John_Slatin 16:22:02 ag: describes - http://lists.w3.org/Archives/Public/w3c-wai-gl/2005JanMar/0062 16:22:24 ag: ppl can know w/certainty if tech applies to them or not 16:23:39 mc: e.g. - frame title is applicable if frame is used 16:23:49 q+ 16:24:06 +Tim_Boland 16:24:54 ack w 16:25:11 q+ 16:25:31 wac: if this checklist oriented, is it mainly metadata? 16:25:36 wac: sounds like metadata used to assemble the checklist 16:25:38 ack b 16:26:08 bc: could be metadata, if techs are compendium of "all things" and some are required other optional. makes sense to expose info to the reader. 16:26:19 q+ 16:26:25 ack w 16:26:58 wac: an example where hard to determine if something applies or not? 16:27:12 ack j 16:27:36 js: the checklist of checkpoints (for WCAG 1.0), had applicability statements, "if you use frames..." and groups the relevant checkpoints. 16:27:42 q+ 16:28:13 q+ 16:28:19 q+ 16:28:36 ag: w/the 1.0 checklist, have groups. therefore, applicability statement given. 16:28:51 ag: only thing that might be missing is a document that tells youhow to recognize when youhave an item. 16:28:59 ag: how do you know if you have a data table? 16:29:08 ack w 16:30:17 wac: perhaps then by section. techniques are already grouped. 16:30:39 wac: e.g. of data tables, when to apply was to be included int he heading of that section. 16:30:42 ack m 16:31:01 mc: supporting the applicability conditions, in our software we've built applicability into every evaluation. 16:31:23 mc: have found that sometimes the applicability is straight forward. in some cases, less straightforward. 16:31:36 mc: useful to have that spelled out for every technique. 16:31:44 mc: fine it if is metadata and presented or not. 16:31:49 mc: quite important for checklists. 16:32:05 mc: can't assign pass/fail to something that is n/a 16:32:38 q+ to say "at min add applicaibility to dtd" 16:32:41 ack b 16:33:06 bc: summary attribute on tables. whenr eading a technique, "this only applies to data tables..." then maybe people wouldn't use summary in as many goofy ways. 16:33:12 ack w 16:33:12 wendy, you wanted to say "at min add applicaibility to dtd" 16:33:49 q+ 16:35:58 action: wac add applicability condition element after task to dtd (make it optional not required) 16:36:05 ack a 16:36:24 ag: about the term, "applic. conditions" could be one or more statements. 16:36:34 q+ 16:36:36 ag: if these 3 statements are yes, then this is applicable. 16:36:43 ack m 16:36:59 q+ 16:37:17 mc: would not want to have more than one applicability condition / technique. perhaps it has a few clauses. 16:37:22 ag: agrees 16:37:30 ag: one statement and prehaps conditions w/in the statement. 16:37:32 ack b 16:37:51 bc: are there subsets of pplicability conditions? required at level 1, 2... only if using element x... etc. 16:38:01 bc: there might be more than one 16:38:54 ximgblah blah thsen aoiuwer 16:39:50 q+ 16:40:15 ack a 16:40:40 I propose using instead of because it's already in the xmlspec dtd 16:40:49 ag: some things will relate only if building entire web site. site map only for scope of whole site. 16:41:16 scope: page, site, element 16:41:44 ack t 16:41:50 tb: which technology employed? 16:42:13 tb: could use html or could use xmlw/css. how do applicability conditions relate to technologies? 16:42:40 mc: my view is that the applicabilty to tech comes from the fact that it is an html-techs document. 16:43:13 RRSAgent, make log world 16:43:59 ag: the work re: checklists, supported a lot of the things about what ac would look like, 16:45:40 http://www.accessinmind.com/w3c/HTML14_4.html 16:46:21 http://www.accessinmind.com/w3c/ConceptPage2.html 16:46:55 ag: technology, scope, content 16:49:12 wac: conformance level, content/element, description/prose, scope. technology inherited from document it is in. 16:49:19 zakim, close this item 16:49:19 agendum 3 closed 16:49:21 I see 1 item remaining on the agenda: 16:49:23 4. Assign reviewers to test files http://www.w3.org/WAI/GL/WCAG20/tests/ [from wendy] 16:49:26 zakim, take up item 4 16:49:26 agendum 4. "Assign reviewers to test files http://www.w3.org/WAI/GL/WCAG20/tests/" taken up [from wendy] 16:49:49 mc: there are a lot of existing test files that have not been accepted in a formal way and not official part of test suite (only about 10 tests that are). 16:50:25 mc: hoping to get people to take batches of test files, read them, identify any issues, and send post to the list and propose, "should accept this one" or "discuss this part of this one" or "accept this one with changes xy, z" etc. 16:50:42 dmd: hoping that people will look at them, see if have same problems or acceptance? 16:50:58 mc: yes, reviewer should be as thorough as possible. 16:51:06 q+ 16:51:07 tb: what are the metrics for review? 16:52:08 mc: look at test and its metadata. does the test support the technique? does the requirement have the same priority as the technique? is the test workable in the true/false sense? is the requirement in the test is something that should be a requirmeent? 16:52:24 q+ to say, "wording - does it synch with success criteria. vocabulary used in synch" 16:53:06 mc: should alt-text be short? we discussed what was short and if requried. 16:53:28 ack wendy 16:53:28 wendy, you wanted to say, "wording - does it synch with success criteria. vocabulary used in synch" 16:54:15 wac: additionally: are there any gotchas? anything that will cause contention when goes for public review? 16:54:17 ack a 16:54:34 ag: write testable statement for each technique. then look at the tests and determine how well they are mapping to the testable statements. 16:55:03 mc: may come up with very different statments that what exist. 16:55:12 ag: would see how well the tests map to the techniques. 16:56:45 q+ 16:58:18 http://www.w3.org/WAI/GL/2004/11/19-sc-techniques-mapping.html 16:59:29 ack b 16:59:43 dmd: look at technique, then look at the test case 17:01:06 q+ 17:01:14 bc: the thing to look for is a reality check. what do our current guideliens and techniques actuallys ay. 17:01:33 dmd: is there one for 1.0? 17:01:33 http://www.w3.org/TR/AERT 17:01:40 mc: closest thing is AERT 17:01:45 mc: no test files 17:07:34 ' 17:07:37 ' 17:07:39 ''''''"/ 17:07:40 ' 17:07:48 -Jenae 17:10:38 mc: arranging batches about 6-12 17:10:54 js: requests small batch under input] 17:10:55 -John_Slatin 17:13:15 -Tim_Boland 17:13:17 -Michael_Cooper 17:13:18 -Alex_Li 17:13:19 -Wendy 17:13:20 -Ben 17:13:20 -Alistair 17:13:22 -David_MacDonald 17:13:24 WAI_WCAG(techniques)10:00AM has ended 17:13:25 Attendees were Michael_Cooper, David_MacDonald, Wendy, John_Slatin, Jenae, Ben, [IPcaller], Alistair, Jeremy_Carroll, Lisa, Alex_Li, [Microsoft], Tim_Boland 17:13:26 alistair - yes, send it! :) 17:13:34 sounds good. happy to hear only 10 tasks that don't map. 17:14:00 Present: Michael_Cooper, David_MacDonald, Wendy, John_Slatin, Jenae, Ben, Alistair, Lisa, Alex_Li, Tim_Boland 17:14:08 RRSAgent, draft minutes 17:46:11 zakim, bye 17:46:11 Zakim has left #wai-wcag 17:46:14 RRSAgent, bye 17:46:14 I see 3 open action items: 17:46:14 ACTION: john and michael - incorporate changes to gen techs requirements and incorporate those into requirements for WCAG 2.0 Checklists, Techniques, and Test Files [1] 17:46:14 recorded in http://www.w3.org/2005/01/26-wai-wcag-irc#T15-45-16 17:46:14 ACTION: michael write definitions for testable statement, test file, and test case. update draft based on. include other edits as discussed. [2] 17:46:14 recorded in http://www.w3.org/2005/01/26-wai-wcag-irc#T16-09-58 17:46:14 ACTION: wac add applicability condition element after task to dtd (make it optional not required) [3] 17:46:14 recorded in http://www.w3.org/2005/01/26-wai-wcag-irc#T16-35-58