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

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

From: Shadi Abou-Zahra <shadi@w3.org>
Date: Wed, 19 Oct 2011 17:32:32 +0200
Message-ID: <4E9EED90.1020308@w3.org>
To: Detlev Fischer <fischer@dias.de>
CC: public-wai-evaltf@w3.org
Hi Detlev,

On 18.10.2011 12:05, Detlev Fischer wrote:
> 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?

Hopefully this will not be necessary.

The Methodology will provide a procedure around WCAG 2.0. In addition, 
there is room for improving the How to Meet WCAG 2.0 quick reference [1] 
(or develop a similar interface) to be more geared for evaluators. It is 
planned WAI work [2] to be done through the WAI-ACT Project [3].

[1] <http://www.w3.org/WAI/WCAG20/quickref/>
[2] <http://www.w3.org/WAI/ER/2011/eval/#supporting>
[3] <http://www.w3.org/WAI/ACT/>

Best,
   Shadi


>> 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 Wednesday, 19 October 2011 15:33:00 GMT

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