W3C home > Mailing lists > Public > public-wai-evaltf@w3.org > November 2011

Re: Comments from WCAG WG

From: RichardWarren <richard.warren@userite.com>
Date: Tue, 22 Nov 2011 15:54:38 -0000
Message-ID: <61649359E2774CB3A6C4C59D7462B83F@DaddyPC>
To: "Shadi Abou-Zahra" <shadi@w3.org>, "Eric Velleman" <E.Velleman@bartimeus.nl>, "Eval TF" <public-wai-evaltf@w3.org>
Dear Shadi and Eval TF,

First my humble apologise for missing so much in the past few weeks. We have 
been having technical and other problems which, hopefully, are now solved.

I feel that the comments from WCAG WG are valid, particularly the comments 
from Michael and Loretta. I also agree with most of your comments (mostly 
editorial) sent on 17th November. However...

I have a problem with the current section 7 -  "Procedure to express the 
scope of the evaluation" -

The examples provided in section 7.1 are presented as conditions instead of 
examples for ways that the scope could be expressed. The purpose of the 
scope statement in the eventual evaluation should be to help future 
evaluators or moderators know what has been evaluated AND also to help users 
know what is compliant, and if appropriate, which parts may not be fully 
compliant and should be treated with care. In this case statements like 
"same look and feel" or "same owner" are not helpful to a blind user!

I suggest a more precise version of section 7

7. Procedure to express the Scope of the evaluation

While the WCAG 2.0 Recommendation focus on webpages, the Evaluation 
Methodology focuses on evaluating the conformance of a website. This means 
that it is important to define what is considered to be part of the website 
and what is not. To be more precise, to define what is part of the coherent 
collection of one or more related web pages that together provide common use 
or functionality. This can include static web pages, dynamically generated 
web pages, and/or web applications.

A clear scope statement ensures that
a) The owner, the evaluation team and any future evaluators or moderators 
know exactly what was included in the evaluation and what was not.
b) Users of the website can distinguish from the URI and any link text which 
parts are compliant and which are not.

7.1 Key functionalities
The primary purpose of the website should be defined. This sets the context 
of the evaluation. It is important that any exceptions (see 7.3 below) do 
not prevent the website from performing this function in a compliant way.

7.2 Base URI
The use of the URI is the clearest way to define the scope of an evaluation. 
The base URI is the most appropriate starting point. This would normally be 
a domain name such as mysite.com, but it could be a subsection such as 
mysite.com/education/. If everything within that domain or subdomain is to 
be included in the evaluation then that single statement is sufficient.

7.3 Exceptions
Where part of a site or sub-site is to be excluded from the evaluation it is 
important to clearly state the relevant descriptions and URI's of sections 
to be excluded or included. The decision regarding whether to specify the 
inclusion or exclusion areas will depend upon the size and detail of the 
part to be excluded or included. In addition to the URI the 
inclusion/exclusion statement should include a text description. For example 
"The application process initiated by the form at 
mysite.com/forms/application/appform.php is excluded from this evaluation"

7.4 Complete Processes
Whilst it is desirable to test individual components of an application 
during development this approach is not supported by this evaluation 
methodology. If any part of a process is to be excluded from the evaluation 
then the whole process should be excluded.

7.5 If the overall evaluation process is to be divided into teams of 
evaluators (e.g. for a large site) then each team will have its' own 
specific scope statement for the relevant task in hand. A single, combined, 
meaningful scope statement must also be prepared to cover the whole 
evaluation.


I also have suggestions for sections 8 and 9 but will send those separately 
to avoid confusion and give me more time to refine them.

Regards

Richard







-----Original Message----- 
From: Shadi Abou-Zahra
Sent: Thursday, November 17, 2011 10:09 PM
To: Eric Velleman ; Eval TF
Subject: Comments from WCAG WG

Dear Eric, Eval TF,

Ref: <http://www.w3.org/2002/09/wbs/35422/20111117misc/results>

WCAG WG provided comments on the current Methodology Editors Draft. In
general there is a sentiment that it may be too early to publish the
document as-is, which is in-line with what others have expressed on
today's Eval TF call. I think it is useful feedback that can help us
focus on how we are framing our work for public consumption.

Best,
   Shadi

-- 
Shadi Abou-Zahra - http://www.w3.org/People/shadi/
Activity Lead, W3C/WAI International Program Office
Evaluation and Repair Tools Working Group (ERT WG)
Research and Development Working Group (RDWG) 
Received on Tuesday, 22 November 2011 15:55:07 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:52:12 GMT