See also: IRC log
CV: would like to focus on the code developers
SAZ: do we have the resources to do that?
CV: give an overall introduction
... not do implementation plan for each requirement
... introduce what the major problems are
SAZ: what exactly would be a "major problem"?
CV: issues on interpreting techniques and
failures
... developers often don't understand that
... so many ways to implement checks
... problems when you are developing an authoring tool
... explain what support is needed
... for example rendering the DOM
CS: seems developers may the primary audience
... not sure how we can address "managers"
CV: prefer developers or end-users
... difficult to define what the "managers" are
SAZ: end-users are not our primary target
audience for this
... have EO resource "selecting web accessibility evaluation tools"
... will also be updated along with this
... but here our focus is not end-users
CS: think also procurers would fit into a separate document
SAZ: explaining techniques and failures should
also not be the main focus of our document
... think it is on WCAG WG radar already
... maybe summarize from eval tool developer perspective
... and reference existing WCAG resources
CV: it is one of the most important issues that eval tool developers have
CS: not all Success Criteria have common failures
... sometimes deemed not necessary when it is just the inverse of the Success
Criteria
... but maybe out of date with the evaluation methodology
SAZ: evaluation methodology does not go into that
level of detail
... not sure if we have the bandwidth to develop failure techniques
... need something less broad but still significant progress in the field
CS: would need to convince WCAG WG on the need for failure techniques anyway
SAZ: last week we talked about a "framework" with
a list of features that tools could have
... broad selection of possibilities
... developers could explore how their tools could support these features
CV: that alone may be not too attractive
... missing failure techniques is a big issue for tool developers
... also explaining the overall evaluation process and where testing fits in
... need to consider white-box, black-box, and other sorts of testing
SAZ: think dialog now with WCAG WG on updating
guidance on techniques and failures
... need to bring in our perspectives into this discussion
... but not take up the development of failures ourselves
CV: not shortcoming of WCAG but need explanation from eval tool developer perspective
CS: would that list of features be for developers or for procurers?
SAZ: think it has dual role but we probably want
to primarily focus on developers
... but this same list of features could be reused in the "selecting web
accessibility evaluation tools" and "web accessibility evaluation tools list"
resources of EOWG
... to address other audiences such as end-users, procurers, etc
... how about if this list of features was embedded into overall description
of the evaluation process, the different types of testing and when they
typcially take place in the evaluation process, and "profiles" of types of web
accessibility evaluation tools?
CV: could try that approach
CS: would the description of the evaluation process be part of the document?
SAZ: yes, but from a tool developer perspective
[methodology Step 1.d and 4.c]
SAZ: need to keep overall background concise
... focus needs to be on the features and profiles
... gives targets for eval tool developers to strive towards
CV: will send update by this Friday
http://www.w3.org/WAI/ER/conformance/ED-methodology-20130219
http://www.w3.org/WAI/ER/conformance/comments-20130208
CS: how long will the commenting period be?
SAZ: think 3 or 4 weeks
RESOLUTION: approval to publish as updated Working Draft
no meeting next week
next meeting March 6th
no meeting March 13th
meeting again on March 20th