Re: scope of the Methodology (was Re: "website" vs "web content" vs other (was Re: Short name for Methodology))

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.

This may have been agreed. I just wonder what remains as practical 
operational value for evaluators wanting to use the methodology in real 
cases, with real sites. Is the idea that the methodology just 
establishes a blueprint that would then be fleshed out / operationalised 
by actors from the target audience in more hands-on procedures?
>
> 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
>>>>>>>> ---------------------------------------------------------------
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>


-- 
---------------------------------------------------------------
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
---------------------------------------------------------------

Received on Tuesday, 18 October 2011 10:06:00 UTC