See also: IRC log
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.
gv: did everyone have a chance to look at the prototype?
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)
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: 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.
issue 1324 <http://tinyurl.com/6qqvk>
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 <http://tinyurl.com/6l3tz>
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 <http://tinyurl.com/5sjcd>
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?
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