Re: methodology and method

Hi Detlev,

Just to understand what you mean by "rationale": are you suggesting that 
Eval TF develops a document explaining why it is important to evaluate 
websites for accessibility? This is not in the initial plan.

Best,
   Shadi


On 25.10.2011 22:08, Detlev Fischer wrote:
> I think the rationale (methodology) needs to be well argued and
> referenced and cannot really be very short. It is just a type of
> document that has a different purpose and audience compared to a
> succinct procedural instruction. The latter should be optimised for the
> practitioner tackling a website and should have little or no theoretical
> ballast.
>
> Quoting Shadi Abou-Zahra <shadi@w3.org>:
>
>> 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)
>>
>>
>
>
>
> --
> ---------------------------------------------------------------
> 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 Wednesday, 26 October 2011 07:25:44 UTC