13:57:17 RRSAgent has joined #wai-wcag 13:57:17 logging to http://www.w3.org/2005/04/06-wai-wcag-irc 13:59:00 Becky_Gibson has joined #wai-wcag 13:59:12 WAI_WCAG(techniques)10:00AM has now started 13:59:19 +Becky_Gibson 13:59:55 +??P20 14:00:00 zakim, ??P20 is Ben 14:00:00 +Ben; got it 14:00:30 Chair: Michael_Cooper 14:00:32 +Michael_Cooper 14:01:17 ChrisR has joined #wai-wcag 14:01:26 +Don_Evans 14:02:13 +[IPcaller] 14:02:29 zakim, ipcaller is Chris_Ridpath 14:02:29 +Chris_Ridpath; got it 14:03:01 +Dave_MacDonald 14:04:10 David has joined #wai-wcag 14:04:20 test 14:05:11 zakim, who's on the call 14:05:11 I don't understand 'who's on the call', David 14:05:28 zakim, I am Ben 14:05:28 ok, ben, I now associate you with Ben 14:05:33 scribe: Ben 14:05:54 mc: agenda for today: 14:06:07 agenda + Impact of externalized baseline on Techniques 14:06:21 agenda + Impact of externalized baseline on Requirements 14:06:26 +Tim_Boland 14:06:30 agenda + Need to agree on matrix of UA for which we provide support information 14:06:40 agenda + Test file reviews (if time) 14:07:06 mc: re: test files - need to follow up with people on assignments and make new assignments 14:07:18 zakim, who is here? 14:07:18 On the phone I see Becky_Gibson, Ben, Michael_Cooper, Don_Evans, Chris_Ridpath, Dave_MacDonald, Tim_Boland 14:07:20 On IRC I see David, ChrisR, Becky_Gibson, RRSAgent, Zakim, Michael, ben 14:07:44 zakim, next agendum 14:07:44 agendum 1. "Impact of externalized baseline on Techniques" taken up [from ben] 14:08:03 message summarizing topic: http://lists.w3.org/Archives/Public/w3c-wai-gl/2005AprJun/0010.html 14:08:25 mc: three generic baselines proposed, a modern-day mainstream baseline and a future/perfect world baseline 14:09:15 mc: then looked at how each technique applies to these baselines - conclusion was that things don't really break across baselines (it is possible to follow techniques to meet needs of both basic and mainstream) 14:09:49 mc: big hole is that techniques for scripting currently assume need for alternatives 14:09:59 tb: what's relationship between 3 hypothetical baselines? 14:10:26 mc: one assumes you support HTML with caveats for things like accesskey (support HTML, but provide fallbacks for everythine else) 14:10:44 mc: mainstream was that you support HTML, CSS, Javascript and accessibility features of plugins 14:11:01 mc: didn't break it down into particular versions of the technologies 14:11:18 mc: future was that whatever tech you're using, features are supported by user agents world-wide. 14:12:17 mc: in general, a lot of techniques become optional the further forward we go, but the further backward we go, the more techniques are in the category of "repair" 14:13:22 tb: in terms of testing, is there widespread coverage of techniques that are sufficient? 14:13:47 mc: didn't analyze that out fullly - think that if we accept baseline, we'll need to look for holes in techniques 14:14:58 bc: sense is that we don't have real good coverage of sufficient techniques 14:15:47 tb: so should those guidelines/sc be included if we dont' have sufficient techniques? 14:16:07 bc: think it's more that we still need to write sufficient techniques 14:17:31 mc: graceful degredation (last paragraph of summary) - there are some examples where if technology is not supported (ex. CSS is off) do we then make up for that in the baseline supported technology (fallbacks that recommend table layouts or font tags)?? 14:18:11 mc: if we recommend using CSS to expose semantic structure or make things more understandable, some of the understandability goes away if CSS if not enabled. 14:18:34 dm: slippery slope to make old technology that has been deprecated make up for this. 14:18:49 mc: also breaks the idea that we could have a union set of techniques that addresses multiple baselines 14:20:24 bc: in CSS, design principle is that this can be turned off, so recc. that we not create HTML-only techniques around table-layout or font elements. 14:21:02 mc: what about scripts? would we care about scripts failing gracefully in a graphical browser baseline? 14:21:30 bg: to me that's why you have that baseline, assume your audience supports it and go from there 14:22:11 dm: degrade gracefully came up with 4.2 discussions, but it started to fall apart in some ways. 14:22:57 bg: in today's world, if you know your audience, you should be able to use javascript without creating an alternative (given that you're targeting a US audience...) 14:23:19 mc: are we willing to make a recomendation that the concept of degrading gracefully disappears? 14:23:27 bg: in certain baselines, yes 14:24:45 dm: instead of saying degrade gracefully, we talked about technologies above your baseline and that content would still be accessible without the tech above the baseline 14:25:02 mc: do we need to define "degrade gracefully"? 14:25:49 bc: what was it in WCAG 1.0? 14:26:13 mc: was "transform gracefully" in WCAG 1.0 14:27:14 dm: need to define it in a testable way 14:27:42 dm: if you use something beyond your baseline, you'll be able to access content even if you don't have access to that tech. beyond baseline 14:28:00 mc: most general technique is either transform gracfully or provide a fallback 14:29:42 bc: consistent with conformance summary wendy and I did (required technolgoies vs. used technologies) 14:30:39 action: michael - define term "tranform gracefully" and put it into context of why we wanted to define it. 14:31:33 mc: seems that we're going back to the group with a recommendation to continue working with the baseline assumptions we've been headed toward 14:31:42 zakim, next agendum 14:31:42 agendum 2. "Impact of externalized baseline on Requirements" taken up [from ben] 14:31:52 zakim, take up agendum 2 14:31:52 agendum 2. "Impact of externalized baseline on Requirements" taken up [from ben] 14:32:45 mc: Guide document and general techniques 14:33:51 dm: concerns about guide document - people looking for techniques will mostly not be interested in rationale, etc. (thing we're planning for the Guide Document). In gerenal, the guide document seems to be directed at people interested in guidelines (policy and high-level understanding people ) 14:34:50 mc: can this be summarized by saying that we still need a traffic cop (independent of the guide document)? 14:35:05 dm: yes, anything that includes techniques needs to include general techniques 14:35:26 mc: not clear if what we've been talking about is including the general techniques in the guide docuemtn or not 14:35:56 dm: we need a way for people who are working on the code to have easy access to general techniques without having it sloshed around in the rationale, etc. 14:36:16 dm: technical nature of techniques should not put too much cognitive load on the webmaster 14:36:28 bg: probably a way we can pull them out into a separate document. 14:37:00 dm: no problem with that, would like to see them married to techniques vs. guidelines 14:37:16 tb: depends on how content developers will access the WCAG documents 14:37:36 dm: what I'm saying is that technical people will go into techniques themselves 14:37:50 mc: inclined to think each of us has diff. assumptions about how people will use these docs 14:39:12 mc: at CSUN, someone mentioned that it's possible that few will actually read the guidelines, but it's the framework under which the rest of this exists. 14:40:27 bc: prototypes for what the guide doc might look like coming next week (with content) - might be something to bring up again when we've seen those 14:41:19 mc: let's keep that on the table, are there other impacts on techniques for externalized baseline? 14:41:46 mc: obvious one is that techs need to indicate whether it's a technique for making a technology accessible or it's a technique for providing a fallback. 14:44:00 bc: challenge for techniques around grouping - think that what we want is to provide info so authors know if a technique applies to the baseline they're using. if they don't have a baseline, then they need to be able to derive a good one from the pro/con info we provide in techniques. 14:45:53 bc: not sure how it works, seems to be a need to talk about techniques as groups - (ex. if you're using baseline X, look at techniques 1, 3, and 8, if you're using baseline Y, look at 2, 4, etc.) 14:47:18 mc: a number of ways we might deal with this, ex. levels of techniques 14:48:25 bc: seems like an end-to-end type thing - ex. i18n has "pros" "cons" "discussion" in their techniques. 14:49:02 mc: seems like prototyping for a couple technques would be good to get started on. 14:49:39 bg: could each take some techniques and work on them 14:52:07 bc: 2 things (1) what to include in techniques to see what baseline the technique applies to and (2) pros/cons/discussion such that an author can make a baseline decision based on available techniques 14:55:00 action: bg, bc, dm, de - take 2 techniques (HTML or CSS) and revise to include baseline info (to list by April 11) 14:56:20 mc: that action should help us to work on requrements as well - other minor requirements changes needed as well 14:56:53 dm: are we assuming the 3 baselines from summary? 14:57:27 mc: more about covering baseline issues and how does use of a technique relate to an authors baseline? 14:57:50 zakim, agenda? 14:57:50 I see 3 items remaining on the agenda: 14:57:52 2. Impact of externalized baseline on Requirements [from ben] 14:57:53 3. Need to agree on matrix of UA for which we provide support information [from ben] 14:57:55 4. Test file reviews (if time) [from ben] 14:58:04 zakim, next agendum 14:58:04 agendum 3. "Need to agree on matrix of UA for which we provide support information" taken up [from ben] 14:58:19 zakim, ping in 5 minutes 14:58:19 ok, Michael 14:58:20 -Tim_Boland 14:58:25 -Dave_MacDonald 14:58:35 ---- 5 minute break ---- 15:03:19 Michael, you asked to be pinged at this time 15:03:47 +Dave_MacDonald 15:04:09 zakim, agenda? 15:04:09 I see 2 items remaining on the agenda: 15:04:11 3. Need to agree on matrix of UA for which we provide support information [from ben] 15:04:12 4. Test file reviews (if time) [from ben] 15:04:25 quarum 15:04:45 zakim, take up agendum 3 15:04:45 agendum 3. "Need to agree on matrix of UA for which we provide support information" taken up [from ben] 15:05:10 http://lists.w3.org/Archives/Public/w3c-wai-gl/2004JanMar/att-0667/draft_test_matrix_v2.html 15:05:44 mc: need to define which UA we want to provide support information for 15:06:21 bg: clarification on priorities? 15:06:36 mc: priorities for us, not related to priorities in guidelines 15:08:53 MC: firefox 1.0 no AT, FF 1.1 with Jaws and/or Window Eyes 15:09:26 lynx 15:09:35 i.e 6 with AT 15:09:39 HPR 15:09:53 HPR 3.04 15:10:36 opera (level 2, firefox level 2) 15:11:22 slightly newer version: http://lists.w3.org/Archives/Public/w3c-wai-gl/2004JanMar/att-0667/draft_test_matrix_v2.html 15:16:11 +Tim_Boland 15:16:50 AT Jaws, window eyes, daulphin, latest versions 15:16:55 zoomtext 15:21:31 dm: can get some help with testing magnification software 15:21:53 dm: should we include voice navigation? 15:22:30 dm: scansoft is about the only one in the mkt. these days 15:23:06 mc: scansoft = dragon 15:23:28 bc: what would we be testing? 15:24:01 mc: ex. form labels - "click first name" could put focus in appropriate field (buttons and hyperlinks primarily) 15:24:51 de: what if someone wants to include a new product or is angry that we haven't included theirs? 15:25:25 mc: could say we chose these tools to get a reasonable sample, if you'd like your sincluded, we're happy to include the results and you'll have to do the testing 15:25:43 bc: do we even have the resources to include the results of their testing? 15:26:02 dm: we'll be more critical of things than a company might. 15:26:09 mc: maybe cross that bridge when we come to it. 15:27:26 bc: might be able to include info on some only for certain techniques (ex. dragon on forms and links, but not other techniques) 15:27:42 mc: good idea to try to scope what we test, especially ATs 15:28:15 mc: what about linux and mac? 15:30:25 o Firefox 1.0 15:30:27 o IE 6 plus AT 15:30:29 o HPR 15:30:30 o Lynx 15:30:32 o Firefox 1.1 plus AT if available (p2) 15:30:33 o Opera (p2) 15:30:35 o ATs: 15:30:36 · JAWS 15:30:38 · WindowsEyes 15:30:40 · ZoomText 15:30:41 · Dolphin 15:30:43 · Dragon 15:31:05 zakim, next agendum 15:31:05 agendum 4. "Test file reviews (if time)" taken up [from ben] 15:31:42 mc: defined batches of 5-10 and assigned action items 15:32:31 mc: please complete assigned tests by next week 15:34:49 mc: ready for assignments of second batch? 15:35:26 action: michael to assign some additional test reviews 15:38:59 zakim, agenda? 15:38:59 I see 1 item remaining on the agenda: 15:39:00 4. Test file reviews (if time) [from ben] 15:39:08 zakim, close agendum 4 15:39:08 agendum 4 closed 15:39:09 I see nothing remaining on the agenda 15:39:38 -Tim_Boland 15:39:39 -Michael_Cooper 15:39:40 -Becky_Gibson 15:39:41 ChrisR has left #wai-wcag 15:39:42 -Chris_Ridpath 15:39:43 -Dave_MacDonald 15:39:46 -Ben 15:40:00 RRSAgent, generate minutes 15:40:00 I have made the request to generate http://www.w3.org/2005/04/06-wai-wcag-minutes.html ben 15:42:13 -Don_Evans 15:42:14 WAI_WCAG(techniques)10:00AM has ended 15:42:15 Attendees were Becky_Gibson, Ben, Michael_Cooper, Don_Evans, [IPcaller], Chris_Ridpath, Dave_MacDonald, Tim_Boland 15:42:39 Present: Becky_Gibson, Chris_Ridpath, David_MacDonald, Don_Evans, Michael ichael_Cooper, Ben_Caldwell, Tim_Boland 15:42:59 Meeting: WCAG Techniques 15:43:27 RRSAgent, generate minutes 15:43:27 I have made the request to generate http://www.w3.org/2005/04/06-wai-wcag-minutes.html ben 15:45:56 RRSAgent, bye 15:45:56 I see 3 open action items: 15:45:56 ACTION: michael - define term "tranform gracefully" and put it into context of why we wanted to define it. [1] 15:45:56 recorded in http://www.w3.org/2005/04/06-wai-wcag-irc#T14-30-39 15:45:56 ACTION: bg, bc, dm, de - take 2 techniques (HTML or CSS) and revise to include baseline info (to list by April 11) [2] 15:45:56 recorded in http://www.w3.org/2005/04/06-wai-wcag-irc#T14-55-00 15:45:56 ACTION: michael to assign some additional test reviews [3] 15:45:56 recorded in http://www.w3.org/2005/04/06-wai-wcag-irc#T15-35-26