W3C

- DRAFT -

WCAG WG TTF weekly telecon

26 Jan 2005

Agenda

See also: IRC log

Attendees

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
Chair
SV_MEETING_CHAIR
Scribe
wendy

Contents


 

<scribe> scribe: wendy

Date: 26 January 2005

<David_> test

Requirements for General techniques http://lists.w3.org/Archives/Public/w3c-wai-gl/2005JanMar/0301.html

js: examples should build on each other (from SC through general through other techs documents)
... 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?

mc: 1.
... 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 for general
... 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 those?
... 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 techniques.
... 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) and examples.
... 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 overcomplicating.
... 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 that...
... 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 testable statements?
... 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.

mc: agree

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 tech-specific.
... end goal is that they are useful and that people don't need to wade through lots of info.

Requirements for checklists & techniques & test files http://www.w3.org/WAI/GL/WCAG20/WD-wcag2-tech-req-20050125.html

mc: section 6 - test file requirements

ja: compatibility of test files?
... 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 priority.
... 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 useful
... but if not, then we won't
... maybe have a place for limitations or provisos

mc: in metadat?

ack

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.

http://www.w3.org/2004/04/wcag-charter.html#deliverables

Applicability Conditions http://lists.w3.org/Archives/Public/w3c-wai-gl/2005JanMar/0062

ag: describes - http://lists.w3.org/Archives/Public/w3c-wai-gl/2005JanMar/0062
... 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 every evaluation.
... 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.

ag: agrees
... 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 employed?
... 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,

http://www.accessinmind.com/w3c/HTML14_4.html

http://www.accessinmind.com/w3c/ConceptPage2.html

ag: technology, scope, content

wac: conformance level, content/element, description/prose, scope. technology inherited from document it is in.

Assign reviewers to test files http://www.w3.org/WAI/GL/WCAG20/tests/

mc: there are a lot of existing test files that have not been accepted in a formal way and not official part of test suite (only about 10 tests that are).
... 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.

<ben> http://www.w3.org/WAI/GL/2004/11/19-sc-techniques-mapping.html

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?

<Michael> http://www.w3.org/TR/AERT

mc: closest thing is AERT
... no test files

<David_> '

<David_> '

<David_> ''''''"/

<David_> '

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.

Summary of Action Items

[NEW] ACTION: john and michael - incorporate changes to gen techs
... requirements and incorporate those into requirements for WCAG
... 2.0 Checklists, Techniques, and Test Files
[NEW] ACTION: michael write definitions for testable statement,
... test file, and test case. update draft based on. include
... other edits as discussed.
[NEW] ACTION: wac add applicability condition element after task to
... dtd (make it optional not required)
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.109 (CVS log)
$Date: 2005/01/26 17:14:14 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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]