wendyPresent: 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√°lezhttp://lists.w3.org/Archives/Public/w3c-wai-gl/ 2005JanMar/0512.htmlandi - please use a colon after the people's names (it's for the formatting scripts). ala "mc: says blargh"Scribe: AndiChair: Michael Andiok - gotit wendyMeeting: Techniques Task Force of the WCAG WG face-to-face (at the Technical Plenary)thx joeclarkDO THE WAVE! Andimc: WCAG Techniques Requirements wendytalking about this draft: (michael may be showing a newer version) - http://www.w3.org/TR/wcag2-tech-req/ Andire-opened because needed boundaries around test cases and needed requirements for general techniquesmc: Don't identify the technologies for technology specific techniques because then we would have to have a document for each benDraft Reqs: http://www.w3.org/WAI/GL/WCAG20/WD-wcag2-tech-req-20050208.html Andimc: technology specific techniques will grow as new technologies are created AliGircAliG has joined wai-wcag wendyagenda+ every technique must map to a SC wendyTopic: Requirementsagenda+ permissable to create techniques for technologies that cannot meet the minimum Success Criteria of the guidelines even in combination with other technologies Andiwc: recaps discussion from last Thursday's WCAG teleconferencewc: checklists would not have technology-specific "criteria" but would be annotated with t-s information as explanations wendyagenda+ providing user agent information and providing interpretation info so that ppl can create own techniques Andimc: under General Techniques - req't that each general technique must clearly indicate what is required for conformance to the SC to which it applies.mc: this is a general requirement that applies to "all" techniquestc: how does reading level relate to technical information?js: it works finejc: 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. RyladogircRyladog has joined wai-wcag Andijc: also, it's specific to Englishwc: yes, it is specific to English but it should facilitate the translation of our documents into other languages. mcmayircmcmay has joined wai-wcag Andijc: plain language is desirable because WCAG 1.0 doesn't have itjs: 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 onesjs: general issues of readability without specifying grade-based reading levelag: techniques should just reference the other relevant documents wendyaction: mc add defn of positive test case * RRSAgent records action 1 wendyaction: mc update references to "additional ideas" * RRSAgent records action 2 wendyagenda+ techniques related to level 2 and 3 SC wendyaction: mc add applicability conditions to req * RRSAgent records action 3 wendyhttp://www.w3.org/WAI/GL/WCAG20/WD-wcag2-tech-req-20050208.html Andimc: need to create a change log for this document wendyaction: wac and mc create change log for reqs document * RRSAgent records action 4 Andimc: when the document is finalized, we will create a change logwc: we do have change logs for all technical documents wendyagenda? Andias: for "reliably human testable" criteria, 80% implies that we are testing to make sure that 80% of the people will agreewc: need to take this definition to the WCAG group wendyhttp://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-20050211/ Andichecking language in WCAG document - it's differentaction: mc to use the same definition in requirements document * RRSAgent records action 5 wendyaction: 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." * RRSAgent records action 6 Andioops wendyaction: jenae compare definitions from reqs doc with QA glossary * RRSAgent records action 7 Andiag: a testable statement is something that can be either reliably human tested or automatically machine tested shawnircshawn has joined wai-wcag Andiag: disagrees that related technologies should reference each other's techniquesag: for example, HTML should only provide HTML techniques wendyagenda+ bindings between techniques documents Andiag: then if CSS is replaced with something else, you don't have to modify the HTML techniques document JessieircJessie has joined wai-wcag Andiwc: discusses issue of mapping every technique to a SC - seems to be very problematic with CSSwc: don't want to have to create CSS-specific SC in the guidelineswc: there are many CSS techniques that meet the spirit of the guidelines but don't map to a specific SCmc: 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 SCjs: reminds us that all techniques are non-normativemc: but they are effectively normative if they specify how to meet the normative guidelineswc: example - creating borders - maps to GL 1.3 - ensure that information, functionality, and structure are separable from presentation shawnircshawn has left wai-wcag Andidm: ran into a lot of similar issues when writing general techniques for GL 2.5wc: does make me worry about the completeness of SCmc: if we think something is worth doing, there should be a SC associated with itmc: but practically speaking, we are years away from having a set of guidelines that do thisjc: I can come up with a few PDF techniques that do not correlate to HTML techniques or anything in WCAG 1 or 2jc: but there isn't a nice 1-2-1 relationship between all these thingsag: each SC should provide a benefit and they should all be supported by techniquesag: could probably select 10 that are "really" beneficial and 90 that are "fractionally" beneficialwc: could have a SC for every guideline at every levelwc: that would say "you have created a technique that does blah, blah, blah"wc: important to provide enough information for people to create their own techniquestc: expect to be writing techniques that other people can understandtc: need internal way to say how we're going to write techniques - should be able to externalize thatwc: would force us to document assumptions and processes that people can replicatewc: not a proposal yet - a questionwc: do worry that if we do something like that, there would be a lot of questions about the checklistsmc: 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 wendyScribe: katiescribe: ryladogaction: wac proposal about mapping techniques to success criteria or guideline ok * RRSAgent records action 8 RyladogBen:JS: It isnot that it is permissable o write tech? I am just sayingthat we do not want to use the word permissableMC: JS: This one should go to the disc of checklistSG: It is silly to say thatcss HAS TO FIT INTO THIS LANGUAGE wendys/SG/ag Ryladogmc: YOU CAN USE WHAT YPOU LIKE AS LONG AS THE END PRODUCT CONFORMSmc: WE CANNOT USE THE WORD fLASH ANYWHEREMC: we do not know that it is possible to have it conformMC: Is it useful to provide tech for tech that connmot conform?MC: this was a debateJC:JC: telll people all the relevant things evewn if it cannot meet all the sectins of the specMC: fall back tech might workTC: where do we draw the line?AG: that is not quite rightJC: CIO may say we will conform to 80%WC: we are trying to get rid of thatLS: we find it easier to cater to some dis. than othersAL: because it does not meet all the guideline does not nec. make something accessTC: look at it from the point of view of the authorsTC: nwhat if they are using a technology does not provide that functionality for the authorsTC: we need to find tech for themTC: can your tech intergrate with anoth4r tech?TC: do we insist that all tech meet that minimum? Doesw thsat make sense?JC: is it fair to say relevance or applicability is mportant?AG: you really ought to have this in that because it is a legal requirement?MC: I don't think you can prove thaTAG: desicions around this atble will cost the EU millions of dollarsJC: a validator will flunk an access pageMC: that is already actionedWC: I am concerned about fallback page, or alternative pagesWC: flash will only work on Windows machinsWC: if they had a plugin, that would ne greatMC: it is the fault of the platform, not the techMC: until user agents kind of thing againTC and WC: it is reloated to baselineTC: did that discussion get resolvedAG: what about your intended audience?WC: I really worry about that they, you are assuming other people are not part of your audienceJC: you can optimiseJC: text onlyWC: bit I am concerned that people can chose that tranformationWC: it should be a choice joeclarkNo, *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). RyladogAG: I do feel that sometimes there is this idea that you must produce one set of content for everybodythanks Joe I am very bad at minutingLS: tomorrrow there is going to be discussion about thisWC: a couple of things set off bells in my heafLS: we should scheduke concernes about adaptive contentTC: what this is a framework for techni are we going to enforce technologies that confrom to techniquesmust provide the overall min req of WCAG 2JC: and developing technologiesMC: a tech that is not mature ids not ready for WCAF conformanceAG: when do we know it is ready?JC: that is a bit presuptious I thinkMC: we need to work with tech that will conform with WCAG 2JS: but we do have levelsJS: we are already building in an assumption that there are things that cannot conformJC: we should be honest about O or 1BC: we do not inadvertantly applyBC: we are tryingf to inform poeple that this tech cannot address this techg at this timeDMD: are we going to name tech?TC: noTC: specific things for specific people, provide the same content. It is not that you cannot use the tech that you waANTjc: it seems that it is not permissableMC: is it permissable to provide tech for less access tech?JS: as far as I know , we are supposed to be providing tech for W3C tech?JS: that goes back to the req doc for techJS: to Macromdeia or Adobe; here are the requitements for youto writetechniques for your technologiesWC: I think it only make sense to have a combined html and css tech, etcWC: are we doing an annoteted checklist? I am not sure that we need it for recommAG: in the past, all was bound through the checklists, you don't write combined techniques, what if someone is using only html?WC: that is why combined checklist is goodMC: I would like to look at seperate techniquesw for clear seperation wendyq+ matt, lisa, tom Ryladogof technologies wendyq+ greggircgregg has joined wai-wcag wendyircwendy has left wai-wcag alanircalan has left wai-wcag Michaelq? Andiscribe: Andimm: recaps what MC said - opposed to combined document - HTML & CSSmc: not opposed to it but it won't meet mc's needsmm: mc has specific needs because develops eval toolsmm: target audience is authorsmm: CSS is incomplete document in terms of satisfying needs of authorsmm: have to look at this holistically - CSS is "a" way to separate content from presentationmc: believe can have a "not very pretty" document that is HTML onlymc: don't believe it is just my needsmm: we should be encouraging people to use CSS Michaelack matt Michaelack lisa Andijc: all graphical browsers use a default set of CSSls: when merge technologies in a document, limiting audience to those with expertise on all the technologies in the document AliGq+ Michaelack tom Ryladogq+ Anditc: similar to discussion on conformance of authored vs. deliverery units wendyircwendy has joined wai-wcag wendyq? Anditc: CSS document is authored unit - only certain things are applicabletc: it may cause complications to try to test the CSS document separatelytc: it's only relevant to test the CSS as it is applied to the HTML document Michaelack wendy joeclarkadd me to the queue, please. Andi(joe, type q+) joeclarkq+ AndiQ? joeclarkq+ Michaelq+ joeclark sh1mmerircsh1mmer has joined wai-wcag joeclarkwhoops. Andiwc: for e & r tools developers, need to provide an index joeclarktrue. Michaelack alistair Andiwc: 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 Michaelack al wendyagenda+ usability of the documents, audiences wendyq+ davide joeclarkack AliG Andiag: maybe we should combine wc points about usability and intended audience of document wendyq+ to say, "where do you stop? where it m akes sense for our users" wendyack ryla Andiag: have to decide who is the primary audience joeclarkack Ryladogack Ryladog wendyq+ john Andikh: have to be able to combine documents but will also need to be able to find individual things wendyq+ lisa Andiwc: not suggesting that all techniques are in one document - just suggesting that CSS be covered in HTML documentmm: 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 developerswc: suggesting that you have documents for "host" languages - HTML, SVG, SMIL, etc. and cover CSS in themwc: other people like WebAim, Jim Thatcher, etc. will address other audiencesag: thinks we should produce separate documents and let others combine themwc: almost every single test for CSS links back to an HTML techniquewc: makes sense to come up with a concrete proposal that we can debate wendyq+ jenae Michaelack joe wendyq- Andijc: wrt ls point about barrier to entry - authoring tool should handle without the author even having to understand it Michaelack d wendyq+ to say "need audience section for every part of the technqiues requirements" Andijc: CSS needed for simple documents is not that complicated to understanddm: tc drew up some good personas for the document target audiencesdm: look at the personas quite often to ensure we are being true to themag: so what was the result of that work? separate docs or combined docs better?dm: it was never on the table before to combine the technologiesdm: thinks there is some merit to combining themdm: want people to use CSS Michaelack j Michaelack john Tomsh1mmerircsh1mmer is now known as Tom alanircalan has joined wai-wcag Andijs: techniques documents are not "documents" - collections of individual bits - not meant to be read front to backjs: they are really "long lists" of techniquesjs: 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 viewsjs: referring back to wc comment about index - not just an index, there's also a TOC, provide different ways of getting at materialjs: need to find a way to talk about the set of documents that constitute WCAG2.0js: our list of audiences for these documents contains different people with very different needs AliGq+ Michaelack lisa Andijs: need different avenues of combining, separating, and REALLY good navigation system Andils: 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 Andils: people don't always know how to ignore information that they don't need to learn wendyack we Andils: it's irrelavant though because we can provide both very easilywc: we have to define exactly what we have to do to get to final recommendation this yearls: yes but we could have a "to do" list of things to do after we get to final recommendation Ryladogq+ AL Andiwc: litmus test - is this needed to get to recommendation?wc: current view after reading CSS techniques and listening to usability feedback, sense is that we need techniques documents that have "macro level" taskswc: example is "how do I create a form?"tc: that's user centered design (UCD)wc: haven't done a lot with user scenarios and persona we created at the Toronto meeting a few years agowc: don't want to re-create the usability problems of WCAG 1.0wc: techniques are a database dump - don't connect the techniqueswc: works well for e & r tool developers - doesn't work well for people trying to figure out how to implementwc: need different audience statement for different deliverables - get Shawn to review Michaelack sh Andiq+ jenai wendyaction: mc and wac incorporate/link to scenarios/personas (that eowg evolved from tom's earlier work) * RRSAgent records action 9 Michaelack alig Andiag: Michaelack jenae Michaelack jenai AndiMichael, when you did "ack j" instead of "ack john", it bumped jenai off the queue * Michael sorry! joeclarkack AliGack AliG