Techniques Task Force weekly telecon -- 30 Mar 2005

<David> me/ david is front

<David> me, test

<wendy> scribe: Becky

Work plan

mc: please get in habit of dialing in and being ready to go at top of hour

wc: wendy will chair since Michael has little voice
... discuss work plan
... want to go to last call by June; need to consider what we need to do as tech. task force before June
... goal is to have sched. of every wed. until June and agenda, milestones, work items
... need to divy up open bugzilla entries to tackle each week

ja: what is status of techniques docs before last call

wc: need html, css, general and Javascript and ideally would like to have another technology as well
... html and css about 100 open items each
... JavaScript has been waiting for the baseline and script alternatives issue to be resolved
... have been discussing with svg group
... voice xml Katie and ? have created document
... lisa has created rdf techs draft; macromedia is working on techs for flash; Loretta is thinking about pdf

js: can we tie looking at techs with GL and issues summary to help things go in parallel
... for ex: looking at GL 2.1 on Thurs call it might help to look at techs related to 2.1 the same or next week

wc: techs bugzilla entries aren't tied to particular guidelines - makes it hard to query for techs issues realted to a particular GL

bc: many issues are global and apply to mulitple techs; might be able to update entry form

wc: could use keywords to tie tech issue with GL

js: would help with end to end stuff; but might take more time to set up than it would save
... consider it if it isn't too much work to map the issues

wc: would help to see where we are missing techs and to help close issues we have; sounds like good approach and should consider

js: anyone think it is a bad idea?

bc: will help us keep focused and not jump around from week 2 week

wc: will help with end to end

js: perhaps Wendy and Ben take an action item to see how hard it would be to categorize techs by GL

wc: still have to figure out how to divy up work
... do similar to GL end to end where someone looks at issues and makes proposals to solve
... how can we do apply that method to techs

js: sometimes issue review can be daunting when there are many open issues - having two people, 1 for GL and 1 for techs might help divy up work

wc: seems analogous to extreme programming - pairs programmers to share ideas and work

js: extreme issue closing!

wc: Wendy will look at this - are there other volunteers to help?

bc: each tech has to be looked at for sorting - can label at the same time?

ja: what techs have to be done for last call?

wc: some techs might not be completed ever becuz of changes in tech
... but will change over time
... want techs as complete as possible before we go to rec. minimum is HTML, CSS, and Scripting
... Dean Jackson is willing to work with us but we need to make time to work with him

ja: what about test suite?

wc: yes needed for last call; also need CSS and scripting tests;
... feel that at a minimum need html tests and css tests; scripting really depends upon baseline
... techniques could be enough;

mc: if we go with baseline (in current form) have to modify JS
... need to remind people that we need folks to volunteer and take on tasks in order to reach these goals

Discuss baseline proposal and implications for techniques

wc: aiming for an hour call today - likely will be 1.5 hours

mc: should discuss call length at end of call

wc: discuss baseline proposal and affect on techs
... started that with discussion of JS techs

mc: want to checkin and see if people have concerns about how baseline decision affect techs
... need to get out a post about baseline and techs
... there are techs for making tech X accessible and techs for what to do if tech X is not supported and techs for what to do when a Ua screws up
... right now we provide all of them but don't necessarily give details about what they are for beyond GL
... so nned to map techs to a given baseline that author selects; perhaps in metadata
... does group have other issues or reactions?

js: when providing techs for different scenarios Michael outlined are some types more laborious than others?

wc: hoping we can talk about things in terms of audience and what tools they have
... concern when we talk about UA support

js: is there a way to do this that doesn't req. exhaustive info about UA support?
... what other issues do people have?

<wendy> bg: when a technology is not supported, providing the alternative is harder to write (those techniques).

<wendy> bg: is there a way we can specify technologies vs user agents?

<wendy> bg: to say ecmascript 1.3 vs firefox 1.0

dm: in HTML techs are we going to add all these if ands & ors? if this is supported do that if y do this

mc: assume it is in metadata

dm: how to look at metadata - rdf?
... I'm Joe WebMaster I want to know if I can put a JS menu into my page. Is there a place I can look to figure out what to assume about my audience or policy?

mc: WCAG provides advice about selecting baseline; onced that's done there are ready made views of the common baselines we need to provide

dm: so we are into the world of views

bc: that info should be clear by reading techs; i18n uses lang. like consider doing x to acheive Y and listing pros and cons
... see a fair amt of x-referencing; author reads all techs on technology they are interested in

dm: one document or many - have we decided?
... each tech in separate file or all together

wc: on agenda for discussion in future
... have issues when hear "view" - seems over complicated

mc and wc: agree with

Ben's suggestion

dm: going thru techs for accessible JS menu and then at end there is a link to a tech on how to degrade gracefully
... new tech, new document or what?

bc: in discussion for that tech you might include UA info about support of JS - and might provide link to tech for providing alternatives
... author may or may not use the alternate tech

dm: but would that be going somewhere else - to another document or is all the info inline?

bc: I don't think the organization matters as long as all cross linked

dm: thinking about a person that wants to print out the techs document - one print button to get whole thing - do we want to support that?

wc: who as action item to do structural layout?

js: I have action item for structure of guide doc - but I hope that is all

bc: I'm willing to work on it

js: good idea to do comparable example exercise for techniques

wc: good idea but who can do it and by when?

js: do we have to answer now?

mc: having some navigation and knowing it will work is imp

bc: need agreement on types of techs - sufficient tech and optional tech;

js: so taxonomy matters more than navigation

bc: most tech are written in such a way that doesn't work with baseline discussion- often say must do this

mc: do we have to go thru each tech and say how it might need to be rewritten

bc: yes, can talk in generalities about how tasks or titles might be rewritten but will eventually need to get to specifics

mc: Ben, Becky and Michael have action item to do that

wc: is there a way to pick 10 HTML techs and get some sense of what the issues are before the Thursday call?
... Ben may have already done some of this?

js: structure discussion happens on April 14 and want some prototype stuff for some of the GL 1.1,1.3,2.4 and 4.2 (scribe thinks)
... can we look at the techs related to those GL

dm: techs docs is where all these ifs and ors will come in
... related to baseline decision

mc: could do all script ones and some from HTML and CSS

js: what has to happen with techs sorting stuff that was done in Boston - is that enough so don't have to go back to Html and focus on css and scripting

wc: tomorrow meeting is not about structure; focusing on baseline and effect on techs

bc: phrasing to me seems to fall into structure; until have done soring we can't really determine phrasing and organization

js: do similar sorting exercise on CSS and scripting

bc: sorting ques relate to SC
... need to pick a few SC and look at techs from different technologies

js: look at some ones as for guide doc: 1.1, 1.3, 2.4, 3.1 and 4.2

wc: techs sorting has been covered in this discussion

bc: that seems to be the next big work item - we should figure out how to assign to members in group to get raw data

wc: Wendy and Ben work on a plan for that so can assign that out next week
... can spend time now or take offline

<wendy> ACTION: wendy and ben figure methodology and plan for techniques sorting assignments [recorded in http://www.w3.org/2005/03/30-wai-wcag-minutes.html#action01]

Success criteria as checklists

wc: discussion of how people feel this affects techniques

mc: just want to have a checkin on this from techs task force

wc: are there comments or concerns about directon of SC as checklists?

js: in order to get to recommendation favors the simple checklist - don't think we need annotated one for recommendation

Plan to deal with test cases marked as pending

wc: plan to deal with test cases marked as pending

cr: we have a bunch of tests that are pending; we have 2 steps - 1 we are finished with test, it is good for accessibility and 2 how it fits into WCAG

js: process reminder - techs task force makes proposals to WG and WG has final say on what is accepted and not
... for recommendation track we need to focus on what should be in WCAG and propose those items to full WG

cr: what are we going to be polling for? accepted, rejected and optional or do we need more categories?
... is OK if we just stay with those 3?

wc: what other categories could there be?

bc: changes in structure related to baseline change where test cases fit in
... for ex: easy to accept test for optional tech but not necessarily for a sufficient tech.

js: why is one harder than other? is just a test of does the technique accomplish its goal or not?
... tech describe how to code things that are sufficient to satisfy a SC
... just need to figure out if test really tests the given technique or not

cr: see tests and techs as being equiv. if techs are req or not req then that is the same for the test
... see the tests as beyond WCAG; if test is good for accessibility but not covered in WCAG it is still useful

js: but that is outside of our scope given the amount of work we have; keep these tests but doesn't make
... sense to have tests techs that we don't have

cr: how can we figure out now what techs will be included for sure

wc: back to John's suggestion of having techs calls follow the WG call discussion of GL; test discussion should follow GL discussion as well
... in order to reach last call when tough GL at WG call we need to be closing it; this will help techs close on the issue as well

ja: but way more techs than there are GL so will take us longer - need to take into consideration

wc: agreed - need to look at using more polls; and getting people to take assignments and making recommendations;
... like we did when reviewing tests - can we expand to techs; do more work offline so can get to more yes and no decisions at meetings

cr: keep polling as before? break test into batches?

wc: not exactly; instead of just looking at tests perhaps look at techniques and related tests
... and follow the WG GL discussions

ja: is there a way to assign techs and test review based on GL?

wc: 9 of us and 13 guidelines; but have concerns

js: think it should at least be a two person group; one can take respon. for techs and someone else takes tests

wc: Jenae is suggesting breaking up techs by GL

js: but like earlier idea of assigning at least two people per GL

wc: need a detailed plan to get from a to b so we can stop talking about process -that is the goal
... at one hour - would like to give remaining time to Ben, Becky, Michael and other to discuss techs before Thurs call

<wendy> actions?

cr: would like to move ahead but not quite sure how to do it?

wc: wendy will propose a plan

js: don't move forward right now with previous test review plans - but hold off until Wendy proposes new plan

wc: need to get new plan in motion by next week

<wendy> ACTION: michael drink lots of throat coat tea to get well soon! [recorded in http://www.w3.org/2005/03/30-wai-wcag-minutes.html#action02]

- DRAFT -

Techniques Task Force weekly telecon

30 Mar 2005

Attendees

Contents

Work plan

Discuss baseline proposal and implications for techniques

Success criteria as checklists

Plan to deal with test cases marked as pending

Summary of Action Items

Scribe.perl diagnostic output