See also: IRC log
<wendy> http://lists.w3.org/Archives/Public/w3c-wai-gl/2005JanMar/0391.html
ben: talks about cheklists model page 1, 2 ,3. page one, two interogation phase, tie into aplicability, to filter out unnecesary tech. page 3 provides summary of what you chose, and beow that there are checklst items. top left would have a status icon. status depends on the items checked off below. each checklist item is true false with a reference to the test procedusre or the techniaue, both of which are linked
AL: you mean I have to ALL the tests in order to conform
BC: yup but there may be alternative ways
AG: you can scope it for each web section
TB: who is it designed for
BC: either designer or reviewer, could be several people
ag: likely an evaluator would have tools to help them
js: my understanding is that conformance can only be made at the level of the delivery unit
aa conformance clame for the site says every delivery unit conforms
ag: not the best way to look at it because here may be some overall priciples that would fail the site even though delivery units are ok. should be a series of questions "are you dealing swith whole site", or "this section only etc...."
shadi: builing a manual evaluation tool, I think it ias a bit too manual could become too big to go through one by one on, can we allow evaluation moduals to fill out part of this check list
i don't see that built in, it is user based evaluation rather than automation
ag: this is just a mock up, it could be put into a tool if we get the design riight
bc: it published in TR version must be kitchen sink
js: checklist items for general techniques, generalitems human testible, the technolgy specific could be automated
al: Itcould be difficult to comply
bc: is there goig to be an equivalent facilitation, ie, i have a better technique don't want to use yours, should be ok
al: if people meet the big picture, then it's ok,
js: techniques docs non normative so they canbe updated
ag: 2 issues, 1) how to handle feedback from users about new techniues 2) applying these techs, they are testable techniques must be prescriptive, and udated as things change.
js: big issue because of time commitments etc..
ag: without it techs will be out of date
cr: equivalent not a good idea, they should not be allowed to comply
dm: undermines our hard work descerning the technicques
js: I want this to be the bar, now your talented developers can come up with stuff we didn't think about
shadi: trying to understand the target audience? i've been looking into describing wcag 2.0 techniques in rdf. taking them as machine readable, tools can do them or pass thm o to the enduser fo fill in the blanks. wcag role to publish model that tools adhere to and follow
cr: i share jon's concern aabout flexibility, want to make sure best techniques in doc...but allowing user to do it themselve allows peole who don't conform to claim conform. must be able to update techniques to accomodat at least 1x per year, the other way opens flood gates
wc: i'm concerned about the stuff we've added only deals in HTML, i think we need to give innovation
bc: agree with wendy, besides anyone who does it is volunariy anyway
we can't be web police
<Zakim> Michael, you wanted to say you can conform to wcag w/o following techs
mc: agree, with ben and wendy, but yes we should update frequently
tb: agree, I' hope there will be updated
ag: agree with tim, but I've seen 2 countries, if they do not see us updating they go and update their own guidlines. hope wcag 2.0 will call things back together
wc: i hope that we will be able to put ourselves out of a job. if we provide enough info, ppl should know enough to create innovative, accessible applications
js: jason and I took action to update "how to read this doc" i we say "if you still can't figure out, and take most generous interpretation of sc, and guidine and principle,....how in a principled way to procedd in abscence of understanding to sc perfectly..our job is to produce materials that tell people what the end result, we are not in the evaluations business, we give them information they they can use to make those tools
mc: support john, i see our value as good advice, and bottom up part of developing guidelines. I would like to see other orgs taking on the work based on what we are doing. non-public technologies can conform to wcag but we can't create techniques
ag: we need industrial strength feedback mech but perhaps a local level, and these tech could be forwarded to wai.
ag: we must write very prescriptive things , nice to do there own thing but I think it needs approval
wc: what do you guys need on checklists?
bc: need discussion on equiv facilitation but if we are ok with basic structure, them we need to flesh it out
ag: i think valuable to look at aplicabity conditions
wc: issues we spoke about good for requirements doc...scope, goals, how we expect t to live on... great discusion...as far as checklists, need to keep talking about tests, and appp conditions
<wendy> ACTION: someone add to requirements from today's discussion and perhaps summarize in intro to wcag (our general philosphy about how this to live in the future, our approach, and philosophy)
ag: we heard about equiv facilitation, itsa big point can we get more clarification and why it is required
bc: we are divided on issue, so we could take it to big group
<wendy> ACTION: John send previous writing about wcag 2.0 approach to mailing list as initial proposal/discussion starter for an intro to wcag about philosphy/approach.
js: i want to caution against using the term equivalent facilitation. it has very specific meaning within u.s. law. equivalent facilitation means that someone could provide another method (non-web) and declare they have made their web application accessible. we mean "alternative method" or something like that. avoid using the term to avoid creating confusion.
<Becky_Gibson> mc: prev review of gen techs and test files we identified some changes needed
<Becky_Gibson> mc: reorganized the documents some
<Becky_Gibson> mc: now intro section for gen. req. and section for techs and section for checklists - tests are under checklists
<Becky_Gibson> mc: is this new organization ok to proceed with?
<Becky_Gibson> mc: req. doc isn't clear about what happens where (now that we have added more and more pieces)
<Becky_Gibson> mc: will continue to work on this
<Becky_Gibson> wc: thinks structure will work - looks good
<Becky_Gibson> wc: meeting tomorrow for more info about getting thru reccommendation track
<Becky_Gibson> wc: these goals should be in our req. docs
<Becky_Gibson> cr: 4 more tests to list all having to do with title. some comments but not much disagreement
<Becky_Gibson> cr: doc must have a title, title must not be empty
<Becky_Gibson> cr: some discussion about what 'empty' means
<Becky_Gibson> cr: propose the name from "title is not empty" to "title contains text"
<Becky_Gibson> cr: and indicate the text does contain just whitespace
<Becky_Gibson> cr: title describes document
<Becky_Gibson> cr: some discussion abt this but WCAG says describe
<Becky_Gibson> cr: are these 4 tests ok or do we need to do more?
<Becky_Gibson> wc: sc actually says "has descriptive title" which is different than title describes
<Becky_Gibson> cr: mc comment about title outside of head won't validate
<Becky_Gibson> js: people talk about level one heading describing the page - that is outside of the head but title can't be
<Becky_Gibson> mc: when things are bad html do they still work as they are supposed to or do they break - sometimes they work even when
<Becky_Gibson> wrong - is an accessibility issue
<Becky_Gibson> cr: are first 3 tests ok?
<Becky_Gibson> cr: title describes the document - is that ok? should it be summarize, etc
<Becky_Gibson> js: how about "title is descriptive" so it matches SC
<Becky_Gibson> js: that sounds like a general tech. - automated tool can't pick that up
<Becky_Gibson> bc: test 54 sounds like it is part of general tech suite
<Becky_Gibson> wc: 2 categories of test: manual and automated
<Becky_Gibson> dm: title can be tech specific (is there a technology that doesn't have a title?)
<Becky_Gibson> js: are there technologies that don't support a title?
<Becky_Gibson> bc: there are enuf techs that have title that is ok to make a general tech.
<Becky_Gibson> js: david is right, have to make sure to consider technology support before moving to general techs.
<Becky_Gibson> cr; where are we with 54 - title describes doc?
<Becky_Gibson> wc: put it in a holding pattern - it will likely move to general tests.
<Becky_Gibson> wc: have to decide if will have tech. specific test or general test
<Becky_Gibson> js: propse changing title to "title is descriptive of the document"
<Becky_Gibson> cr: will leave the test in for now with the change in test title
<Becky_Gibson> debate about identifies or labels wording
<Becky_Gibson> cr: general agreement on the test and we can tweak the language later
<Becky_Gibson> cr: if change the title can we take it to straw poll?
<Becky_Gibson> wc: depends upon ben, john and wendy conversations about general tests
<Becky_Gibson> js: prefer not to go to straw poll yet
<Becky_Gibson> bc: leave it as pending
<Becky_Gibson> cr: will change the name of 54 and change to pending
<Becky_Gibson> js: other 3 will got to straw poll (50,51,53)
<Becky_Gibson> wc: are we going to a two state poll? accept/reject and comment
<Becky_Gibson> cr: other 5 states were confusing so prefer accept/reject and comment
<Becky_Gibson> ag: is there a decision that general techs are only manually tested
<Becky_Gibson> wc: no decisions - just some discussion in small group (Ben, Wendy, John) and are working on a proposal
<Becky_Gibson> mc: decision about manual or automatic testing is not in WCAG scope
<Becky_Gibson> wc: no proposal yet - just giving the group a heads up that proposal is coming
<Becky_Gibson> bc: would prefer required vs. optional since all are valid tests
<Becky_Gibson> wc: but that is at technique level
<Becky_Gibson> cr: if not required by guidelines than test shouldn't be in there
<Becky_Gibson> bc: but there may be tests that are not required but are helpful (good idea to look at this)
<Becky_Gibson> cr: those wouldn't be in the test suite
<Becky_Gibson> wc: if a technique is optional, it doesn't have any tests associated with it?
<Becky_Gibson> wc: do people agree?
<Becky_Gibson> cr: perhaps we can collect them but they are not required for conformance so aren't part of WCAG test suite
<Becky_Gibson> js: if there is an optional tech. it provides one possible way of meeting S
<Becky_Gibson> JS SC and it can be used to support conformance clain
<Becky_Gibson> bc: opt. tech. might be good advice - might work for one group or not another
<Becky_Gibson> js: so if use only optional techs then can't satisfy SC?
<Becky_Gibson> bc: yes
<Becky_Gibson> wc: can straw poll can we just say accept/reject and comments can be accept only as optional
<Becky_Gibson> wc: does that give us the info that we need?
<Becky_Gibson> bc: but if no such thing as optional than that should't come up
<Becky_Gibson> mc: but there are some that we want to reject outright
<Becky_Gibson> js: proposed req. optional, reject
<Becky_Gibson> wc: accept as required; accept as optional; reject - ?
<Becky_Gibson> js: designatate as optional means it can't be used for conformance
<Becky_Gibson> wc: will make poll with accept as required, accept as optional, reject, comment
<Becky_Gibson> js: modify to good advice but not required for conformance
<Becky_Gibson> js: optional but can't be used to claim conformance
<Becky_Gibson> wc: still somewhat unsure about what we mean by required and optioanl
<Becky_Gibson> cr: is there a publishing deadline at the end of the week?
<Becky_Gibson> wc: yes
<Becky_Gibson> bc: not sure we have enough to publish internal draft at end of week
<Becky_Gibson> wc: need to publish something - if we keep pushing deadlines back we develop a habit
<Becky_Gibson> bc: not really anything of substance to add to GL so why waste time with it
<Becky_Gibson> cr: wants to publish test suite
<Becky_Gibson> js: several changes to general techs so want to publish
<Becky_Gibson> wc: one change in css
<Becky_Gibson> wc: we haven't published anything since Nov. 19 and we don't have many changes so should be a wake up
<Becky_Gibson> wc: call to the group that we need to get going!
<Becky_Gibson> cr: can we get the straw poll done so can vote by end of week and get more tests in the suite
<Becky_Gibson> wc: yes
bg: said that any input elements must have
tabindex. uaag requires sequential navigation. putting tabindex has some
implications.
... it puts it in the beginning of the tab order
bg: the technique has several editorial notes that say need to describe default navigation is generally ok. feeling that they should be rejected. or if stay, make optional. tabindex can make confusing if not careful how to do it.
mc, js, bc agree should not be required
bc: perhaps a condition where could be required, but need to describe
js: level 3 criterion that could map to
bg: the test currently maps to level 2. if make it optional, update it to map to 2.4 #2 level 3
resolution: reject tests #138, #139, #140, #141, #142 (or make them optional). saying right now - not required
bc: they are never musts
js: need a test for if tabindex provided, how to do it properly
<scribe> ACTION: chris and michael (and maybe john in general) clarify techniques/tests for using tabindex properly (if provided, do so ala....)
mc: meeting 2/28 and 3/1 for techs faces 2 face. sending delegates to some of the other meetngs during the plenary
<Michael> o I18N (Michael, John)
<Michael> o DIWG
<Michael> o ERT WG
<Michael> o Timed text (Michael, Wendy)
<Michael> o QA (Tim, Jenae)
<Michael> o UA (Ben)
<Michael> o PFWG, EO (John)
mc: device independence - we don't have a rep. yet
wc: will probabably attend DI - have done so before
mc: talk about requirements; techs; test files on Monday & Tuesday at F2F
mc: try to get drafts in good shape
... have a public WD after WCAG F2F in LA a few weeks later
... need techs docs in good shape
... look at end to end analysis; over all look and feel
... come up with a plan to get to recommendation - Wendy is really only one
that understands that at this time
wc: good to invite Steve, Tim or Ian (director,
COO, head of comm)
... so can hear about W3c process directly
mc: action items most people on this call do
have a list of tests to reviews
... please comment on your assigned tests to the list in the next few days
<Michael> Action items at: http://trace.wisc.edu/bugzilla_wcag/condensedreports/actionitems.php
mc: many people have action items posted to bugzilla
<Michael> http://trace.wisc.edu/bugzilla_wcag/condensedreports/actionitems.php
mc: please review
... and make an effort to knock off - volunteer to take other items if you
see ones you can handle
ag: have been reading techs and GL - have non-text content defined in GL but in other docs refer to more specific terms
js: general techniques?
ag: specifically HTML techniques - these reference images directly but might it be better to refer to "non-text content" as in the rest of the docs
mc: too big to handle at end of call - can we take this up offline and add to agenda at later meeting
ag: hard to address to the list - hard issue to describe
mc: either post to list or start by addressing with Michael directly
wc: got through all items on agenda except alt tests - yeah! good progess today