W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > January to March 2005

[minutes] 24 February 2005 WCAG WG weekly telecon

From: Wendy Chisholm <wendy@w3.org>
Date: Thu, 24 Feb 2005 18:52:26 -0500
Message-ID: <421E68BA.40700@w3.org>
To: wai-gl <w3c-wai-gl@w3.org>

Available at: http://www.w3.org/2005/02/24-wai-wcag-minutes.html


      [1] http://www.w3.org/

                            WCAG WG weekly telecon

24 Feb 2005


      [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


          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




     * [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


      [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

   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

   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
   ... 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
   ... 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 =
   ... 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

   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

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

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

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

   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
Received on Thursday, 24 February 2005 23:52:31 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 16 January 2018 15:33:52 UTC