See also: IRC log
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.
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