- From: RichardWarren <richard.warren@userite.com>
- Date: Tue, 22 Nov 2011 15:54:38 -0000
- 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 UTC