Re: methodology and method

Hi Detlev,

I'm not sure what the others think but I'm not convinced we need two 
documents. The "rationale, audience & scope, rationale of sampling" 
sections should probably be very short to set the scene for the main 
sections but maybe this is unclear from the table of contents alone.

Best,
   Shadi


On 25.10.2011 09:45, Detlev Fischer wrote:
> Hi Shadi, hi all,
>
> I made a suggestion a while ago to decouple the methodology (rationale)
> from the method.
>
> * Methodology: rationale, audience & scope, rationale of sampling
> and sampling methods, measurement of score / tolerances,
> references etc.
>
> * Method: a usable procedure for the actual testing of websites, e.g.:
> - make entry check (site applicable for testing)
> - select WCAG level applied (A, AA, AAA)
> - define page sample, select states and processes
> - run through procedure proper, with checkpoints based on WCAG
> success criteria and all checks needed to test whether the sites
> meets them - which in case of 1.1.1 and 1.3.1 probably means
> several checkpoints
> - generate report and, if applicable, conformance statement
>
> The reason is simply that the procedure gets lost in the draft Table of
> Contents. We also need to think from a point of view of the users of the
> method.
>
> Any comments?
>
> Detlev
>
> Am 18.10.2011 11:59, schrieb Shadi Abou-Zahra:
>> Hi Detlev,
>>
>> I believe we agreed that the Methodology would explain how to use WCAG
>> 2.0 Techniques for evaluating web page samples rather than to duplicate
>> them or to create synthesized versions of them.
>>
>> If we go down that route we risk re-interpreting WCAG or running into
>> maintenance issues for chasing web technologies as they are released.
>>
>> I think we should, as far as possible, decouple the Methodology from the
>> detailed "alt-text checking"-level; this is already covered by WCAG.
>>
>> Having said that, I can imagine improvements to the "How to Meet WCAG2"
>> quick reference [1], to better address the need of evaluators rather
>> than developers. For example by organizing the Techniques thematically
>> rather than by Success Criteria. However, this would be separate work.
>>
>> [1] <http://www.w3.org/WAI/WCAG20/quickref/>
>>
>> Regards,
>> Shadi
>>
>>
>> On 18.10.2011 11:24, Detlev Fischer wrote:
>>> Am 18.10.2011 09:14, schrieb Shadi Abou-Zahra:
>>>> Hi Detlev,
>>>>
>>>> On 18.10.2011 08:39, Detlev Fischer wrote:
>>>>> Hi Shady,
>>>>>
>>>>> I am still not sure how we can clearly delineate the difference
>>>>> between
>>>>> the wider term "web content" (as in WCAG) and "website" as
>>>>> explained on
>>>>> - <http://www.w3.org/WAI/ER/methodology-reqs/#website>
>>>>
>>>> Agree, this is a challenge that we need to address.
>>>>
>>>>
>>>>> Maybe we should clearly state in the definition whether "website"
>>>>> includes any content offered via plugin technologies like Flash?
>>>>
>>>> As I understand it, "website" includes any web content as defined by
>>>> WCAG 2.0, which would include Flash and other web technologies.
>>>>
>>>>
>>>>> Thisa has practical implications. For example, if Flash would be
>>>>> included, the testing procedure would then either have to be *very*
>>>>> general (actually more general than in many tests of techniques, which
>>>>> do reference tools like aDesigner2) or fork depending on HTML, FLASH,
>>>>> etc.
>>>>
>>>> I'm not sure I understand this rationale. There are already WCAG 2.0
>>>> Techniques for Flash. Maybe not yet a complete set but enough to show
>>>> how the Methodology would utilize existing WCAG 2.0 Techniques.
>>>
>>> I guess the procedure would either reference, as planned, tests in
>>> individual techniques (HTML, CSS, Flash, etc) which means it would be
>>> very bitty and carry a lot of redundancy, or it would offer a practical
>>> synthesis from a hands-on point of view and thereby, add practical value
>>> for testers. When checking for alt texts, for example, there will be
>>> many applicable techniques which are often mutually exclusive. If I use
>>> "list images" in WAT to trundle through the images of a web page and
>>> check whether alt texts descripe content (unlinked images), indicate
>>> link target or purpose (linked images) or are empty (decorative images),
>>> the economic procedure is to synthesize the assessment as you go through
>>> the list. No one would *actually* step through the atomic tests again
>>> and again. It would also be disruptive from an operational perspective.
>>> You want to have *one* page which tells you what to do and how to assess
>>> the instances you find (for some complex SC like 1.1.1 and 1.3.1, it may
>>> be several, of course).
>>>
>>> So back to my original rationale:
>>>
>>> Either the test procedure is generic and says "Check all images opn the
>>> page to verify that the alt attribute is present and appropriate" which
>>> hardly goes beyond the text of WCAG Guideline 1.1. and is therefore of
>>> questionable merit, or it would present some sort of decision tree which
>>> recommends a sequence or path through options and thereby synthesizes
>>> the atomic tests necessary to check for conformance to a particular SC.
>>>
>>> Now, if we deal with HTML/CSS/JS content but also FLASH content, this
>>> might then apear as a choice at some point the decision tree: you check
>>> if FLASH is used, fork to applicable Flash tests (or a procedure
>>> syntheizing tests), the return to check HTML (just as an example). It
>>> just makes an already complex HTML-oriented test procedure still more
>>> complex.
>>>
>>> Just as an aside: in BIT-Test we deal with this problem in a 'silo
>>> approach': we (will) offer separate WCAG-based tests for different media
>>> (HTML/CSS/JS, PDF, maybe some day Flash).
>>>
>>> I personally think (and I have said this before) that a test procedure
>>> that integrates atomic tests and offers advice regarding the success of
>>> failure of instances checked is the actual added value in practical
>>> terms.
>>>
>>> Detlev
>>>>
>>>> Best,
>>>> Shadi
>>>>
>>>>
>>>>> Regards,
>>>>> Detlev
>>>>>
>>>>> Am 17.10.2011 15:15, schrieb Shadi Abou-Zahra:
>>>>>> Dear Detlev, All,
>>>>>>
>>>>>> On 17.10.2011 10:15, Detlev Fischer wrote:
>>>>>>> I have now fully caught up with the discussion of the term "website"
>>>>>>> and
>>>>>>> I realise it can be (or has been) defined to include web apps etc.
>>>>>>
>>>>>> Correct:
>>>>>> - <http://www.w3.org/WAI/ER/methodology-reqs/#website>
>>>>>>
>>>>>>
>>>>>>> Still, since the term "website" has been avoided in the title of
>>>>>>> WCAG
>>>>>>> and also carries connotations of a traditional hierachical site, ist
>>>>>>> seems more congenial to me to use "Web content" instead (even if it
>>>>>>> makes the acronym still thornier).
>>>>>>
>>>>>> It is not about the acronym but rather about the scope of WCAG versus
>>>>>> that of the Methodology. Web content is used to build websites. WCAG
>>>>>> applies to any web content while our Methodology is limited to
>>>>>> websites.
>>>>>>
>>>>>> I think we should either use the term "website" to denote static and
>>>>>> dynamic web pages, web applications, intranets, mobile sites, etc, or
>>>>>> come up with another term that applies to websites in their entirety.
>>>>>>
>>>>>> Regards,
>>>>>> Shadi
>>>>>>
>>>>>>
>>>>>>> Detlev
>>>>>>>
>>>>>>> Am 17.10.2011 08:40, schrieb kvotis@iti.gr:
>>>>>>>> Hello everyone
>>>>>>>>
>>>>>>>> i aggree with the following comment of Detlev and this was also my
>>>>>>>> comment
>>>>>>>> to a previous mail. I cannot understand why we are refereeing
>>>>>>>> only to
>>>>>>>> Websites. I think that we need a more general term including also
>>>>>>>> Web
>>>>>>>> applications, Mobile Web applications,etc...
>>>>>>>>
>>>>>>>> regards
>>>>>>>>
>>>>>>>> kostas
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Hi everyone,
>>>>>>>>>
>>>>>>>>> back from holidays, I am trying to catch up with discussions now.
>>>>>>>>>
>>>>>>>>> I do not mind WAEM even though I do not think it is particularly
>>>>>>>>> easy
>>>>>>>>> to pronounce (other then spelling out double-U - E - A - M).
>>>>>>>>>
>>>>>>>>> I have some concern regarding the W for "website", as in the
>>>>>>>>> current
>>>>>>>>> full title
>>>>>>>>> "Website Accessibility Evaluation Methodology". The "WC" of WCAG
>>>>>>>>> sounds a lot more general than the term "website". This also
>>>>>>>>> relates
>>>>>>>>> to the important comments by Aaron Leventhal regarding the
>>>>>>>>> scope of
>>>>>>>>> the methodology, tool independence, and the possible need to cover
>>>>>>>>> different web content and UA scenarios.
>>>>>>>>>
>>>>>>>>> Is what we develop here focused on websites and not on things like
>>>>>>>>> web
>>>>>>>>> apps for mobile UAs? If we want to be as general as WCAG we might
>>>>>>>>> need
>>>>>>>>> to change the full name of the methodology and accordingly, the
>>>>>>>>> acronym.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Detlev
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Zitat von "Velleman, Eric"<evelleman@bartimeus.nl>:
>>>>>>>>>
>>>>>>>>>> Dear all,
>>>>>>>>>>
>>>>>>>>>> We decided in the call to discuss the short name in the list.
>>>>>>>>>> Below
>>>>>>>>>> are some short names from the discussions we had sofar and a
>>>>>>>>>> proposed shortlist of requirements:
>>>>>>>>>>
>>>>>>>>>> Requirements for a short name:
>>>>>>>>>> - It should be short
>>>>>>>>>> - Easy to pronounce
>>>>>>>>>> - Clear to all what it means (selfexplanatory)
>>>>>>>>>> - Be about the methodology
>>>>>>>>>>
>>>>>>>>>> Shortnames (Make your choice or add new ones):
>>>>>>>>>> - SiteAccess
>>>>>>>>>> - WCAG-Method
>>>>>>>>>> - WCAG-EM
>>>>>>>>>> - WAEM (really using the title)
>>>>>>>>>> - WCAG-Check
>>>>>>>>>> - AccessSite
>>>>>>>>>> - WCAG-Site
>>>>>>>>>> - AccessCheck
>>>>>>>>>> - SiteCheck
>>>>>>>>>> - CheckSite
>>>>>>>>>> - WAMBAM
>>>>>>>>>> - WAME
>>>>>>>>>> - MCEWA
>>>>>>>>>> - CEWA
>>>>>>>>>> - CEW2WCAG2
>>>>>>>>>> - UWEM
>>>>>>>>>> - SITE
>>>>>>>>>> - MAWA
>>>>>>>>>> - MDWC
>>>>>>>>>> - EWAMAC
>>>>>>>>>> - EMAWC
>>>>>>>>>> - WEM
>>>>>>>>>>
>>>>>>>>>> Kindest regards,
>>>>>>>>>>
>>>>>>>>>> Eric
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> ---------------------------------------------------------------
>>>>>>>>> Detlev Fischer PhD
>>>>>>>>> DIAS GmbH - Daten, Informationssysteme und Analysen im Sozialen
>>>>>>>>> Gesch?ftsf?hrung: Thomas Lilienthal, Michael Zapp
>>>>>>>>>
>>>>>>>>> Telefon: +49-40-43 18 75-25
>>>>>>>>> Mobile: +49-157 7-170 73 84
>>>>>>>>> Fax: +49-40-43 18 75-19
>>>>>>>>> E-Mail: fischer@dias.de
>>>>>>>>>
>>>>>>>>> Anschrift: Schulterblatt 36, D-20357 Hamburg
>>>>>>>>> Amtsgericht Hamburg HRB 58 167
>>>>>>>>> Gesch?ftsf?hrer: Thomas Lilienthal, Michael Zapp
>>>>>>>>> ---------------------------------------------------------------
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>

-- 
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, 25 October 2011 19:32:37 UTC