- From: Wendy Chisholm <cwendy10@qwest.net>
- Date: Thu, 10 Feb 2005 17:54:10 -0500
- To: "wai-gl" <w3c-wai-gl@w3.org>
Available at: http://www.w3.org/2005/02/10-wai-wcag-minutes.html
[1]W3C
[1] http://www.w3.org/
WCAG WG weekly telecon
10 Feb 2005
[2]Agenda
[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
Attendees
Present
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
Regrets
Alan_Chuter, Roberto_Castaldo, WATANABE_Takayuki,
Sailesh_Panchang
Chair
Gregg
Scribe
wendy
Contents
* [4]Topics
1. [5]TTF summary
2. [6]Brief Intro to Checklist Format
3. [7]2.4 L3 SC1 (Reading order)
<http://lists.w3.org/Archives/Public/w3c-wai-gl/2005JanMar/03
49.html>
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,
techniques
... 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
drafts.
jw: 1. none of the techs can be required for conformance. they are not
normative.
... 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
enough.
... 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
specs
... that's how we got to point of having one checklist instead of
multiple.
... 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
of.
... 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
checklists.
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
things.
... 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
developments
gv: checklists tend to be that way.
al: encourage, "this will work" and not say, "that will not work for
sure"
... 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
[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
techniques.
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:
checker.atrc.utoronto.ca
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>
[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
meaning..."
... 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
[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
required?
... 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
not.
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
prototype?
gv: rather than having these floating around, is this replacing
something?
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.
baseline
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
problem.
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