WCAG WG weekly telecon

10 Feb 2005


See also: IRC log


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, Sailesh_Panchang


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?


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) <http://lists.w3.org/Archives/Public/w3c-wai-gl/2005JanMar/0349.html>

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?

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 scribe.perl version 1.110 (CVS log)
$Date: 2005/02/10 22:53:02 $