13:52:01 RRSAgent has joined #wai-wcag 13:52:01 logging to http://www.w3.org/2005/02/28-wai-wcag-irc 14:02:50 ben has joined #wai-wcag 14:03:59 Michael has joined #wai-wcag 14:04:44 joeclark has joined #wai-wcag 14:05:27 alan has joined #wai-wcag 14:06:09 Andi has joined #wai-wcag 14:06:52 mc reviews agenda 14:06:53 Present: John Slatin, Andi Snow-Weaver, Jenae Andershonis, Alex Li, David MacDonald, Ben Caldwell, Wendy Chisholm, Katie Haritos-Shea, Michael Cooper, Tom Croucher, Joe Clark, Alistair Garrison, Matt May, Alan Chuter, Jessie Li, Lourdes González 14:07:04 http://lists.w3.org/Archives/Public/w3c-wai-gl/2005JanMar/0512.html 14:07:32 andi - please use a colon after the people's names (it's for the formatting scripts). ala "mc: says blargh" 14:07:35 Scribe: Andi 14:07:40 Chair: Michael 14:07:43 ok - gotit 14:07:57 Meeting: Techniques Task Force of the WCAG WG face-to-face (at the Technical Plenary) 14:08:47 thx 14:14:03 DO THE WAVE! 14:14:36 mc: WCAG Techniques Requirements 14:14:53 talking about this draft: (michael may be showing a newer version) - http://www.w3.org/TR/wcag2-tech-req/ 14:15:02 re-opened because needed boundaries around test cases and needed requirements for general techniques 14:17:56 mc: Don't identify the technologies for technology specific techniques because then we would have to have a document for each 14:18:23 Draft Reqs: http://www.w3.org/WAI/GL/WCAG20/WD-wcag2-tech-req-20050208.html 14:18:27 mc: technology specific techniques will grow as new technologies are created 14:19:11 AliG has joined #wai-wcag 14:20:01 Zakim has joined #wai-wcag 14:20:16 agenda+ every technique must map to a SC 14:20:35 Topic: Requirements 14:21:34 agenda+ permissable to create techniques for technologies that cannot meet the minimum Success Criteria of the guidelines even in combination with other technologies 14:25:01 wc: recaps discussion from last Thursday's WCAG teleconference 14:25:35 wc: checklists would not have technology-specific "criteria" but would be annotated with t-s information as explanations 14:26:13 agenda+ providing user agent information and providing interpretation info so that ppl can create own techniques 14:27:00 mc: under General Techniques - req't that each general technique must clearly indicate what is required for conformance to the SC to which it applies. 14:27:11 mc: this is a general requirement that applies to "all" techniques 14:27:46 tc: how does reading level relate to technical information? 14:27:49 js: it works fine 14:28:40 jc: this seems to be the only place where we talk about reading level. it's unusually specific and it requires that we test the document. 14:28:57 Ryladog has joined #wai-wcag 14:29:00 jc: also, it's specific to English 14:29:19 wc: yes, it is specific to English but it should facilitate the translation of our documents into other languages. 14:29:31 mcmay has joined #wai-wcag 14:29:39 jc: plain language is desirable because WCAG 1.0 doesn't have it 14:30:33 js: one of my goals in drafting general techniques for 3.1 is to develop ways of writing more rigorously testable test criteria that are less English-specific than our current ones 14:30:59 js: general issues of readability without specifying grade-based reading level 14:32:03 ag: techniques should just reference the other relevant documents 14:32:28 action: mc add defn of positive test case 14:33:10 action: mc update references to "additional ideas" 14:33:51 agenda+ techniques related to level 2 and 3 SC 14:34:47 action: mc add applicability conditions to req 14:35:04 http://www.w3.org/WAI/GL/WCAG20/WD-wcag2-tech-req-20050208.html 14:35:16 mc: need to create a change log for this document 14:35:33 action: wac and mc create change log for reqs document 14:35:58 mc: when the document is finalized, we will create a change log 14:37:25 wc: we do have change logs for all technical documents 14:38:47 agenda? 14:41:17 as: for "reliably human testable" criteria, 80% implies that we are testing to make sure that 80% of the people will agree 14:41:27 wc: need to take this definition to the WCAG group 14:42:20 http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-20050211/ 14:43:40 checking language in WCAG document - it's different 14:43:56 action: mc to use the same definition in requirements document 14:43:57 action: mc move testability language from wcag 2.0 into requirements doc ("The Working Group believes that all success criteria should be testable. Tests can be done by computer programs or by people who understand these guidelines. Tests done by people who understand the guidelines should get the same results testing the same content for the same success criteria." 14:44:00 oops 14:44:42 action: jenae compare definitions from reqs doc with QA glossary 14:45:46 ag: a testable statement is something that can be either reliably human tested or automatically machine tested 14:45:47 shawn has joined #wai-wcag 14:48:17 ag: disagrees that related technologies should reference each other's techniques 14:48:32 ag: for example, HTML should only provide HTML techniques 14:48:36 agenda+ bindings between techniques documents 14:48:58 ag: then if CSS is replaced with something else, you don't have to modify the HTML techniques document 14:49:31 Jessie has joined #wai-wcag 14:50:32 wc: discusses issue of mapping every technique to a SC - seems to be very problematic with CSS 14:50:49 wc: don't want to have to create CSS-specific SC in the guidelines 14:51:08 wc: there are many CSS techniques that meet the spirit of the guidelines but don't map to a specific SC 14:51:41 mc: if we don't see fit to write a SC for something that we have a technique for, what does it say about the other SC 14:51:57 js: reminds us that all techniques are non-normative 14:52:13 mc: but they are effectively normative if they specify how to meet the normative guidelines 14:53:21 wc: example - creating borders - maps to GL 1.3 - ensure that information, functionality, and structure are separable from presentation 14:54:11 shawn has left #wai-wcag 14:54:47 dm: ran into a lot of similar issues when writing general techniques for GL 2.5 14:55:23 wc: does make me worry about the completeness of SC 14:55:48 mc: if we think something is worth doing, there should be a SC associated with it 14:56:07 mc: but practically speaking, we are years away from having a set of guidelines that do this 14:57:11 jc: I can come up with a few PDF techniques that do not correlate to HTML techniques or anything in WCAG 1 or 2 14:57:30 jc: but there isn't a nice 1-2-1 relationship between all these things 14:57:50 ag: each SC should provide a benefit and they should all be supported by techniques 14:58:10 ag: could probably select 10 that are "really" beneficial and 90 that are "fractionally" beneficial 14:58:38 wc: could have a SC for every guideline at every level 14:59:07 wc: that would say "you have created a technique that does blah, blah, blah" 14:59:23 wc: important to provide enough information for people to create their own techniques 14:59:35 tc: expect to be writing techniques that other people can understand 14:59:55 tc: need internal way to say how we're going to write techniques - should be able to externalize that 15:00:13 wc: would force us to document assumptions and processes that people can replicate 15:00:25 wc: not a proposal yet - a question 15:00:40 wc: do worry that if we do something like that, there would be a lot of questions about the checklists 15:01:14 mc: can go on this track for now - think it will lead us to a set of problems - but that's better than not discovering them until after we go to final recommendation 15:02:10 Scribe: katie 15:02:18 scribe: ryladog 15:03:08 action: wac proposal about mapping techniques to success criteria or guideline ok 15:03:15 zakim, close item 1 15:03:15 agendum 1 closed 15:03:17 I see 4 items remaining on the agenda; the next one is 15:03:18 2. permissable to create techniques for technologies that cannot meet the minimum Success Criteria of the guidelines even in combination with other technologies [from wendy] 15:03:23 zakim, take up item 2 15:03:23 agendum 2. "permissable to create techniques for technologies that cannot meet the minimum Success Criteria of the guidelines even in combination with other technologies" taken up 15:03:26 ... [from wendy] 15:04:02 Ben: 15:05:12 JS: It isnot that it is permissable o write tech? I am just sayingthat we do not want to use the word permissable 15:05:43 MC: JS: This one should go to the disc of checklist 15:06:02 SG: It is silly to say thatcss HAS TO FIT INTO THIS LANGUAGE 15:06:08 s/SG/ag 15:06:23 mc: YOU CAN USE WHAT YPOU LIKE AS LONG AS THE END PRODUCT CONFORMS 15:06:40 mc: WE CANNOT USE THE WORD fLASH ANYWHERE 15:07:08 MC: we do not know that it is possible to have it conform 15:07:27 MC: Is it useful to provide tech for tech that connmot conform? 15:07:35 MC: this was a debate 15:07:46 JC: 15:09:06 JC: telll people all the relevant things evewn if it cannot meet all the sectins of the spec 15:09:20 MC: fall back tech might work 15:09:38 TC: where do we draw the line? 15:09:48 AG: that is not quite right 15:10:27 JC: CIO may say we will conform to 80% 15:10:37 WC: we are trying to get rid of that 15:11:21 LS: we find it easier to cater to some dis. than others 15:11:52 AL: because it does not meet all the guideline does not nec. make something access 15:12:10 TC: look at it from the point of view of the authors 15:12:35 TC: nwhat if they are using a technology does not provide that functionality for the authors 15:12:44 TC: we need to find tech for them 15:13:03 TC: can your tech intergrate with anoth4r tech? 15:13:35 TC: do we insist that all tech meet that minimum? Doesw thsat make sense? 15:14:23 JC: is it fair to say relevance or applicability is mportant? 15:15:24 AG: you really ought to have this in that because it is a legal requirement? 15:15:36 MC: I don't think you can prove thaT 15:16:10 AG: desicions around this atble will cost the EU millions of dollars 15:16:35 JC: a validator will flunk an access page 15:16:44 MC: that is already actioned 15:17:05 WC: I am concerned about fallback page, or alternative pages 15:17:23 WC: flash will only work on Windows machins 15:17:38 WC: if they had a plugin, that would ne great 15:18:01 MC: it is the fault of the platform, not the tech 15:18:15 MC: until user agents kind of thing again 15:18:57 TC and WC: it is reloated to baseline 15:19:12 TC: did that discussion get resolved 15:19:26 AG: what about your intended audience? 15:20:00 WC: I really worry about that they, you are assuming other people are not part of your audience 15:20:28 JC: you can optimise 15:20:38 JC: text only 15:20:56 WC: bit I am concerned that people can chose that tranformation 15:21:06 WC: it should be a choice 15:21:31 No, *not* text only! That's the wrong way to do it. Standards-compliant methods allow us to customize views for different disabled groups (e.g., zoom layouts). 15:21:43 AG: I do feel that sometimes there is this idea that you must produce one set of content for everybody 15:22:09 thanks Joe I am very bad at minuting 15:22:30 LS: tomorrrow there is going to be discussion about this 15:22:59 WC: a couple of things set off bells in my heaf 15:23:26 LS: we should scheduke concernes about adaptive content 15:24:04 TC: what this is a framework for techni are we going to enforce technologies that confrom to techniques 15:24:19 must provide the overall min req of WCAG 2 15:24:31 JC: and developing technologies 15:24:52 MC: a tech that is not mature ids not ready for WCAF conformance 15:25:04 AG: when do we know it is ready? 15:25:17 JC: that is a bit presuptious I think 15:25:37 MC: we need to work with tech that will conform with WCAG 2 15:25:52 JS: but we do have levels 15:26:20 JS: we are already building in an assumption that there are things that cannot conform 15:26:37 JC: we should be honest about O or 1 15:26:52 BC: we do not inadvertantly apply 15:27:22 BC: we are tryingf to inform poeple that this tech cannot address this techg at this time 15:27:35 DMD: are we going to name tech? 15:27:40 TC: no 15:28:24 TC: specific things for specific people, provide the same content. It is not that you cannot use the tech that you waANT 15:28:43 jc: it seems that it is not permissable 15:29:07 MC: is it permissable to provide tech for less access tech? 15:29:30 JS: as far as I know , we are supposed to be providing tech for W3C tech? 15:29:43 JS: that goes back to the req doc for tech 15:30:18 JS: to Macromdeia or Adobe; here are the requitements for youto writetechniques for your technologies 15:31:15 WC: I think it only make sense to have a combined html and css tech, etc 15:32:02 WC: are we doing an annoteted checklist? I am not sure that we need it for recomm 15:32:48 AG: in the past, all was bound through the checklists, you don't write combined techniques, what if someone is using only html? 15:33:14 WC: that is why combined checklist is good 15:33:43 MC: I would like to look at seperate techniquesw for clear seperation 15:33:44 q+ matt, lisa, tom 15:33:48 of technologies 15:33:51 q+ 15:35:43 gregg has joined #wai-wcag 16:00:02 q? 16:00:14 scribe: Andi 16:01:15 mm: recaps what MC said - opposed to combined document - HTML & CSS 16:01:25 mc: not opposed to it but it won't meet mc's needs 16:01:40 mm: mc has specific needs because develops eval tools 16:02:19 mm: target audience is authors 16:02:41 mm: CSS is incomplete document in terms of satisfying needs of authors 16:03:07 mm: have to look at this holistically - CSS is "a" way to separate content from presentation 16:03:23 mc: believe can have a "not very pretty" document that is HTML only 16:03:29 mc: don't believe it is just my needs 16:03:51 mm: we should be encouraging people to use CSS 16:04:11 ack matt 16:04:13 ack lisa 16:04:13 jc: all graphical browsers use a default set of CSS 16:05:03 ls: when merge technologies in a document, limiting audience to those with expertise on all the technologies in the document 16:05:09 q+ 16:05:53 ack tom 16:05:53 q+ 16:06:19 tc: similar to discussion on conformance of authored vs. deliverery units 16:06:44 wendy has joined #wai-wcag 16:06:48 q? 16:06:52 tc: CSS document is authored unit - only certain things are applicable 16:07:16 tc: it may cause complications to try to test the CSS document separately 16:07:30 tc: it's only relevant to test the CSS as it is applied to the HTML document 16:07:40 ack wendy 16:07:53 add me to the queue, please. 16:08:06 (joe, type q+) 16:08:12 q+  16:08:22 Q? 16:08:34 q+ 16:08:55 q+ joeclark 16:09:03 sh1mmer has joined #wai-wcag 16:09:04 whoops. 16:09:12 wc: for e & r tools developers, need to provide an index 16:09:57 true. 16:10:00 ack alistair 16:10:00 wc: other people can re-write our content - we can't provide everything for everyone - but we can provide the base that others can build on 16:10:03 ack al 16:10:47 agenda+ usability of the documents, audiences 16:10:49 q+ davide 16:10:54 ack AliG 16:11:05 ag: maybe we should combine wc points about usability and intended audience of document 16:11:12 q+ to say, "where do you stop? where it m akes sense for our users" 16:11:40 ack ryla 16:11:44 ag: have to decide who is the primary audience 16:11:49 ack Ryladog 16:12:01 ack Ryladog 16:12:19 q+ john 16:12:20 kh: have to be able to combine documents but will also need to be able to find individual things 16:12:24 q+ lisa 16:13:04 wc: not suggesting that all techniques are in one document - just suggesting that CSS be covered in HTML document 16:13:38 mm: the reason that CSS is a stand-alone document is because it can be applied to different things. Makes sense for tool or user agent developers 16:14:04 wc: suggesting that you have documents for "host" languages - HTML, SVG, SMIL, etc. and cover CSS in them 16:14:32 wc: other people like WebAim, Jim Thatcher, etc. will address other audiences 16:14:50 ag: thinks we should produce separate documents and let others combine them 16:15:06 wc: almost every single test for CSS links back to an HTML technique 16:15:21 wc: makes sense to come up with a concrete proposal that we can debate 16:15:22 q+ jenae 16:15:24 ack joe 16:15:25 q- 16:16:49 jc: wrt ls point about barrier to entry - authoring tool should handle without the author even having to understand it 16:17:14 ack d 16:17:16 q+ to say "need audience section for every part of the technqiues requirements" 16:17:19 jc: CSS needed for simple documents is not that complicated to understand 16:17:35 dm: tc drew up some good personas for the document target audiences 16:17:50 dm: look at the personas quite often to ensure we are being true to them 16:18:44 ag: so what was the result of that work? separate docs or combined docs better? 16:19:04 dm: it was never on the table before to combine the technologies 16:19:16 dm: thinks there is some merit to combining them 16:19:23 dm: want people to use CSS 16:19:35 ack j 16:19:38 ack john 16:19:39 q+ 16:19:55 alan has joined #wai-wcag 16:20:06 js: techniques documents are not "documents" - collections of individual bits - not meant to be read front to back 16:20:28 js: they are really "long lists" of techniques 16:21:11 js: because they are done in xml, we have the capacity to integrate them or keep them separate - user could decide - we could provide some default or suggested views 16:22:12 js: referring back to wc comment about index - not just an index, there's also a TOC, provide different ways of getting at material 16:23:09 js: need to find a way to talk about the set of documents that constitute WCAG2.0 16:23:38 js: our list of audiences for these documents contains different people with very different needs 16:23:51 q+ 16:23:57 ack lisa 16:24:00 js: need different avenues of combining, separating, and REALLY good navigation system 16:24:53 ls: don't think keeping the documents separate or combining the documents changes what we say is required - it just makes it easier or more difficult for someone to use them 16:25:23 ls: people don't always know how to ignore information that they don't need to learn 16:25:25 ack we 16:25:25 wendy, you wanted to say "need audience section for every part of the technqiues requirements" 16:25:46 ls: it's irrelavant though because we can provide both very easily 16:26:03 wc: we have to define exactly what we have to do to get to final recommendation this year 16:26:23 ls: yes but we could have a "to do" list of things to do after we get to final recommendation 16:26:30 q+ AL 16:26:38 wc: litmus test - is this needed to get to recommendation? 16:27:12 wc: current view after reading CSS techniques and listening to usability feedback, sense is that we need techniques documents that have "macro level" tasks 16:27:34 wc: example is "how do I create a form?" 16:27:45 tc: that's user centered design (UCD) 16:28:09 wc: haven't done a lot with user scenarios and persona we created at the Toronto meeting a few years ago 16:28:27 wc: don't want to re-create the usability problems of WCAG 1.0 16:28:50 wc: techniques are a database dump - don't connect the techniques 16:29:09 wc: works well for e & r tool developers - doesn't work well for people trying to figure out how to implement 16:29:39 wc: need different audience statement for different deliverables - get Shawn to review 16:29:46 ack sh 16:29:53 q+ jenai 16:31:24 action: mc and wac incorporate/link to scenarios/personas (that eowg evolved from tom's earlier work) 16:31:26 ack alig 16:31:29 ag: 16:31:49 ack jenae 16:31:53 ack jenai 16:32:13 Michael, when you did "ack j" instead of "ack john", it bumped jenai off the queue 16:32:57 ack AliG 16:33:07 ack AliG 16:33:17 joeclark has left #wai-wcag 16:33:44 ag: shouldn't be asking just "is this required for recommendation". should be asking "will it be adoptable after recommendation" 16:34:05 ja: we have no control over whether people will adopt it 16:34:14 ja: we can only control completing it 16:34:46 ag: all Europeans have developed their own expertise now. will be looking at W3C recommendations and judging whether good or not. 16:35:04 wc: we have to solicit comments from those European organizations and have to address them 16:35:19 mc: ag thinks we won't be able to get through that stage 16:35:31 Shaun's user/audiance analysis page http://www.w3.org/WAI/EO/2003/analysis-sum#users 16:35:34 wc: we have 700 issues in db - have done usability testing on WCAG 1.0 - we have a lot of data 16:35:48 wc: format issue keeps coming up 16:36:05 joeclark has joined #wai-wcag 16:36:25 ag: if have a good idea of what people like or don't like about 1.0, why are we rewriting the guidelines. Why not just address those problems 16:36:47 ag: new format is going to cost a lot of money to a lot of people who have been trained to implement 1.0 16:37:22 q? 16:37:49 tc: using Shawn's work and being aware of users' goals 16:38:00 ag: five years worth of training has gone into WCAG 1.0 16:38:14 q+ David 16:38:14 what governments need is a slightly updated version of WCAG 1.0 16:38:32 q+ 16:38:34 q+ john 16:38:35 ag: for a lot of people HTML is as far as they've gotten - just starting to learn about CSS 16:39:26 wc: I would not touch the guidelines or SC at this point 16:39:40 q+ 16:39:41 wc: if we go back and re-do WCAG 1.0, it will be another two years 16:39:53 wc: we need to move on 16:40:03 q+ lisa 16:40:04 ack AL 16:40:40 al: understand idea of combining some technologies - vast majority of Web sites use these two 16:41:19 al: lots of Web sites use such a vast range of technologies, we could not possibly combine them all 16:41:52 ack david 16:42:20 al: think it's fine to combine as long as people can still make their own judgements about how to meet the GLs and SC 16:42:38 dm: we came here with work to do - out of our scope to challenge the direction of the guidelines 16:43:03 dm: guidelines direction has been thought out very carefully 16:43:11 q+ to say we make recommendations to Guidelines 16:43:57 ack tom 16:44:13 dm: need to stick with our purpose if we are going to be productive over the next two days 16:44:30 tc: major goal was to make WCAG 2.0 extensible in a way that WCAG 1.0 was not. 16:44:37 andi - want me to minute for the next bit? 16:44:51 ok 16:44:56 scribe: wendy 16:45:04 q? 16:45:18 dino has joined #wai-wcag 16:45:35 q- john 16:45:39 q- john 16:45:39 q- lisa 16:45:39 q+ 16:45:43 ack joe 16:46:16 ack michael 16:46:16 Michael, you wanted to say we make recommendations to Guidelines 16:46:18 jc: many people have not been using for the last 5 years. there is proposal to make errata 1.0. even after wcag 2.0 goes to rec, can still use wcag 1.0. 16:47:02 mc: there is a guidelines f2f in 2 weeks. 16:47:17 mc: perhaps an outcome of this discussion is input into that f2f discussion. 16:48:35 ag: seems silly to say things are set in stone when you've used "rewrite" sevearl things. 16:48:35 ack andi 16:48:42 asw: it's tweaking not rewriting in many sense. 16:48:59 asw: we have several issues in bugzilla about ppl not understanding 1.0 to 2.0 mapping. thus, started mapping. 16:49:13 asw: this should help preserve the investment that people have. 16:49:23 ag: that principle that i've been operating under. 16:49:59 ag: at the techniques level. take 2.0 techniques and map to wcag 1.0 checkpoints. 16:50:16 q+ 16:50:35 q+ 16:51:05 q- 16:51:17 ack w 16:52:22 action: mc add the importance of linking from wcag 2.0 techniques to wcag 1.0 checkpoints 16:53:19 action: wac write proposal for how css techniques could be written with "macro-level" tasks and how might be incorporated into html techniques. think about how map from wcag 1.0 checkpoints to wcag 2.0 techniques. includes how to link to tests (many of which are html) and back to general techniques. 16:54:09 agenda? 16:56:23 zakim, close item 5 16:56:23 agendum 5 closed 16:56:24 I see 3 items remaining on the agenda; the next one is 16:56:25 3. providing user agent information and providing interpretation info so that ppl can create own techniques [from wendy] 16:56:31 zakim, close item 6 16:56:31 agendum 6 closed 16:56:33 I see 2 items remaining on the agenda; the next one is 16:56:35 3. providing user agent information and providing interpretation info so that ppl can create own techniques [from wendy] 16:57:11 q? 16:57:17 q+ john 16:57:38 RRSAgent, make log world 16:57:47 ack john 16:58:10 js: that sounds like we are obligating ourselves to a detailed oversation of all known user agents and if they support a technique. 16:58:24 js: is that correct? if so, when will we finish? 16:58:32 mc: minimum - say if it is implemented. 16:59:09 mc: if we know it is supported in one ua one way and something diff in another, makes it difficult to implement. 16:59:15 jc: UAWG does that. 16:59:20 mc: overlaps, but not 100# 16:59:24 s/#/% 16:59:30 jc: that's a lot of work. have someone else do it. 16:59:43 bc: when we conceived it, we were going to define a set of reasonable UAs for which this would apply. 17:00:11 mc: if we go with baseline, could end up with 0. :) 17:00:29 http://lists.w3.org/Archives/Public/w3c-wai-gl/2004JanMar/att-0667/draft_test_matrix_v2.html 17:01:06 mc: there are 2 approaches we can take: 1. s/must/should 2. remove UA info completely 3. leave as is 17:01:07 Kerstin has joined #wai-wcag 17:01:46 ag: there is info available from other groups. e.g., supoprt for css http://lists.w3.org/Archives/Public/w3c-wai-gl/2005JanMar/0517.html 17:01:55 js: mathml and svg have imp info, too 17:02:19 ls: there is a difference between UA support and user support. 17:02:58 ls: server solutions that provide semantic info is available in a form that current technologies can accept. 17:03:11 ls: eventually, ua support will overtake/incorporate server-side solutions 17:03:28 q+ 17:03:34 ls: important thing is that the user has a mech to get to the info, not that directly in UA 17:03:39 ack ry 17:03:56 q+ to get on with the show a bit 17:03:58 khs: let's lessen the constraint 17:04:05 mc: is s/must/may enough? 17:04:35 bc: have minimum in 2nd sentence. therefore, delete 1st 2 sentences. 17:04:42 mc: proposes rewording 17:05:10 ack joe 17:05:10 joeclark, you wanted to get on with the show a bit 17:05:19 jc: something needs to change. delete it. 17:05:33 action: mc delete first two sentences of UA support documentation requirement 17:05:49 zakim, close item 3 17:05:49 agendum 3 closed 17:05:50 I see 1 item remaining on the agenda: 17:05:52 4. techniques related to level 2 and 3 SC [from wendy] 17:06:57 4. techniques related to level 2 and 3 SC [from wendy] 17:09:37 q+ 17:09:51 q+ john 17:09:52 ack joe 17:10:47 q+ 17:10:55 q+ 17:11:12 ack john 17:12:33 ack wendy 17:13:58 ack a 17:13:58 ack ali 17:14:10 wac, alig: delete them 17:14:13 action: mc delete the untestable techniques / additional ideas stuff 17:14:14 lots of nodding heads 17:14:21 zakim, close this item 17:14:21 agendum 2 closed 17:14:23 I see 1 item remaining on the agenda: 17:14:25 4. techniques related to level 2 and 3 SC [from wendy] 17:14:30 zakim, close item 17:14:30 I don't understand 'close item', Michael 17:14:32 zakim, close this item 17:14:32 I do not know what agendum had been taken up, Michael 17:14:33 zakim, close item 4 17:14:33 agendum 4 closed 17:14:34 I see nothing remaining on the agenda 17:16:25 topic: Getting to rec 17:25:35 AliG has left #wai-wcag 17:26:31 ben has left #wai-wcag 17:26:59 Kerstin has left #wai-wcag 17:51:12 dino has left #wai-wcag 18:19:46 ben has joined #wai-wcag 18:36:20 agenda? 18:36:25 Michael has joined #wai-wcag 18:36:34 scribe: ben 18:37:11 agenda + What's needed to get through the recommendation process? 18:37:23 zakim, take up next agendum 18:37:23 agendum 7. "What's needed to get through the recommendation process?" taken up [from ben] 18:37:32 wendy has joined #wai-wcag 18:38:12 Steve Bratt, COO of W3C - responsible for recommendation track process, here to discuss what's neded to get through the process 18:41:03 alan has joined #wai-wcag 18:42:02 wc: do people have thoughts or questions about what we talked about before lunch? (things we need to do to get through rec.?) 18:42:11 Andi has joined #wai-wcag 18:42:12 khs: what do we need to do? 18:43:04 mc: suggest doing a high-level summary and then discss some of the transition points to help figure out where what we're doing is and isn't helpful toward getting us to recc. 18:43:38 wc: there are about 10 major projects we could be doing based on how WCAG 1.0 is being used worldwide - would like to get to what it is we must do to get through recc. 18:43:57 wc: what does it mean for us to have 2 interoperable implementations and how would we demonstrate that? 18:44:17 wc: ex. 2 sites that we think meet WCAG 2.0 and then conduct usability testing 18:44:56 wc: main thing is to do testing with people with disabilities 18:45:09 ag: a little bit of usability too 18:45:23 js: so now you have a sense for why this is taking us so long 18:45:53 sb: 1st group of this type was UA, not quite like other specs in that there are issues of language, browsers, platforms, etc. 18:46:16 sb: simple case that we talk about is two simple prorams that can talk to each other in a specific way 18:46:52 sb: separating it into what we think has to be done is not easy - esp. because we want this to be adoptable into regulation 18:47:23 sb: most people see our criteria as simple as 2 interop. implementations for each reqd. feature, your group may want to write up a page 18:47:42 Tom has joined #wai-wcag 18:47:54 mc: does that go in requirements itself? 18:48:09 sb: usually, there is information about this specific to the CR stage 18:48:29 mc: do we set criteria as we please or are there guidelines for how to construct this? 18:49:23 sb: at some point, you'll go to last call and there will be a request from the group and a link to the group's decision to do this, a link to comments from last call and their disposition (incl. formal objections) 18:49:47 sb: going from CR to Proposed Rec. then we look at what your criteria were for getting out of CR stage 18:50:30 sb: problems can be avoided if WG can show agreed upon minimum criterion and how we met them 18:51:38 khs: technically, what we need to do is decide we want to have a site that complies. can it be two implementations from two different types of content (ex. one HTML/CSS site and a VoiceXML site) 18:51:59 ag: can I ask how the public comments are actually being integrated? 18:52:10 Kerstin has joined #wai-wcag 18:52:22 wc: we have bugzilla database, which come from WG and public comments - we are working to close each of those issues before we go to last call 18:52:40 Ben, let me know if you want a break for a little while taking notes .... 18:52:44 Jessie has joined #wai-wcag 18:52:53 Can't promise the whole afternoon, but part of it certainly. :-) 18:53:06 q? 18:53:10 q+ 18:53:13 sb: yes, and closed means either you've agreed, not agreed and whether they want a formal objection 18:53:46 wc: all of this gets loged in public comments list - right now, I have a queue of 200+ issues that need to be sent to reviewers 18:54:56 wc: also have a reviewer list and we keep in touch with them about how we're handling their comments. we've had substantial comments from Access Board, IAC Canada, etc. 18:55:05 ack joe 18:55:11 wc: some reviewers are waiting for last call 18:55:37 jc: can you explain the w3c's responsibility for handling comments? address them? 18:56:20 sb: response, ex. good suggestion, but no, good idea, but future... 18:56:45 jc: there are parts of WCAG 2.0 where people fundamentally dispute issues 18:57:20 jc: all of the disputed issues will go through, my point is that the way you address it is, "yes, thank you for commenting"? 18:58:02 sb: we would look for response that includes a rationale and give commenters opportunity to comment or formally object about something. 18:58:33 sb: formal objections are rare, but it is possible for a formal objection to result in a case where Tim would overturn the decisions of a group 18:59:04 jc: tme crunch is another issue 19:00:03 sb: most specs have some known faults. we do report formal objections and note them in the process of going to recc. we do make a best effort to make people feel that they've been heard and address the issues 19:00:33 sb: all the process does is force you to go through objections, realizing nothing is perfect 19:00:43 Time crunch is another issue that will tempt WCAG WG to ignore objections. (To clarify.) 19:01:37 ag: time crunch is an issue, if you're not certain, there's no point in rushing ahead 19:01:48 ag: bigger than producing a technology spec 19:02:42 sb: question is whether in 2 years you'll have a spec that improves, by 1%, 2%, 50%? 19:02:57 q+ 19:03:04 khs: at some point, you have to move forward and work with something, knowing that issues have been vetted 19:03:15 q+ 19:03:26 ag: ex. in my job, I could be sued because of decisions made around this table - more impact than you thought about originally 19:05:00 js: web is 15 years old. advent of GUI set blind users back 15 years, so we're just now catching up again. WCAG 1.0 pulled together a number of documents written to address these issues. there are a lot of problems with 1.0 and a lot of great things about 1.0. you've talked about how important it is in Europe and it's been important here too, so we should not change it lightly, but it makes some fundamental assumptions that simply don't hold 19:05:02 ack t 19:05:02 ack Tom 19:05:44 steve has joined #wai-wcag 19:06:32 q+ to ask, "what need to do, not do we need to do it" 19:06:50 tc: so what I see from ag is that you want something that is substantial enough that we won't put ourselves in danger if adopted into legislation, but at the same time we're worried about timeframe. if we try to make it too perfect, how much better will it get? fundamental shift in 2.0 sets more of a framework for what needs to be done. getting that in place I think is much more important than improving on 1.0 19:07:05 q+ david 19:07:08 q+ Alistair 19:07:14 alan has joined #wai-wcag 19:07:14 ack j 19:08:45 jc: point of interest for Steve. differenc between WCAG and many other W3C recs and even betwen other guidelines like ATAG and UAAG is that WCAG isn't being ignored and is being legislated. issue is that this is under more scrutiny and most cenrally, web access is a contensious issue in the first place, so the typical W3C approach may fail for WCAG 2.0 for the reasons that I mentioned 19:09:20 sb: if the goal is to get the whole world to agree on something, does anyone think that's possible? how do you deal with that? 19:09:53 sb: your group would know better than anyone else, but process and commenting is a way to measure how far we are from agreement 19:10:15 ack we 19:10:15 wendy, you wanted to ask, "what need to do, not do we need to do it" 19:10:36 AliG has joined #wai-wcag 19:10:50 wc: I want to acknowledge that I don't think anyone thinks we're ready for last call or that we've addressed all the issues. ? is what is it we need to do to make the world better than it is now? 19:11:26 wc: would like us to focus on the ? of what it is we need to do. how do we make it more likely than not that WCAG 2.0 will be adopted. We can't guarantee adoption, we can't guarantee world consensus. 19:11:34 ack d 19:12:37 dm: feel privledged to hear some of your experience, discerning when issues are and are not an issue is a big job. can you provide an example where a technology needed to be changed radically from it's first release? 19:13:08 sb: good question, XML 1.1 might be a good example, but not a very good analogy to WCAG case 19:13:37 sb: XML 1.1 yielded a lot of pushback because a number of people didn't want to change what they'd already did 19:14:03 dm: ex. like sleeping next to an elephant, every little change has big impact 19:14:14 sb: an new opportunities 19:14:16 q? 19:15:19 sb: hopefully in the end, the decisions benefit everyone 19:15:21 q+ 19:15:23 ack a 19:15:56 ag: in terms of getting a new guideline together, you would have to show that it was a considerable improvement 19:16:02 q lisa 19:16:05 q+ lisa 19:16:08 q+ 19:16:46 ag: second, if you could keep it as in sync as possible with the previous version so that the investents in training that were made don't require retraining (ex.Priority vs. Levels change in terminology) 19:17:37 ag: so you're really talking about cost benefit. you actually have to show that somehow because people will belooking at WCAG 2.0 carefully to see whether it's better. If it's not, they can afford to wait until we do prove that it's better. 19:17:44 q+ 19:18:41 ag: my major concern is that releasing too early, degrades the output and creates potential for others to write their own. would suggest that we hold back until we're sure it's ready. 19:18:49 ack r 19:19:08 khs: several people here have experience with different types of stds. organizations 19:19:26 ken has joined #wai-wcag 19:19:58 khs: I think there isn't going to be a point where you can say it's perfect. choice is avail. to stick with 1.0 or migrate to 2.0. govts./orgs. have a choice about which standard they're going to follow 19:20:16 khs: what is status of W3C specs fast-tracing to ISO 19:20:36 sb: we decided to wait until a group really wants to do it 19:20:40 q+ 19:20:43 Al has joined #wai-wcag 19:21:48 q+ david 19:22:10 khs: I have had limited experience with an ISO spec and they all have a logical order for dealing with comments and making some kind of resolution and deciding when to move forward. You'll never have all commenters agree that things are perfect, so I'd like to know what is it WCAG needs to do (technicaly) to move forward? 19:22:11 ack l 19:23:00 gregg has joined #wai-wcag 19:24:01 ls: to give some perspective, in Israel, we don't currently have access regs. they are currently writing some and so far (though it's not final) they seem to be referring to WCAG 2.0 as the latest draft and will eventually point to WCAG 2.0 later on. reason they did that was that they decided it was better to start with latest. it's a country without any baggage around access regulation and they still came up with a decision that WCAG 2.0 was better even th 19:24:14 ack t 19:25:12 tc: I'm going to step back a minute to examine why are we saying that WCAG 2.0 is really different and why it's better. thing is, we think this approach is better for people with disabilities and the regulation is up to policy makers 19:26:19 tc: we have got considerable evidence that what we're doing does constitute a considerable improvement. as much as adoption is a big issue, we shouldn't tie ourselves to the fact that some will have to change what they're already doing 19:26:35 ack s 19:26:37 q? 19:26:40 q+ tim 19:26:49 tc: far more credible to say that we've taken an approach that benefits pwds than one that benefits people who have adopted previous guidelines 19:27:42 sb: patent policy example. it was very contentious in W3C as a community and got a lot of public scrutiny. decided new patent policy was worth it and went ahead 19:28:22 sb: if you can make significant improvements with another year of work, then you should do it, but if it's another 5, it may not be worthwhile 19:29:12 sb: getting something out to last call indicates that the WG is ready for the world to review and comment 19:29:38 sb: ok to highlight differences of opinion in WG at last call stage if need be, though not ideal 19:29:54 sb: getting it out there sooner sounds like it would be beneficial to you 19:30:40 sb: goal for testability also points toward moving toward CR stage sooner to establish testability 19:31:13 sb: get to a point where some of the things we're concerned about get out there for the public to review 19:31:33 ack w 19:31:46 sb: not uncommon to go back to last call phase after getting public comments from this stage - groups usually decide to go back based on those comments. 19:32:18 ag: one of our issues is defining what testability means. if there was a level where you could say everyone who reads it has to come up with the same thing. that would really help. 19:32:29 wc: but some of those things will nevery be objectively testable 19:32:59 scribe: AliG 19:33:04 ack d 19:34:22 ack t 19:34:26 dm: disability rights organsations are pushing things. If we take too much time, there is a cost in terms of corporate knowledge. 19:36:33 TB People say WCAG 2 is better than WCAG 1. From a QA standpoint, WCAG 2 should not be seen as a completely different thing. WCAG 2 should be see as more of an enhancement. Demonstrating that WCAG 2.0 we should show the changes which have been made. With regard to testing, are there certain less contenscious things which could be tested first, then move on to other things. 19:37:00 WC : Sounds like end to end. Taking one thing. 19:37:53 SB: Is there a business case which shows the improvements. 19:38:23 DM: There was a person in Canada that thought it was better because it does not go out of date. 19:38:55 WC: Reads requirements for WCAG 2.0 19:40:24 http://www.w3.org/TR/wcag2-req/ 19:40:57 DM: WCAG 1.0 was descriminatory, so it helped people with certain disabilities over others. 19:41:22 WC: This was a myth. Other myths existed about WCAG 1.0 also. 19:42:34 MC: I am hearing concern that WCAG 2.0 is not right because it is not fully baked. Others say that it is better. We still need to know what work needs to be done. 19:43:01 MC: We also heard that things need to be done right now. 19:45:41 If you rolled the knowledge gained from the usability study of 1.0, you would at least know what would be acceptable for 2.0. 19:45:55 WENDY: 1.0 has too may serious flaws to simply be fixedup. 19:46:23 ALISTAIR: An improved 1.0 might buy us a little more time. 19:46:33 STEVE: Then you'd have to train people on the new "1.5" as well as 2.0. 19:46:37 ALISTAIR: No, you wouldn't. 19:46:52 WENDY: Governments aren't going to change their laws this year for "1.5" and next year for 2.0. 19:47:01 scribe: joeclark 19:47:07 ALISTAIR: I'm not saying to make a "1.5." Use errata to create an updated version of 2.0. 19:47:15 WC: There are problems with WCAG 2 which could loose us credibility. We need to find out what we need to do to iron out these problems. 19:47:18 JOHN SLATIN: We talked about that over the last 1.5 years. 19:47:26 [Scribe returns to Alistair] 19:47:32 scribe: AliG 19:48:27 q? 19:49:42 someone else scribe, please. 19:50:52 JS: We have looked at an errata for WCAG 1.0. But the time you spend on WCAG 1.0 errata is time lost on WCAG 2.0. 19:52:21 JC: There is a killer to using a WCAG 1.0 errata. There does not seem to be enough time, or people to work on an errata. 19:52:59 TC: Errata would be window dressing. 19:54:28 q+ 19:54:50 Wendy utters phrase "so we do not produce a piece of *crap*" 19:54:58 WC: If we provide a WCAG 2.0 which is testable then it would allow authoring tools to take it up, etc... 19:55:24 ack t 19:55:24 MC: What I am hearing is a way off between sooner rather than better. 19:55:51 TC: Is it reasonable to start the process in order to get feedback. 19:56:02 Al has left #wai-wcag 19:56:38 SB: It would be good to solicite feedback about things which could have a negative impact. 19:58:10 TC: AG was saying that things have to be really solid, but due to resources some time we have to guess as some things. 19:58:38 DM: are there any cases where a new recommendation is produced, and people continue to use the old spec. 19:58:45 SB: CSS, XHTML. 19:59:48 TB: Are there any chartering things regarding WCAG 20:00:47 steve bratt - http://w3.org/People/all#steve 20:01:13 MC: How do we resolve the issue which is blocking us. 20:02:42 WC: I have been pushing hard on time lines, which has forced people, which is good. We need to look at the things which we need to get done for WCAG 2.0. We have a lot of pieces, but we just need to pull the information together. 20:03:59 JS: I would like to see this group concentrate on keeping a line between the issues which we can work on and those things which the full WCAG working group can work on. 20:04:16 MC: Sometimes there is nothing we can do about that. 20:05:11 TC: We should be able to find any critical decisions, and we should then able to get an answer back from the main WCAG 2.0 working group. 20:06:08 WC: We need to make some progress on the techniques documents. It would be great to break up into groups and look the different techniques. 20:06:30 BC: It would be good to look at the flow through the documents. 20:07:33 KG: There is a lot of work ahead. And a number of different things which need to be done. 20:08:17 BC: The discussion suggests that we need to start processing issues. 20:08:51 KG: There seems to be more to it than that. There are a number of large issues which need to be tackled. 20:10:27 KG: This brings me back to Ian's suggestion that we need to come up with a model for how technology producers can produce there own guidelines. 20:10:50 The audience are technology spec writers. 20:11:56 q+ 20:11:57 DM: There is a general spec. 20:12:40 q+ al 20:12:42 Al has joined #wai-wcag 20:12:49 q? 20:12:56 q+ 20:13:17 ack t 20:13:34 MC: I think the audience of WCAG is content writers. But I think that the document which Kerstein is talking about does not exist. WCAG is trying to fulfil a larger role than it is designed for, hence the problems. 20:14:31 TC: We have a good insight into how to make technologies accessible, we should pass this on to other developers of technologies. 20:15:21 TC: We also need to realise that our documents are to be written into legislation etc... 20:15:26 ack al 20:16:57 AGillman: Some concerns which have been raised in PF is ZAG WCAG integration. 20:17:51 ack ben 20:18:05 s/ZAG/xag 20:18:11 q+ to ask about topics for these imminent breakout groups 20:18:24 BC: A spec for how to write accessible specs does not describe the specification which tells authors how to make accessible content. 20:18:26 q+ lisa 20:19:33 ack lisa 20:19:34 ack l 20:20:21 ack joeclark 20:20:21 joeclark, you wanted to ask about topics for these imminent breakout groups 20:20:21 ack j 20:20:24 zakim, close q 20:20:26 LS: I liked the idea of looking at different areas, we are trying to produce documents which are too much to too many. This is the route of the problem. If the idea is to produce guidelines for guidelines makers, it would narrow what we are looking at and we find a way to a specification. 20:20:27 I don't understand 'close q', wendy 20:20:49 zakim, close queue 20:20:49 ok, Tom, the speaker queue is closed 20:22:05 our charter: http://www.w3.org/2004/04/wcag-charter.html 20:22:16 MC: The breakout groups are CSS, formats, scripting, general, a proposal for moving forward. 20:24:04 For creating an accessible specifications - the hook between wcag 2.0 may be the requirment on exposing stucture to programmes. 20:24:25 What are the deliverables for these breakout groups? 20:25:51 deliverables: notes, hopefully in the form of a draft proposal or list of issues and/or summary. reports from each group. 20:34:24 Michael_ has joined #wai-wcag 21:08:48 Michael_ has joined #wai-wcag 21:11:54 Michael__ has joined #wai-wcag 22:09:22 Andi has joined #wai-wcag 22:09:42 MICHAEL: We feel that we're stuck because we need resolution on topics that are not getting resolved. 22:10:05 In the Techniques group, suddenly we keep hearing that only the larger group can make certain decisions, which aren't getting made. 22:10:15 "And the larger group is not fully cognizant of our ability to do the work." 22:10:36 Our proposal is to work with the larger group to resolve certain blocker issues, like baseline, 22:10:53 which here means which accessibility tasks are delegated to Web content, which to adaptive technology, and which to user agent. 22:11:11 Also technology features that are not formal parts of a specification (e.g., embed). 22:11:38 WENDY: Tim has a list of all possible CSS attributes we could address, but we should probably focus solely on access-related attributes. 22:12:22 When you say "stymied," Michael, you make it sound like we haven't made progress, but we *have* made progress (Kerstin, Andi agree). 22:12:40 Wendy tries to "gauge the frustration in the room." 22:13:28 KERSTIN: We're talking about baseline as though we didn't have energy and excitement on that topic from Dublin. 22:13:42 TOM: We seemed to have all but completely decided on baseline at Dublin. 22:13:53 WENDY: We should entirely resolve baseline at CSUN meeting. 22:14:54 Propose that we spend tomorrow morning creating a project plan for what needs to be done between now and CSUN, how much time each task takes, and what skills-- all just for baseline. 22:15:26 "I really wanted to leave the meeting knowing which of those things we could scratch off the list" of things we needed to do before Candidate Recommendation. 22:16:54 Ben notes that some UAAG checklists seem to be unrelated to the reality of the device in question, so the UAAG checklists are possibly unreliable. 22:18:17 WENDY: One of the UAAG issues is support of scripting, which UAAG does not require. So we still have an unanswered question about scripting/no script. 22:18:25 q+ Tom 22:18:37 zakim, open queue 22:18:37 ok, Michael, the speaker queue is open 22:18:43 q+ tom 22:18:54 WENDY: There's a baseline keyword in Bugzilla that can be searched on. 22:20:02 q+ Andi 22:20:22 ack tom 22:20:56 TOM: As mentioned in Dublin, having a suite of WCAG documents would be "cool." But could UAAG be brought to v2.0 with some alterations to the issues? 22:21:01 WENDY: I'd rather do WCAG 1.1. 22:21:15 "I don't think that's currently in their charter." 22:22:14 BEN: Conditional content is a big one, and I think that needs to happen. For example, title="" can be rendered instead of the original. 22:22:56 That could be dealt with in an errate. 22:22:58 errata. 22:23:24 TOM: But you'd have ATAG 2, WCAG 2, and UAAG 2 tied together as a suite and interrelated. 22:23:48 As an example of "Here's where authors, authoring tools, and user agents need to get to." 22:24:01 WENDY: That already exists. It's called the Interdependent Components of Web Accessibility. 22:24:25 To fix that, we'd have to know what's wrong with UAAG, talk to them about it, and bring it back here. 22:25:23 We have a confirmed PF/UA/WCAG meeting tomorrow where we could bring this up. 22:25:37 So, tomorrow: Work with Ben on UAAG gap analysis. 22:26:02 Come up with work plan on how to resolve baseline between now and CSUN, and, if possible, an agenda of questions and items on how to address it for CSUN. 22:26:22 Also, long-term planning: Which things that are "all possible" can we knock off the list? 22:26:45 NEXT! 22:27:35 JENAE: Wendy's idea of combining HTML with CSS. A lot of the CSS techniques and test cases are triggered by HTML elements. Thus HTML doc will trigger CSS and vice-versa. 22:28:02 Putting them together has them all in one place. 22:29:13 ALISTAIR: Combining them to reduce "links" seems pointless since the total number of links will be the same. 22:29:33 WENDY: Feedback from usability testing of WCAG 1 and WAI redesign is task-based. 22:30:09 ALISTAIR: It's completely up to you. Personally, in terms of what I look at the documents for, I would say that HTML and CSS should be separated, since that's how people are used to it. 22:30:16 WENDY: But the ways people are used to it are not usable. 22:31:09 ANDI wants to see a proposal, "but don't make it look like a document." 22:32:11 WENDY thinks the most important thing to have is the index, then items by tasks. 22:32:32 Our tasks right now are too atomic. 22:33:13 JOHN: Has a list of things they have general techniques for. David has some for GL 2.5, which they looked over. 22:33:29 Hoped to revise them so they look more like the more-recent techniques. 22:33:40 DAVID will clean those up and give them back to John by CSUN. 22:34:19 John is working on Level 3 success criterion for GL 3.1 about complexity reduction and assertions of those. 22:34:37 "We decided a long time ago to expunge from the guidelines anything that requires that merely a statement exist." 22:34:59 KATIE is to produce a VoiceML technique. 22:35:27 JOE knows people at Opera who could help Katie with that. 22:36:50 1:30 tomorrow is the joint meeting with PF and UA. 22:37:11 MICHAEL: We will definitely plan for next f2f meeting and what needs to be done for candidate recommendation. 22:38:11 We will break out into three groups tomorrow: Analyzing UAAG; workplan for resolving baseline; plan for Recommendation. 22:38:25 i.e., UAAG, baseline, long-term planning. 22:39:11 KERSTIN to present 5min overview to PF/UA meeting tomorrow. 22:39:18 gregg has joined #wai-wcag 22:39:26 MICHAEL adjourns. 22:39:58 though people keep talking. 22:48:42 ben has left #wai-wcag 22:50:17 rrsagent, generate minutes 22:50:17 I have made the request to generate http://www.w3.org/2005/02/28-wai-wcag-minutes Michael 22:50:58 joeclark has left #wai-wcag