- From: Wendy Chisholm <wendy@w3.org>
- Date: Thu, 24 Feb 2005 18:52:26 -0500
- To: wai-gl <w3c-wai-gl@w3.org>
Available at: http://www.w3.org/2005/02/24-wai-wcag-minutes.html
[1]W3C
[1] http://www.w3.org/
WCAG WG weekly telecon
24 Feb 2005
[2]Agenda
[2] http://lists.w3.org/Archives/Public/w3c-wai-gl/2005JanMar/0527.html
See also: [3]IRC log
[3] http://www.w3.org/2005/02/24-wai-wcag-irc
Attendees
Present
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
Regrets
Roberto Castaldo, Avi Arditti
Chair
Gregg
Scribe
David
Contents
* [4]Topics
1. [5]TTF Update
2. [6]new concept
* [7]Summary of Action Items
_________________________________________________________________
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>
[8]http://lists.w3.org/Archives/Public/w3c-wai-gl/2005JanMar/0543.html
[8] 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 [9]scribe.perl version 1.115
([10]CVS log)
$Date: 2005/02/24 23:51:13 $
[9] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[10] http://dev.w3.org/cvsweb/2002/scribe/
_________________________________________________________________
--
wendy a chisholm
world wide web consortium
web accessibility initiative
http://www.w3.org/WAI/
/--
Received on Thursday, 24 February 2005 23:52:31 UTC