W3C

Evaluation and Repair Tools Working Group Teleconference

20 Feb 2013

See also: IRC log

Attendees

Present
Shadi, Carlos, Christophe
Regrets
Philip
Chair
Shadi
Scribe
Shadi

Contents


Requirements for AERT

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

Approval of WCAG-EM publication as updated Working Draft

http://www.w3.org/WAI/ER/conformance/ED-methodology-20130219

http://www.w3.org/WAI/ER/conformance/comments-20130208

http://services.w3.org/htmldiff?doc1=http%3A%2F%2Fwww.w3.org%2FWAI%2FER%2Fconformance%2FED-methodology-20130208&doc2=http%3A%2F%2Fwww.w3.org%2FWAI%2FER%2Fconformance%2FED-methodology-20130219

CS: how long will the commenting period be?

SAZ: think 3 or 4 weeks

RESOLUTION: approval to publish as updated Working Draft

Next meeting

no meeting next week

next meeting March 6th

no meeting March 13th

meeting again on March 20th

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.137 (CVS log)
$Date: 2013-02-20 17:13:09 $