Evaluation and Repair Tools Working Group Teleconference

Editorial Approach

[[A cookie is a name-value pair that it is stored in the browser of the user [HTTPCOOKIES]. Cookies contain information relevant to the website that is being rendered and often include authentication and session information. This information is relevant to other use cases, like the crawling tool described later.]]

[[Similarly to content negotiation, evaluation tools can control the HTTP headers to exchange cookies with the web server to imitate particular situations. Evaluation tools can allow the tool users to set the behavior, in particular in combination with test automation functionality. For example, tool users can set the evaluation tools to accept or reject cookies on particular web pages, or to send cookies with specific parameters on other web pages, to evoke web appl

ications to generate particular content.]]

SAZ: describing the function of an evaluation tool rather than describing what a cookie is

CV: some people don't know what cookies are

SAZ: could add the reference
... the first approach explains cookies but does not explain the tool function at all
... this is what we need to change
... to describe the actual functionality rather than the technology

concept of "Evaluation Tool"

http://www.w3.org/WAI/ER/WD-AERT/ED-AERT#tools

SAZ: think the features could be more applicable than to "web accessibility evaluation tools" only
... so needed broader term, and calling them "evaluation tools" now

CV: seems OK but would start the list with web accessibility evaluation tools

Abstract

http://www.w3.org/WAI/ER/WD-AERT/ED-AERT#abstract

SAZ: important to review this section
... it sets the tone and the framing for the document
... also a brief synposis of what's to come
... we need to agree on what is in it, even though it may change over time

CV: like it at first but will look at it more closeky

SAZ: also introduction and the (example) use cases there
... often use cases work better than trying to enumerate audiences
... did not draw out a separate section for the use cases to keep the document simple

Grouping of Features

http://www.w3.org/WAI/ER/WD-AERT/ED-AERT#toc

CV: mostly like it except 2.1 and 2.2

<samuelm> Question: as far as I understand, the organization of the document has been revamped, sections from 2.2 to 2.5 are deemed to be extracted from the following sections, kept from the previous version, right?

Response: yes - this document version proposes a new grouping/organization of the features

CV: don't like traversing

SAZ: is it the wording? would the grouping work if the heading title was different?

CV: don't like the limitation of 2.1.6

<samuelm> agree that traversing probably doesn't reflect well the goal, maybe content retrieval / acquisition / etc. (traversing for me seems applicable to crawling specially)

SAZ: but the grouping overall works?

CV: more or less, not like 2.1.7

<samuelm> regarding grouping: I don't agree with 2.2.1, 2.2.2, and 2.2.3 into testing functionality

<samuelm> ... or maybe I did not understand well those points

<samuelm> the point is they do not seem deal with what you are testing against, but what is your test subject

2.2.1 is intended to describe tool capability in testing different formats, 2.2.2 in testing content in different langauges, and 2.2.3 in testing content snippets

scribe: seems that this is not clear to CV either

<samuelm> I understand specific test cases may be needed for different formats (clearly), different languages (e.g. readability) and content snippets (e.g. do not try to validate as xml document), but do not think they fit that way

<samuelm> plus, I think content-snippets should be first and overall a way to retrieve contents