See also: IRC log
<scribe> scribe: wendy
Date: 26 January 2005
js: examples should build on each
other (from SC through general through other techs
... reads through proposal
dmd: can we get to a 9th grade level?
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"
... don't know that we can get tehre, but want to try.
... have been spending a lot of time with this wrt techniques for 3.1
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?
... creating one example for every tech will be difficult.
js: what does it say if we can't do it?
<Michael> mc: 1 entry per SC - are some 100% tech specific?
js: (rephrasing) are there any SC that are tech-specific?
bc: reading score - when it comes to technical terms at technology-specific level, how does the score...
js: this is a requirement just
... would like to aim for that for other docs, but doubt it for tech-specifics
bc: may not want to set it as
goal for self in req doc.
... same diverse audience? general techniques may be more appropriate for specific audience. each document in our collection seems to have slightly diff audience.
ja: thinking about examples -
there are several in the guidelines, how will we deal with
... we haven't mapped the examples from the techniques and how to apply techniques to those examples.
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.
<Zakim> wendy, you wanted to say "purpose of requirements"
<Michael> wac: can include "must", "should", "may" but purpose is for at each stage in Rec track to explain how we met the requirements
<Michael> wac: doesn't mean we can't put things in, just have different "strengths"
ag: testability of general
techniques - this idea of one example, could get tricky.
... show the gen as part of each tech-specifics. i.e., general incorproated into each of the tech-specifics to elaborate on examples.
js: html tech incorp. general?
ag: when you start to test those,
you'll need tech-specific examples.
... html techniques with general applied
js: talking about documents, test files, checklists?
ag: techniques documents
js: what would such a document look like? sounds like saying that general techniques would not be a separate document.
ag: then provide html general techniques, that are testable
js: then replicate the same material in other documents?
<Zakim> Michael, you wanted to say maybe examples can be in a technology is necessary, but further elaborated at tech specific level
mc: maybe we can consider
acceptable for examples to be tech-specific in general
... those examples could be further elaborated in the tech-specifics
... reluctant to get rid of general techniques, because a lot of discussion went into having them and discovering the need for them.
ag: would need a tech-specific example for every tech you are addressing, could have 50 examples.
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.
js: don't see anything wrong with
refering to specific technologies in general techniques.
... 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.
... 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.
... for english, measured in # of words and syllables/word.
... it looks at averages. so, it's not that you can't have long sentences or long words. it's averages.
... 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.
... and we should make the document as accessible as we can.
mc: obviously, questions about
reading levels, testability (what it means for general techs)
... do we like the idea generally of the general techs and where they live (section w/in techspecifics)
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.
... general techs is something that we pass through. not sure that we should have an example for each one to be dogmatic.
... concern that people will read through extra stuff.
... if we keep it separated out, then should link to examples in the tech-specific documents.
js: re:examples - my guess is
that devlopers will spend less time on gen techs than policy
makers or trainers.
... ppl who want gen techs are those for whom not interested in tech-specifics
al: or where we don't have tech-specifics
ag: testability - may be
... would need test files
mc: right, do we have test files for gen techs
js: yes. how would that work?
<Zakim> 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
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
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
dmd: it's not on the table that
we inc gen techs into tech-specific, if we were to reexamine
... have a central pool and the specific docs would pull from that pool, so that there isn't repetition of work.
<Zakim> ben, you wanted to say, "maybe not test files, but testable statements?"
bc: maybe not test files, but
... the checklist will have a decision tree.
... perhaps some of the testable statements (for gen techs) are met by following tests at technology-specific level.
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.
mc: that is possible
... propose that we add a section for general techniques in the reqs for techniques checklists, etc.
... also propose then incorporate changes to john's proposal and incorporate into that doc
<scribe> ACTION: john and michael - incorporate changes to gen techs requirements and incorporate those into requirements for WCAG 2.0 Checklists, Techniques, and Test Files
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)
ag: additional point - use of
vocabulary. could replace general words with
... end goal is that they are useful and that people don't need to wade through lots of info.
mc: section 6 - test file requirements
ja: compatibility of test
... compatibilty against browsers/user agents.
... "this works in browser A but works in browser B, C, D"
mc: may need to have test cases for browser variations
ja: in metadata, this test will
work in these browsers...
... result of running the test
mc: perhaps user agent info for techniques move to test files
<Zakim> wendy, you wanted to say "must/should"
<Michael> wac: concern about must have 1 test case for each technique, because of getting through process
<Michael> wac: might be better to say "should" so lack of test cases doesn't trip us up in Rec process
<Michael> wac: we can continue to expand test suites after Rec
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
... that could trip us up later.
... don't know that will have an absolute true/false for each test. is there a way to state limitations of a test.
mc: change granularity to a should?
ls: will do it when it is
... but if not, then we won't
... maybe have a place for limitations or provisos
mc: in metadat?
ag: "test cases must support a
testable statement or statements"
... in other techs write test statements first then forge test cases.
mc: a test file is a test case?
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.
mc: is the metadata associated w/test file or testble statement?
ag: test file
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.
mc: test files support a testable statement. the metadata is assoc with testable statements.
<AliG> AG agrees
ja: ppl use diff terms. we justneed to deterine what means for us and define.
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
mc: perhaps define things better and will make clearer
<scribe> ACTION: michael write definitions for testable statement, test file, and test case. update draft based on. include other edits as discussed.
wac: each techniques must have a testable statement. each technique should have a test case.
ag: or perhaps don't need test files.
mc: propose that we merge general techs into this. believe that accepted.
ag: describes -
... ppl can know w/certainty if tech applies to them or not
mc: e.g. - frame title is applicable if frame is used
<Michael> wac: if this checklist oriented, is it mainly metadata?
wac: sounds like metadata used to assemble the checklist
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.
wac: an example where hard to determine if something applies or not?
js: the checklist of checkpoints (for WCAG 1.0), had applicability statements, "if you use frames..." and groups the relevant checkpoints.
ag: w/the 1.0 checklist, have
groups. therefore, applicability statement given.
... only thing that might be missing is a document that tells youhow to recognize when youhave an item.
... how do you know if you have a data table?
wac: perhaps then by section.
techniques are already grouped.
... e.g. of data tables, when to apply was to be included int he heading of that section.
mc: supporting the applicability
conditions, in our software we've built applicability into
... have found that sometimes the applicability is straight forward. in some cases, less straightforward.
... useful to have that spelled out for every technique.
... fine it if is metadata and presented or not.
... quite important for checklists.
... can't assign pass/fail to something that is n/a
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.
<Zakim> wendy, you wanted to say "at min add applicaibility to dtd"
<scribe> ACTION: wac add applicability condition element after task to dtd (make it optional not required)
ag: about the term, "applic.
conditions" could be one or more statements.
... if these 3 statements are yes, then this is applicable.
mc: would not want to have more than one applicability condition / technique. perhaps it has a few clauses.
... one statement and prehaps conditions w/in the statement.
bc: are there subsets of
pplicability conditions? required at level 1, 2... only if
using element x... etc.
... there might be more than one
<applicability-conditions> <conformance-level>x</conformance-level><elements><element>img</element></elements><prose>blah blah thsen aoiuwer</prose></applicability-conditions>
<Michael> I propose using <el> instead of <element> because it's already in the xmlspec dtd
ag: some things will relate only if building entire web site. site map only for scope of whole site.
scope: page, site, element
tb: which technology
... could use html or could use xmlw/css. how do applicability conditions relate to technologies?
mc: my view is that the applicabilty to tech comes from the fact that it is an html-techs document.
ag: the work re: checklists, supported a lot of the things about what ac would look like,
ag: technology, scope, content
wac: conformance level, content/element, description/prose, scope. technology inherited from document it is in.
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
... 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.
dmd: hoping that people will look at them, see if have same problems or acceptance?
mc: yes, reviewer should be as thorough as possible.
tb: what are the metrics for review?
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?
... should alt-text be short? we discussed what was short and if requried.
<Zakim> wendy, you wanted to say, "wording - does it synch with success criteria. vocabulary used in synch"
wac: additionally: are there any gotchas? anything that will cause contention when goes for public review?
ag: write testable statement for each technique. then look at the tests and determine how well they are mapping to the testable statements.
mc: may come up with very different statments that what exist.
ag: would see how well the tests map to the techniques.
dmd: look at technique, then look at the test case
bc: the thing to look for is a reality check. what do our current guideliens and techniques actuallys ay.
dmd: is there one for 1.0?
mc: closest thing is AERT
... no test files
mc: arranging batches about 6-12
js: requests small batch under input]
alistair - yes, send it! :)
sounds good. happy to hear only 10 tasks that don't map.
This is scribe.perl Revision: 1.109 of Date: 2005/01/21 04:36:25 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Found Scribe: wendy Inferring ScribeNick: wendy Scribes: wendy ScribeNicks: wendy Default Present: Michael_Cooper, David_MacDonald, Wendy, John_Slatin, Jenae, Ben, [IPcaller], Alistair, Jeremy_Carroll, Lisa, Alex_Li, [Microsoft], Tim_Boland Present: Michael_Cooper David_MacDonald Wendy John_Slatin Jenae Ben Alistair Lisa Alex_Li Tim_Boland Regrets: Chris_Ridpath Ken_Kipnes Becky_Gibson Sailesh_Panchang Don_Evans Neil_Soiffer Agenda: http://lists.w3.org/Archives/Public/w3c-wai-gl/2005JanMar/0303.html WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 26 Jan 2005 People with action items: - add after applicability changes condition element incorporate john michael task wac WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]