W3C home > Mailing lists > Public > w3c-wai-au@w3.org > April to June 2007

Re: ERT WG comments on ATAG 2.0 Last Call Working Draft of 7 December 2006

From: Jan Richards <jan.richards@utoronto.ca>
Date: Thu, 19 Apr 2007 13:59:29 -0400
Message-ID: <4627AE01.2060808@utoronto.ca>
To: Shadi Abou-Zahra <shadi@w3.org>
CC: w3c-wai-au@w3.org

Hi Shadi,

Thanks to the ERT group for these comments. I have entered them into our 
issues table at:

http://www.w3.org/WAI/AU/2007/atag20_pubWD_7dec2006_comment_responses.html


My personal take on the comments follow in-line...

Shadi Abou-Zahra wrote:
> 
> Dear AUWG,
> 
> ERT has looked the ATAG 2.0 Last Call Working Draft of 7 December 2006 
> [1] during the teleconferences on 31 January 2007 [2], 7 February 2007 
> [3], and 18 April 2007 [4]. Please find our comments below:
> 
> #1. DEFINITION OF AUTHORING TOOLS
>  - <http://www.w3.org/TR/2006/WD-ATAG20-20061207/#intro-def-au>
>  - While the definition of an "authoring tool" is non-trivial and 
> ideally addresses all components that are part of a Web development 
> process, the currently proposed definition seems to be too broad. For 
> example, image and plain text editors are regarded as Web authoring 
> tools even when they are "used separately".

JR: We intended to cover image and plain text editors by the definition 
because these tools are often used to create Web content, either alone 
or in conjunction with other tools. However, if a developer does not 
wish to make an ATAG claim that is their choice.


> #2. INTERACTION WITH EVALUATION TOOLS
>  - There was no clear consensus or a specific suggestion from ERT WG but 
> in general a clearer definition of the interaction between authoring and 
> evaluation tools may be helpful. For example mentioning the possibility 
> of providing APIs for plugin evaluation tools where appropriate (such as 
> B.2.2 & B2.3) may be helpful.

JR: Maybe we should refer more formally to Evaluation and Repair Tools 
as a defined term. RE: APIs. Maybe we can include the provision of such 
APIs as a technique.


> #3. DEFINITION OF SEMI-AUTOMATED CHECKS
>  - <http://www.w3.org/TR/2006/WD-ATAG20-20061207/#def-Checking>
>  - In ERT WG we have been discussing the definition of semi-automated 
> checking. In the latest EARL 1.0 Last Call Working Draft [5], we took an 
> approach based on the *primary responsibility* for determining the 
> outcome of a check to differentiate between the different types of 
> testing. For example, consider the following tow scenarios:
>   o A person uses a tool to evaluate a site. The tool asks the user if 
> the color-contrast is sufficient, and uses this input directly as an 
> outcome of a test (such as WCAG 1.0 CP 2.2).
>   o A tool uses a person to evaluate a site. The tool asks the user if a 
> table is used for layout or data purposes, and uses this input for 
> carrying out other tests (such as WCAG 1.0 CP 5.1).

JR: I'm a bit confused by this. To me, the first example seems more like 
a "tool uses a person to evaluate a site" because the person is 
responsible for the entire decision. BTW: ATAG would count these both as 
semi-automated which seems to make sense given that the user experience 
of both is so similar (i.e. being as asked a yes/no question about a 
fairly constrained piece of content).

It seems to me that there are several axes of potential automation:

1. Does the tool automatically even attempt to identify content with 
potential for problems (high="look at this <img>"; low="look at any 
images in your doc")?

2. Does the tool fully identify the content (e.g. high="this layout 
table..."; low="is this a layout table?...followed by more tests")

3. Does the tool know there is a problem (e.g. high="this img needs alt 
text"; low="does this img need a longdesc?")


>  - We have received some review comments on this topic and will be 
> processing them in the coming weeks. ERT WG would like to coordinate 
> with AUWG on a common definition for manual, semi-automatic, and 
> automatic testing of Web content.

JR: I do think it is a good idea to coordinate on this.


> #4. EXPORTING AND IMPORTING REPORTS
>  - <http://www.w3.org/TR/2006/WD-ATAG20-20061207/#check-progress-feedback>
>  - Despite EARL 1.0 being in draft stage, it may be useful to provide an 
> optional provision for exporting and importing reports in a structured 
> format. This may further improve the interaction between authoring and 
> evaluation tools by promoting the integration and exchange of data.

JR: This is definitely a good technique. I've wondered for a while if we 
want to say anything about saving user decisions to avoid asking the 
same questions over and over...maybe a P3 thing.

Cheers,
Jan



> [1] <http://www.w3.org/TR/2006/WD-ATAG20-20061207/>
> [2] <http://www.w3.org/2007/01/31-er-minutes#item03>
> [3] <http://www.w3.org/2007/02/07-er-minutes#item02>
> [4] <http://www.w3.org/2007/04/18-er-minutes#item03>
> [5] <http://www.w3.org/TR/2007/WD-EARL10-Schema-20070323/#testmode>
> 
> Regards,
>   Shadi Abou-Zahra for ERT WG
> 
> 
Received on Thursday, 19 April 2007 17:59:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 22 September 2008 15:53:06 GMT