Evaluation and Repair Tools Working Group Teleconference

ERT WG Charter updating

<shadi> http://www.w3.org/WAI/ER/charter4

SAZ: Current charter runs out 30 June 2013. We're preparing a new charter for July 2013 - July 2016.
... We can now review our past activities and think about what we should do next.
... WG was initially created as a parallel to WCAG - idea that much of the evaluation could be automated, so drafted a techniques document. Many of these techniques were taken up by WCAG.
... Two important tasks: Testing support across the WAI domain and finalising EARL.

<shadi> http://www.w3.org/WAI/accessibility-support/

SAZ: This WG will probably be responsible for work deveveloped in WAI-ACT & accessibility-support database. Will be discussed again in next meeting.
... Tool support and evaluation & repair: what is the current landscape and what can we do in this area? What is already being taken care of?
... Look at success criteria and deliverables. Currently mainly focused on EARL.
... Next step would be creation of draft charter for the WG to review.
... Should finalise EARL but it should be in a less prominent role. Also the test suite. The test suite should not be that hard to generate once tools support EARL.

SM: Agree that EARL is quite advanced; a few steps that are missing. Other documents that were initially part of EARL but that were separated: HTTP in RDF and Pointers: continue development?
... (...) Used XPointer in the past, but XPointer did not advance as expected. Plans?

CV: Think these are almost done. There were not many changes coming from the comment phase.

SAZ: "EARL" refers to the entire package, not just EARL Schema. However, only EARL Schema is on REC track.
... So "completion" refers to completing the entire package.
... Need to clean up things, cross-referencing. Test suites for EARL Schema, because that is on REC track.
... Also talked about putting some of the other docs on the REC track but we were hesitant because of the pace of implementation of EARL Schema.

SM: Pointers in RDF: concern that it becomes dated. See my e-mail from a few months ago.
... See specification for another pointer system by another WG and something from Adobe for PDF.

<shadi> http://lists.w3.org/Archives/Public/public-wai-ert/2013Jan/0003.html

SM: If we close it soon, it would miss some new things from the last 4 years.

SAZ: Good point. One of the missing steps is a "stabilisation draft". We would not be able to finalise the current draft without a "stabilisation draft" since our last call is several years back.
... When we publish the next "last call" the test suites should be in good progress, so we can progress directly from last call to "candidate recommendation".
... Our "techniques" document (ERT): we talked about different aspects of tool-supported evaluation & repair and about reducing the scope.
... What we write in the charter should be realistic. We might be able to attract new participants. Alternatively, we could decide to go into a mode that focuses on closing all the current work.
... Next charter should describe the WG's value proposition.
... Can people review the current charter and send comments? Before the end of the week?

Requirements for "Techniques for Automated and Semi-Automated Evaluation Tools"

<shadi> http://www.w3.org/WAI/ER/WD-AERT/ED-requirements20130402.html

<shadi> http://services.w3.org/htmldiff?doc1=http%3A%2F%2Fwww.w3.org%2FWAI%2FER%2FWD-AERT%2FED-requirements20130320&doc2=http%3A%2F%2Fwww.w3.org%2FWAI%2FER%2FWD-AERT%2FED-requirements20130402

SM: Worked on a use case. Hope to have it finished by next Monday.

SAZ: Hope to have new draft from CV by next Monday.

CV: Went through notes from last meeting and separated objectives.
... Would like some feedback. Moved "issues not covered" to the end.
... Separation of purpose and objectives: would like feedback on that.

SM: Agree with purpose; summarises what we discussed before.

CS: Purpose is good; no comments.

SAZ: Curious about strong focus on introductory info and the order in the second paragraph.
... Should not delve to deeply in background. Most important part would be description of different features of evaluation tools.

CV: Based this on previous discussions. (...) Remove "best practice examples"?

SAZ: Would propose to make "descriptions of typical features of evaluation tools" the main point. Depends a bit on what is meant by "introductory info".

CV: Would avoid the term "framework".

SM: Think the document should focus on the features of E&R tools.
... Should describe what tools can be like without proscribing certain specific technical details.
... Also describe best practices and how some workflows can make use of certain features.

SAZ: "Informative guidance" rather than "introductory info", since that is what we are providing?
... I would avoid the term "introductory".
... E.g. " ... to provide descriptions of [typical?] features of evaluation tools". "This may include some background info for implementing WCAG 2 "

CS: First objective: "ways to classify accessibility evaluation tools according to their profile": how would that help tool developers?
... Seems to be different types of info: one that helps developers create tools, another type helps classify them.

<shadi> [[The purpose of the document "Techniques for Automated and Semi-Automated Evaluation Tools" is to present descriptions of typical features of web accessibility evaluation tools. This may include some background information on how to implement WCAG 2.0 in evaluation tools.]]

CS: Would say that objectives 4, 5, 6,7 are of a different category (more dev-oriented) than 1, 2 and 3 (possibly also for users).

SAZ: See objectives.

SM: Tool developer would want to know what developing a tool means, what (...)

<shadi> [[List typical features of web accessibility evaluation tools]]

SM: Then the profiles make sense: list of features that all together constitute a specific class of evaluation tool.

<shadi> [[Inform tool developers about typical features of web accessibility evaluation tools]]

SM: The developer would be able to see what a complete tool requires. (...)

<shadi> [[Describe profiles of different types of evaluation tools based on the feautres they provide.]]

SM: I.e. what is required for a specific "profile";

SAZ: SM comments - point of view what a developer gets from the document.

<shadi> [[To inform developers about the differen t

<shadi> [[To inform tool developers about the different types of features that they could implement in their tools]]

SAZ: Thinking about what a developer gets out of the document is a good perspective.