W3C home > Mailing lists > Public > public-wai-ert-tsdtf@w3.org > April 2007

Re: [TSD TF] Minutes for Teleconference on 10 April, 2007

From: Christophe Strobbe <christophe.strobbe@esat.kuleuven.be>
Date: Tue, 17 Apr 2007 14:27:46 +0200
Message-Id: <>
To: public-wai-ert-tsdtf@w3.org


At 09:47 13/04/2007, Shadi Abou-Zahra wrote:

>Christophe Strobbe wrote:
>>Carlos Iglesias said we needed a mechanism to vote on or approve 
>>"issues" for the WCAG WG. My understanding is that this would be 
>>covered by Shadi's proposal [1] for the addition of an "issue" 
>>status as an additional outcome of step 5 (Task force decision). 
>>There were no objections to this proposal, and the discussion led 
>>to the question when an issue is actually written up (i.e. using 
>>the Issues Template [2])? I can think of two approaches:
>>1. write the issue after step 5, based on the comments in the 
>>Content Review page where the issue was raised and on the 
>>discussion of the straw poll results in step 4;
>>2. write the issue during the Content Review, add it to the straw 
>>poll in step 4 and discuss changes etc during the telecon.
>The proposal is that during a Content Review step, a reviewer will 
>note the issue. It is ideally identified at this stage already. In 
>the next step the opinion of the other TF participants on this 
>review is gathered using the online strawpoll. In most cases, this 
>is where the voting will take place. However, in other cases the 
>other TF participants may have comments or even objections to the 
>review. These different opinions are discussed on a teleconference 
>in step 5, and one of the following will come out:
>#1. content review (in this case an issue) is accepted as-is
>#2. minor modifications needs to be made to the review (issue)
>#3. the review is rejected and the process must be repeated

OK, but we should also clarify if the issue (currently with the Wiki 
template) is created before the strawpoll (as input) or after the 
teleconference in step 5 (as output).

>>So far, we have assumed that issues only result from reviews of 
>>test samples. It was pointed out that issues may also be found 
>>before test samples are created. In other words, if we can't create 
>>a test samples because we think there is an issue with a technique 
>>or failure, where do we document this? This would require a 
>>separate list (i.e. separate from the last column of the Test 
>>Sample Status List).
>Good point. However, right now we are not actively developing test 
>samples (only reviewing existing ones). I suggest we postpone this 
>discussion until we start actively developing test samples.


>>Vangelis also pointed out that there may be more than one issue per 
>>test sample. In the Wiki, I think that this can be addressed by 
>>having more than one link in the last column of the Test Sample 
>>Status List [3].
>>This also reminds me that we should give each issue a unique identifier.
>It has a URI -is this sufficient for now?

For now, yes. But the wiki page for the issue could also have an ID 
in the title (i.e. the last part of the URL, if the URLs for issues 
follow the same convention).

>>If or when we move to a test case management system such as Mozilla 
>>Testopia, we will have to look into this again. We need to know not 
>>only what issues are related with a certain test sample, but also 
>>which test samples  are related with an issue, so that we know 
>>which test samples can be reopened by the task force when an issue 
>>has been closed by the WCAG WG.
>It seems to me that we may need to tap into the WCAG Bugzilla...
>>Regarding the attributes "complexity" (on the testCase element) and 
>>"primary" (on the rule element): the proposal was about default 
>>values in TCDL 2.0, not fixed values. However, the script that will 
>>automate the structure review will check that the values are 
>>"atomic" and "yes", respectively, if the attributes are present.
>Any volunteers to work on this script?

I gave myself an action item for this last week. I hope I'll find 
time to work on it on Thursday and Friday.

Best regards,


>>[2] http://www.w3.org/2006/tsdtf/IssuesTemplatePage
>>[3] http://www.w3.org/2006/tsdtf/TestSampleStatusList
>   Shadi
>Shadi Abou-Zahra     Web Accessibility Specialist for Europe |
>Chair & Staff Contact for the Evaluation and Repair Tools WG |
>World Wide Web Consortium (W3C)           http://www.w3.org/ |
>Web Accessibility Initiative (WAI),   http://www.w3.org/WAI/ |
>WAI-TIES Project,                http://www.w3.org/WAI/TIES/ |
>Evaluation and Repair Tools WG,    http://www.w3.org/WAI/ER/ |
>2004, Route des Lucioles - 06560,  Sophia-Antipolis - France |
>Voice: +33(0)4 92 38 50 64          Fax: +33(0)4 92 38 78 22 |

Christophe Strobbe
K.U.Leuven - Departement of Electrical Engineering - Research Group 
on Document Architectures
Kasteelpark Arenberg 10 - 3001 Leuven-Heverlee - BELGIUM
tel: +32 16 32 85 51

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
Received on Tuesday, 17 April 2007 12:27:49 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:06:00 UTC