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

[minutes] 10 February 2005 WCAG WG telecon

From: Wendy Chisholm <cwendy10@qwest.net>
Date: Thu, 10 Feb 2005 17:54:10 -0500
Message-ID: <420BE612.9030108@qwest.net>
To: "wai-gl" <w3c-wai-gl@w3.org>

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


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

                            WCAG WG weekly telecon

10 Feb 2005


      [2] http://lists.w3.org/Archives/Public/w3c-wai-gl/2005JanMar/0390.html

   See also: [3]IRC log

      [3] http://www.w3.org/2005/02/10-wai-wcag-irc


          Michael_Cooper, Alex_Li, Loretta_Guarino_Reid, Matt, Wendy,
          Yvette_Hoitink, Gregg_and_Ben, Mike, David, Chris, Bengt_Farre,
          Doyle, John_Slatin, JasonWhite, Luca_Mascaro, Becky_Gibson,
          Avi, rellero, Kerstin_Goldsmith

          Alan_Chuter, Roberto_Castaldo, WATANABE_Takayuki,




     * [4]Topics
         1. [5]TTF summary
         2. [6]Brief Intro to Checklist Format
         3. [7]2.4 L3 SC1 (Reading order)
         4. [8]baseline
         5. [9]Handling issues
     * [10]Summary of Action Items


TTF summary

   mc: discussed the question, "must you follow our techniques/tests to
   conform?" if that's teh case, then we'd have to provide techs/tests
   for variety of technologies and be able to address changes quickly and
   deal w/internaional landscape.
   ... therefore, difficult to do however if don't, people may take
   greater license than we'd intended.
   ... still working on requirements. starting to gel.
   ... requirements include checklists, general techs, test cases,
   ... starting to speed up process of reviewing test cases.
   ... need to be able to approve test cases.
   ... a test case required for conformance (just for html at this time),
   means that content would have to follow test cases.
   ... decided that there are some test cases we feel are optional (not
   required for optional). a "holding bin" for now.
   ... some tests we've scrapped (went too far)
   ... checklists and test cases taking up majority of attention. techs
   need to proceed. lots of work to do.
   ... assigning action items to people.
   ... working on ways to move quickly/make progress.
   ... at the f2f at tp will work on. output should be documents ready
   for review by csun f2f meetings and shortly after, publish as public

   jw: 1. none of the techs can be required for conformance. they are not
   ... in that sense, devs able to depart from techs as long as they meet
   the SC
   ... therefore, that aspect is addressed. however, how comprehensive do
   techs need to be?
   ... as far as checklist, completeing one should give strong assurance
   of conformance.
   ... however, may not be possible to provide checklists for every tech
   or combo of techs
   ... however, provide as much info as we can given our resources

   mc: reflecting concerns of the group - 1. using techs and checklists
   to clarify guidelines.
   ... if we don't have them, will guidelines be clear enough.
   ... if we don't provide a checklist, author left to best
   interpretation, is there adequate assurance they following correctly.

   gv: goes back to question of checklists are normative or not.
   ... some feel that checklist should be normative b/c SC not clear
   ... if there isn't a checklist, then ppl would make up their own.
   ... wrt new techs, don't want to create info for non-open, public
   ... that's how we got to point of having one checklist instead of
   ... think can put off issue for now. we have 2 types of checklist
   items those that require both author and user agent requirements
   (these should not change often).
   ... if author's use new rules, then user agents can't take advantage
   ... compatibility issues as well as affordance issues.
   ... before get too deeply into debate, let's put ideas on the table
   and capture them. return to later after have made more effort on

   wac: clarifies that we are not limited to w3c technologies, we are
   limited to technologies developed by consortia in an open process and
   available royalty free, etc. etc. reminds that we are working on
   client-side scripting b/c of ECMA.

   js: wants to encourage innovation.

   mc: who does what work. clear that we need to provide clarity.
   however, we're taking on several parts at once and that could muddy
   ... we could decrease our workload and provide focus.
   ... we need to discuss what we might farm out.

   al: a # of techniques that say, "must"
   ... that language decreases flexibility/innovation and future

   gv: checklists tend to be that way.

   al: encourage, "this will work" and not say, "that will not work for
   ... it is not a repository of all techs on the web

   jw: if this wg were to contemplate normative checklists, would argue
   strongly for checklists being generated by 3rd parties. then have a
   test for valid checklists.
   ... uaag has something similar - how to use uaag in other specs
   ... if checklists were created outside of the WG, create a reasonable
   verification regime.

   yh: some techniques are _a_ way but not the only way and not
   necessarily _the_ way

   gv: need to separate compatibility from ~affordance

   gv: those checklist items where user agent has to do something w/what
   the author does - we need to be concrete about.

Brief Intro to Checklist Format

   gv: did everyone have a chance to look at the prototype?


     [11] http://w3.org/WAI/GL/2005/02/checklistFeb2005/ConceptPage1.html

   bc: tour - broken into 3 sections. 1 scoping query 2 questions about
   elements, types of categories (forms, non-text content)
   ... those related to applicability conditions that we're including in

   gv: purpose for the 2 pages is to make the checklist shorter?

   bc: right
   ... reduces the # of checklist items on page 3
   ... page 3 includes 20-some items which is not a complete set for the
   6 level 1 criterion for guideline 1.1 - it's only listing those tests
   that are most complete.
   ... primarily idea for format

   gv: questions or comments?
   ... since no questions, apparently it's perfect. ;)

   js: yesterday, talked about the need to provide for interaction
   between automated tools and human evaluators.
   ... some of these items likely to be tested by tools. author primarily
   by humans.

   gv: what if someone partially fills out and wants to come back,
   perhaps fill it out then generate an earl statement. when come back,
   feed earl into it.
   ... could run an automated tool could do as much as it could, generate
   earl, show up as comment fields in the checklist.
   ... through more use, generate more complete earl statements

   js: perhaps flip it around so that automated tool can incorporate this
   checklist and use it to spit out results

   gv: use this as a reporting format
   ... then tools will help you fill this out

   <ChrisR> tool that performs evaluation and produces EARL statement:

   js: turn this over to the ERT WG and write guidelines

   wac: sounds like post-rec work.

   gv: yes

   wac: how expansive is checklist that feel we need to get through rec?

   gv: should cover major w3c technologies

   js: what are those?

   gv: html, css. question is also, what about movies? no checklist for
   any multimedia? in general, so not tech-specific.

   js: presumably SMIL
   ... are there ppl we can recruit who are not part of this group who
   can help us write checklists?

   wac: hoping to coord w/european project. preliminary discussions have
   started. they are chartered to work on smil and svg.

   gv: next step - get some checks that are not compatibility related.

   (i.e., general techniques)

2.4 L3 SC1 (Reading order)

     [12] http://lists.w3.org/Archives/Public/w3c-wai-gl/2005JanMar/0349.html%3E

   js: these still need a lot of work. would like to ask if good enough
   to include in next WG.
   ... don't feel will get much better until get suggestions/comments.

   js: there are no techniques for level 1 of 2.4. all we say at level 1
   is a cross-reference to 1.3
   ... these drafts written b4 most recent draft of req docs

   gv: looking at the first one - "when arranged in order that effects
   ... title "reading order" task "controlling reading order"
   ... what is the actual technique?
   ... list under "may be reduced or avoided by..."

   gv: techs tend to morph the meaning of the SC
   ... if more restrictive, have to be careful when map to checklist

   js: ongoing concern is that it is diffcult to simulaneously staying
   general (w/out relying on html) and make the distinction what might be
   required vs good practice.
   ... one goal is to get that feedback from the group.
   ... many places where i don't know.
   ... need a way to distinguish between required vs good practice

   gv: should we organize these by writing in the success criteria, and
   writing "advisory" below it. SC becomes the task. below it: the
   following are things that need to be done...
   ... then below that, "these are recommended..."
   ... required goes into checklist. recommended are advisory.
   ... when come into techniques get this is required, more info about
   why doing it, etc.

   js: that might work. in discussion about including in general
   techniques testable statement (same or not as task) that could be the
   checklist item.

   marked up a draft of something like that at:

     [13] http://www.w3.org/WAI/GL/2005/02/gen1_1.html

   js: these things written in november before that discussion

   lgr: looking at 1st item in reading order. would any of these be
   ... are these all advisory?

   gv: when is it good advice vs when it is required?

   lgr: understand that format a problem, what about the content?

   js: jw raised a question a while ago about reading order, should it
   even be a SC. could be handled by 1.3.
   ... may be another instance of the bottom-up approach.

   wac: if level 3 then it is optional for level 1.
   ... should clarify what level it is required for.
   ... are some people saying should not be required at any level?

   dmd: req vs advisory problematic when dealing w/things that are not
   part of the document. people could theoretically not follow any
   techniques documents and conform.

   js: and these are non-normative docs

   gv: it is compeltely open whether the checklists will be normative or

   lgr: my confusion goes back to yvette's comment.

   <gregg> use the word "necessary" instead of required - at least while
   working on this

   lgr: (looking at using lists) if you are numbering things, can help
   with reading order. but there are other ways to do it.

   wac: restates for clarification - concern that there are many ways to
   do something and fear that we are requiring only one way.

   js: lgr is right. in this case, there are several techniques that
   could work in certain circumstances, so it is that kind of list.
   ... it is clear that is not what people are envisioning.
   ... to return to david's point, confusing required/optional point - my
   understanding of the status of the checklist (normative or not), but
   clear that the techs docs will be non-normative.
   ... have to be careful to use words like required here.
   ... we are providing non-normative info. "this will be required" in a
   tech doc is a non-normative statement.
   ... this is an issue for how we use the term "required"
   ... could say, "this is currently the only way we know how to do
   this." and may not be able to go any further.

   gv: currently believe to be necessary.

   wac: important for us to provide as much as we can about our intent so
   that people can interpret for their own situations.
   ... js, bc, and i are working on a prototype

   js: should we hold off on these drafts until after we show the

   gv: rather than having these floating around, is this replacing

   js: emptiness

   gv: put an editor's note that the form and format is being
   reconsidered. put into doc to collect them.
   ... anyone speak against?
   ... internal draft

   no one disagrees

   bc: need to be cleaned up before next public draft

   js, gv - agreed

   gv: may pull out if don't have cleaned up.


   issue 1324 <[14]http://tinyurl.com/6qqvk>

     [14] http://tinyurl.com/6qqvk%3E

   gv: these were public comments
   ... people expressed concerns about baseline.
   ... concern that it will create a gap - how can you say that you know
   there is a gap but we're only requiring x.
   ... please read it.

   issue 1073 <[15]http://tinyurl.com/6l3tz>

     [15] http://tinyurl.com/6l3tz%3E

   gv: discussion of client-side scripts.
   ... uaag doesn't require scripts but if you support them, here's what
   you (a user agent developer) needs to do.
   ... does that mean that authors can use scripts w/out an
   equivalent/alternative, or only worry about accessible scripts.
   ... that parallels 4.2 - if you provide your own UI, ensure that what
   you do meets UAAG.
   ... that would seem that scripting is not outlawed any more than
   anything else as long as you do it in an accessible form.

   issue 1161 <[16]http://tinyurl.com/5sjcd>

     [16] http://tinyurl.com/5sjcd%3E

   gv: how much do we assume about the technologies that end-users have?
   ... it could be accessible if you have the right parts or do we say,
   only those things that everyone is likely to have are accessible.
   ... how easy is it to get the technologies needed.
   ... the $40,000 user agent would make it accessible vs. there is a
   free UA that does it but you choose another one - may not be the
   author's problem.

   m3m: there is a continuum on the scale where on the developer side
   there is a lot of javascript that is superfulous. can do it or do it
   in a way that doesn't require javascript or can be done in an
   equivalent manner.
   ... in the techniques, biased towards stripping out as much
   superfulous javascript as possibl.e
   ... however, point where a web doc becomes a web app.
   ... at a certain point, you can't have everything from a web app
   unless create a separate site.
   ... can say it is part of the baseline, but that techniques suggest
   say to use as sparsely as possible.

   <LucaMascaro> how it is behaved to us when the application adopts
   javascript XMLhttp for modify the content?

   yh: 40k is ok if everyone has to pay it. that's not an accessibility

   gv: means that pwd is paying that while others are not

   yh: really like that the author not have to worry about the
   capabilities of the user agent.
   ... as long as the author can make content that follows guidelines,
   the user will be able to find a UA-conformant tool.
   ... creates problems in the short term. and introduce problem when new
   tech introduced.
   ... however, if tells authors how to create content that is at least
   theoretically accessible should stimulate creation of accessible UA.

   al: nothing else to add

   jw: important that we are talking of a recipe for setting baseline
   rather than setting a baseline itself.

   wac: what are the next steps?

Handling issues

   yh: a few weeks ago (25 jan), sent mail about captions/audio
   descriptions. didn't get much response.
   ... how do i put issues out there that didn't get much attn.
   ... how raise issues if not on the list.

   gv: when raise it on the list, it gets put on bugzilla. but may not
   get discussed again until 1.2 comes around.

   yh: felt like was dropping a bombshell and no one responded.

   gv: if worried, check with ben so that ensure gets added.

   bc: even better, add to bugzilla yourself.

   <scribe> ACTION: yvette ensure that 1.2 issue sent to mailing list is
   added to bugzilla

Summary of Action Items

   [NEW] ACTION: yvette ensure that 1.2 issue sent to mailing list is
   added to bugzilla

   [End of minutes]


    Minutes formatted by David Booth's [17]scribe.perl version 1.110
    ([18]CVS log)
    $Date: 2005/02/10 22:53:02 $

     [17] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [18] http://dev.w3.org/cvsweb/2002/scribe/

Received on Thursday, 10 February 2005 22:54:19 UTC

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