WCAG WG weekly telecon

24 Feb 2005


See also: IRC log


Bengt Farre, John Slatin, Roberto Scano, WATANABE Takayuki, Wendy Chisholm, Alex Li, Andi Snow-Weaver, Luca Mascaro, Yvette Hoitink, Loretta Guarino Reid, David MacDonald, Mike Barta, Jenae Andershonis, Matt May, Roberto Ellero, Alistair Garrison, Gregg Vanderheiden, Ben Caldwell, Neil Soiffer, Jason White, Chris Ridpath, Sebastiano Nutarelli, Doyle Burnett, Becky Gibson, Michael Cooper
Roberto Castaldo, Avi Arditti


TTF Update

Continuing to discuss test files and prepare for the face-to-face meeting next week - we have a joint meeting with UAWG and PFWG about dhtml roadmap.

new concept

gv: presume people have read post

<wendy> http://lists.w3.org/Archives/Public/w3c-wai-gl/2005JanMar/0543.html

js: like new approach clearer better good

lg: like that it reflects what our mapping issues did finding sc in that process, read our minds well

yh: like it a lot. thought it was already what we were doing.

gv: still lots of work to do but it solves big issues we think, but lets really look for ugly corners

doyle: lots of work but a lot better

gv: some hard stuff is ....ben looked at me and said how will we make expanding checklist
... a least 1.0 had checklist, we leverage that idea
... guidelines>tech doc> checklist
... annotated check list in checklist order rather that tech doc
... go from there to techs which help understand guidelines
... explains the way it works

<LucaMascaro> i'm sorry, but is not more siple for the tester say "if the technology support that assistive tecnology, then...."

wc: litmus test..."what do we need for recommendation" apply this to the variety of views that can be generated. Are they needed now or can be generated after WCAG 2.0 goes to Recommendation?

gv:it does not need to be generated before Recommendation. What we need to capture is before Recommendation is, "what was in their minds when they wrote the guidelines version." the next exercise is to test this from top to bottom with a few guidelines: 1.1, 3.1, and 4.1 or 4.2.

js: Didn't hear any from Guideline 2. Suggest that we include at least one guideline from each principle.

gv: sure

jw: found proposal, issue, for 1.3 (fairly general nature) what you do depends on the content you write, different tech have different structures

gv:we should not be exhaustive, should be comprehensive. we want to be able to make sure sc are in fact very clear, some places we were wishy washy because wanted to cover more, but we sacrificed the line that "you can't cross" our new approach will cause us to be disciplined and sometimes wring our hands but its ok, . it worries me a bit

jw: my concern is that the success criteria will not withstand strict interpretation. they are not written like legislations, would be better to keep level of exactness that people try to achieve in legislations [appropriate summary of jason's comment?]

gv: what will happen as we do that is "plain& simple " will take beating but that's where tech docs come to the rescue

js: we need to come up with a wordcount to aim for

gv: we should not put too high a premium on being short

mm: suggest if requirements for content comprehensibility into doc, we would not be credible unless we did it on our own work
... we use some difficult terms and we need to keep it simple
... reading level should be easy

gv: agree
... readability up comprehensibility up
... must practice what we preach, or withhold our rocks

cr: nice end to end, may affect test suite, seems narrowly defined

gv: "test tools" better name, none of them will allow them to conform run them as procedures or as code,
... very few of sc can be entirely automatically
... determined
... a pdf image based "declaration of independence" is next to a link to text version. This is accessible but would flunk tool test

wc: concerned of direction...don't want to call it a test tool, test suite better because "tool" will be interpreted as w3c is creating its own "evaluation tool"

<rscano> "Test Criteria"

gv: ok, if we have a suite of tests, different from test suite, we have suite of tests,
... test suite for testing tools, here will tell you if it is a good tool for auto

wc: we want to make sure we include human judgement

gv: yup erase last line of mine
... let's create a test suite for testing tools

cr: agree with wendy, most include human intervention, what about test (non-normative) away from normative stuff

gv: I don't think we can stop
... is the test suite for testing tools or testing web pages

wc: can you call back we lost you

cr: think to test tools and pages
... when we bring non-normative to normative, close to guidelines, implies that the test are "required for performance" or if they are passed the web site "does conform" which may or may not be true

gv: let's divide it up. a tool tester and web tester samples
... thought there were 2 different things, and it is confusing
... chris do you want to separate the tests from the guidelines

cr: yes

gv: that's what we've done

cr: but it appears the tests are almost normative.

gv: testing to techniques not sc
... that separates it. SC are necessary, there are techniques to address it and the test test the techniques no the sc

js: addendum an important point is that people could satisfy sc b/c of what we provide, but they may have their own techniques

gv: sure
... solves a million problems if we can execute it, getting specific enough
... the history is that we went very general of guidelines, and relied on techniques to make up slack,

wc: when talking about rewriting sc, what do you mean, significantly longer? what is the extent of changes?

gv: does not change them all, some ok, but sometimes qualifying additions
... i.e., "in a standard fashion" if there is a standard way they must do it

aw: nervous about timing, rewrites take a lot of time. what is the difference between a "standard way" and "until user agents?"

gv: ie. in html alt text has standard way that is supported

loretta: standard and supported could be problematic

gv: going to have to be concrete, can't say in glossary standard = typical
... whether it works is whether we successfully define words

jw: using the language and feature of the language used in the technology specification. problem is that people can reduce requirements, need to encourage people to choose the right type of technology, case some people will choose lousy technology to lower their requirements

js: aka me again
... another way of coming at problem is to do our best to think about functional specs we after

gv: yup

<wendy> goal - functional statements

gv: sometimes complication is fine, as long as it is to spec
... its worth a lot of work to make the sc checkable cause there were convolution in the other way, including sc non normative in a normative document
... do we have consensus into trying to make this work or prove that it doesn't
... no dissent yet?

wc: so we don't go back down the path again, its ok that even if people don't get the sc: we will have enough informative stuff they will be able to make their interpretations on their own

js: sc don't say what to do, they say what will be true at the end of the process

wc: prefer functional requirement (ala Loretta's suggestion) instead of "in a stand way"

gv: "standard way same as why we did 4.1 & 4.2

lg: like to pick up jason's wording rather than "standard way"

gv: the definition says if there is a stand way use it

gv: ok to make sc objective enough that they cannot wiggle out

neil: worried that sc get too long

gv: yeah in going over them not too much longer..comments about length were re: plain language not making more bulletproof

bc: worried going to techniques next week, is there new sorting vocabulary?

gv: you're closer than me, much would not change
... in a standard way means if in SMIL then use common SMIL way...

wc: i think next week tech linking to sc. and have different level of requirement...perhaps this approach will free us, with less focus on tech specific checklist
... next week less pressure from tech specific checklists
... if we have focus on sc at functional level, then techniques could be less atomic....ie. form accessible....here are the macro level tasks,

gv: different views. techniques docs have reference and application section.
... access board did a special thing about forms b/c we didn't go into specifics

js: seems we are getting to fundamental usability premise that when you present material you don't require administrators to dig through stuff

gv: came out of wendy's comments, "why can't we go back and make sc a checklist"

Consensus to move forward with the goal of checklist comprised of testable success criteria

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.115 (CVS log)
$Date: 2005/02/24 23:51:13 $