See also: IRC log
mc: discussed how baseline proposal effects
techniques. ben, becky, and michael sent something today. overlaps with
techniques sorting.
... test cases. shelved discussion for a while. not sure how long.
... discussed some about plan
gv: going through "key results" msg: http://lists.w3.org/Archives/Public/w3c-wai-gl/2005JanMar/0642.html
... describes process used at the F2F to reach proposed resolutions
... found places where UAAG is useful, but not useful as baseline.
... every time considered a baseline, the useful life of wcag decreased.
... baseline and techniques - clear that if guidelines said "do x" and techs
said "do subset of x" that would be changing what is required for
conformance.
... we've set an aggressive timeline and thanks to those who are working to
help reach it.
... thank you to those who worked so hard this last week to prep for today's
meeting.
js: wcag won't set baseline doesn't mean that baselines won't be set. that takes place outside of wcag (govnt agency, policy, etc.)
gv: typically at f2f we create proposals and
bring to list/group to discuss since not everyone can attend the f2f.
... goes through agenda for today
... "round robin" means that each person says something. starting w/those not
in L.A.
... not debating, but get everything on the table
... by raising some of these issues, it may help us make a more intelligent
baseline decision
http://lists.w3.org/Archives/Public/w3c-wai-gl/2005JanMar/0706.html
js: action item from f2f. how would SC need to
be changed to describe functional outcomes if no baseline is adopted in wcag
2.0.
... Mike, Michael, Gregg, and John.
... where there is an effect, proposed wording. often the proposal is more
about addressing a functional outcome than a baseline issue.
... did not propose new wording for 3.1 since john is working on
comprehensive 3.1 proposal.
... likewise, others are working on 4.2
... becky posted friendly amendment about 1.4.
gv: the big question is, "does the impact analysis indicate that the approach is workable or unworkable?"
js: bottom line - it would be doable.
mc, mb: nothing to add
http://lists.w3.org/Archives/Public/w3c-wai-gl/2005JanMar/0703.html
http://lists.w3.org/Archives/Public/w3c-wai-gl/2005JanMar/0715.html
wc: 2 messages. 6 independent proposals made
... using terms differently primarily: "normative," "standard," and
"required" and believe we are in more agreement than may seem obvious because
we seem to be saying similar things but using different terms or using the
same terms differently.
gv: lets walk these issues and see what ppl
think about them
wc: current definition of normative in our
glossary, "required for conformance"
<DoyleB> normative - an authorative standard...Webster's
wc: However, seem to be questions about: does normative only apply to a doc through w3c or other standards body? standard is used in many ways. normative, also confusing. is RSS a standard? not published by ISO or W3C ... community-based.
<jslatin> so "normative" = "required or permitted by the recommendaiton"?
<ben> gv: need to be sure we don't treat things differntly in diff. docs
wc: I believe relationship of UAAG sufficient techniques is to uaag as our sc to our GL
wc: UAAG has normative non-technology-specific techniques
<jslatin> time check...
jason: if the techniques has to be normative they have to be put through w3c process
wc: I'm concerned about how people will claim conformance no matter what we do
gv: comment on #8 - f2f - baseline
responsibiliy is on many, customers, governments, authors etc.
... baseline responsibilities will fall on a whole bunch of people
wc: let's move on and take this to the mailing
list
... there are many assumptions we need to address and many issues to
discuss
gv: issues wendy has identified are pulled from the list, summaries not necessarily her issues, just capturing issues for us to look at, these issues are meant to inform us, a lot of issues will be overcome by events
wc: some of the disagreements we are having is from using the same terms differently
gv: as editors we found out we have some questions to ask above us, in the W3c
mc: impact analysis, not having baseline means can't write techniques to a particular baseline so we have to write techniques for each sc for lots of "if's and ors"
mc: we may have to clarify technologies whether or not to includes UA's
<wendy> http://lists.w3.org/Archives/Public/w3c-wai-gl/2005JanMar/0707.html
mc: one issue is clear we cannot have an inventory of all techniques---would have been hard otherwise now super hard given all the combinations in a baselines
impossible to inventory all User agents
mc: graceful degradation, think if CSS not in baseline, realize that you use layout info tat helps understandability,,,, difficult position, graceful degradation would be layout tables and a big problem
gv: makes me shutter to think of all combinations, is it possible to put a technique and put assumptions below that in a list,
mc: we see documenting it in metadata so we can assemble it easily but want that info in the prose of the tech doc also so average web designer can use it...
wc: would there be information, if you can make
assumptions about audience, here's what you can do....I think we need the
techniques walk through ASAP
... especially scripting, concerned how people will claim conformance.
mc: fortunately scripting doc is short....wendy ben becky & mike need to get together
bc: need to scope work by having statements about "this is what we recommend as a baseline" and have 3 or 4 of them otherwise scope is infinite
gv: scoping-what's that
bc: scoping - above no scopint
... I'm concerned we have no good information about what a baseline...I need
to know...are you targeting a 4 year old screen reader or a 2 year old...
gv: can you put together a short post...for example this is a reasonable baseline
<ben> ACTION: ben to send some "for example" recommended baselines to list for discussion
neil: I think a user coming in is going to be unsure about a reasonable baseline and won't look in the tech docs, in writing techniques we need to say.."these are the most likely combinations, "
mc: ... need good info on how to chose good baseline,
gv: if not in tech doc, perhaps we need a "how
to set a good a baseline" non-normative doc
... even if its for our own use
neil: above said ignore unlikely combinations
<wendy> ACTION: ben, becky, michael sort techniques. send something to list by tuesday 5 april
gv: we need to find out if we have found a solution or have we just shifted an unsolvable prob from GL to Tech docs we need to answer that
people on call not in LA= neil, jason, yvette, Bengt, matt. roundrobin starting with them
neil: think the general idea, good, but baseline just keeps coming back, shouldn't be normative but we need to nail down baseline down,,
jw: reasonable that tech should make assumption about UA support for some features, separate from guidelines proper, I agree we shouldn't make normative baseline probably the guide to the guidelines would be ok for baseline discussion
gv: want to capture, if in techniques, one were
to say we provide under these circumstances, likely to be true circumstances,
doesn't say anything else cannot be conformant
... we can say " If you choose this baseline...the only way we no how to do
it is ...'
ben: that's exactly what I meant...lay out reasonable baselines ...ignore unreasonable baselines
yh: we should try to make as much of guidelines do not assume baselines...describe GL in functional terms not technical terms...worthwhile to provide 3 extremes and describe pros and cons, do straw poll and see where people sit on this....
bengt: confused about baseline, still think our work has to assume a baseline of what browsers we want people to have....should be backwards compatible..
<Yvette_Hoitink> david: that's the opposite of what I understood
gv: did you mean we not get to hungup on backward compatible lets look forward
bengt; yes
mm: at first I was very unhappy about dropping
baseline, thought authors needed a grasp of that,
... cause there are all kinds of people who assume lynx and others with ie5
with this spread, there will be people pointing at the same document....and
not agree on conformance. but I've softened...
mm: we should talk about web apps. 85% of sites have heavy js all working from the same tools so if we go this way , we need at least one example of a web app environment...
js: lgr mentioned at the f2f that we seem to
use the word "baseline" in 2 senses: 1. thinking of baseline as a ceiling
(bump head on as moving up the tech ladder) 2. a floor that you can solidly
base assumptions on.
... "profiles" may be less-loaded than "baseline"
m3m: "profiles" has a defined meaning in w3c
terms. it's an applicable definition.
... a profile is essentially a subset of applicability within a
specification. e.g., "full" SVG, SVG Basic
gv: DLNA doesn't create standards, it only creates profiles of standards
<scribe> ACTION: wendy research proposals on profiles that have been mentioned before.
bc: as look at baseline, need to evaluate the
baseline assumptions. not convinced that if those are at technology-level
they are enough.
... as web content becomes more complex, the baseline assumptions needed to
evaluate a conformance claim, will be specific to UA and features of specs.
... just like every author knows what combo of mainstream their content works
on, need same level of detail for asst techs.
oops.
gv: might be tough to determine what techs ppl
have on or not.
... is it legally possible to make a detailed claim? probably not likely they
will not make any claim at all.
... realistic baselines - i conform to wcag 2.0 based on unrealistic
assumptions...sounds dangerous to leave up to authors.
... whether we set a baseline or not, having authors think about and include
in conformance claim, will make them likely to consider it.
<Michael> Conformance is in context of a baseline, which I guess means you have to state what baseline you used in a claim. Should be simple, e.g., "WCAG conformant when tech A, B, and C supported". In metadata if we have metadata conformance claims. In prose if we have prose conformance claims.
yh: if a site presumes IE...think claims should be based on technology not user agents. One assumption of accessibility is not assuming what technology your user has.
yh: think many orgs will not make conformance claim, otherwise will make them liable.
js: assuming wcag does not specify a baseline,
then conformance claim has to make statement about what techs the content
supports.
... agree info should be requested in simplest form.
... agree, about technologies not UAs.
... people can add UA info, don't prevent them.
dmd: agree, need a baseline statement in a
conformance claim. provide a template.
... don't know that we can easily say that you won't be assuming specific
UAs, if go back to IE3, make certain assumptions.
m3m: agree, don't tie to specific UAs.
... browsecap.ini enumerated all capabilities of every browser. had to be
updated every week.
asw: agree, listing the techs as part of conf
claim. agree, specify level of tech (or version?). agree, can spec UA but
don't require.
... like template idea
ns: ppl likely to use a tool, like bobby, to
claim conformance. w/a movable baseline, how will tools claim wcag
conformance?
... create checkboxes? create own baseline?
... does WCAG 1.0 have a conformance claim that ppl make?
lgr: checking tools do have implicit baseline,
perhaps be good if they made that implicit.
... agree, specify by tech, not UA. however, requirements often based on UAs
that need to support.
... useful to have info about which UAs support which techs.
... however, ack matt's comment about how often that info changes.
bg: agree, spec by tech.
... optionally, UA and AT tested with.
... consider "audience" - u.s.-only or britain-only...may have useful
implications. probably not required.
... ppl assuming UAs all the day. accept that happening today.
db: perhaps do a "feature match" -
commonalities between user agents.
... don't think bulk of orgs will publish the fact that they conform.
... wonder about ppl who post logos and how many of them conform.
jw: position sent to mailing list. should be
minimal conditions for a tech to be used in conforming content.
... min info required to enable 3rd party to verify if the claim is true.
... names, versions of techs that are required.
... that should be sufficient. optionally: enable additional info about other
assumptions.
... important to allow ppl to link to baselines instead of including them in
the conformance claim directly.
... commonly used ones, could be provided in guide or whichever doc we
choose.
mu: more difficult for developers to claim
conformance. especially in non-english-speaking countries e.g., japan, korea,
china.
... need UA support info and simple guidelines for authors to claim
conformance.
bf: agree, tech instead of UA
... confused about baseline. if set profile for different user groups. e.g.,
cognitive may have one type of profile.
... that would match the audience you are looking for.
... something about IE and non-supported tech...
wac: this feedback will be used to create summary and hopefully proposal to be sent by next tuesday.
gv: seems to be more consensus than i would
have guessed.
... talking about techs vs browsers - is there at least one implementation
for every technology. if did state UA, would need to state version, security
patches, etc.
... had lots of reports today. the summary seems to be: lots of work to do.
the conclusion about "no baseline in guidelines document itself" seems to
hold (not collapse). however, lots of exploration still needed.
... haven't found a reason not to include this direction, have lots of work
before are successfully heading in this direction.
js: what is in the pipeline for next week? 4.2 (lgr, et al), conformance claims (wac, et al), techniques (bc, mc, bg), defn of terms (editors)
yh: like the round robin approach. nice to hear
more ppl's opinions than usual.
... like to hear from everyone.
gv: we'll use the technique for big issues. in general, try to focus on ppl preparing info in advance.